Notes about CDDB id weirdnesses and JUCE

General JUCE discussion
1

Jules incorporated (and fixed) my code to improve the AudioCDReader to get CDDB ids.

There are some… interesting results now I am successfully using this to get CDDB data (using the LGPL library libcddb).

I have a series of tests using a “reference CD” that I had lying around, Kate Bush’s “Never For Ever”.

libcddb only needs the track lengths in frames and the total length to function - it doesn’t need the CDDB id (but the track lengths are part of the new functionality in JUCE).

I used the track lengths as returned by JUCE and I got the album back from freedb on the first try.

BUT in fact, I got THREE copies of the album from the one call, with different cddb ids:
http://www.freedb.org/freedb/rock/8508c00b
http://www.freedb.org/freedb/rock/8a08ca0b
http://www.freedb.org/freedb/rock/8d08cf0b

None of these CDDB ids are the one that JUCE is computing(!!) - - http://www.freedb.org/freedb/rock/9608bd0b

and all of these albums are correct!

I’m not entirely sure what’s going on here. The actual definition of the CDDB id calculation is subtly ambiguous (because of rounding issues in computing the length) but I can’t see how there are four possible results…

This is a Pretty Good Outcome anyway. I’m getting too much data - and I had to write a deduplicator for albums, but that was fun and fast, and I would have had to have done that anyway.

2

I’m guessing that the three copies are just because there are 3 different pressings of that album…?

So if the track lengths are being retrieved correctly, I guess the error must be in the calculation in AudioCDReader::getCDDBId(). There’s a bodge number in there: 88200 because of the weird “first track starts at 2 seconds” thing that seems to be a part of the CD spec but which I don’t exactly understand. You could try fiddling with that and try to make the data to match up.