I have MP3d most of my CDs and built a database of tracks, artists,
composers, performers, orchestras, etc. It's incomplete because I
can't get this information usefully out of cddb.
I have a small LCD panel I can use to display CD information. But because
there is little structure to the information in cddb, it is hard to write
code that picks out a sensible string to display. Sometimes the entry
is too long to show it all, sometimes there are just a few meaningless
characters without the context of the previous and next tracks.
> I don't think that CDDB's extended data was limited, but the
> format left something to be desired. Do we really need all of this
> heavyweight track/title/movement reordering stuff?
Some of that seems like overkill to me too. But I always thought that
the one-per-disk field for Artist was far too limited. Classical disks
(and a few non-classical disks) just don't fit. It would be really nice
to have a layer between track and disk to attach common information.
> ...Simple formats are better. If CDDB was more complex than sending
> a line or two of query info, most players wouldn't implement it.
This is certainly true. A well-designed protocol can be simple
and still do complicated things.
> Don't re-implement stuff. Can't we use CDDB's ID generator method?
Yes, but it isn't very good. It throws away information and doesn't
hash what it keeps very well. Because it is well established, we need
to support it for backwards compatibility, but we can do better---for
example, we could just keep the whole TOC for identification and use
a guaranteed unique key for further transactions. The TOC is only a
few hundred bytes, and you can't get much simpler than just sending
it verbatim.
A quick, simple, direct drop-in replacement for cddb is a good idea.
But a well thought-out, fully-featured extension is a better idea.
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK