GNOME Bugzilla – Bug 498004
preset is ignored by lame plugin
Last modified: 2008-07-31 10:12:24 UTC
The lame plugin doesn't properly use the preset option anymore. This is my pipeline:
gst-launch-0.10 filesrc location=cdda.wav ! audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 ! xingmux ! id3v2mux ! filesink location=bla.mp3
This creates a file with an ABR of 159 kBit/s, while the command line lame -V --preset=standard cdda.wav produces a file with an ABR of 279 kBit/s.
This used to be different, as I haven't changed that pipeline for a while.
It is caused by this change:
Just reverting the #if 0 part makes the preset work again. I think it is wrong to initialize the lame encoder with your default.
I'm using 0.10.6 on Gutsy.
Reverting the mentioned change didn't solve it for me.
(changed #if 0 to #if 1 which should be the same)
I also tried to build it with Revision 1.110 of this file, without success.
I have downgraded just libgstlame.so to 0.10.5 and it works fine.
Created attachment 100039 [details] [review]
patch to change the way properties are set.
This patch is probably incomplete, but it demonstrates a different way to modify properties. In the current implementation all parameters are set in gst_lame_setup() whether or not they are being set by gst_lame_set_property(). I just wanted to set lame_set_preset() not touching all other settings. I moved all calls to lame_set_* to gst_lame_set_property(). If I understood correctly, GstLame hold a shadow copy of all properties, which is still useful for reading properties. The way it deals with defaults needs work. Let me know what you think. I'd be happy to make it more complete.
I hope I'm not polluting the bug report, but setting vbr-quality also seems to ignored.
gst-launch-0.10 filesrc location=foo.wav ! audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr-quality=0 ! xingmux ! id3v2mux ! filesink location=foo.mp3
produces a file with an ABR of 128 kbps, whereas lame from the CLI produces a file that has a much higher bitrate (as you would expect for vbr-quality=0). When trying to set the vbr parameters it seems that the bitrate is defaulting to either 128 or 160 kbps.
By setting vbr-min-bitrate you can get bitrates higher than 160, but they are constant bitrates.
This bug is also reported in launchpad bug https://bugs.launchpad.net/gstreamer/+bug/165219 Please don't hesitate to ask for more information.
This bug still exists in Hardy 8.04.1. The default lame parameters used in Sound Juicer and Rhythmbox to encode MP3's using gstreamer are not behaving as expected. When I used preset=stanadard or just vbr-quality=2, the bit rate is WAY too low on the resulting MP3.
But when I use the same parameters on the CLI using LAME, I get reaL VBR MP3's with the right bit rate.
The bug is definitely with libgstlame.so. (If you revert to a previous version, the resulting MP3s are encoded properly with the right bit rates.
PLEASE fix this bug!! Creating MP3's is a common and important task for most GMONE users.
I forgot to add that you may want to look at this thread on the Ubuntu forums:
"The culprit is version 0.10.6 of the gstreamer library file libgstlame.so. To downgrade to a working version (0.10.5) simply downgrade the gstreamer0.10-plugins-ugly-multiverse package from version 0.10.6-0ubuntu1 to version 0.10.5-2."
Once you downgrade the library, the MP3's produced by gstreamer have the right VBR bit rates.
I saw that this bug is still unconfirmed, so I thought I would add a "me too."
Out-of-the-box MP3 encoding on modern distros is in some sense broken because of this bug, because they all seem to use gstreamer.
Ok, this should be fixed now with latest CVS. The problem was, that the min/max/mean bitrates were set which then restricted the bitrates that could be used by the preset.
2008-07-27 Sebastian Dröge <firstname.lastname@example.org>
* ext/lame/gstlame.c: (gst_lame_init):
Use LAME's default for the min/max/mean VBR bitrate. Setting our own
defaults will restrict the bitrate when using a preset in a bad way.
Fixes bug #498004.
Thanks for the update.
Until the bug fix flows down to the distros, the work-around appears to be simple. Just set vbr-max-bitrate=320.
e.g. for preset standard use this the pipeline in Sound Juicer or Rhythmbox:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 quality=1 preset=1001 vbr-max-bitrate=320 ! xingmux ! id3v2mux
It does not look like you need to set or over-ride the vbr-min-bitrate or vbr-mean-bitrate. Just setting vbr-max-bitrate seems to do the trick.
But I could be wrong. If I understand Sabastian correctly, the bug is caused by gstreamer-lame setting the (min-max and mean) bit rates when vbr presets are being used. It should not set the bit-rates when vbr presets are being used. That makes sense. If gstreamer always uses the default gstreamer vbr-max-bitrate of 160, then the resulting mp3's will be a lot smaller than expected (when using preset standard or higher).
Perhaps, you need to set or over-ride the min and mean vbr bitrates as well. The default vbr-min-bitrate is 112. Perhaps, LAME CLI may use an even lower min-bit-rate when executed at the command line with --preset-standard option. In any event, it probably won't make much difference to the final mp3 if you do not over-ride the vbr-min-bitrate (until the bug fix makes it to your distro).
I suspect this bug also occurs if you just use vbr-quality instead of presets. My understanding is that vbr-quality=2 is the same as preset standard when using LAME for the CLI.
Lets hope this bug fix makes it way to the distros soon so we don't have to do work-arounds!
Even with the patch the bitrate of the file created by the command in the initial report and lame --preset standard differ. In my test, lame created a file with a bitrate of ~174kb/s, while gst's file has 181kb/s. I guess the lame library is still initialized in a slightly different way.
With the patch or with Rob's workaround? The minimal bitrate with Rob's workaround is still 112 while lame's default is 96 or 64 or something.
I didn't use Rob's workaround, just the patch from CVS HEAD.
Ok, I'll take another look later. Thanks :)
I guess it was the quality setting which didn't have the default value.
Now we're using the default value almost everywhere:
2008-07-29 Sebastian Dröge <email@example.com>
* ext/lame/gstlame.c: (gst_lame_class_init), (gst_lame_init),
(gst_lame_chain), (gst_lame_get_default_settings), (plugin_init):
Get the defaults settings of LAME in the plugin initialization
function and return FALSE here if something goes wrong. This removes
the hacky failing instance init function.
Use LAMEs default value for all settings instead of overwriting some
of them. Overwriting some of them gives unexpected results if one only
sets a preset. Fixes bug #498004.
Please check if everythnig works fine for you with latest CVS :)
I have tested this and I'm happy now, thanks.
I think I know what is really causing the problem.
gst-plugins-ugly is NOT using the SAME default vbr min and max bitrate values as the LAME CLI.
In Terminal, if you run "lame --longhelp", you will see what default vbr values LAME uses. Here are LAME's default value:
-b VBR minimum bitrate (default: 32)
-B VBR maximum bitrate (default: 320)
However, for some unknown reason the developers of gst-plugins-ugly are using different default values as follow:
vbr-min-bitrate -- (default 112)
vbr-max-bitrate -- (default 160).
I don't think specifying --preset-standard on the LAME CLI changes the vbr min and max bitrate values. And it looks like gst-ugly also does not attempt to change its brain-dead default values when preset=1001 (ie preset standard) is used. As a result, a lot of people complain that gst-plugins-ugly only gives them a MP3 file with a maximum bitrate of 160 when any of the presets are used.
P.S. It looks like --preset standard on the LAME CLI, just sets the vbr quality to 2. So "lame --preset standard in.wav out.mp3" is the same as "lame -V 2 in.wav out.mp3"
To test this theory, I tried the following pipeline:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc quality=3 vbr=4
preset=1001 vbr-min-bitrate=32 vbr-max-bitrate=320 ! xingmux ! id3v2mux
The resulting mp3 has almost the same bitrate (e.g. 181 bits/s) as one produced by the lame CLI using "lame --vbr-new --preset stanadard in.wav out.mp3" (182 bits/s)
It is very strange that NOT ONLY one must over ride the brain dead vbr-min-bitrate and vbr-max-bitrate values to get gst-plugins-ugly to work properly with presets BUT one must also over ride the default quality value (5) with the proper one (e.g. 3) used by the preset.
I think that this might be another bug. I suspect that the REAL default value for q or quality on the LAME CLI is 3 and not 5 (as stated in the LAME help). As a result, the default value for quality in gst-plugins-ugly should be 3 and NOT 5. But you may want to check with the LAME developers.
Another strange thing occurs if you replace preset=1001 with vbr-quality=2 in the above pipeline. They should produce the same mp3's but they don't. vbr-quality=2 and quality=3 gives you slightly higher bitrates. the LAME CLI does not exhibit this behaviour.
To summarize, I do hope that the fix in the CVS for gst-plugins-ugly has changed the default values for vbr-min-bitrate and vbr-max-bitrate to the SAME default values as the LAME CLI. That will fix a lot of problems. But the behaviour of the "preset= " option in the gstreamer pipeline needs to be investigated further. It looks like the gst-plugins-ugly is using the wrong default value for quality. (It looks like it should be 3 and not 5). That may fix the problem.
(In reply to comment #18)
> To summarize, I do hope that the fix in the CVS for gst-plugins-ugly has
> changed the default values for vbr-min-bitrate and vbr-max-bitrate to the SAME
> default values as the LAME CLI. That will fix a lot of problems. But the
> behaviour of the "preset= " option in the gstreamer pipeline needs to be
> investigated further. It looks like the gst-plugins-ugly is using the wrong
> default value for quality. (It looks like it should be 3 and not 5). That may
> fix the problem.
Yes, that's what the patch does: "Use LAMEs default value for all settings instead of overwriting some of them."
> Yes, that's what the patch does: "Use LAMEs default value for all settings
> instead of overwriting some of them."
That is great news. But I am not sure whether the "lame --longhelp" accurately lists all of the LAME default values.
For example, "lame --longhelp" states that the default value for "q" (or "quality" in gstreamer lame) is 5. But whenever I run lame, a different default value of 3 is used for q. If possible, I would check with the LAME developers on what the right default value for q actually is.
(In reply to comment #20)
> > Yes, that's what the patch does: "Use LAMEs default value for all settings
> > instead of overwriting some of them."
> That is great news. But I am not sure whether the "lame --longhelp" accurately
> lists all of the LAME default values.
> For example, "lame --longhelp" states that the default value for "q" (or
> "quality" in gstreamer lame) is 5. But whenever I run lame, a different
> default value of 3 is used for q. If possible, I would check with the LAME
> developers on what the right default value for q actually is.
Well, the default values are what lame tells you for every setting after you've initialized it for encoding without changing any settings ;) So there's no problem