Two different crc16

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Two different crc16

I see (as reported here ) 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 ?


Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Lame-dev mailing list
[hidden email]