Things are actually worse than they seem. As a matter of fact, LAME should only be invoked with a handful of simple "master" options (like -V4), each of which activates myriads of internal encoder parameters. Manually setting those parameters through "advanced" switches will disrupt the carefully tuned balance between the different encoder parameters, and result in substandard MP3 files. See the LAME man pages and also http://wiki.hydrogenaudio.org/index.php?title=LAME
Now, the problem is, the gstreamer LAME plugin implements an large number of these "advanced" switches, and sets them all to a default value, thereby completely overriding LAME's normal mode of operation. A list of these options can be obtained by typing: gst-inspect-0.10 lame The developers of gst-plugins-ugly are even aware of this, judging by the gstlame.c source code, which is ridden with comments like this: /* FIXME 0.11: Remove all properties except the useful ones. Nobody knows what most * properties are doing and they're intended for LAME developers only. */ As a demonstration, I tried to find a combination of gstreamer lame settings that reproduce the behavior of invoking standalone LAME. After half a day of trying, I gave up. Conclusion: gstlame.c is broken. If you want to rip CDs to mp3 format on UBUNTU, use rubyripper instead of juicer http://wiki.hydrogenaudio.org/index.php?title=Rubyripper#Installation_on_Ubuntu_8.04 For the die-hards that absolutely insist on using the gstreamer LAME plugin, please be aware that the workarounds in earlier posts in this thread are flawed. Most importantly, by setting vbr-max-bitrate=256 to values lower than 320, they disregard the following recommendation from the LAME man page: The use of -B is NOT RECOMMENDED. A 128 kbps CBR bitstream, because of the bit reservoir, can actually have frames which use as many bits as a 320 kbps frame. VBR modes minimize the use of the bit reservoir, and thus need to allow 320 kbps frames to get the same flexibility as CBR streams. The best combinations of flags I could come up with in my abovementioned experiment were: If your most important goal is to minimize the risk of audible MP3 artefacts: lame name=enc mode=0 vbr=4 vbr-min-bitrate=32 vbr-max-bitrate=320 vbr-quality=0 A good trade-off between file size and quality: lame name=enc mode=1 vbr=4 vbr-min-bitrate=32 vbr-max-bitrate=320 vbr-quality=4 Note that I don't really recommend using these settings, as they don't do LAME any justice. Again, if you are serious about your mp3s, go with rubyripper or wait for the issues to be fixed in gstreamer 0.11 -- Sound Juicer - MP3 quality doesn't change https://bugs.launchpad.net/bugs/195483 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
