> I've been playing around with adding support for the CD Index to my
> program, alongside the CDDB support. Since the program is already an
> unusual CDDB client (looks up discs in batches, not just the one in the
> drive), and I'm now making the same program be a CD Index client, I've
> noticed a number of minor issues that I thought were worth mentioning.
Sorry for not getting back to you sooner -- I've been digging out from
under all the e-mail I got right off the bat.
> -- How stable is the "http://www.freeamp.org/cgi-bin/cdi/hget.pl?"
> URL? Is it reasonable to hard-code it into a program that's not a simple
> CD Index client? Is the host likely to change? The path to the CGI
> directory? The name of the script? The name of the "id" parameter?
This is all pretty stable now. I've also included XML support --
instead of using hget.pl or get.pl use xget.pl.
> -- I am currently parsing the HTML result from the hget.pl script in
> a simple-minded way. I am ignoring the tags in a super-simplistic way,
> and I'm assuming things about the HTML source to make my coding easier,
> like assuming that each data item will be on a separate line. I'm
> assuming things about the format of the output, like assuming that the
> word Artist comes before a colon and the name of the artist comes after
> it. Is this a good long-term way to extract the CD Index information from
> a program?
Use get.pl instead -- it returns a mcuh simpler format.
> -- CDDB entries use Latin-1 characters so they can accomodate
> titles, performers, and track names with characters other than those in
> ASCII. What's the CD Index approach for this?
Right now we're using the ISO-88591 (is that the right number?)
character set, but I would like to move to UNICODE in the future.
> -- CDDB has a few concepts that CD Index doesn't. Each disc has a
> "category". I think this has little value, and I'm glad CD Index doesn't
> have it. There's also extended data for the disc and for each track. Any
> plans for further information for each CD for CD Index?
Yes, but I haven't really decided exactly what extra data to store.
> -- I can't tell from any of the examples how I'm supposed to handle
> CDs with non-audio tracks. Most hybrid CDs with both sound and data hide
> the data before the start of the first track, but I know that some CDs
> have both audio and data tracks. I researched this when I started working
> with the CDDB, and I discovered that the disc ID for the CDDB includes
> all tracks, including data tracks, but the data in the CDDB entry has
> track names (and extended data) only for the audio tracks, and it numbers
> the audio tracks in a way that skips any data tracks as if they're not
> there. What's the CD Index approach for these discs?
Enter [data track] for the title of a data track.
> -- I did a lookup on an album with 15 tracks, Bad Religion's
> "stranger than fiction", ID FUOVM1t7bROszZlP5Sk0Bzfp_Ow-. The returned
> information is for an album with 17 tracks, presumably a different
> version of the same recording with bonus tracks. Luckily, the first 15
> tracks happen to match. What's the CD Index approach for this sort of
> thing?
I'm working on fixing such problems -- the latest submission scripts
are much more careful about checking the number of tracks and so forth.
We'll need to put more safeguards in place...
Another thing that I was thinking about is the data that is contains in
the CD Researcher -- I am working on an XML submission process. Could
we build a feature into the CD Researcher that allows the user to
upload the data to the CD Index?
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- robert nospam at moon.eorbit.net http://moon.eorbit.net/~robert