NCDI/Checksum
From ThorxWiki
				
								
				(Difference between revisions)
				
																
				
				
								
				m  | 
			m (link fix)  | 
			||
| 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 - a clear improvement over mod256 - more numbers 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  | 
||
Revision as of 01:15, 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
 
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