Sound Juicer - MP3 quality doesn't change

[Srik]

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

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Srik (maxpower-email)]

Having only one cd-dvd reader on my pc, i don't think i could test the extraction and encoding of cd audio track in mp3 while using the live cd! May i use a virtual machine? Is there no one that could test this bug?

[Srik (maxpower-email)]

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

[Cliff Hall (12barz)]

I have had the same experience Srik describes. This has been batted around for months on the forums at http://ubuntuforums.org/showthread.php?t=608034&highlight=vbr+mp3. VBR mp3 encoding just doesn't work in sound juicer. I have the same problem that Srik has in that I only have one cd/dvd drive and can't test the bug using a live cd. Can't anybody help with this? Vbr mp3 encoding is an important function.

[Srik (maxpower-email)]

Same problem using the sound recorder (that uses the same sound profiles of soundjuicer).

[Pedro Villavicencio (pedro)]

May you forward it upstream to bugzilla.gnome.org since you're facing the issue? I can't reproduce it here. You can look to https://wiki.ubuntu.com/Bugs/Upstream/GNOME for filing instructions. thanks in advance.

[Srik (maxpower-email)]

Forwarded. They provided a solution: adding the "xingmux" parameter to the "Pipeline Gstreamer". I think this parameter should be inserted by default in the profile for cd-quality mp3!!!

[Cliff Hall (12barz)]

Does that work for you? Are you using vbr? I've tried it and it didn't
work for me.

On 3/5/08, Srik <email address hidden> wrote:
>
> Forwarded. They provided a solution: adding the "xingmux" parameter to
> the "Pipeline Gstreamer". I think this parameter should be inserted by
> default in the profile for cd-quality mp3!!!
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Srik (maxpower-email)]

This is the functional line:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux

I've specified to use the new algorithm (vbr=4) and i've setted min and max bitrate. Try this!

[Cliff Hall (12barz)]

I'll give it a try as soon as I get a CD to burn. I'm working out of town
without my CD's. I'll let you know what happens. Thanks.

On 3/5/08, Srik <email address hidden> wrote:
>
> This is the functional line:
> audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4
> vbr-quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux
>
> I've specified to use the new algorithm (vbr=4) and i've setted min and
> max bitrate. Try this!
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Cliff Hall (12barz)]

I tried it, except I changed vbr-max-bitrate=192 to vbr-max-bitrate=256.
The cd ripped just fine, but Amarok reports a bitrate of 128 for all the
tracks. This is something that's definitley broken in g-streamer as is well
documented in the ubuntu forums, it's definitly not fixed, I don't know how
to fix it, and the bug guys just don't seem interested. This is very
peculiar since variable bit rate encoding of mp3's is such an important
function. Note that Amazon.com (which incidentally has recently released a
linux version of it's downloader) encodes all it's DRM-free tracks with vbr
avg bitrate 256. Did you check to see what bitrates your software is
reporting for the cd's you ripped?

On 3/5/08, Srik <email address hidden> wrote:
>
> This is the functional line:
> audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4
> vbr-quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux
>
> I've specified to use the new algorithm (vbr=4) and i've setted min and
> max bitrate. Try this!
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Srik (maxpower-email)]

Sorry, i had no time during these days. I will check my mp3s and i'll report here the results!

[jorns (jorn-skorstad)]

I tried the above mentioned sentence:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux

and changed 192 with 256. For me it worked like a charm, it now makes VBR mp3's between 160-256 kbps.
My software is the same, Ubuntu 7.10 and Sound Juicer 2.20.1

[Cliff Hall (12barz)]

I wonder how to even begin figuring out what my problem is.

On Sun, Mar 23, 2008 at 11:17 AM, jorns <email address hidden> wrote:

> I tried the above mentioned sentence:
>
> audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-
> quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux
>
> and changed 192 with 256. For me it worked like a charm, it now makes VBR
> mp3's between 160-256 kbps.
> My software is the same, Ubuntu 7.10 and Sound Juicer 2.20.1
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Cliff Hall (12barz)]

I should have made my plaintive query about what I should do next a "reply
to all."

On Sun, Mar 23, 2008 at 9:15 PM, Cliff Hall <email address hidden> wrote:

> I wonder how to even begin figuring out what my problem is.
>
>
> On Sun, Mar 23, 2008 at 11:17 AM, jorns <email address hidden> wrote:
>
> > I tried the above mentioned sentence:
> >
> > audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-
> > quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux
> >
> > and changed 192 with 256. For me it worked like a charm, it now makes
> > VBR mp3's between 160-256 kbps.
> > My software is the same, Ubuntu 7.10 and Sound Juicer 2.20.1
> >
> > --
> > Sound Juicer - MP3 quality doesn't change
> > https://bugs.launchpad.net/bugs/195483
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>

[goto (gotolaunchpad)]

I've had the same experience as Cliff Hall; however I'm using SoundJuicer 2.22 with Ubuntu 8.04 (beta).

The xingmux parameter makes no difference to how the CD rips--I still end up with 128 cbr files instead of 160-192 vbr or 160-256 vbr :-(

[Cliff Hall (12barz)]

This is really interesting. There are lots of posts about this on Ubuntu
Forums. Look here:

http://ubuntuforums.org/showthread.php?t=608034&highlight=vbr+mp3

Several of us are getting low quality cbr's no matter what we do with sound
juicer. Jorns, however, replied that it worked just fine for him and he was
able to get genuine vbr files. He writes:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
jorns to me
show details Mar 23 (13 days ago)
 Reply

I tried the above mentioned sentence:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-
quality=0 vbr-min-bitrate=160 vbr-max-bitrate=192 ! xingmux ! id3v2mux

and changed 192 with 256. For me it worked like a charm, it now makes VBR
mp3's between 160-256 kbps.
My software is the same, Ubuntu 7.10 and Sound Juicer 2.20.1
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

So what makes the difference here? Is there some kind of hardware
variable? Is that possible? I'm using an HP Pavillion dv4000. What about
you other guys who are unable to get soundjuicer to properly juice? (BTW,
I'm using Gutsy with Sound Juicer 2.20.1.)

On Sat, Apr 5, 2008 at 9:14 AM, bugmenot <email address hidden> wrote:

> I've had the same experience as Cliff Hall; however I'm using
> SoundJuicer 2.22 with Ubuntu 8.04 (beta).
>
> The xingmux parameter makes no difference to how the CD rips--I still
> end up with 128 cbr files instead of 160-192 vbr or 160-256 vbr :-(
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[jorns (jorn-skorstad)]

My hardware is an IBM Thinkpad R60. Ubuntu 7.10 and Sound Juicer 2.20.1 as mentioned above.

What is funny in this, i tried another CD now, and now I have lost the choice to make MP3 again. I will have another look at it later today, if something new shows up I will let you know.

[jorns (jorn-skorstad)]

OK, I have ripping back working. I don't know what made it disappear, maybe some package update?

I issued the following command to make it work again:
sudo apt-get install ubuntu-restricted-extras

Setting in Sound Juicer is as before:
(CD Quality, MP3)
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-quality=0 vbr-min-bitrate=160 vbr-max-bitrate=256 ! xingmux ! id3v2mux

[Srik (maxpower-email)]

I've just upgraded to hardy (8.04) and the default line still doesn't give correct vbr mp3s but the suggested line above still resolves the problem,
even changing vbr-max-bitrate to 256 (from 192) gives to me VBR mp3s between 160-256 kbps (checked with nautilus, amarok, easy tag)!

I continue to think that this line should be the default in soundjucer!!

The actual default gstreamer line doesn't give correct vbr mp3s or at least correct tags of these mp3!!

Soundjuicer is the default application for cd-ripping and a lot of people need to rip in mp3 (because of their portable mp3s readers) so it has to do its job correctly!

[Zer0Nin3r (zer0nin3r)]

To verify that VBR is actually working after you have encoded your files you will need to use a media player that will report back to you real time statistics about what is happening during decoding. Programs like Winamp for windows or the Linux version XMMS (I think the project is dead though) will give you the feedback in real time. Also you may use VLC with the media information (ctrl-i).

I've been looking and looking for good information, everyone seems to have a little variation on VBR with Sound Juicer. This is the current setup I'm running and it seems to work. I'm getting ~220k.

---
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-quality=0 vbr-min-bitrate=32 vbr-max-bitrate=256 ! xingmux ! id3v2mux
---
Links of use:
http://ubuntuforums.org/showthread.php?t=839198

http://www.pizon.org/articles/adding-mp3-support-to-gnome.html

http://ubuntuforums.org/showthread.php?t=952807&highlight=Sound+Juicer+options+vbr

Cheers!

[KennoVO (kenno-xs4all)]

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

[Christian Niemeyer (christian-niemeyer)]

@KennoVo: I tried half a day yesterday trying to get different VBR-mp3-filesizes and came to the same conclusion. Thanks for explaining.

For example I tried this:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 quality=2 vbr=4 vbr-quality=3 ! xingmux ! id3v2mux
then checking with VLC's Stream and Media Info... (Ctrl+I) the bitrates and it was just switching aroung 158kbps to 162 kbps. No matter if vbr-quality was "0" or e.g. "4". This is because of the too much default values gstreamer passes to lame, like vbr-min-bitrate, vbr-mean-bitrate and vbr-max-bitrate. Usually with vbr-quality you choose kind of a preset for bitrate measure. Like when using lame on the command line. quality is just how good the general algorithm for encoding is. Even bitrate (for CBR useful) always (!) passes a default value. This is so confusing. ;-)

I tried many gstreamer pipelines with the same song (length 4:19) and always got 4.9 MB or 7.3 MB, no matter how detailed and different my settings were. Though encoding as VBR worked and Rhythmbox and Nautilus getting the lenght right, which is an improvement though.

With this pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 quality=2 vbr=4 vbr-quality=3 ! xingmux ! id3v2mux
I managed to get a filesize of 5.5 MB, which is kind of quality vs. filesize, that I was looking for. Though I'm confused how fast gstreamer is with encoding, but maybe that's because of the pipeline. Grip is much slower. Now I'm wondering if this has any quality issues maybe.

Again the Defaul values you see by "gstreamer-inspect lame" are altogether too much and very counterproductive for the result. Someone knowing if there is a possibility to switch this default values to "none" or "not set"? This would be a good workaround.

Last question: When will gstreamer-0.11 will be released? Google doesn't help me with that question.

PS: Set Importance at least to medium. Though this is a universe/multiverse bug, it is a showstopper for people who want VBR mp3s. Thanks.

[Christian Niemeyer (christian-niemeyer)]

Oops, my second pipeline (which got me a 5.5 MB file) is wrong above, a typo. Here's the correct pipeline:

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=4 vbr-min-bitrate=96 vbr-max-bitrate=320 vbr-mean-bitrate=192 vbr=4 quality=0 ! xingmux ! id3v2mux

With "quality is just how good the general algorithm for encoding is. Even bitrate (for CBR useful) always (!) passes a default value. This is so confusing. ;-)" I meant the bitrate= and quality= values.

[Srik (maxpower-email)]

I've checked my mp3s encoded with the line i suggested using vlc and i found they are ok.
So i've encoded mp3s on an other pc using xubuntu with sound juicer and still i've obtained good vbr mp3s (tried with different min and max bitrate).

[Christian Niemeyer (christian-niemeyer)]

The weird thing is, when you check those vbr mp3s created with sound-juicer in VLC (Ctrl+i there the "statistics"-tab) the vbr-bitrate only varies around 10 kb/s or even less, up and down. Check at the "Input" box the values for "Input bitrate" and "Stream bitrate". This is technically VBR, but not the way VBR is intended. Imho, VBR does have a wide range of bitrate. So the VBR encoding remains somehow useless with sound juicer. I think this happens since gstreamer-0.10.

Maybe someone can write some kind of a hack, that filters the specific useless values that gstreamer passes to lame?

[Doug Shelton (dshelton-san)]

It seems the only way to get gstreamer to work the way you want is to override every one of its settings with something you want. I was finally able to use this pipeline:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr=4 vbr-quality=0 quality=0 vbr-min-bitrate=32 vbr-max-bitrate=320 lowpass-freq=25000 ath-lower=0 ! id3v2mux

to get insane-quality VBR files equivalent to
lame -m stereo -q 0 --vbr-new -V0 --add-id3v2 {infile} {outfile}

I used VLC's statistics feature as suggested above and found these files to have the same stream bitrate and variability with files created by command-line invocation of LAME using the above parameters.

gstreamer definitely needs some way of invoking LAME with only the overrides provided in the pipeline instead of specifiying its own (difficult to decypher) defaults.

[KennoVO (kenno-xs4all)]

@Christian Niemeyer: I believe vbr-mean-bitrate actually requests ABR encoding, which conflicts with vbr-quality=4, the switch that requests VBR encoding.

@tigerdog: Nyquist's theorem dictates that the lowpass frequency needs to be significantly lower than half of the bitrate (44100) to avoid aliasing artefacts (which can be quite severe). I believe standalone Lame internally sets the lowpass to 21000 when asked for CBR 320 (the highest quality available), to 19500 when given -V 0 (the highest VBR quality), and even lower for lower qualities. Anything higher than 21000 is considered unsafe with regard to aliasing.

@everyone: knowing just how many "internal" switches LAME has and how unskillfully the defaults are set in the gstreamer plugin, it is very unlikely to find a gstreamer command line that works as intended and will pass rigorous listening tests. The issues with the above command-lines perfectly illustrate my point. The only way to fix the problem is at code level, and posting command-lines will just distract from this.

[Srik (maxpower-email)]

I want only to say the the bug that i've posted to bugzilla is now "resolved". The understanding or the problem it's far from my informatic knowledges. If you are interested in this bug (like me) you should find interesting the following link:

http://bugzilla.gnome.org/show_bug.cgi?id=519882

My question is "and now, what could we do? (like post bug somewhere else, etc)".
Bye

[KennoVO (kenno-xs4all)]

They rightly marked that bug report "resolved" because (just like here on launchpad) it was filed as a Juicer bug, while it really is a bug in the gstreamer LAME plugin, not in Juicer. The actual bug that causes all our misery is here:
http://bugzilla.gnome.org/show_bug.cgi?id=494528

The problem is just that they're not taking it very seriously.

[KennoVO (kenno-xs4all)]

Seems that I was was a bit too quick on the trigger with my "nobody takes it serious" statement. Sebastian Dröge essentially fixed the bug upstream, and I have good hopes that it won't be long before the fix comes to an Ubuntu repository near you :)

[Srik (maxpower-email)]

I'm happy we have contributed (at least just a bit) to solve this problem! :)
I hope too it will be fixed soon ;)

[Christian Niemeyer (christian-niemeyer)]

Thanks everyone, especially @KennoVO for reporting.

Hopefully we don't have to wait till gstreamer-0.11 is releases and this will just be included in a minor bugfix release of the lame plugin in gstreamer-0.10.

Great news though. :-)

[darkham (darkham)]

Gstreamer staff: please build an official documentation about the syntax of gstreamers pipelines
users can't going crazy for customizing their own sound juicer or something like.

[Daniel Harvey (daniel.harvey)]

This bug is marked as "Fix Released" but I don't see it in the karmic or lucid packages.

[Tristan Hill (stan)]

I'm using a gstreamer pipeline of

audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc quality=0 encoding-engine-quality=2 ! id3v2mux

which appears to behave correctly (gstreamer0.10-plugins-ugly-multiverse version 0.10.12-0ubuntu1 on karmic).

[Cliff Hall (12barz)]

Can you refer me to a source of definitions for these pipeline arguments.
For example, I don't know what "encoding-engine-quality=2!" means. Thanks.

On Tue, Jan 5, 2010 at 4:56 PM, Tristan Hill <email address hidden> wrote:

> I'm using a gstreamer pipeline of
>
> audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc quality=0
> encoding-engine-quality=2 ! id3v2mux
>
> which appears to behave correctly (gstreamer0.10-plugins-ugly-multiverse
> version 0.10.12-0ubuntu1 on karmic).
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Tristan Hill (stan)]

Options available can be seen from "gst-inspect-0.10 lamemp3enc":

Element Properties:
  name : The name of the object
                        flags: readable, writable
                        String. Default: null Current: "lamemp3enc0"
  target : Optimize for quality or bitrate
                        flags: readable, writable
                        Enum "GstLameMP3EncTarget" Default: 0, "quality" Current: 0, "quality"
                           (0): quality - Quality
                           (1): bitrate - Bitrate
  bitrate : Bitrate in kbit/sec (Only valid if target is bitrate, for CBR one of 8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 or 320)
                        flags: readable, writable
                        Integer. Range: 8 - 320 Default: 128 Current: 128
  cbr : Enforce constant bitrate encoding (Only valid if target is bitrate)
                        flags: readable, writable
                        Boolean. Default: false Current: false
  quality : VBR Quality from 0 to 10, 0 being the best (Only valid if target is quality)
                        flags: readable, writable
                        Float. Range: 0 - 9.999 Default: 4 Current: 4
  encoding-engine-quality: Quality/speed of the encoding engine, this does not affect the bitrate!
                        flags: readable, writable
                        Enum "GstLameMP3EncEncodingEngineQuality" Default: 1, "standard" Current: 1, "standard"
                           (0): fast - Fast
                           (1): standard - Standard
                           (2): high - High
  mono : Enforce mono encoding
                        flags: readable, writable
                        Boolean. Default: false Current: false

They generally match definitions on http://lame.sourceforge.net/lame_ui_example.php

[Cliff Hall (12barz)]

Thanks.

On Wed, Jan 6, 2010 at 1:54 AM, Tristan Hill <email address hidden> wrote:

> Options available can be seen from "gst-inspect-0.10 lamemp3enc":
>
> Element Properties:
> name : The name of the object
> flags: readable, writable
> String. Default: null Current: "lamemp3enc0"
> target : Optimize for quality or bitrate
> flags: readable, writable
> Enum "GstLameMP3EncTarget" Default: 0, "quality"
> Current: 0, "quality"
> (0): quality - Quality
> (1): bitrate - Bitrate
> bitrate : Bitrate in kbit/sec (Only valid if target is
> bitrate, for CBR one of 8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128,
> 160, 192, 224, 256 or 320)
> flags: readable, writable
> Integer. Range: 8 - 320 Default: 128 Current: 128
> cbr : Enforce constant bitrate encoding (Only valid if
> target is bitrate)
> flags: readable, writable
> Boolean. Default: false Current: false
> quality : VBR Quality from 0 to 10, 0 being the best (Only
> valid if target is quality)
> flags: readable, writable
> Float. Range: 0 - 9.999
> Default: 4 Current: 4
> encoding-engine-quality: Quality/speed of the encoding engine, this does
> not affect the bitrate!
> flags: readable, writable
> Enum "GstLameMP3EncEncodingEngineQuality" Default:
> 1, "standard" Current: 1, "standard"
> (0): fast - Fast
> (1): standard - Standard
> (2): high - High
> mono : Enforce mono encoding
> flags: readable, writable
> Boolean. Default: false Current: false
>
> They generally match definitions on
> http://lame.sourceforge.net/lame_ui_example.php
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Scott Bronson (bronson)]

The Ubuntu project is far too casual about this data loss bug! If it's not going to get fixed (and given the age of this bug, it appears that it won't) then at least remove the mp3 pipelines from the default Ubuntu install. A computer should never lie to the user about what's happening.

(I just ripped a 15 CDs on Karmic using the default CD Quality MP3 setting and only discovered this bug by chance. Sure enough, everything's 128 bit. Now I get to re-rip them all. What a waste of time...)

[Bruce R (bm007a0030)]

It's nice to be able to offer a solution for a change.
The fault lies not with GStreamer, but with a failure to provide the wrong command string or 'profile' for LAME to execute.
For the CD Quality MP3 Profile, Edit it to read as follows :
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 vbr-min-bitrate=32 vbr-max-bitrate=320 vbr-quality=3 ! id3v2mux
This will result in what I call 'Super MP3' quality, average 171Kbps, ranging from 32-320Kbps, in accordance with another forum audio expert's recommendations, back when I researched sound-juicer as a suitable Linux ripping tool, which was around the time of Ubuntu 7.10 and LinuxMint-4.
As I recall, the mode=1 entry ensures stereo channel separation, the vbr=4 entry ensures correct operation with the old version of LAME then being used, the critical vbr-min and vbr-max commands set the range of compression desired and the quality command merely adds a subtle enhancement,
Note that this also works with other distros, especially PCLinuxOS.
Regarding Scott Bronson's comment, by also setting Preferences to Eject after extracting and Open music folder and running it while using a fast Internet connection for automatic tracks data download, it can be a quite fast process of just putting a CD into the preferences optical drive, clicking on Extract and waiting for the disc to be ejected.

[Bruce R (bm007a0030)]

Sorry, Second sentence should read :
The fault lies not with GStreamer, but with a failure to provide the right command string or 'profile' for LAME to execute.

[Bruce R (bm007a0030)]

Sorry guys, some more information. Having just today re-checked it out, I can advise that for Ubuntu and LinuxMint, you also need gstreamer LAME plugins etc installed, most easily achieved by adding ubuntu-restricted-extras, which I am in the habit of always doing, if only to get MicroSoft Core Fonts installed, to ease cross-platform interoperation.
For the real techies amongst you, gst-inspect lame will then lead you on to the LAME plugin commands that are applicable to that specific implementation of Linux LAME, so have fun !

[Gotit (sca957)]

@Bruce R
My experience is that making changes in Sound Juicer's output format doesn't make any difference in the resulting mp3 quality. I used your setting above and then modified it to have vbr-quality=0 and extracted the same trac off the same CD, both resulting files report the bitrate of 128.

I am running:
Ubuntu 9.04
Lame 3.98
Sound Juicer 2.26.1
Ubuntu restricted extras 31

[Bruce R (bm007a0030)]

@Gotit
Puzzling - I will try to investigate further.
Meanwhile, for your information, the attached picture is from Ubuntu 8.04 era analysis of Sound Juicer encoding results for encoding of 'Jupiter' from Holst's Planet suite.

[Bruce R (bm007a0030)]

Fascinating !
Re-reading the thread I see that folk are using different analysis tools or players to decide what the results are, rather than simply listening to the results with their chosen player.
Such players and tools produce different, sometimes highly misleading reports, such as just blandly reporting an encoded stream to be CBR 128Kbps, when it's actually a VBR stream.
Even VLC Player's Ctrl_I report is misleading !
Back when I originally researched gst-inspect lame to come up with my recommended profile for Sound-Juicer, I was advised to use WinXP-hosted EncSpot, then at version 2.0 Basic, to analyse the results, for comparison with WinXP-hosted CDEX encoding results.
That resulting Histogram is as attached in my Comment to Gotit, above.
Re-running that analysis, there's been a subtle change in results, now reporting VBR average BitRate of only 165 rather than 171, but the revised results are still acceptable when simply dwelling on a track in Nautilus, or better yet when playing in Exaile, whose simple interface I prefer to the complexity of Rhythmbox or Amarok.
However, most players and tools are still providing misleading technical reports on my rigs.
So could it all be down to misleading analysis of results, rather than gstreamer problems ?

[Cliff Hall (12barz)]

The trouble with the misleading reporting by apps theory is that the apps
report expected values correctly when tracks are ripped using Ruby Ripper or
Grip. Seems to point the finger at g-streamer?

On Mon, Jul 12, 2010 at 3:30 AM, Bruce R <email address hidden> wrote:

> Fascinating !
> Re-reading the thread I see that folk are using different analysis tools or
> players to decide what the results are, rather than simply listening to the
> results with their chosen player.
> Such players and tools produce different, sometimes highly misleading
> reports, such as just blandly reporting an encoded stream to be CBR 128Kbps,
> when it's actually a VBR stream.
> Even VLC Player's Ctrl_I report is misleading !
> Back when I originally researched gst-inspect lame to come up with my
> recommended profile for Sound-Juicer, I was advised to use WinXP-hosted
> EncSpot, then at version 2.0 Basic, to analyse the results, for comparison
> with WinXP-hosted CDEX encoding results.
> That resulting Histogram is as attached in my Comment to Gotit, above.
> Re-running that analysis, there's been a subtle change in results, now
> reporting VBR average BitRate of only 165 rather than 171, but the revised
> results are still acceptable when simply dwelling on a track in Nautilus, or
> better yet when playing in Exaile, whose simple interface I prefer to the
> complexity of Rhythmbox or Amarok.
> However, most players and tools are still providing misleading technical
> reports on my rigs.
> So could it all be down to misleading analysis of results, rather than
> gstreamer problems ?
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Bruce R (bm007a0030)]

Grip never used to work at all well, which is why I guess that it's no longer in the current repository. I don't know about Ruby Ripper, which I gather needs creating from source, never a certain outcome process with Ubuntu, success varying between versions.
Meanwhlie, if you are into compilation, why not produce a Lucid deb file for EncSpot, whose tar file was released just before the originators 'closed shop' ?
On the other hand, you could simply add checkmp3 and run it in Terminal against your mp3s, where it provides a better and more comprehensive report than other tools etc that folk have been using and whose report details just happen to completely agree with WinXP-hosted EncSpot analysis of my Sound-Juicer produced VBR files.

[Bruce R (bm007a0030)]

Sorry to be slow to add this comment folks, but it looks as if my original Sound Juicer recommendations haven't been strictly followed, the most common mistake being to insert 'vbr=3' instead of just 'vbr=4' in editing the profile, which de-selects LAME's new VBR algorithm instead of selecting it.
The next most common mistake appears to be not installing the associated GStreamer LAME plugin by installing 'ubuntu-restricted-extras', which sadly gets stalled in installing MScoreTTFonts for some variants of Ubuntu.
Finally, even if folk get all that right, players and other tools can misleadingly report no change from unmodified Sound Juicer CBR, with added 'checkMP3' providing more truthful information.

[Bruce R (bm007a0030)]

Wow, just updating from a LiveDVD session of Maverick Alpha3 to let folk know that, after adding sound-juicer and ubuntu-restricted-extras, 'Audio CD Extractor', aka Sound Juicer's default Quality MP3 profile is now audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=0 quality=6 ! xingmux ! id3v2mux, which then defaults to creation of 32K-320K VBR instead of 128K CBR MP3s.
After applying sudo apt-get install gstreamer-tools and running gst-inspect lame to consult the LAME settings, I then changed quality=6 to quality=2, which sounds subtly better to my reduced frequency response ears and a lot better to those with keener hearing !
I may now consult a forum genuine audio expert to see whether further 'tweaks' should be made, but it looks like positive progress is now being made.

[FiloSottile (filosottile-wiki)]

For me (Ubuntu 9.10) there isn't a REAL bug. Simply GStreamer Pipeline is erroneous.

Using the info from "gst-inspect-0.10 lamemp3enc" (see attachment) and the string from Maverick Alpha is simple to get a string that does what we want:
audio/x-raw-int,rate=44100,channels=2 ! ... ! xingmux ! id3v2mux
and replace ... with:
VBR of quality N lamemp3enc name=enc target=0 quality=N
ABR of BR near N kbps lamemp3enc name=enc target=1 bitrate=N
CBR of BR N kbps lamemp3enc name=enc target=1 cbr=true bitrate=N

Some VBR quality examples:
214.856873 kbps, 44 kHz (joint stereo) quality=2
142.501816 kbps, 44 kHz (joint stereo) quality=4
118.212517 kbps, 44 kHz (joint stereo) quality=6
094.653938 kbps, 32 kHz (joint stereo) quality=8

Add mono=true if needed.

What about adding this memo to the bug description to make it simple to get around?

[KennoVO (kenno-xs4all)]

OK, this might be getting confusing. Just a summary for people who are new to this bug, and some suggestions for future directions:

- People initially filed this as a sound-juicer bug, while *at that time*, it was actually a gstreamer bug; the "lame" element, which was responsible for encoding mp3 files by interfacing with the LAME mp3 library, was misbehaving.
- Rather than attempting to fix the "lame" element, which was entirely based on incorrect assumptions, Sebastian Dröge created a brand new LAME interface named "lamemp3enc", which is simple to use and in line with the LAME developer's UI guidelines.
http://lame.sourceforge.net/lame_ui_example.php
Around that time, I stopped following this bug, assuming that it would be fixed soon (I'm using RubyRipper with standalone lame for my own CD ripping purposes so I'm not directly affected).
- Now, more than a year later, "lamemp3enc" is indeed in gstreamer0.10-plugins-ugly-multiverse (which is good), but sound juicer still calls the obsolete and buggy "lame" element instead of "lamemp3enc" (which is inane).
- So, what we're looking at *right now* is a sound juicer bug (yes I consider a default setting that results in "data loss" - quality loss actually - a bug), and what we need is suggestions for default gstreamer pipe lines for sound-juicer.
- A good starting point for this would be hydrogeaudio.org - the guys over there are digital audio professionals and enthusiasts and they have done an incredible amount of ABX blind testing and debating to come up with recommendations for using lame.
http://wiki.hydrogenaudio.org/index.php?title=LAME
    * For what most people would call "CD quality", they recommend VBR qualities 0,1,2 or 3 (according to taste).
    * For "portable mp3 player quality", they recommend VBR qualities 4, 5 or 6
    * For "voice quality" they recommend ABR with a target bitrate lower than 100. The current juicer presets join the channels to mono when voice is selected, so in that case, a target bit rate of 56 seems sensible (ie. "lamemp3enc name=enc target=1 bitrate=56 mono=true" , thus mimicking "--preset voice" of standalone lame).
- How to implement this all depend on how much of these internals one would want to expose to the user. While I myself would very much enjoy juicer giving me the option to choose between VBR and ABR and set the quality/bitrate myself (as FiloSottile seems to suggest), juicer's design philosophy seem to be to keep it simple and stupid. In that case picking one "CD quality" preset, one "portable mp3 player" preset, and one "voice" preset would be the way to go.
- Finally, the sound juicer devs (or whoever makes up these defaults) seem to be biased towards lower bitrates/qualities; the current "CD quality" preset attempts to use VBR quality 6, in which most people could clearly hear the artifacts giving good enough listening conditions.
- Anyway, to stay totally in line with juicer's design philosophy (however objectionable this may be), my final recommendation would be to use FiloSottile's "audio/x-raw-int,rate=44100,channels=2 ! ... ! xingmux ! id3v2mux" with the following lamemp3enc lines:
"CD quality": lamemp3enc name=enc target=0 quality=2
"p...

[Bruce R (bm007a0030)]

It's taken over a year for me to obtain a cataract operation, but I can now see well enough to add another response to this Sound-Juicer problem saga.
When I first researched modifying Sound Juicer (aka Audio CD Extractor) back in LinuxMint-4 and Ubuntu 7.10 days, I downloaded and printed out the 'buntu-restricted-extras, gst-inspect information for the included LAME encoder variant (aka lamemp3enc).
However, I was then greatly aided in data interpretation by a Windows audio expert (aka Slipstreem), who knew all about LAME developer activities and guided my work and use of no-longer-available graphical EncSpot to assess the outcome of applied modifications.
Only being interested in 'CD Quality MP3' that by default was actually only Constant Bit Rate (CBR) 128K, I wasn't interested in greater than 320K studio quality but in 32K-320K Variable Bit Rate (VBR) quality.

Since then, folk have failed or been unable to add the requisite 'ugly' plugins that are part of the 'buntu-restricted-extras suite, which hasn't been helped by release varying Synaptic 'glitches'. Also, in typical typo-intolerant fashion, folk have failed to enter the profile modifications that I recommended.
To recap, after Adding 'buntu-restricted-extras and then Sound Juicer, select Edit Preferences, select the requisite CD Drive, select Eject after extracting tracks and Open music folder when finished. Next select 'CD Quality, MP3 (.mp3 type)' Output Format and Edit Profiles, then select 'CD Quality, MP3' and Edit. Finally Edit the Gstreamer pipeline as follows and then Close, Close, Close to save all modifications, which become the defaults.
Initial, default profile :
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=0 vbr-quality=6 ! Id3v2mux
Amend mode=0 to mode=1, to obtain 'Joint Stereo'
Amend vbr-quality=6 to vbr-quality=2, for the benefit of young and keen of hearing
Insert vbr=4 to employ LAME's new VBR algorithm (nothing to do with misquoted quality)
Insert vbr-min-bitrate=32, to set the minimum VBR bitrate
Insert vbr-max-bitrate=320, to set the maximum VBR bitrate
Hence the final, modified profile :
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc mode=1 vbr=4 vbr-min-bitrate=32 vbr-max-bitrate=320 vbr-quality=2 ! Id3v2mux
(KennoVO - note that 'lame name=enc' ensures use of the correct LAME plugin.)

In general, note that distributions like LinuxMint-9 'dvds' and PCLinuxOS have got round all the plugin addition problems by pre-including them.

Meanwhile, Ubuntu 10.10 Alpha2 briefly introduced a new default as follows, but it's been abandoned in later development releases, so who knows what the formal release will use :

audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=0 quality=6 ! xingmux ! Id3v2mux

I don't claim to have achieved perfection with my modifications, but most if not all listeners are content with achieved playback through reasonable equipment.

For 'tinkerers' I attach a PDF file reproduction of Ubuntu 10.04's LAME information etc.

[KennoVO (kenno-xs4all)]

Bruce R, please read all the posts carefully. The "lame" element is known to be broken, and has been superseded by "lamemp3enc". Stop encouraging people to use the "lame" element.
https://bugzilla.gnome.org/show_bug.cgi?id=494528
(FYI, Gabriel Bouvigne is one of the core LAME developers).

I did elaborate tests and not even once succeeded to make the "lame" element produce the same output as the standalone LAME program, because the "lame" element internally sets a whole series of developmental LAME flags to ill-conceived values. Ironically, the combination of flags you're suggesting are the ones I came up with in January 2009:
https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/195483/comments/22
Notice the last two sentences of my post. Yes, these flags seem to be well behaved if you only look at the output bitrates, but remember, bitrates are not everything. It's perfectly possible to encode at high bitrates and still have audible artifacts *cough* xingmp3encoder *cough*

Again, the "lame" element is officially deprecated; the "lamemp3enc" element leaves all flags at their (good) default values and produces outputs that are bitwise identical to standalone LAME.

Oh yeah, I still don't know what name=enc does, but it's definitely *not* "ensuring use of the correct LAME plugin". My best guess so far is that it sets some tag, which perhaps facilitates interfacing with some other program.

[Bruce R (bm007a0030)]

KennonVO - I think that you will find that my settings do in fact use
the GStreamer lamemp3enc and NOT what you call 'broken lame',
which can still be installed and used or mis-used by other ripping
tools, yet which I have not recommended as misquoted by you,
whilst the xing encoder is yet another animal that I have used in the
past, post fraunhofer and it's not too bad.

Incidentally, in view of misleading reporting by tools and even players
like VLC, simple checkmp3 does a better job of analysing mp3 files,
but you may prefer trying mp3diags now that Win EncSpot isn't
readily available.

At the end of the day, subjective assessment by those with keen
hearing using decent reproduction kit, like Sennheiser 'phones is
probably the best arbiter as to what's acceptable CD-like quality.

Bruce R

[Bruce R (bm007a0030)]

Upon reflection I think I see where your confusion arises, KennoVO.

Although the GStreamer lamemp3enc is what is invoked by the default and by modified profiles, it still needs instructing using original lame commands, which is why, if you want to try different settings, you need to have the 'gst-inspect lame' listed commands, which is what I reproduced as a PDF file.

'gst-inspect lamemp3enc' merely produces some less helpful information about its status.

I would also add that I am not an obsessed with perfection/detail kind of a guy, having found that in a long career as a professional engineer, documentation, like the software itself is rarely perfect and it's best to just use 'what works', whilst leaving others to eventually come up with a better mousetrap and instruction manual.
(By way of example, in the case of GRUB2 or even PulseAudio it will probably be a long time, if ever, before that occurs.)

[KennoVO (kenno-xs4all)]

The gstreamer bug is fixed but the implementation of this fix depends on sound juicer - updated remote watch accordingly.

[KennoVO (kenno-xs4all)]

BruceR, the things you're saying are simply not true. This is complex business and I can understand it confuses you, but please don't make stuff up. Browse Gnome Bugzilla (links at the end of this post). Look at the source code. Encode the same sample with gstreamer and with standalone LAME and do a binary comparison on the outputs (a hex editor might be helpful for this purpose).

What you need to understand is that the deprecated "lame" element and the new "lamemp3enc" element are simply two different gstreamer interfaces to the same liblame library. The "lame" element is called by specifying "lame" in the gstreamer pipeline, the "lamemp3enc" element is called by specifying "lamemp3enc" in the gstreamer pipeline. Not difficult so far. Now, here are the differences:
- The "lame" element tried to expose each and every LAME flag to the user, including many developmental flags that were never meant by the LAME developers to be set by end-users. Unfortunately, it had default values for each and every of these flags, and it would pass all of them on to liblame. This was harmful because (1) not all of the "lame" element's default values were sensible and (2) these flags override a number of settings that otherwise would be set internally by liblame at runtime depending on the situation.
- Specifically to cure this problem, Sebastian Dröge wrote the "lamemp3enc" element, at the request of (among others) Gabriel Bouvigne (LAME developer), David Joaquim (gnac developer) and myself. The "lamemp3enc" element is a much simpler interface, giving the user only the few options that were meant by the LAME developers to be set by end-users. Flags that are not specified by the user (in the gstreamer pipeline) are mostly left "undefined", allowing liblame to achieve its maximum quality by setting the corresponding settings internally to sensible values depending on the situation.

If you don't believe me, here's some background information. Please do your homework (ie. read each and every post *carefully*) before posting again.
https://bugzilla.gnome.org/show_bug.cgi?id=494528
http://git.gnome.org/browse/gnome-media/commit/?id=155f6ce6463a95146664b08b924d057679ca2f7c
https://bugzilla.gnome.org/show_bug.cgi?id=619642
https://bugzilla.gnome.org/show_bug.cgi?id=626285

[Bruce R (bm007a0030)]

KennoVO - trying to respond in a less inflammatory style, your attached links made interesting reading, effectively discussing the absence of the settings used in my/other amended profiles for CD QualityMP3 before addressing the proposed use of xingmux, as then briefly revealed to the world in the Maverick Alpha2 development release.

Please note that back in 2007, rather than using a 'down among the weeds'
hex editor, I used EncSpot which rather uniquely produces histograms of
resulting MP3s. Windows-hosted, sadly it's no longer supported although
source code may still be available for its resurrection as a Linux tool.

At the time, it confirmed that Sound Juicer defaults produced 128K CBR.
Best advice was to use Windows CDEX with modified settings, effectively
in a multi-pass operation to achieve 32K-320K VBR results as again
confirmed by encSpot, but I found that by consulting gst-inspect lame, I
could achieve similar results with Sound Juicer, as further confirmed by
subjective tests.

Since then there have been several reports of use of other tools and players, including VLC Player, that falsely report 32K-320K VBR encoded streams
as 128K CBR, without folk simply listening to the difference, such is the blind
trust in such tools, reinforced by a disbelief in faulty or limited software.
This leads me to wonder what 'analysis' tools you guys have been using.

Today, although there is the rather complex Linux mp3diags, I prefer to use
the simple checkmp3 to report on encoded streams, plus actually listening
to the results.

However, with my recently restored vision I have searched for and found my
original test CD, a Deutsche Grammophon recording of the Planet Suite.
Also, although several PC failures have lost other information, I still have a
working copy of EncSpot, so I have just run tests on three differently-created
copies of the Jupiter sound track

I attach a text file of checksum results, plus four EncSpot JPEG image files.

[Bruce R (bm007a0030)]

Apologies, only one attachment accepted, so single, three-page PDF file now attached.

[FiloSottile (filosottile-wiki)]

Ok, now these opinions about differences between results or different testing tools are silmply useless.
Here we are searching for the cause of the bug and for the best solution to it.
The cause was a buggy/misused gstramer plugin "lame". Now developers rolled out "lamemp3enc", a better interface to the same library. All we need is that the sound-juicer Gstreamer pipeline is changed to use it.
So, which are the best default options? I don't know. But surely the optimal pipeline is the one i proposed above, taken from Maverick. (See gst-inspect lamemp3enc or my precedent message for reference)
There are no other questions. Let's speak about this one.

[Bruce R (bm007a0030)]

Long ago, when my hearing was a lot keener, Xing encoding in AudioCatalyst markedly improved upon Frauhofer encoding in AudioGrabber and was faster, so using a new implementation of what was a non-free product in Sound Juicer may provide a better result.
I am puzzled at Ubuntu's discarding it after Maverick Alpha2 and assume that it will be re-instated or simply discarded for the 10-Oct-2010 release. Meanwhile, despite refutation that has included false accusations of results remaining 128K CBR rather than 32-320K VBR, the settings used by me have simply worked well, whilst Maverick Alpha2 settings are fine but a little strident to my old ears. When someone 'comes clean' about Maverick intentions, I will try out some subjective comparison tests on younger, keener hearing ears.

It would be nice to think that there are no other questions, but I'm not yet convinced that it's actually broken, only mis-used, although that doesn't fit well with Canonical policy 'to fix what ain't broke'.

[KennoVO (kenno-xs4all)]

- This is not about bit rate, this is about quality. Getting a higher bit rate does not automatically equal getting a higher quality. In fact, botching the psychoacoustics model with a load of settings is a good recipe to get similar or higher bit rates but a lower quality.
- For assessing quality, one person's subjective listening tests mean next to nothing. It is for this reason that I kept my own perception of sound quality out of this discussion (I also have a set of pretty good headphones and trained ears, but that's simply not relevant). However, there are ways to objectively test quality, by using ABX methodology, long systematic testing, a large sample of listeners, and sounds statistical analysis. That 's exactly what the folks at hydrogenaudio.org did, and they came up with recommended settings for standalone LAME. They also found that it's easy to pull down the quality by giving LAME a bunch of extra switches (you'd have to go digging through the hydrogenaudio forums for that). For this reason, I will trust anything that gives output that is bitwise identical to standalone LAME with the hydrogenaudio recommended switches, and I will not trust anything else. The "lamemp3enc" element falls into the former category, the "lame" element into the latter. Histograms of bitrates are irrelevant.
- Conicidentally, the same people at hydrogenaudio.org found that "Nowadays LAME is considered the best MP3 encoder at mid-high bitrates and features the best VBR model among MP3 implementations." Oh, and there's what they think about Xing: "The Xing (pronounced "zing") MP3 encoder was one of the fastest MP3 encoders. Of course that comes with a price, and quality wasn't on par with encoders tuned for quality instead of speed, like FhG Slowenc (Audioactive) and LAME."

So here we are, LAME is at the very least one of the best encoders out there, and nobody will miss the restricted ones that were thrown out. As FiloSottile said, the "lame" interface to liblame is buggy, the "lamemp3enc" interface is not. The only thing up for discussion is really how to call "lamemp3enc" (and make sure it's implemented in the Maverick release). Here's my proposal again:
https://bugzilla.gnome.org/show_bug.cgi?id=630779

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

[FiloSottile (filosottile-wiki)]

Definitively in line with kenovo's conclusions. They are well documented and based upon solid facts and data.
Also defaults seems good.
What's the next step to get the bug solved?

[Bruce R (bm007a0030)]

You know, I can remember the same sort of sweeping, dismissive statements being made when CDaudio sampling rates, A-D quantization and coding laws were discussed, with audiophiles being disappointed that a higher sampling rate, number of levels or a better coding law were not chosen. At the time those with deep pockets could demonstrate the superiority of vinyl's better dynamic range, rather ignoring record tracking distortion, so what emerged was a compromise. The further stage of then re-encoding that to MPEG1 Layer 3 standards with various proprietary or free tools seems to be going through a similar set of arguments.
As to 'statistically significant' blind tests they often forget to take account of the different human beings involved and their specific musical preferences.
If you merely look at high frequency perception this is permanently damaged by exposure to intense high frequencies, in my case compressor 'whistle' or jet engine 'whine' that reduced my teens 24kHz hearing to 17KHz in my thirties and is now barely 15kHz, despite taking care.
That still doesn't stop folk with more severely damaged hearing from spending vast sums on hi-quality reproduction kit or arguing for 'more faithful' coding, but that's life.
In practice I have found that it's a good idea to include some young folk with undamaged hearing when sorting out the best, within budget compromise.
As it's only a few weeks away, I'll wait to seen what Maverick finally chooses before conducting further coding and subjective tests with actual equipment and consumers.
As to the new parameters being discussed, they still seem to lack definition, gst-inspect not making that clear.

[KennoVO (kenno-xs4all)]

I attached a patch to be applied to /usr/share/gconf/schemas/gnome-audio-profiles.schemas

> What's the next step to get the bug solved?

The next step is to get this patch into Maverick. In an ideal world, gnome-media should adopt it, then Ubuntu should simply pull it in from the upstream repo's. However, there's no time for that anymore; the gnome-media people haven't even looked at my new bug report yet, leave alone discussed it and committed it, and Maverick comes out of beta and into "release candidate" in 2 days, at which point they won't be willing to change a lot anymore, leave alone pulling in new stuff from upstream. Our only chance is that some friendly ubuntu developer is willing to slip this in as a last-minute ubuntu-specific patch. I wouldn't hold my breath; my best bet is that users will still be plagued with quality=6 until "Natty Narwhal" comes out. It's a shame because it's only a few lines in gnome-audio-profiles.schemas (ignoring translation to other languages than English for now); no recompiling required or anything.

> As to the new parameters being discussed, they still seem to
> lack definition
ABX results or else it's just your imagination.
http://www.hydrogenaudio.org/forums/index.php?showtopic=16295
http://wiki.hydrogenaudio.org/index.php?title=ABX
Evaluation of sound quality is pathologically susceptible to listener bias. This is why there is a market for "$$$$$ ultra high quality S/PDIF cables" and other such snake oil.

[KennoVO (kenno-xs4all)]

I also submitted a patch upstream which processes the file gnome-audio-profiles.schemas.in.in , from which gnome-audio-profiles.schemas is generated at compile time. The package maintainer is free to choose whichever patch they find most convenient to use. ;)
http://bugzilla-attachments.gnome.org/attachment.cgi?id=171324

[Bruce R (bm007a0030)]

I see that 'if something can possibly be misinterpreted (or misquoted) it wil bel' applies again.

By 'new parameters lacking definition' I was referring to technical definition, not subjective audio clarity.

Meanwhile, posting this from a Live 'daily Maverick DVD' (28-Sep-2010) session, I can report that the 'xingmux' profile for 'CD Quality MP3' has been re-instated, again with 'quality=6' that is best changed to 3 or better yet 2.

The xingmux settings still seem to have a strident, harsh colouration to my ears, but I will use this setting versus my early recommendation to try polling some folk with better and more discerning hearing, hopefully including some young musicians with decent pitch perception.

[KennoVO (kenno-xs4all)]

Ah, so you mean the new parameters are poorly documented???

BTW, xingmux only adds a header, it doesn't touch or affect the audio in any way:
http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/gst-plugins-ugly-plugins-xingmux.html
It would be clearer and technically more accurate to refer to the different profiles as "lame" and "lamemp3enc" (if that's what you mean). Using ambiguous language is asking for being misinterpreted.

[Bruce R (bm007a0030)]

Yes, although the industry-wide lack of configuration control means that
keeping track of coding changes is a difficult and thankless task, not made
any easier if the coding is poorly structured or commented in the first place.

In my own case, cataract progression hasn't made reading 'available'
documentation any easier, but that's life.

[Bruce R (bm007a0030)]

Some afterthoughts.
In case it's not been clear, I am not interested in scoring 'brownie points' for 'being smart', only in obtaining a 'CD Quality' profile that consistently works for friends and other users, leaving 'B-cubed' to other folk, but so far I have not seen any meaningful definition of 'lame' versus 'lamemp3enc' terms and profiles, so if we are to be pedantic, I will in future just refer to the 'BruceR' versus 'KennoVO' profiles.
Meanwhile, I see that the Ubuntu 10.10 'rc' releases are still exhibiting some inconsistencies in operation between the Ubuntu Software Center and Synaptic, in adding ubuntu-restricted-extras and sound-juicer, where initiation by the Software Center then needs completion or reinstallation by Synaptic. However, once installed, Audio CD Extractor's less obvious CD Quality, MP3 default profile is a KennoVO style profile (audio/x-raw-int,rate=44100,channels=2 ! lameemp3enc name=enc target=0 quality=6 ! xingmux ! id3v2mux) which I have simply amended with 'quality=2' before use in a LiveCD session.
It's then a lot slower encoding than my 'Mint-9 on a stick' and still has 'a strident and raucous colouration' to my ears, but I really must get some younger, keener, and more musical ears to compare the results against the original CDs.

[Bruce R (bm007a0030)]

Stop PRESS - there's something weird going on. Although the Maverick RC Live CD produces different sounding results with the KennoVO and BruceR profiles, they are both OGG files, rather than MP3 files, whereas in Mint-9 they are, as expected, both MP3 files, so there would appear to be a lot more to do before this gets sorted for Ubuntu10.10 (Maverick)

[Bruce R (bm007a0030)]

Indeed, Sound Juicer's MP3 capability has been completely removed from the Ubuntu repository ! Talk about cockups !

[Bruce R (bm007a0030)]

Weirder and weirder. Reinstalling the packages didn't get around what has proved to be my cockup, but a completely fresh distribution installation restored Sound Juicer complete with an MP3 capability. After attending an eye operation follow-up appointment, I must see if I can repeat the cockup, so as to avoid it in future.

[FiloSottile (filosottile-wiki)]

Current Maverick CD quality is (installing restricted-extras and sound-juicer)
audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=0 quality=6 ! xingmux ! id3v2mux

Definitively not CD quality.

Developers need to be advised to change profiles to KennoVO's ones:
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

@BruceR:
OGG files?? I haven't understood anything of your latest messages (except the pointless information about your eyes). If you have something to say about these profiles, say it clearly and directly, else let devs do their work.

[Bruce R (bm007a0030)]

@FiloSottle - thank you for yet another polite, considerate reply, but perhaps that's not clear enough ?
  ----- Original Message -----
  From: FiloSottile
  To: <email address hidden>
  Sent: Sunday, October 03, 2010 3:22 PM
  Subject: [Bug 195483] Re: Sound Juicer - MP3 quality doesn't change

  Current Maverick CD quality is (installing restricted-extras and sound-juicer)
  audio/x-raw-int,rate=44100,channels=2 ! lamemp3enc name=enc target=0 quality=6 ! xingmux ! id3v2mux

  Definitively not CD quality.

  Developers need to be advised to change profiles to KennoVO's ones:
  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

  @BruceR:
  OGG files?? I haven't understood anything of your latest messages (except the pointless information about your eyes). If you have something to say about these profiles, say it clearly and directly, else let devs do their work.

  --
  Sound Juicer - MP3 quality doesn't change
  https://bugs.launchpad.net/bugs/195483
  You received this bug notification because you are a direct subscriber
  of the bug.

[Bruce R (bm007a0030)]

You know an awful lot of nonsense gets dogmatically said on the topic of sound digitisation and this and other related Bug Reports have been no exception to that rule.
Ignoring the inflammatory, not to say ignorant nature of some remarks, yet not yielding to rude bully-boy tactics, I will just make one last attempt to explain.

CD audio digitisation of music is a compromise, originally derived from techniques used to digitise audio speech over buried copper wires, back around 1970.

To then recode those results with MP3 inevitably imposes further limitations on the perceived quality, although 128K CBR coding is found acceptable by quite a lot of folk who have probably never heard anything better or who have already damaged hearing.

More discriminating listeners, who may have experienced live orchestral music or old technology vinyl records and valve amplifiers or even modern products from the likes of NAIM (who haven't forgotten that it's user perception that counts) may be hoping for something better.

CD-like Quality, provided that the reproduction equipment and listener perceptions are good enough, is generally recognised to be a better compromise for MP3 re-coding.
On a 'please most of the folk most of the time' basis, 32-320K VBR coding seems to be acceptable, but most disagreement seems to have been about whether that new compromise is perfectly achieved, without stopping to simply listen to the results.

When I simply stop to listen, 128K CBR sounds 'muffled' to my ears, whilst different VBR codings impose their own colouration, so it was with relief I found that Linux Sound Juicer could be modified for perceptibly better results, rather than using Windows hosted CDEX or later Foobar2000 as directly recommended by a Hydrogenaudio forum member.

Using 'Bruce R' profiles I have received some very favourable comments from my circle of friends and others, including some musicians. However, the bottom line is that if they report an improvement using a 'KennoVO' profile, I may re-encode my CD collection for their listening benefit, but I hope to retain the freedom to make that choice, which is why I was distressed to have that apparently being desperately prevented, for whatever reason.

[Bruce R (bm007a0030)]

Profuse apologies everyone, but I have just discovered that Sound Juicer MP3 ripping simply doesn't work for Ubuntu 10.10 or Ubuntu.10.04, only for LinuxMint 7, 8 and 9 and Ubuntu 9.04, leaving Ubuntu 9.10 to be investigated, where I suspect that in Ubuntu 'it ain't broke so let's fix it' - style, the addition of something needed like a GStreamer plugin was blocked.
So, if you're serious about ripping to MP3, forget Ubuntu and get LinuxMint-9 ?

[Bruce R (bm007a0030)]

After further investigation with LiveCD sessions of Ubuntu 9.04, 9,10, 10.04 and 10.10 I can report that it's the introduction of Ubuntu's Software Center and its poor handling of essential dependencies etcetera that has sabotaged the addition of Ubuntu Restricted Extras and Sound Juicer (aka Audio CD Extractor) itself, and has also prevented the previously correct operation of the Synaptic package manager for the addition of other packages.
This means that this Bug Report's discussions of profile modifications have been nugatory.
Because my modifications worked so well with Ubuntu 9.04 and then with LinuxMint and especially LinuxMint-9 which has become my everyday Linux distribution, I had failed to appreciate this, so I'm very sorry folks.

[Simon Reed (xubuntu-o)]

Does this bug still exist?

The recent reviews (2013) for Sound Juicer complain about the poor quality. presumably because of this bug. (If bug it is. Having read all of the above I now cannot tell what it is.)

On trying to decide on CD ripping software to produce MP3s to run under Xubuntu 13.04, I came across the Ubuntu help page on CD ripping ( https://help.ubuntu.com/community/CDRipping ) still has KennoVO's comment "WARNING: the gstreamer LAME plugin, used in the instructions below, is broken and will produce substandard quality MP3s. You can track the bug here. If you want to create MP3s, it is recommended not to use Sound Juicer; use a program that doesn't interface with LAME through gstreamer instead. Good examples are RubyRipper and ABCDE."

Is that still true?

To get Xubutu 13.04's default ripping software, K3b, to produce MP3s, one must install LAME. How does one tell which CD ripping software doesn't interface with LAME through gstreamer?

Asunder, Ripper X, Audex, AcidRip and RipOff are all highly rated in the Ubuntu Software Centre, but how to tell which are affected by this bug report?

Any chance of a summary of what the state of this problem is?

[Phillip Susi (psusi)]

It looks like this was fixed upstream years ago.

[Gotit (sca957)]

@Simon
I have tried Sound Juicer 3.4.0 and it no longer provides a way to adjust MP3 ripping parameters, at least not via the GUI.
Currently I'm using Asunder 2.1 because my wife thinks it provides a richer sounding rip than Rubyripper 0.6.2.
Both Asunder and Rubyripper provide control over the ripping parameters.
Granted, my ripping tools may be somewhat down rev. as I am on Ubuntu 12.04