[gstreamer-bugs] [Bug 498004] preset is ignored by lame plugin

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Tue Jul 29 16:33:25 PDT 2008


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=498004

  GStreamer | gst-plugins-ugly | Ver: 0.10.7




------- Comment #18 from Rob  2008-07-29 23:33 UTC -------
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.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=498004.




More information about the Gstreamer-bugs mailing list