I see (as reported here http://gabriel.mp3-tech.org/mp3infotag.html ) the lame tag is crc16 protected.
Now, knowing every audio mpeg frame may be crc16 protected as well, lame already has its own routine
and I thought the same algorithm was also applied for lame tag. Well, it is not.
Aside from the algorithm starting value (0xffff in case of audio frame, 0x0000 in case of the tag),
the "CRC_update_lookup" routine into VbrTag.c (which uses a lookup array and it's fast indeed) gives
different results from the usual "CRC_update" routine into bitstream.c
Now, does any software aiming to verify both frames and lame tags need to implement two different
crc16 routines (I hope it doesn't) ? Isn't this a waste of space/code ?
Can anyone explain why ?