GNOME Bugzilla – Bug 519882
VBR encoding not fuctional - Read description
Last modified: 2010-09-26 22:45:50 UTC
Please describe the problem: Bug segnalized here: https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/195483 Bug description [edit] Modifying the audio profile (or creating a new one) for obtainig CD quality mp3s doesn't change the result. I always obtain 128 kbps CBR mp3s. This is the line inserted in "Pipeline GStreamer" in the "editing profile" window: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=6 ! id3v2mux Precisely i've modified the "vbr-quality" value (from 0 to 9) without obtaining any change in the result files. Here are informations of my system: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=7.10 DISTRIB_CODENAME=gutsy DISTRIB_DESCRIPTION="Ubuntu 7.10" Sound Juicer 2.20.1 Gstreamer installed packages with relative versions: gstreamer0.10-alsa 0.10.14-1ubuntu3 gstreamer0.10-esd 0.10.6.0ubuntu4 gstreamer0.10-ffmpeg 0.10.2.2ubuntu1 gstreamer0.10-gnomevfs 0.10.14-1ubuntu3 gstreamer0.10-plugins-bad 0.10.5-4ubuntu1 gstreamer0.10-plugins-bad-multiverse 0.10.5-1 gstreamer0.10-plugins-base 0.10.14-1ubuntu3 gstreamer0.10-plugins-base-apps 0.10.14-1ubuntu3 gstreamer0.10-plugins-good 0.10.6.0ubuntu4 gstreamer0.10-plugins-ugly 0.10.6.0ubuntu2 gstreamer0.10-plugins-ugly-multiverse 0.10.6.0ubuntu1 gstreamer0.10-tools 0.10.14-1ubuntu3 libgstreamer0.10-x 0.10.14-1ubuntu3 libgstreamer-plugins-base0.10-0 0.10.14-1ubuntu3 * I tried to add the "vbr=(0,2,3,4) parameter and the here are the results: - vbr=0 I obtain the same file with CBR 128 kbps (vbr=0 stands for no vbr!) - vbr=2 I obtain a 32 kbps CBR file with incorrect total lenght (7:28 instead of 1:42) (vbr=2 stands for use the old algorithm) - vbr=3 I obtain a 112 kbps CBR file with incorrect total lenght (1:51 instead of 1:42) (vbr=3 stands for use a medium bitrate) - vbr=4 I obtain a 32 kbps CBR file with incorrect total lenght (7:28 instead of 1:42) (vbr=4 stands for use the new algorithm) Same problem using the sound recorder (that uses the same sound profiles of soundjuicer). As mentioned the problem has been discussed for month here: http://ubuntuforums.org/showthread.php?t=608034&highlight=vbr+mp3 Maybe could be connected to this other bug: Steps to reproduce: 1. Modify the vbr-quality parameter (0-9) or try to add the vbr parameter (0,2-4) 2. You'll have the problem Actual results: Expected results: Does this happen every time? Other information:
"Maybe could be connected to this other bug:" Ignore this
First, try using audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=6 ! xingmux ! id3v2mux Without a xing header, there is no easy way to know if the mp3 file is vbr or not nor to know its length. Your testing with CBR files having the wrong duration probably indicates the file is encoded as VBR.
Ok! Now it seems all ok! I think that "xingmux" should be inserted by default to avoid these problems!
Closing this bug since it seems it wasn't an actual bug. Unless it should be changed to "xingmux should be used by default when encoding mp3s" ?
As you can read here: https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/195483 This bug isn't resolved yet and the "xingmux" didn't resolved the problem. There's a more wide discussion in that link and i think you should read that (i'm not so expert to tell you the other users thoughts about this bug). What i've understood it's that it should be a gstreamer code bug but it's better you read all the discussion for your own. Bye
I read the link you gave me as "I'm randomly changing tons of VBR parameters and I don't get whatever result I think I should get", however the resulting files are VBR. xingmux is only useful to get the proper length/bitrate of the vbr files (instead of thinking you got 32kbps CBR files or things like that). I'm only using lame presets and things are working fine. Anyway, if there's indeed a bug, this is a lame gstreamer element bug.
The actual bug is that no matter the command line, the lame gstreamer plugin sets tons of those internal VBR parameters to very uneducated values, instead of leaving this job to lame itself. The flurry of posts with combinations of parameters are just (fruitless) attempts to counteract what lame gstreamer plugin does. Christophe is right that this is a lame gstreamer plugin bug, not a Juicer bug. It is a rather serious one, too; tons of users use this functionality.
OK guys, the ball is in the sound-juicer camp now. The problem in gstreamer was fixed more than a year ago by the creation of a new LAME interface named "lamemp3enc" (the old "lame" one was broken beyond repair), and it's now up to sound-juicer to change its defaults so that it calls the new "lamemp3enc" (with the appropriate new flags) rather than the old "lame" (which still exists and is still broken). There's been some discussion on launchpad about this https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/195483 and the current suggested defaults are: "CD quality": audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=0 quality=2 ! xingmux ! id3v2mux "portable mp3 player quality": audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=0 quality=6 ! xingmux ! id3v2mux "voice quality": audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=1 bitrate=56 mono=true ! xingmux ! id3v2mux Can we please reopen this bug? (I don't seem to be able to do this myself.)
The audio profiles shipped by default comes from gnome-media, see http://git.gnome.org/browse/gnome-media/tree/profiles/gnome-audio-profiles.schemas.in.in?id=155f6ce6463a95146664b08b924d057679ca2f7c However, lame was already replaced by lamemp3enc in http://git.gnome.org/browse/gnome-media/commit/?id=155f6ce6463a95146664b08b924d057679ca2f7c I don't know how the gnome-media maintainers would feel about adding a "portable mp3 player" profile, but it's better to open a new bug for that.
Oops sorry. I go bug the gnome-media people. Wonder where *they* will send me ;)