What I'd like to see is this is a generic format that is extensible enough
to be a generic Multimedia Indexing Format (MIF?) that can span CD's (audio,
multisession), DVD's (video, future audio), and even MP3's. We have
a great opportunity here, and simply designing a replacement for CDDB would
be very limiting in scope.
What I'd like to see is something to the effect of:
Track { // many additional fields could be borrowed from ID3
Id 1234567890 // some unique identifier
Flags admv // audio/data/mp3/video/etc
Genre RP // can be multiple genres
Title "Blah"
Desc "Foo"
Artist 12345 // Artist's index in the DB
Collection 12345667889 // collection that this track
// belongs to
...
}
Artist {
Index 12345 // unique artist index in DB
Name "Joe.Artist"
...
}
Collection {
Index 1234565677 // some unique identifier for this CD/DVD/
// collection
Flags cdC // CD? DVD? compilation? etc
Genre RPG // Genre (can be several)
Title "CD Title"
Artist 12345 // index of the artist
Desc "Description"
...
}
Most importantly, this allows:
* Per-track identification lets you identify songs that are on multiple
CD's or in formats (such as MP3) without having to enter them in several
times.
* Artist identification logically groups collections and songs by artist,
which makes sense.
* Collections can group tracks together to represent a CD, DVD, directory
of MP3's, etc.
The actual written format of the index should not be a concern at this
point; it can be ASCII, XML, HTML, whatever. The key here is to identify
the structure of the index and database.
As for backwards compatibility with CDDB, I think that the new format
should be able to serve the CDDB protocol by translation so that existing
CDDB apps could point the URL to a MIF server. Naturally, a MIF aware
client would have access to the full information. To avoid any legal
issues with CDDB, however, I think that information should be entered
strictly from scratch for the new DB.
This format doesn't conflict with the various proposals made for classical
music that may require additional fields.
The numerous database synchronization issues are also unimportant at
this point in time. It can be worked out after the format is ironed out
and agreed upon.
Personally, I feel that we should begin the DB compilation as soon as
possible. I think that the cdindex is too limited in scope, so something
more comprehensive is needed. If we accumulate 2000 cdindex entries before
the format is changed, those 2000 entries would have to be redone.
Just my two cents...
-- Dave Ahn / ahn nospam at vec.wfubmc.edu