View Full Version : Proposed CD TOC storage standard

12-13-2007, 09:14 AM
As it stands very few (tagging formats) have provisions to store CD TOC (CD Table of Contents) in the ID Tags, why is it important? the TOC allows for precise identification of an audio file, freedb ID / any online meta data provider, even Accuraterip IDs can be all calculated with the TOC without the need for the CD. Time to clear up the mess that exists.

Those with CD TOCs storing abilities:

Any Id3v2 format (mp3)
WMA **
Wave ++
iTunes Tagging (m4a)

Those without:

Vorbis Comments (ogg, flac)
(ape2) Wavpack, musepack

2 'Standards' of storing the CD TOC:

CD drives give out 2 table of contents, either LBA (logical block address) or MSF (minute seconds frames), one can be calculated from the other: for example: 0 LBA = 0 / 2 / 0 MSF (or 2 seconds in). This is given out by the CD drive its self.

Here is where it gets complex, 2 seconds in (MSF) really is 150 LBA (if you take the disc start into account), the reason CD drives return 0 LBA, is for a valid audio CD it has to have 2 seconds of lead-in, anything less is not valid, so everything is referenced from 0 LBA, not 150 LBA.

Many metadata providers use 150 as the starting point when calculating the database identifier (such as freedb id), there is considerable confusement about which should be stored. After much research (existing programs) it seems there are 2 standards:

If the raw (as I call it, or untouched LBA toc is to be stored, ie a binary TOC) it should be stored as is, no adding of 150, to my best knowledge Cdex and Audiograbber both do this in ID3v2.

If a string representation is to be used (ie like WMA which is the only one), then that standard is:

TrackCount + (LBA0+150) + (LBA1+150)

..but stored in Hex, so a 2 track cd might be:


There is a slight issue if a CD-extra TOC is to be stored, this is another matter and I will post about it later.


Proposed new standards (we will implement these by Jan 2008)

APE2: Nice an easy, lets call the field 'cdtoc' (unless someone is storing already) and store as a binary item (raw untoched CD TOC).

Ogg Vorbis: Vorbis comments are 'stuck in a rut' if you ask me, not even able to decide simple standards such as Album Artist, Ratings, Album Art, Disc Count, Track Total.
Anyhow, VC cannot have binary items, so go with the string representation as above.

FLAC: 2 choices here, either go the same as Ogg Vorbis, or make a special 'chunk' area like with Album Art, Cue Sheets, etc, it should not really go in RIFF chunks as they do not need to go back to wav files.

iTunes Tagging: Seems to be done, a little like WMA using the rare field iTunes_CDDB_1, Chungalin says it is:
- Leadout sector LBA address
- Number of tracks
- For each track: starting track sector LBA address

ie: 9D07F70B+153089+11+150+12007+27749+43216+55300+664 49+81003+96490+10955 1+125279+142145


** Highlighting WMA as Microsoft's left hand, does not know what the right hand is doing:


Basically it says that WM/MCDI should be the same as ID3v2, ie a binary dump, but WMP11 is storing as a unicode string, nothing binary about it at all, also it is worth noting WMP is adding 150 to each LBA address (see above).


++ There are a number of wave tagging standards, BWF, Cart, INFO List, even 'tag ' (id3v2 chunk). There is provision to store the toc if 'tag ' is used, so wave is covered.