The LAME tag (aka Mp3 Info Tag) has all sorts of neat data stored in it, but I'd like to know in what version of LAME each part of the tag was added. For example, wasn't bytes $B6-$B7 Preset and surround info original designated reserved, and is now defined? Is there a list somewhere of what was added when? When was the LAME tag itself first introduced?

Preset and surround fields were originally reserved.
As adding them in this place does not break anything, I added those fields in the same Tag revision (btw we are still at rev0 and not rev1)

Preset was added in 3.93, but if you get an older version, you will just have 0 as preset value.
Surround mode is not used right now.

In what version of LAME was the whole LAME tag first added?

My idea was that if I knew in which version of LAME each portion of the tag was added, for earlier versions I could suppress parsing those parts of the tag that should be undefined, rather than returning incorrect data (source frequency, MusicLength, etc).

byte $B4 Misc has space for Source Sample Frequency, with the zero value representing <= 32kHz... If an early version of LAME didn't know about this data field it would be left at zero, implying a <=32kHz source, when in fact it should be undefined. Actually, looking at it now, do any versions of LAME support this field? All the test files I've encoded (stereo-44kHz source) show up as "<= 32kHz"...

As near as I've been able to determine (I'm still looking for old LAME binaries), the features that could potentially return bad data if unspecified, and the version they were introduced in:

Source Sample Frequency - still not in use in any version of LAME?
stereo_mode - enabled in 3.90.3, not enabled in 3.82 (defaults to MONO)
encoder delay - enabled in 3.90.3, not (?) enabled in 3.82
ATH type - enabled in 3.90.3, not (?) enabled in 3.82
end padding - enabled in 3.90.3, not (?) enabled in 3.82
music CRC - enabled in 3.90.3, not (?) enabled in 3.82
LAME tag CRC - enabled in 3.90.3, not (?) enabled in 3.82
audio bytes - enabled in 3.90.3, not (?) enabled in 3.82

Ideally I would've thought the Tag Revision field would be used to indicate when new features were added/used, but it still seems to be sitting at Rev 0?

It looks like I should ignore all the new extra data from the MP3 Info Tag for LAME versions older than 3.90 - does that sound reasonable?

The Lame tag was introduced during 3.90.

If you are detecting a Lame tag, you can safely read all the values. (btw Gogo is also using a Lame tag, but for any reason with the LAME identifier for te encoder!)

The only changes I made after introduction of the tag are the preset and surround values. Surround is not filled yet, only preset.
As you can see, the value "0" in preset filed means "unknown". So you can safely use the same routine even for 3.90-3.92, as you will just read the "unknown" value.

I have to check the source sample rate field, because it could be a bug.

While you're looking at LAME bugs - I'm noticing strange things with the LAME tag "stereo mode" field (byte $B4 Misc, 0x1C). Encoding from a 44kHz stereo WAV, using LAME 3.93.1, I sometimes get "mono" instead of "stereo". Specifically, if I encode in other than VBR mode, it seems to get set to "mono". Here, some examples:

lame test.wav = mono
lame -m m test.wav = mono
lame -m s test.wav = mono
lame -m j test.wav = mono
lame -m a test.wav = mono
lame -v test.wav = stereo
lame -V 4 test.wav = stereo
lame --freeformat 640 test.wav = mono
lame --alt-preset cbr 128 test.wav = forced
lame --abr 128 test.wav = mono

All output files (other than the -m one of course) are stereo files, but the ones in red above have incorrect information in the Stereo Mode bits of the Misc byte in the LAME tag.

Can you confirm this issue?

[EDIT]-m -> -m m; -j -> -m j; -s -> -m s; -a -> -m a[/EDIT]

This post has been edited by getID3(): Jun 1 2003, 14:56

*I can not confirm problem related to source frequency or stereo mode. It seems fine to me
*commands such as "lame -j" are invalid
*EncSpot manages to get source freq and stereo mode fine

Perhaps you are using a wrong bit order?

The -j, -s, -m, -a switches should have been -m j, -m s, -m m, -m a respectively, my typo.

I have carefully gone through my source and compared it to the LAME tag specification. And I found the source of confusion... believe it or not there was actually a typo in my code! (I was parsing the byte correctly, but incorrectly using data from $AF Encoding flags + ATH Type due to a variable name typo)
Sorry to waste your time

However, going through the LAME tag specs I did find two typos:

• "bytes $9A-$A4 Encoder short VersionString" - it's actually $9C - $A4
  
• "bytes $A7-$AF Replay Gain" - it's actually $A7-$AE

And a final comment - the offsets specified (ie "$B6-$B7 Preset Surround Info") assume a starting offset of 0x24 which is true for MPEG-1 non-mono, but not true for MPEG-1 mono, nor for MPEG-2/2.5 (I know we all know that, but it just makes the documentation slightly more confusing since it seems to imply absolute offsets rather than variable (although not relative) offsets - VBR quality ($9B) is actually at $8C in a MPEG1-mono file, for example). I don't know if there's a better way to represent the data offsets, but maybe make a note saying
* subtract 23d from these offsets for MPEG2/2.5-mono
* subtract 15d from these offsets for MPEG2/2.5-stereo/joint-stereo/dual-channel
* subtract 15d from these offsets for MPEG1-mono
or something to that effect?

You are right about the offsets start.
It is quite bad that the Xing header does not always start at the same place.

Btw, I am wondering if in the future we should not use VBRI headers. After all, Xing/Real is not a major player anymore for mp3 encoders. There is only FhG and Lame left.


edit: un-twisted fingers on keyboard

This post has been edited by Gabriel: Jun 1 2003, 18:36

VBRI has the advantage of starting at a consistant offset, and always has a consistant first frame size, but I think it would be better to stick with Xing style VBR headers for two reasons:
1) Most importantly, this is the way it's already being done for LAME - changing it to something completely different will break a lot of software.
2) Xing VBR headers are more widely supported than VBRI - for example Winamp (v2.x at least) doesn't understand VBRI

Winamp 2.92 will according to a beta tester and Foobar 2000 already does

I do not want to switch soon.
It is just something in my mind.