After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 490372 - Variable bit rates are limited to 160 kbps in higher quality modes.
Variable bit rates are limited to 160 kbps in higher quality modes.
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
Other All
: Normal normal
: 0.10.9
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 494528
Reported: 2007-10-26 03:57 UTC by Travis Jones
Modified: 2008-07-31 14:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20

Description Travis Jones 2007-10-26 03:57:42 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?

Other information:
Comment 1 Mark Nauwelaerts 2008-07-17 08:46:15 UTC
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.
Comment 2 Sebastian Dröge (slomo) 2008-07-31 14:21:04 UTC
This is fixed by

2008-07-29  Sebastian Dröge  <>

        * 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.