Hydrogenaudio Forums > LAME tag CRC problem

Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech

SebastianG

Jul 8 2005, 17:14

Hi, there!

According to LAME tag specification one has to compute a CRC16 checkum (with initial value 0) over the first 190 bytes. The problem is: I've CRC16 code which seems to work perfectly for checking/protecting the frame's CRC checkums (with initial value 0xFFFF). I'm quite sure that the CRC implementation is bug-free. But I can't reproduce the lame tag's CRC correctly.

Since the LAME tag specification contains some errors here and there I started to doubt its correctness regarding the CRC computation.

CODE

00000000: FF FB E0 64 00 00 00 00 00 00 00 00 00 00 00 00 ¹Ód............
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020: 00 00 00 00 49 6E 66 6F 00 00 00 0F 00 00 00 75 ....Info.......u
00000030: 00 01 E1 38 00 04 06 08 0A 0D 11 13 15 18 1A 1C ..ß8............
00000040: 20 23 25 27 29 2B 30 32 34 36 38 3B 3F 41 43 46 #%')+02468;?ACF
00000050: 48 4A 4E 50 53 55 57 59 5E 60 62 64 66 69 6D 6F HJNPSUWY^`bdfimo
00000060: 71 73 76 78 7C 7E 81 83 85 89 8C 8E 90 92 94 99 qsvx|~üâàëîÄÉÆöÖ
00000070: 9B 9D 9F A1 A4 A8 AA AC AF B1 B3 B7 B9 BC BE C0 øØƒíñ¿¬¼»_¦À¦+¥+
00000080: C2 C7 C9 CB CD CF D2 D6 D8 DA DC DF E1 E5 E7 EA -Ã+--¤ÊÍÏ+__ßÕþÛ
00000090: EC EE F0 F5 F7 F9 FB FD 00 00 00 39 4C 41 4D 45 ý¯§¸¨¹²...9LAME
000000A0: 33 2E 39 37 61 01 CD 00 00 00 00 2D FE 00 00 34 3.97a.-....-_..4
000000B0: FF 24 07 74 6D 00 01 40 00 01 E1 38 DC 8F 89 EF $.tm..@..ß8_Åë´

My CRC16 calculation over the first 190 bytes with initial value 0 results in 8B4B instead of 89EF.

Question: Is the specification correct (and I'm rwong / have buggy code) or should I calculate the checksum differently. LAME is appearently producing 89EF (see last 2 bytes) in this example.

edit: also: how should an application check the presence of a LAME tag ?
- by checking the "LAME" string (only)
- by checking the CRC (only)
- by checking both ?

Sebi

SebastianG

Jul 8 2005, 18:51

After checking what LAME does here I found out that LAME uses actually two different CRC update functions (In bitstream.c is the 'correct' one, which must be used for calculation of the frame's CRC checkums -- In VbrTag.c is another one which is used for the LAME tag's CRC and is not compatible to the first one. The 2nd update function looks somehow twisted/reversed).

Sebi

Jojo

Jul 9 2005, 06:06

you could take a look at AIs source code and see how it is done

SebastianG

Jul 9 2005, 06:38

QUOTE(Jojo @ Jul 9 2005, 01:06 PM)

you could take a look at AIs source code and see how it is done

Sorry, I should have said that my problem is solved. (I'm just using a VbrTag.c compatible CRC_update function for the tag now).

I just wanted to mention that the 16 bit checksum right after a frame header must be calculated with another crc_update function whereas the LAME tag specification suggests it's the same algorithm and since a CRC16-protection of frames is already part of encoders/decoders routines can be reused. This is obviously not true.

BTW: I'm really confused about the format that "Fix MP3 header" (Foobar) produces. Doesn't look very compatible to the LAME tag specification I linked above. Can somebody explain this ? Is this another tag revision ? Where is it documented ?

Sebi

Gabriel

Jul 9 2005, 10:38

If you want to send me an update/clarified INFO doc, I will replace mine.

Btw, Rob Leslie already pointed this undocumented point in the specs.
Unfortunately it is too late to change the specs for Lame V3.

dev0

Jul 9 2005, 10:47

QUOTE(Gabriel @ Jul 9 2005, 05:38 PM)

If the spec is updated another time could the replaygain fields please include the track peak?

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.