Skip to main content
Topic: CD-DA TOC (Read 11509 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CD-DA TOC

The need to store the table of contents of Compact Discs in FLAC files has been expressed before, in order to compute DiscIDs from separate tracks, or from CDs that have a data track. Indeed, cue sheets can't be used for that purpose. An easy solution would be to store the TOC as an ASCII string of numbers in a vorbis user comment (I'm not sure why that solution hasn't been chosen). An alternative would be a METADATA_BLOCK_APPLICATION equivalent to ID3v2's MCDI frame (Music CD Identifier). Software that already supports that frame could just dump the same data into this application block.

METADATA_BLOCK_APPLICATION
  • <32> Registered application ID: 4D434449 ("MCDI")
  • <32> TOC Header:
    • <16> TOC data length in bytes (excluding the length of the TOC data length field itself). Equal to 2 + (n * 8) + 8, n being the number of tracks.
    • <8> First track number
    • <8> Last track number
  • <n*8*8> n TOC track descriptors (one for each track plus the lead-out track):
    • <8> Reserved. All bits should be set to zero.
    • <4> ADR field: gives the type of information encoded in the Q sub-channel of the block where this TOC entry was found (should be 1).
    • <4> Control field: indicates the attributes of the track.
         
      • <1> if set and track is audio, track has 4 channels, otherwise 2; bit is not set when track is data.
           
      • <1> if set, track is data, otherwise audio
           
      • <1> if set, digital copy is permitted, otherwise prohibited
           
      • <1> if set and track is audio, pre-emphasis is enabled; if set and track is data, track is recorded incrementally, otherwise uninterrupted.
          The following values (expressed in bits) are defined:
         
      • 00x0: 2 audio channels without pre-emphasis
           
      • 00x1: 2 audio channels with pre-emphasis
           
      • 10x0: 4 audio channels without pre-emphasis
           
      • 10x1: 4 audio channels with pre-emphasis
           
      • 01x0: data track, recorded uninterrupted
           
      • 01x1: data track, recorded incrementally
           
      • 11xx: reserved
           
      • xx0x: digital copy prohibited
           
      • xx1x: digital copy permitted
    • <8> Track number. A value of AA (hexadecimal, 170 decimal) indicates that the track descriptor is for the start of the lead-out area.
    • <8> Reserved. All bits should be set to zero.
    • <32> Track start address (Logical Block Address in sectors, not MSF). Note that this is relative to the logical beginning of the media. DiscID hashes usually use offsets that include the mandatory 2 second pre-gap of the disc; for that purpose, one must add 150 to this LBA. Also note that while they are illegal, some discs have negative (signed) LBAs.
All numbers are unsigned, big-endian coded, unless otherwise specified. <Lengths> are expressed in numbers of bits. Please reply to this post if you spot any errors.

Edit 2: switched to the MCDI format.
Edit 3: added a mention about illegal signed LBAs.

CD-DA TOC

Reply #1
ok.  I'd like to hear spoon weigh in on this too.

you're right though, it could just be a tag like
CDTOC=1-3:150,231415,523412,934341

i.e. firsttrack-lasttrack:offset,offset,...,leadout.  much simpler than a separate binary block and useable for any format.

CD-DA TOC

Reply #2
I just learned that MusicBrainz discards the data track for its DiscID calculation; in that context, the last track is the last audio track and the lead-out offset is the end offset of the last audio track, not the data track's start point. Which is a shame, because that information isn't present in a TOC. So, whether a binary or ASCII TOC is used, with or without an additional field "is audio", it couldn't be used to compute a MusicBrainz DiscID reliably. I'm trying to sort this out with people in the know.

Edit: it seems that end points can be retrieved afterall, but also that they aren't needed. I've been told that the gap between the last audio track and the data track is always (150 + 2) seconds (11,400 sectors), which means that with the track type, MB's lead-out offset can be computed by substracting 11,400 to the data track's offset. Since I don't own a copy of the Blue Book I can't check this, but I'll assume it's correct.
Main post edited.

CD-DA TOC

Reply #3
The CD Toc should really be kept in the binary forum, it preseves any 2nd session details, even the flags for the audio tracks (such as copyright, etc).

CD-DA TOC

Reply #4
UUencode the binary and store as a text string?
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

CD-DA TOC

Reply #5
Spoon: alright, what's the format? Also, do you have any arguments against encoding the binary into an ASCII string and putting it in a vorbis comment field, like Nick suggested?

CD-DA TOC

Reply #6
The TOC can be about 820 bytes in binary form, as UUencoded I am guessing double that, programs might break with a 2K tag value.

CD-DA TOC

Reply #7
UUencoding is only 4/3 plus a few header / footer and per line bytes.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

CD-DA TOC

Reply #8
Spoon: it would be helpful if you could either give us or link to CD-DA's TOC format. Let's push things forward!

CD-DA TOC

Reply #9
Here you can find all about TOC. The document has 379 pages, but only pages 36–45 are relevant.
If age or weaknes doe prohibyte bloudletting you must use boxing

CD-DA TOC

Reply #10
I had a more recent revision of that document on my hard drive already, and didn't even know it :-/ Thanks eevan! I'll look into it.

CD-DA TOC

Reply #11
Alright, I think I got a clearer picture of what you (Spoon, other people) want. That's a ID3v2 MCDI (Music CD Identifier) frame, isn't it? It would have saved me a few hours if it had been made clear earlier (the contents of that frame aren't exactly the same as the actual data of a CD TOC).
I've edited the first post, let me know what you think.

CD-DA TOC

Reply #12
It look ok to me. Yes, the actual TOC has to be transformed (track numbers and track start times are BCD encoded, and times are expressed in MSF format) I think it's ok to use unsigned numbers, there is no need for negative values in TOC.
If age or weaknes doe prohibyte bloudletting you must use boxing

CD-DA TOC

Reply #13
Alright, thanks for your input, eevan! I have another question: LBA values are absolute to the program area, not to the beginning of the lead-in track. Meaning, in order to compute either FreeDB or MusicBrainz DiscIDs, one has to add 150 (the length in sectors of the lead-in track) to each track offset value.
My question is: what gets stored in a MCDI frame? The LBA value as reported by driver interfaces (starting from 0 in the program area), or the "corrected" value (LBA + 150)? I assume the former, but I can't confirm this.

CD-DA TOC

Reply #14
First, just a small correction.
Quote
LBA values are absolute to the program area, not to the beginning of the lead-in track

Lead-in track is before the program area and it's 3–4 minutes long. Those 150 frames (2 seconds) are the part of the program area and are the mandatory 2 seconds pre-gap. From the mmc3 spec:
Quote
The Absolute CD Address field gives the current location relative to the logical beginning of the media.
The first addressable sector (sector 0) is the first sector after this pre-gap (unless a drive can overread in lead-in). That's why the device interface reports it as 0. But in fact, it is 2 seconds after the end of the lead-in.

Maybe it's ok to store values as reported by the device interface and leave it up to the routine for calculation of the discid to "correct" the values if needed. I don't know how these routines are implemented.
If age or weaknes doe prohibyte bloudletting you must use boxing


CD-DA TOC

Reply #16
Thanks for the clarification eevan. Storing LBAs as-is makes sense, especially if the first addressable sector comes after the mandatory 2 seconds pre-gap. Adding those 150 sectors to LBAs is pretty much arbitrary and should be left to applications that need to do that (i.e., DiscID routines).
Now that you've cleared that up, I'm convinced most applications do just that (store LBAs untouched). If they don't... uh... where's the bug report button?

CD-DA TOC

Reply #17
What is the "standard" that WMP is using, since WMP already stores CD TOCs?

From what I gathered, it's the same as ("compatible with") ID3v2's MCDI frame. MusicBrainz's documentation, however, says it's not, although I'm inclined to believe it is inaccurate:

Quote
Ah, the mark of the beast. And certainly the most interesting. WMA strings (for which the WM/MCDI frame is one) are all encoded in little-endian UTF-16 (in the typical windows fashion). The WM/MCDI frame resembles (in many aspects) the MCDI frame of ID3v2. However, it consists of (all in UTF-16 hexadecimal):
Number of tracks, followed by track offsets in hexadecimal.

CD-DA TOC

Reply #18
So, is there a consensus on this? Spoon? Josh?

 
SimplePortal 1.0.0 RC1 © 2008-2019