Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Question about LameTag! (Read 4934 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Question about LameTag!

When seeing a V0 file, LameTag will say quality is = 97 (V0 and q3)
When seeing a 320kbps CBR file, LameTag will say quality is = 55 (V4 and q5)

Why is that, is this program crazy?

Question about LameTag!

Reply #1 –
Quote from: Bourne on
Why is that, is this program crazy?

Pretty much. Whatever calculation is used is clearly obsolete, if it ever did make much sense. In this case it probably assumes that vbr is good and cbr is bad, without propely considering the effect of bitrate.

If the developers opened up this can of worms for updating, everybody would have a different opinion on how to quantify quality, so it is better to just let it go.

Question about LameTag!

Reply #2 –
oh ok... I suspect that APP is mad.... ;-)

Question about LameTag!

Reply #3 –
Quote from: Bourne on
oh ok... I suspect that APP is mad.... ;-)

could also be it's a very old version or if it's lame somebody "tweaked" with the wrong settings.. muahaha

edit: by it i mean the 320 mp3 file, encoded with a very old encoder. mmk
Be healthy, be kind, grow rich and prosper

Question about LameTag!

Reply #5 –
I see that the quality value in the Lame tag is specifically "VBR Quality". This would explain why it has no real meaning in CBR mode.
 

Question about LameTag!

Reply #6 –
I wouldn't normally rez such an old thread, but I don't think this has come up anywhere else (or been answered!), it came up on another site I'm on just now and the answer may be interesting

Short version: The quality value is still written by LAME if you encode a CBR file, and it does still carry some limited meaning (although the routines are in VbrTag.c, elsewhere in the source it talks about the boolean bWriteVbrTag which controls whether or not that happens: "It is used for CBR,ABR and VBR.")

in VbrTag.c:
int nQuality = (100 - 10 * gfp->VBR_q - gfp->quality);

So a V0 q2 will give 98, a V2 q4 will give 76, etc

So why do we get weird values for 320 CBR?

Well in lame_init_old (despite the name it is being called!) default values for the gfp struct are set, and one of them is:
gfp->VBR_q = 4;

I assume that this never gets overwritten in the case of a CBR file, the calculation for quality is done the same, and the header written. So, for a CBR file:

quality value = 60 - q

Programs that give you the VBR no. and q value from an MP3 file (including LameTag I guess, we were talking about AudioIdentifier) work it out backwards from the quality value. If you get 55 then that MP3 really was encoded with -q 5, just ignore the VBR value and you do have some meaningful information

Hope that's helpful / interesting to someone!