NCDI/Checksum
From ThorxWiki
(Difference between revisions)
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
