NCDI/Checksum
From ThorxWiki
(Difference between revisions)
(first draft) |
m (4 revision(s)) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
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. |
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. |
||
| − | ;Q:Why 4096? |
+ | ;Why 4096 and not 255 or 65536?:Short answer - Cos FFF in hex is a nice size for the checksum to be |
| − | ;A: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) |
||
| − | ;Q:Why not 255 (FF) or 65536 (FFFF) then? |
+ | [[NCDI]] checksum is based on |
| − | ;A:255 and 65536 were both tested with a conversion script which generated NCDI's from the FreeDB database. 65536 gave no appreciable improvement for guaranteed uniqueness, and 255 was ''(awaiting actual data for this ;)'' |
+ | * 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. |
||
| + | [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
