NCDI/Checksum

Revision as of 12:55, 3 May 2002

The checksum is handled by taking each track offset and summing them together, resulting in a "large number", which is then brought into the range of 0-4095 by applying mod4096.

Why 4096 and not 255 or 65536?

Short answer - Cos FFF in hex is a nice size for the checksum to be

Long answer...

DiscID checksum was based on

• track offsets in seconds
• mod 255 (it should have been mod256, but little difference I think)

NCDI checksum is based on

• track offsets in frames

I then tested with mod256, mod4096 and mod65536 to see how they fared.

• mod256 - clearly better than DiscID - this is only attributable to the difference in using frame-level offsets
• mod4096 - a clear improvement over mod256 - more numbers for the checksum to spread over = less chance of duplication
• mod65536 - marginal improvement on mod4096 - not enough to be worthwhile using compared to mod4096 however

The following graph shows respective counts of Unique and duplicate ID's for each type of ID. the big confusing graph