GNOME Bugzilla – Bug 490372
Variable bit rates are limited to 160 kbps in higher quality modes.
Last modified: 2008-07-31 14:21:04 UTC
Please describe the problem: I discovered the problem using Sound Juicer in Ubuntu 7.10 to extract a song to a variable bit rate .mp3 file. However, the problem may be perfectly replicated by using gst-launch to convert a .wav file to a VBR .mp3 file. The bit rate range in the encoded file is narrower and lower using the GStreamer LAME plug-in than when using the command line version of LAME (version 3.97). The file size is also smaller. From my testing, it appears the plug-in VBR quality settings simply seem to be limited to a maximum bit rate of 160 kbps. Quality setting 3 produces a file that varies between 154 and 161 kpbs when it should vary between 155 and 195 kbps. Quality setting 0 holds at an almost constant 160 +/- 1 kbps when it should vary between 220 and 260 kbps. Variable bit rate presets are also affected. However, the constant bit rate modes I checked were unaffected by this problem. Steps to reproduce: 1. gst-launch filesrc location=infile.wav ! wavparse ! audioconvert ! lame mode=1 quality=0 vbr=4 vbr-quality=3 ! filesink location=outfile-gstlame.mp3 2. lame -m j -q 0 --vbr-new -V 3 infile.wav outfile-lame.mp3 3. Compare file sizes and observe bit rates using a player such as VLC media player 0.8.6c. Actual results: For a particular song, the GStreamer plug-in encoded file is smaller and has a lower, narrower bit rate range than the file encoded by the command line version of LAME. Variable bit rates will not exceed 161 kbps regardless quality setting with the plug-in. Expected results: The files should be approximately the same size and have the same bit rate profile. For example, the Windows version of LAME and the Linux version both produce files that are only 1 byte different in size. Does this happen every time? Yes. Other information:
You indeed observe correctly that the plugin has a max vbr bitrate of 160. This is controlled by the vbr-max-bitrate property which gst-inspect will show has a default value of 160 (since some time before your report), and incidentally does not affect cbr cases. If you set this higher (e.g. 320 is above your expected values), it should produce the same result.
This is fixed by 2008-07-29 Sebastian Dröge <sebastian.droege@collabora.co.uk> * ext/lame/gstlame.c: (gst_lame_class_init), (gst_lame_init), (gst_lame_chain), (gst_lame_get_default_settings), (plugin_init): * ext/lame/gstlame.h: 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.