The purpose of this tag is to provide extra information about the mp3 bistream, encoder and parameters used. This tag should, as much as possible, be meaningfull for as many encoders as possible, even if it is unlikely that other encoders than Lame will implement it.

This tag should be backward compatible with tha Xing vbr tag, providing basic support for a lot of already written software. As much as possible the current revision (revision 1) should provide information similar to the one already provided by revision 0.

A few fields, as they could be necessary for some functionnalities of already existing software, should not be moved in any version of the tag. They are indicated as "UNMOVABLE".

LAME 3.88 Tag example :

frame at 44.1kHz samplerate:
 

/*

//    ZONE A - Traditional Xing VBR Tag data
//    4 bytes for Header Tag
//    4 bytes for Header Flags
//  100 bytes for entry (NUMTOCENTRIES)
//    4 bytes for FRAME SIZE
//    4 bytes for STREAM_SIZE
//    4 bytes for VBR SCALE. a VBR quality indicator: 0=best 100=worst

//   ZONE B - Initial LAME info
//   20 bytes for LAME tag.  for example, "LAME3.12 (beta 6)"
// ___________
//  140 bytes
//

//   ZONE C - LAME Tag
//   208 bytes unused in 128k frame (in 48kHz case)
//
//   using
//   FrameLengthInBytes = 144 * BitRate / SampleRate + Padding
//
//   this gives
//   Layer III, BitRate=128000, SampleRate=44100, Padding=0
//        ==>  FrameSize=417 bytes
//   Layer III, BitRate=128000, SampleRate=48000, Padding=0
//        ==>  FrameSize=384 bytes
//
//   so this would make the minimal frame size 384 bytes ($0-$17F), hence the available bytes for this field are not 241 as in this 44100Hz case, but at most 208 bytes.
*/

frame at a 48.0kHz samplerate:
 

examples:

V0 and q0 = 100 - 10 * 0 - 0 = 100 => 64h
V0 and q2 = 100 - 10 * 0 - 2 = 98 => 62h
V2 and q5 = 100 - 10 * 2 - 5 = 75 => 4Bh
V9 and q9 = 100 - 10 * 9 - 9 = 1 => 01h

examples:

"LAME3.90a" : LAME version 3.90 alpha
"GOGO3.02b" : GOGO version 3.02 beta

• 4 MSB: Info Tag revision, range 0d-15d
  Possible values:
  0: rev0
  1: rev1
  15: reserved
  
  
  
• 4 LSB: VBR Method, range 0d-15d
  Indicate the VBR method used for encoding.
  Possible values:
  
  

0d	unknown
1d	constant bitrate
2d	restricted VBR targetting a given average bitrate (ABR)
3d	full VBR method1
4d	full VBR method2
5d	full VBR method3
6d	full VBR method4
7d
8d	constant bitrate 2 pass
9d	abr 2 pass
10d
11d
12d
13d
14d
15d	reserved

In case of Lame, the meaning is the following:
2: abr
3: vbr old / vbr rh
4: vbr mtrh
5: vbr mt

examples:

byte $A5 = 03h

= 0000 0011b =>

• 4 MSB = 0001b =1d : LAME Tag revision 1
• 4 LSB = 0011b = 3d : vbr-old / vbr-rh

= 0011 0101b =>

• 4 MSB = 0011b = 3d : LAME Tag revision 3
• 4 LSB = 0101b = 5d : vbr-new / vbr-mt

range: 01h = 01d : 100Hz -> FFh = 255d : 25500Hz

value 00h => unknown

examples:

byte $A6 = C3h

C3h = 195d : 19500Hz

byte $A6 = 78h

78h = 120d : 12000Hz

as defined here: http://www.david.robinson.org/replaylevel/ by David Robinson

three fields:

• bytes $A7-$AA : 32 bit floating point "Peak signal amplitude"  32 bit floating point. 00h00h00h00h : unknown

 

 

1.0 is maximal signal amplitude storeable in decoding format.
0.8 is 80% of maximal signal amplitude storeable in decoding format.
1.5 is 150% of maximal signal amplitude storeable in decoding format.

info + examples: will follow


---

• byte $AB-$AC : 16 bit "Radio Replay Gain" field, required to make all tracks equal loudness.

   

from http://privatewww.essex.ac.uk/~djmrob/replaygain/rg_data_format.html

bits 0h-2h: NAME of Gain adjustment:
000 = not set
001 = radio
010 = audiophile
(see - room for plenty more!)

bits 3h-5h: ORIGINATOR of Gain adjustment:
000 = not set
001 = set by artist
010 = set by user
011 = set by my model
100 = set by simple RMS average
etc etc (see - room for plenty more again!)

bit 6h: Sign bit
bits 7h-Fh: ABSOLUTE GAIN ADJUSTMENT
storing 10x the adjustment (to give the extra decimal place).

---

• byte $AD-AE : 16 bit "Audiophile Replay Gain" field, required to give ideal listening loudness

 

from http://privatewww.essex.ac.uk/~djmrob/replaygain/rg_data_format.html

bits 0h-2h: NAME of Gain adjustment:
000 = not set
001 = radio
010 = audiophile
(see - room for plenty more!)

bits 3h-5h: ORIGINATOR of Gain adjustment:
000 = not set
001 = set by artist
010 = set by user
011 = set by my model
100 = set by simple RMS average
etc etc (see - room for plenty more again!)

bit 6h: Sign bit
bits 7h-Fh: ABSOLUTE GAIN ADJUSTMENT
storing 10x the adjustment (to give the extra decimal place).

• 4 MSB: 4 encoding flags

000?	LAME uses "--nspsytune",  ? = 0 : false ? = 1 : true
00?0	LAME uses "--nssafejoint" ? = 0 : false ? = 1 : true
0?00	This track is --nogap continued in a next track ? = 0 : false ? = 1 : true is true for all but the last track in a --nogap album
?000	This track is the --nogap continuation of an earlier one ? = 0 : false ? = 1 : true is true for all but the first track in a --nogap album

• 4 LSB: LAME ATH Type, range 0d-15d

byte $AF = 03h

= 0000 0011b =>

• 4 MSB = 0000b = 0d : LAME does NOT use --nspsytune, LAME does NOT use --nssafejoint
• 4 LSB = 0011b = 3d : ATH type 3 used

= 0001 0101b =>

• 4 MSB = 0001b = 3d : LAME does use --nspsytune, LAME does NOT use --nssafejoint
• 4 LSB = 0101b = 5d : ATH type 5 used

range: 01h = 01d : 1 kbit/s (--abr 1)  -> FFh = 255d : 255 kbit/s or larger (--abr 255)

value 00h => unknown

examples:

byte $B0 = C3h

C3h = 195d : --abr 195

byte $B0 = 78h

78h = 128d : --abr 128

byte $B0 = FEh

FEh = 254d : --abr 254

byte $B0 = FFh

FEh = 255d : --abr 255 or higher, eg: --abr 280

IF the file is NOT an ABR file: (CBR/VBR)

the (CBR)/(minimal VBR (-b)) bitrate is stored here 8-255. 255 if bigger.

examples:

• "LAME -V0 -b224" will store (224)d=(E0)h
• "LAME -b320" will store (255)d=(FF)h

[xxxxxxxx][xxxxyyyy][yyyyyyyy]

the 12 bit values (0-4095) of how many samples were added at start (encoder delay) in X and how many 0-samples were padded at the end in Y to complete the last frame.

so ideally you could do: #frames*(#samples/frame)-(these two values) = exact number of samples in original wav.

so worst case scenario you'd have a 48kHz file which would give it a range of 0.085s at the end and at the start.

example:
[01101100][00010010][11010010]

X = (011011000001)b = (1729)d, so 1729 samples is the encoder delay
Y = (001011010010)b = (722)d, so 722 samples have been padded at the end of the file

(*)some settings were used which would likely damage quality in normal circumstances. (like disabling all use of the ATH or forcing only short blocks, -b192 ...)

byte $B5 is set to (00)h by default.

if done so, this 8-bit field can be used to log such transformation happened so that any given time it can be undone.
 

2^(a/4) , range of "a" here: -127..0..127
 

the +-190.5dB range is too large, but there was little else to do with the extra bits, so for uniformity we took this range.

The first byte it counts is the first byte of this LAME Tag and the last byte it counts is the last byte of the last mp3 frame containing music.

Should be filelength at the time of LAME encoding, except when using ID3 tags.

practical example:
[misc+ID3v2 tag info][LAME Tag frame][complete mp3 music data][misc+ID3v1/2 tag info]

remark: applying any (ID3v2) kind of tagging or information in FRONT of the LAME/Xing Tag frame is a very bad idea.  You will disable the functionality of all decoders to read the tag info correctly. (for example: VBR mp3 seek info will no longer be usable)

range (1)d-(4,294,967,295)d [ or about 4294967295/(650*1024*1024)/320*1411 = 27.79 hours of 44.1kHz 320kbit/s music. ]

Musiclength not set / unknown / larger than 4G:

use of this field: together with the next field deliver

• an effective verification of music's integrity
• and effective shield from TAGs.

Examples:
 

• with as first byte the first byte of the first mp3 frame containing music. (the frame right after this LAME Tag)
• with as last byte the last byte of the last mp3 frame containing music. (so that additional tags at the end are not included.)

practical example:
[misc+ID3v2 tag info][LAME Tag frame][complete mp3 music data as made by LAME][misc+ID3v1/2 tag info]

remark: applying any (ID3v2) kind of tagging or information in FRONT of the LAME/Xing Tag frame is a very bad idea.  You will disable the functionality of all decoders to read the tag info correctly. (for example: VBR mp3 seek info will no longer be usable)

Meaning of this musicCRC:

It does not say:

• this is a valid mp3
• this mp3 sounds good
• this mp3 has been downloaded correctly off the internet
• it has not been retagged (very possible)

• effective verification method to see if the music data is exactly what it was at time of encoding
• swift and accurate removal of any sort of ID3 or different tags
1) search for start of a LAME Tag ( pos $xy )
2) if CRC($(xy+c0)..$(xy+MusicLength)) corrent then cut out $(xy+c0)..$(xy+MusicLength)

CRCInitValue := $0000;

reason : safeguards LAME VBR header against easy tampering.  Improving the header functionality as quality control/verification tool for VBR files.

CRCInitValue := $0000;

Remarks / Ideas:

• The idea behind storing all this specific (quality significant) LAME settings used to encode in the mp3 itself is to give some kind of quality assurance for (mainly) non-CBR files.  You would download an mp3 from the web and know exactly what kind of setting was used on this file.  Now there is no way to keep find out if your download is a "-V9 --lowpass 12" or a "-V1 --lowpass 19.5" file.  Even though both have a significant quality difference.
• These headers should also be placed in front of CBR files. Given the Bitrate is >=64 the frame could be housed in a CBR file using the same framesize as the mp3 itself.
• If limiting the LAME string to 9 bytes "LAME X.YZu", the extension revision 0 could take 27 bytes and it would still fit a 64 kbit 48kHz frame:

0000: 0010: 0020: 0030: 0040: 0050: 0060: 0070: 0080: 0090: 00A0: 00B0:

FF FB 54 04-00 00 00 00-00 00 00 00-00 00 00 00 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 00 00 00 00-58 69 6E 67-00 00 00 0F-00 00 00 7E 00 00 2F E1-00 04 04 04-04 04 04 05-09 0B 0D 0F 13 15 17 19-1D 1F 21 23-27 29 2B 2D-31 33 35 39 3B 3D 3F 43-45 47 49 4D-4F 51 53 57-59 5B 5D 61 63 65 67 6B-6D 6F 73 75-77 79 7D 7F-81 83 87 89 8B 8D 91 93-95 97 9B 9D-9F A1 A5 A7-A9 AB AF B1 B3 B7 B9 BB-BD C1 C3 C5-C7 CB CD CF-D1 D5 D7 D9 DB DF E1 E3-E5 E9 EB ED-00 00 00 0B-4C 41 4D 45 33 2E 37 30-00 00 00 00-00 00 00 00-00 00 00 00 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00

?T?   Xing   ?   ~   /ß ??????????? ?§????!#')+-1359 ;=?CEGIMOQSWY[]a cegkmosuwy}?üâçë ïìæôòù¢¥ƒíѺ?½»? ???????????????? ??ß?????   ?LAME 3.70

• In these last two cases, instead of the now default 128kbit/s one, in case of non-CBR, LAME could add any (64 .. 320) sized tag to the mp3, being as close as possible to the average bitrate of the file.  So a VBR file averaging 172 kbit would get a 160kbit/s LAME Tag, an ABR file averaging 253 kbit/s a 256kbit/s LAME Tag...  (useful for non-vbr compliant decoders guessing file length based on size first frame)