NCDI
m (3 revision(s)) |
m (fix links) |
||
| Line 53: | Line 53: | ||
* 99 tracks = 0x1 -> 0x63 = 2 chars |
* 99 tracks = 0x1 -> 0x63 = 2 chars |
||
* 74 minutes = 4440seconds = 333,000 frames = 0x514C8 = 5chars (0xFFFFF = about 233 minutes!) |
* 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 [[/checksum]]) |
+ | * checksum mod'd at 4096 = 3 chars. (0-4095 = 0x0-0xFFF) (refer to [[NCDI/checksum]]) |
* 99 tracks (if we have per-track NCDIs) |
* 99 tracks (if we have per-track NCDIs) |
||
| Line 85: | Line 85: | ||
** We could use the XX-unallocated |
** We could use the XX-unallocated |
||
*** One to extend the Length to 3 bytes exactly. (6 chars) |
*** 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) |
+ | *** 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. |
** SACD can have up to 510 tracks - 255 in stereo, AND another 255 tracks in multichannel surround. |
||
Revision as of 13:16, 17 March 2008
Contents |
NUDI CD Id
This replaced DiscID, and will be generated by NUDI designed for NIPL, part of NUMB.
It would also be used in CDwiki.
Are we confused yet?
- Let's try again...
This is Nemo's attempt to improve on the CDDBp DiscID method, as used by CDDB and FreeDB.
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...
NCDI is a component part of NUDI, in turn a component part of NIPL (yes, I know that's kinda backwards) and CDwiki.
Goals
- 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)
In detail
- 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.
Implementation
- See also Bunch O Math
How much space should we allow for the discid then?
The basics:
- 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!
Possible problems:
- 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...:
- Links
NCDI is in accordance with NINS
