Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Notes on format of CDInfo.cidb

28 views
Skip to first unread message

jaegan

unread,
Feb 14, 2002, 9:38:59 AM2/14/02
to
Well, after growing tired of waiting on someone else to write a program
which could deal with the CD Info.cidb file that iTunes 2 uses to store
info about audio cds, I sat down and worked on it myself. Here are the
results, in hiopes someone will put them to good use. (I'd like to see
something like the old CD Coyote app for this new file format)


Notes on the file format of the "CD Info.cidb" used by iTunes 2 to store
data for audio cds.


63696462 \\ 1st 4 bytes = file type "cidb"
00000014 \\ next 4 bytes = unidentified numeric "20" version maybe?
00002868 \\ total file size
00010000 \\ next 4 bytes = unidentified numeric "65536"
00002814 \\ size of record portion of file (total - indx size)
616C626D \\ label of first record "albm"
00000C00 \\ number of bytes from albm to albm "3072" (ie this is the
\\ total record length)
00000A3A \\ length of 1st record in bytes "2618" (ie this is the actual
\\ part of the above which is in use)
616E616D \\ field label "anam"
00000042 \\ "66" length of the anam section in bytes, including the anam
\\ header
001c \\ length of field in characters "28"
\\ next 56 bytes are the 28 charaters of the field stored in 2
\\ byte/character format (unicode?)
61757468 \\ field label "auth"
00000028 \\ "40" length of the auth section in bytes, including the auth
\\ header
000F \\ field length in characters "15"
\\ next 30 bytes is field data
676E7265 \\ field label "gnre"
00000018 \\ "24" length of the gnre section in bytes, including the gnre
\\ header
0007 \\ length of field in characters "7"
\\ next 14 bytes is field data, 2byte/char
79656172 \\ field label "year"
0000000C \\ "12"
\\ next 4 bytes are the year
6D656964 \\ field label "meid"
0000004A \\ "74" length of the meid section in bytes, including the meid
\\ header
\\ next 66 bytes are field data, some sort of identification
\\ numer i think
\\ always of the form <space>then 32-character
\\ number in 2-byte/char format
6D756964 \\ field label "muid"
00000018 \\ "24" length of the muid section in bytes, including the muid
\\ header
0007 \\ length of field in characters "7"
\\ next 14 bytes are the 7 digit number, 2-bytes/char
\\ a little googling seems to indicate this is the cd's Muze-ID
70726F67 \\ field label "prog"
0000001c \\ "28" length of the prog section in bytes, including the prog
\\ header
\\ next 20 bytes are a play order list for the 10 tracks on
\\ this disc
7472616B \\ field label "trak"
000000FE \\ "254" length of the trak section in bytes, including the
\\ trak header
00000001 \\ track number
746E616D \\ field label "tnam"
00000040 \\ "64" length of the tnam section in bytes, including the tnam
\\ header
001B \\ length of field in characters "27"
\\ next 54 bytes is field data
616E616D \\ field label "anam"
00000042 \\ "66" section length in bytes get the idea?
001c \\ length of field in characters "28"
\\ next 56 bytes are the 28 charaters of the field stored in
\\ 2 byte/character format (unicode?)
61757468 \\ field label "auth"
00000028 \\ "40" section length in bytes get the idea?
000F \\ field length in characters "15"
\\ next 30 bytes is field data
676E7265 \\ field label "gnre"
00000018 \\ "24" section length in bytes get the idea?
0007 \\ length of field in characters "7"
\\ next 14 bytes is field data, 2byte/char
766F6C6D \\ field label "volm"
0000000C \\ "12" section length in bytes get the idea?
\\ next 4 bytes are custom volume level info for playback
79656172 \\ field label "year"
0000000C \\ "12" section length in bytes get the idea?
\\ next 4 bytes are the year
73747274 \\ field label "strt"
0000000C \\ "12" section length in bytes get the idea?
\\ next 4 bytes are custom start of track info
73746F70 \\ field label "stop"
0000000C \\ "12" section length in bytes get the idea?
\\ next 4 bytes are custom end of track info
\\ Following this, the rest of the cd tracks are included, in
\\ the same format
\\
\\ After the last track, there is an amount of blank space
\\ (total record minus used portion of record), and the next
\\ record in the database follows, starting with the "albm"
\\ label
\\ following the record portion of the file, is a segement
\\ labelled "indx"
696E6478 \\ indx
\\ next 4 bytes are the length of the indx in bytes
\\ next 4 bytes are the total number of records (ie the number
\\ of cds)
\\ so far i haven't been able to make any other useful
\\ determinations about the index section

Now, the final kicker to this story, is that entries pulled from the
cddb don't always have
all these fields. I wrote a q&d program that gives me a txt listing of
cd and artist (which was
all i wanted - a lot of work for no more than that, eh?) and out of my
~500 cds, about 3-4 came
up with odd info (ie, not the cd title / artist) Examining the .cidb
file, the records for
those discs were missing one or more fields, and in at least a couple of
cases, iTunes didn't
recognize the cd (had to get track names from the cddb again.

So, There it is. Have fun with it. Hopefully someone else can figure
out the parts I couldn't (primarily the indx, the 4th set of bytes
(65536), and what the 32 digit id number is.)

If Apple won't give us the documentation, we'll write it ourselves.

comments to jaegan at jaegan dot net
flames to /dev/null

0 new messages