As you might have deduced, I’m trying to get CDDB data through JUCE…
and am now realizing that I don’t have quite enough information to do so in the correct way - and am going to suggest a change to JUCE (that I could write if Jules could put it in).
Now, the canonical way to get disk information is the “query” command (about a page down on that), which has commands like:cddb query discid ntrks off1 off2 ... nsecs where discid is the CDDB disk ID, ntracks is the number of tracks, off1…offn are the track offsets in frames and nsecs is the total length of the disk in seconds.
Unfortunately, the AudioCDReader class doesn’t give you all this information - specifically, we’re missing track offsets and the length of the disk.
I’m proposing to add these two accessors to the AudioCDReader class.
I can get these values for the Mac.
Looking at the implementation for the PC, it seems that you only have access to the track offsets in seconds, not frames (one frame is 1/75 of a second)… it’d be nice to get those in frames or I could fake it by multiplying them by 75…
For the moment, I’m going to fake it by using this other command!cddb read categ discidand simply commit the sin of iterating through all the categories until I find the disk! Fine for development, but I can’t do that for production as I don’t want our clients to hit the FreeDB 11 times for each query…
Sounds like a good addition. I’m a bit puzzled by what you say about only getting the track offsets in seconds on the PC - the AudioCDReader class returns everything as sample positions, so you get frames, you just divide by 588… Or am I misunderstanding?
By the way, now that I’m inside juce_AudioCDReader.h … I don’t see what the Mac-only “compareElements” method is doing, or even that it’s ever called…?
EDIT: Aha, never mind, it has to do with your sorting mechanism - this doesn’t need to be exposed in the header, however…
Actually, I think it can all go into the “dustbin of history” because I’m no longer expecting to look at the actual file for each track to get the track length. Here’s the scoop - correct me if my reasoning is wrong.
I wrote something that parses the .TOC.plist - a virtual file that OS/X puts at the base of every CD volume. I need this at least to get the offset for the first track which can’t be gotten any other way.
But while I’m there, I’m getting the track lengths for all the tracks in frames. Now, I believe that CDs are only written in whole frames, so the length in frames * the number of samples per frame should be exactly the same as the length computed in samples. (And certainly this operation does give me the right cddb ID - for one CD, granted, but I’ll be trying others - so it’s doing something reasonable…)
So I don’t need to read the file lengths at all (though I’m doing so here just for testing for a while). Am I correct?
Hoping you’re having a loverly summer in Blightey! It looks like I shan’t be there for at least a year so you can let your wives and daughters roam freely.
Yes, you’re definitely wiser to use the toc file rather than reading the audio files - I wouldn’t trust the driver that generates the audio data to make the files exactly the same length as the toc says they should be - it might do things like adding gaps at the end for the track spacing, etc.
Yes, Blighty has been having a really lovely summer this year, which makes a change from the last few years of washouts!
Great then, I shan’t even bother to check against the file lengths. Brilliant.
I should have the code and deltas of your old code up in the next couple of hours.
I have this all as a git repository of course so there’s probably some way I can push to some experiment repo of your or you can pull from me…? Not really quite sure how to do this.
