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?

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.

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

Behold! The tag specification:

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

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.

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!