NCDI/Checksum

From ThorxWiki
(Difference between revisions)
Jump to: navigation, search
m

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

Personal tools
Namespaces

Variants
Actions
Navigation
meta navigation
More thorx
Tools