Hello!

I was wondering how to identify free format MP3 files. I am currently working on a Visual Basic ActiveX which should extract information about MP3/MP2/MP1 files and at the moment it recognizes a 640 kbps MP3 file totally wrong (MPEG 1 Layer I, 448 kbps, 48 KHz, 50/15 microsec. emphasis...).

Thanks!

http://www.mp3-tech.org/programmer/frame_header.html

the bitrate table index 0 indicates a free format stream

Yes, I know that. I also have that bitrate table implemented inside my program, but the MP3 analyzer returns bitrate index 14 (which in my case denotes MPEG 1 Layer I with 448 kbps). Also, it seems that the whole header is different, as the tool returns 48 KHz, 50/15 microsec. emphasis...

you may want to look if there is no ID3v2 tag in front of your stream.

No there isn't, and even if a tag would be there, my program would read the first valid MPEG frame.

Here is the portion of the code, which evaluates the MPEG header data (VB):

Someone just sent me an email asking me to send that song, but I have deleted the mail by mistake.
Anyway, the file has over 20 MB (it is a 640 kbps file).

yes, it was me. just send me the first 100 k bytes for testing.

This post has been edited by robert: May 22 2003, 21:50

It's sent!

well, maybe your stream has some sort of TAG infront and you synchronize not at the first mpeg header but at some point within the heading TAG. that would explain your results.

Actually, it has a LAME Info tag, but it is skipped somhow (it shouldn't). The first valid frame is detected at offset 2326 (decimal) / 0x0916 (hex). The first valid frame should be at offset 0x00.
Anyway, my program loops inside the whole file until it finds a valid header. It seems that 0x00 doesn't contain a valid header.

well, the Xing/Lame header is trash for freeformat bitstreams.

your program seems to work correct, but you should not rely on the first frame you synchronize on only.



This post has been edited by robert: May 22 2003, 21:58

OK, problem fixed. The "bug" was in the "CheckValidHeader" function. My free format table entry had index 15 and the CheckValidHeader function reported bit rate index 0x0F (15) as non-valid MP3. Therefore it skipped some frames.
I am now checking only if the sync word is 2047 (decimal). I have tested it with MPEG 1, 2 and 2.5 files and it is always 2047.

I just checked getID3() for free-format support and it was broken too
I also had the problem of bitrate table index 15 being null, but used for free-format (rather than index 0).
Anyhow, getID3() now recognizes free-format MP3s, and calculates the correct bitrate, but only if a LAME/Xing-style header is present.

Can you elaborate on that? I in fact need the Xing/LAME header to properly handle free-format... The only way I can think to figure out free-format bitrate without the header is to scan the whole file byte by byte looking for sync patterns to calculate frame length - is there a better way to do that?

[edit] I have headerless freeformat working fine now - what I do is scan the file from the beginning for the next occurance of the 4-byte synch pattern (or the alternate 4-byte synch pattern, with the padding bit flipped), and assume that distance is correct, and seek through the file to the next offset based on that frame length (since freeformat is CBR), and check to see if an good synch 4-byte pattern is found there (plus-or-minus 1 byte to account for padding or not). This method might not be the most efficient, but it works... and how often do you see free-format MP3s? [/edit]

This post has been edited by getID3(): Jun 1 2003, 22:00

The Lame tag was broken in case of freeformat. It is now fixed in the cvs version.

Can you elaborate? Broken in what sense?

What about Dibrom's compile? I was able to calculate the correct data evaluating the LAME 3.90.3 header...

The Lame header was broken in case of freeformat, as the bitrate entry was 15 and not 0

Well, shouldn't it be 15; 0 is "bad" and 15 is "free".

no, bitrate table value 0 means free format, 15 means illegal.

What versions of LAME was the index-15 problem present for free-format?
What version will it be fixed for? 3.94?

Fixed in 3.94, present since I do not know wich version.

I just compressed 100kbps freeformat testfiles for all the 3.8x and 3.9x LAME versions I have, and this is what I found:

• Versions prior to 3.9x do not put LAME tag, and do not have the index-15 problem (the index-15 problem is only in the LAME tag, the actual frames have the correct index-0).
  
• LAME 3.88 varies the ModeExtension bit in the frame headers after the initial one, none of the other 3.8x or 3.9x versions do this.
  
• All versions of 3.9x up to and including the latest alpha I just downloaded right now ("LAME version 3.94 MMX (alpha 14, Jun 3 2003 07:00:26)") exhibit the index-15 problem in the LAME tag

Can you double-check that this problem has indeed been fixed? If so, why does it still appear to be broken?