NCDI/Checksum

From ThorxWiki
(Difference between revisions)
Jump to: navigation, search
m
m (4 revision(s))
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
;Why 4096 and not 255 or 65536?:Short answer - Cos FFF in hex is a nice size for the checksum to be
 
;Why 4096 and not 255 or 65536?:Short answer - Cos FFF in hex is a nice size for the checksum to be
 
=== Long answer... ===
 
=== Long answer... ===
DiscID checksum was based on
+
[[DiscID]] checksum was based on
 
* track offsets in seconds
 
* track offsets in seconds
 
* mod 255 (it should have been mod256, but little difference I think)
 
* mod 255 (it should have been mod256, but little difference I think)
Line 12: Line 12:
 
I then tested with mod256, mod4096 and mod65536 to see how they fared.
 
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
+
* mod256 - clearly better than [[DiscID]] - this is only attributable to the difference in using frame-level offsets
* mod4096 - clearly better mod256 - more number for the checksum to spread over = less chance of duplication
+
* 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
 
* mod65536 - marginal improvement on mod4096 - not enough to be worthwhile using compared to mod4096 however
   
I hope to have a graph of this available shortly...
+
The following graph shows respective counts of Unique and duplicate ID's for each type of ID.
  +
[http://www.cheeky.house.cx/~nemo/visible/nudi/ncdi_countcompare-tracks_uniq.png the big confusing graph]

Latest revision as of 02:04, 25 October 2007

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

[edit] 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