NUDI CD Id
It would also be used in CDwiki.
Are we confused yet?
- Let's try again...
The algorithm to determine the ID is not currently set in stone, and awaits final testing of the concept. A whole Bunch O Math has been devoted to this already...
- improved uniqueness to reduce chances of collissions.
- semi-backwards compatible with existing FreeDB DiscID, and largely calculatable from existing FreeDB data.
- cleanly handle collisions
- considerations for dvd-audio and sacd.
Summary of plan
- Take the DiscID method
- checksum, length, tracks
- Re-apply using greater resolution from original CD, or FreeDB complete entry
- tracks, length, checksum
- also allow for additional information
- uniqueness guarantee (for ID's that would otherwise be duplicate but should not be), track# (so the ID can be track-specific)
- A FreeDB complete entry provides us with almost all the nescessary details:
- Number of tracks: yes
- Track offsets: yes (though offset as +150)
- Total length: yes (though only at 1/75th the resolution - ie, in seconds, not frames)
Obviously the track offsets can be corrected. The true accurate length can only be guessed at however.
- See also Bunch O Math
How much space should we allow for the discid then?
- 99 tracks = 0x1 -> 0x63 = 2 chars
- 74 minutes = 4440seconds = 333,000 frames = 0x514C8 = 5chars (0xFFFFF = about 233 minutes!)
- checksum mod'd at 4096 = 3 chars. (0-4095 = 0x0-0xFFF) (refer to NCDI/Checksum)
- 99 tracks (if we have per-track NCDIs)
TTLLLLLCCCNN `---|---|-|-- Track count `---|-|-- Length in frames `-|-- Checksum `-- Track number
Interpreting the above hexadecimal string as a number, it would be six bytes long, an awkward number. Having an 8-byte NCDI would be much more comfortable, so we can safely devote two more bytes to extending the length by inserting a CD duplicate count and including some padding for futureproofing
TTLLLLLXXCCCDDNN `---|---|-|-|-|-- T = Track count `---|-|-|-|-- L = Length in frames `-|-|-|-- X = padding for futureproofing (across the mid-point) `-|-|-- C = Checksum `-|-- D = NCDI Duplicatation number (aka count, aka uniqueness guarantee) `-- N = Track number
To refer to an entire CD, we would leave NN as 00 - this at the end makes it easy for a human to distinguish between a cd-level and track-level NCDI. DD would be '00' to refer to an unknown Disc (queries would use this, for example), while the first allocated CD would have DD=01, the next CD to have an otherwise identical NCDI would have DD=02, and so on. This means we have a limit of only 256 CD's with otherwise identical NCDI's!
- How do we do a query for a CD when we don't know the CD duplicate number?
- If the CDWiki gets a query for a NCDI with the CD duplicate number as 00, it should return a list of CDs whose NCDIs have any duplicate number.
- How do we allocate duplicate numbers?
- Presumably when someone files a new CD with the NCDI server, the server will issue a new duplicate ID, for that CD.
- What is there to stop two different NCDI servers from giving out different duplicate numbers for the same CD?
- Nothing. That's the main flaw in the suggestion. :(
- What about DVD-Audio and SACD? Will this be sufficient? Will the method even be similar?
- We could use the XX-unallocated
- One to extend the Length to 3 bytes exactly. (6 chars)
- One to be a marker to give "type of disc" information. (CD, SACD, CD/SACD hybrid, DVD-A, DVD-Vid, etc)
- SACD can have up to 510 tracks - 255 in stereo, AND another 255 tracks in multichannel surround.
- We could use the XX-unallocated
(Is there a requirement that the 255 stereo tracks must be down-mixed versions of the 255 surround-sound tracks?)
Multisession and enhanced CD's may prove tricky...:
NCDI is in accordance with NINS