Two different crc16

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 ?

Elio


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot