GNOME Bugzilla – Bug 482776
vbr mp3 encoding only offers low bitrates
Last modified: 2010-11-22 20:18:15 UTC
Please describe the problem: The setting dialog for lame doesn't offer the right options. Lame vbr doesn't work like vorbis. While the vbr-quality parameter does set a default bitrate target, the default is not reasonable. Quality 0 selects 112 kbit and quality 9 chooses 8 kbit. The ui currently shows quality 9 as best and quality 0 as worst, which is backwards. These defaults are not reasonable as people want to encode at at least 128. The dialog should present a list of preset bit rates instead of quality. This is how quality settings are usually passed to lame on the command line. Banshee should automatically select a vbr-quality that works well with the user's selected bitrate. Banshee should choose a vbr-min-bitrate and vbr-max-bitrate surrounding the user's selected bitrate. For example, if the user selects 190 from the drop down , banshee should pass vbr-quality=4 vbr-min-bitrate=170 vbr-max-bitrate=210 to lame. A full table of suggested settings is available at http://wiki.hydrogenaudio.org/index.php?title=Lame#VBR_.28variable_bitrate.29_settings Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
This bug seems to read as an enhancement request, but I do believe it's pointing out a real problem. In a nutshell, what I'm seeing is that it's not possible to get high-quality VBR encoding using lame. I think this is a showstopper for lame VBR. However, my observations don't exactly match Andy's. First off, it's apparent to me that Banshee is intentionally presenting the scale as 0 (lowest) to 9 (highest), while lame uses 9 (lowest) to 0 (highest). You can see in mp3-lame.xml that the selected value is being subtracted from 9 to convert to lame's scale. I encoded a sampling of songs at a sampling of quality settings, looked at the average bitrates, and calculated a mean for each quality. Note that they don't come close to lining up with the target values from the table in Andy's link. Quailty Average Bitrate (kb/s) Banshee Lame Measured Target 0 9 111 65 3 6 126 115 6 3 138 175 7 2 154 190 8 1 157 225 9 0 158 245 On the other hand, in years of using lame on the command line, I've found that the average bitrates obtained do come quite close to the specified targets. So, my conclusion is that Banshee is not obtaining the same quality rates from lame that you get on the command line. I simply cannot get very low quality nor high quality VBR. In particular, note that how Banshee qualities 7-9 yield practically indistinguishable results. I have no idea if this is a problem with my configuration, a bug in Banshee, a bug in GStreamer, or if it's working as intended. I'm running a fresh install of Ubuntu 7.10 for amd64, with gstreamer0.10-plugins-ugly 0.10.6, banshee 0.13.1, and lame 3.97. Can anyone help me diagnose things further? I disagree with Andy's suggestion that Banshee should be asking for a bitrate and calculating a quality and min and max bitrates from it. I think things should work just as simply as on the command line: you specify a quality and lame automatically does the encoding as it sees fit. We don't want people to think that they're going to get that bitrate exactly, or that they'll get a quality similar to CBR at the selected rate (it will actually be much better).
Sounds like the Importing process should more closely resemble the UI (and the command line equivalent).
I believe Andrew's comment is an misstatement of this problem. Simply, as I observe it, it is impossible to get high quality VBR MP3 encoding in Banshee. I've just reconfirmed this using the latest in Ubuntu (banshee 1.2.1, gstreamer0.10-plugins-ugly-multiverse 0.10.7, and libmp3lame0 3.98), and things are appearing to work exactly as they did when I tried this a year ago. I cannot get an average bitrate of above 158 for VBR encoding, even at the highest quality setting. Using lame on the command line, I get up to 245. Unless I have some kind of configuration problem, that means Banshee is useless for ripping to VBR MP3 at good quality settings. This bug should really get some attention.
I've come across this bug (actually a setting) in several places, and have resolved it. The reason that you can't get above 158kbps vbr is not because gstreamer is failing, but rather because there is an absurd default value for vbr-max-bitrate as is documented at the below link http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/gst-plugins-ugly-plugins-lame.html#GstLame--vbr-max-bitrate To resolve your issue, simply change the default vbr-max-bitrate to a number higher than that you desire. It should really default to 320 (please change this in the code base to end the confusion), but it defualts to 160, which explains your low maximum bitrate. The below pipeline from my SoundJuicer profile demonstrates the solution. audio/x-raw-int,rate=44100,channels=2 ! lame preset=extreme vbr-max-bitrate=320 ! xingmux ! id3v2mux
Addendum to comment: using gst-plugins-lame-0.10.8and lame-3.98.2, setting the vbr-max-bitrate only works when passing presets. If I try to pass a vbr quality level, ie ! lame name=enc mode=0 vbr-quality=2 ! I get a 128 kbps bitrate limited mp3 of the same bitrate regardless of the quality setting, so it appears that the vbr-quality parameter is not being properly passed to lame. Coincidentally 128 is the vbr-mean-bitrate default, but increasing the value of that parameter does not help. Can't help but wonder if this is somehow related. In all of this exploration, wondering why gstreamer can't simply pass the standard lame parameters instead of creating a whole new set of parameters.
Kurt, Thanks for your insights! I think the problem is a combination of crummy defaults and pretty widespread misunderstanding about lame's encoding modes. Here's what I figure... bitrate: only applies to CBR (vbr=0) vbr-quality: only applies to VBR (vbr=2|4) vbr-mean-bitrate: only applies to ABR (vbr=3) vbr-min-bitrate: applies to VBR and ABR (vbr=2|3|4) vbr-max-bitrate: applies to VBR and ABR (vbr=2|3|4) With VBR, you specify a target audible quality and the average bitrate can vary depending on the particulars of the track. With ABR, you you specify a target average bitrate, and the audible quality can vary depending on the particulars of the track. In both cases, you can set upper and lower limits on the bitrate that will be employed for any frame (though, by default, the lower limit is ignored for silence). Note that what Banshee currently does for ABR, specifying a vbr-quality, doesn't make any sense and probably just results in the default vbr-mean-bitrate (128) being used. Unfortunately, I haven't seen any gstreamer docs that explain this well, but if you cross-reference with the man page for lame, it's pretty apparent. By default, lame doesn't set a min or max bitrate for VBR or ABR. In fact, the man page even says the following: The use of -B is NOT RECOMMENDED. A 128 kbps CBR bitstream, because of the bit reservoir, can actually have frames which use as many bits as a 320 kbps frame. VBR modes minimize the use of the bit reservoir, and thus need to allow 320 kbps frames to get the same flexibility as CBR streams. With lame recommending against using -B (which corresponds directly to vbr-max-bitrate), it seems totally wrong that GStreamer would impose it by default. I'm a total GStreamer newbie, but I'm definitely thinking I'll file a bug on this issue. Nonetheless, I've managed to work around this in Banshee by specifying values of 8 and 320 for vbr-min-bitrate and vbr-max-bitrate. I took a look at the XML-based audio profile configuration (described at http://abock.org/2007/01/06/audio-profile-configuration-for-the-masses/), and found it was really easy to fix things up. Nice work Aaron! I'll attach my modified mp3-lame.xml file to this bug.
Created attachment 123524 [details] Improved LAME profile configuration This is my modified mp3-lame.xml, which I think would form the basis for a much better default one. First and foremost, it specifies overrides for the very wrong GStreamer default values of vbr-min-bitrate and vbr-max-bitrate. This allows high and low quality settings to actually have an effect, and makes everything behave like it does, by default, on the command line. Second, I've fixed the way ABR works. Just like CBR, it should allow the user to choose a bitrate from a combo box. As I explained in comment 6, specifying a VBR quality with just ABR isn't correct. Third, I've added the quality property, to ensure that high quality encoding is used even for CBR, as recommended by the lame man page. I can't see any reason not to do this, as there's no size penalty and machines just keep getting faster. Fourth, since I changed ABR to show the bitrate combo box, I thought it was funny to have "VBR" before "Quality" (for VBR) but not "Bitrate" (for ABR, which is actually also a type of VBR). Then I realized it's even funnier to have "VBR" before "Mode", when one option actually *isn't* VBR at all. So, I went for just "Mode", "Quality" and "Bitrate". Since there's no other kind of mode or quality setting on the dialog, I can't see any downside to the shorter names. This is simpler and better for people who aren't already familiar with the abbreviation. I've only changed the English version so far. I'm not sure how translation is usually done, but I think I could take a pretty decent stab at all of the languages except Dzongkha. ;-) I've tested this and it all seems to work perfectly. It's still simple and it's more functional. Personally, the only room I see for improvement would be to use slightly higher quality default values (probably 160 Kbps and quality 6).
I confirm the original bug and the nature of the bug in comment #1. The bug is still present in Banshee 1.4.1.1. I tried using the modified mp3-lame.xml (from comment #7) by changing it with the one present in /usr/share/banshee-1/audio-profiles/, but the new file was not used when running Banshee. How would I use this new .xml to give the settings a test?
Christoph, All I did was drop it into /usr/share/banshee-1/audio-profiles and Banshee started picking it up. You're sure you put it in the right place and that it's not working? You can immediately see it's working if the first control on the Configuring LAME dialog (a combo box) is labeled "Mode:" instead of "VBR Mode:" in English. Also, if you start Banshee from a console window, you'll see output as it runs, including the pipeline it uses for encoding when you rip a CD. If I set to VBR with VBR quality 6 (which gets converted to 3 for lame), I see this: Ripping using encoder profile `MP3 (LAME Encoder)' with pipeline: audioconvert ! lame mode=4 quality=2 vbr=4 vbr-min-bitrate=8 vbr-max-bitrate=320 vbr-quality=3 ! xingmux ! id3v2mux
Created attachment 123722 [details] [review] Update to improved LAME profile configuration (based on Banshee 1.4.1) I updated my improved mp3-lame.xml to be based on the version in Banshee 1.4.1.
Please provide your modifications to mp3-lame.xml as a patch to data/audio-profiles/mp3-lame.xml.in See http://banshee-project.org/contribute/write-code/ for instructions.
Dave, Kurt, et al: thanks for the great work. Dave, if you could provide your changes in the form of a patch, it would be much appreciated (and much sooner committed). If you want, you can just "diff -u original_file modified_file" to produce a patch - don't have to have a subversion checkout.
Created attachment 126404 [details] [review] Patch for my improvements to mp3-lame.xml.in Here's a patch with my improvements to mp3-lame.xml.in. It's actually a pretty small change. Thanks for your interest, and apologies for the delay in doing it.
Assigning to Aaron; this looks fine to me, but he's done a lot more in depth work on the profiles.
Is there anything more I can do to move this along? The patch is simple, but I really think it's important. Without it, Banshee seems not so useful for ripping with MP3 encoding. And I think that's a shame considering how excellent it is in other respects. Or is it just a matter of too many things on Aaron's plate? If so, I can relate, and apologies for the nag.
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address. It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
It'd be nice if this got fixed...
Comment on attachment 126404 [details] [review] Patch for my improvements to mp3-lame.xml.in Since bug #563303 was committed, this patch needs updating against git master. If you could do that and do some more testing, I'd be happy to commit it.
Since it has been requested that we change to using the lamemp3enc element rather than the lame element this might be a good time to collaborate with Raimo who is patching this as we speak: https://bugzilla.gnome.org/show_bug.cgi?id=626285
According to Dave in #626285 this resolved itself due to GStreamer now picking a saner default. Therefore I am closing this, work verifying the quality of files produced using the patch in #626285 would be most welcome.