Newby time. I've been playing around with different rippers and encoder settings. AudioGrabber, CDex, EAC all using the 3.92 .dll file. Using EncSpot to view the results, you can view the 'Lame Header'. One of the fields in here is 'Quality'.

Is this Quality field a useful judge of anything? I don't know what generates it or how it arrives at the results it shows. Obviously the ear is the best judge, but I was surprised at some of the results comparing alt-presets to picking minB/maxB using the pulldowns, choosing options, etc. If this Quality field is any judge, manually selecting options gave me consistantly better numbers than APE or APS. Smaller file sizes, too. For example:

APS was 7,486kb and scored a 78
APE was 9,116kb and scored a 78
V0 b128 B224 Q0 LP19900 was 7,297kb and scored a 100
(all with CDex, same CD, same track, same CDR)

So, is this Quality number meaningful, or is it just artificial hooey?

By the way, same settings and everything, CDex scored 100 and EAC got a 98. Every time. Go figger.

I'm not sure exactly how EncSpot calculates that score but in any case it's only a rough guess at the quality of a file based on certain settings it can see were used. The ripper you used won't affect the score at all, you could use an old version of Audiograbber on the fastest mode with a badly scratched CD and EncSpot wouldn't be able to "rate" the file compared with if you'd ripped it with EAC in secure mode, it simply looks at switches flicked during the MP3 encoding process, as you assumed, by reading header/bitrate info.

I have never found a use for this, on the contrary, it can be extremely misleading, and I think most people here have similar views. For example, rating the audio quality of a file based on what the header and other basic info say has the following massive flaws:

- The whole file could be a transcode

- The header could have been mis-written by a bad or old encoder

- The header could have been manipulated/re-written


...and then there's the less catastrophic discrepancies like the fact it doesn't discriminate between LAME versions as far as I know (definitely not the newer ones), and it doesn't recognise the presets as being superior to "normal" settings.

So yep, ignore that quality score.

In short, as it looks like you already know, EAC is the best ripper and --alt-preset standard (or --preset standard... they're the same thing) gives the best quality/filesize tradeoff, to generalise, it's transparent 99.9% of the time for 99.9% of people in ordinary listening and in any case, far superior to any setting within any other MP3 encoder (and also superior to that command line which scored a 100 with EncSpot). The recommended version of LAME is 3.90.3.

Use the search function here to read more ina any of the forums if you want more detail

Hooey

I'm not really sure of the how and why of this number, but in LAME, this is how the quality values line up with the presets (presets appear multiple times if the quality stored is different in different versions of LAME).

The Quality field in the lame header is not calculated by EncSpot, it is written in there by LAME when it encodes the file. I think gazzyk1ns is looking at a different place in EncSpot to you: his comments apply to the Quality column in the main grid in EncSpot (the red, yellow or green coloured column).

The Quality field in the lame header you are talking about is, as GetID3() says, not really a reliable indicator of quality. It is actually calculated for vbr files from the V and q settings used during the encoding process. The formula is: 100 - (<V value> * 10) - <q value>

For example, 3.90.3 alt-preset standard uses V2 and q2 so the value is set to 100 - (2 * 10) - 2 which results in 78.

The end result of this pretty much that a high V setting will give a low quality and visa-versa. Which is kind of true but very simplistic. For abr and cbr files the value seems to be always written as 55, unless they are created using a preset command line such as --alt-preset 128 or --alt-preset cbr 128 in which case it is set to 58. I am not sure why this is the case but it doesn't really tell you anything about the quality of these files at all.

I've noticed that the quality values show up as "VBR Scale" in the Xing tag as well. What does this mean?

The LAME tag is an extension of the Xing VBR tag. The quality part is in the original Xing specification, but it's meaning is not well-defined (as far as I know).

Quoting from http://gabriel.mp3-tech.org/mp3infotag.html

Ah, thanks for this correction. I was indeed talking about the coloured bar but also about the quality score - i.e. I thought EncSpot scored it and then showed the appropriate colour in the next column, based on that score, for "at-a-glance" quality scoring when you've got loads of files in your EncSpot window.

Quote:
"The formula is: 100 - (<V value> * 10) - <q value>"

So it would seem that as long as V0 and Q0 are specified, all the other settings would be irrelevant. Wouldn't that mean that any bitrate would score 100, as long as it used V0 & Q0?

Hmmm. This quality field doesn't seem very useful. Guess I should just let my ears be the judge after all. What a concept!

But I still can't figure out why the CDex rips scored 100 while the EAC rips scored 98. Same hardware, same track, same .dll and same settings...

Dammit, this update just in. I just checked again. They both have the 3.92 .dll but CDex has v1.30 and EAC has v1.28.
Never mind.

Quote:
"V0 and q2 = 100 - 10 * 0 - 2 = 98"

Ah, this is where the 98 is coming from. Either I didn't select q0 or else EAC doesn't give me the option and defaults to q2.

Thanks to everyone for the excellent responses. Cheers!

Thanks for the reply. I've been enlightened a bit more...I think...