Problems with AudioCDReader

#1

Hello,

I’m a newbie on JUCE forum and really appreciate your superb library. I’m trying to implement several functions using AudioCDReader class to handle CD and have faced the following two problems:

One is that when I call ejectDisk() function a linking error occurs, because it seems to be declared only to the header file. I couldn’t find the source like juce_win32_AudioCDReader.cpp. Then the other is that getCDDBId() always returns 0.

Do you have any plan to support them in the near future? Or did I mistake something?

Programming Environment:
Mac OS X 10.5.1 / Xcode 2.5 / JUCE v1.46 from SVN

Best regards,
Jazzunko

#2

Haven’t got any immediate plans to finish those - I’d actually forgotten all about them and nobody’s ever asked before!

#3

Thank you for the quick reply!
Okay, I know you’re very busy, but if possible I hope to add them to one of the plans.
And then, I’ve handled AudioCDReader class for one week, so I think I can report its behavior to you.
Anyway, I’m really grateful to this library and you!

#4

Thanks, I’ll add it to my long list…

#5

Hello! I’m about to embark on this code for you. :smiley:

But I have a couple of questions before I start so I don’t screw up.

  1. I assume there’s a reason that the track offsets can’t be computed from getPositionOfTrackStart()?

  2. It seems as if the file juce_mac_AudioCDReader.mm is, well, a .mm file - I’m not quite sure how to care for and feed such files in a disciplined fashion, or really, exactly what they are! :smiley: (That part I can look up of course.) Hints on what NOT to do here? My assumption is that if I carefully add C++ to this file and rebuild JUCE I’m fine…?

  3. Looking at the code for juce_win32_AudioCDReader.cpp, it seems to me as if I replaced getMSFAddressOf() with something that returned the track offsets as read from the .TOC.plist XML file for the CD in question, I’d get the right CDDB id. Is this correct?

  4. Bonus question: is there some simple utility on Mac OS/X that will just print out the CDDB id for a CD that I have so that I can check my work?

  5. Extra bonus question: is anyone talking to FreeDB or Gracenote already and has code to share or pointers? My plan is to use libcddb, which is LGPL.

#6

Thanks for taking a look at it! It’s eons since I wrote the windows cddb stuff so can’t really remember how it all works, but I do vaguely remember that the track start times aren’t quite right for calculating the cddb number. If the TOC file does indeed have the right numbers then it should be pretty easy to do the calculation.

I don’t think you’ll get yourself into too much trouble if you stick to c++!

#7

All right!

So I have code, which I attached(*). This includes complete unit tests - however, I don’t know if the final CDDB id I compare against in the tests is in fact correct, I still have no alternate way to compute the CDDB id to compare it with (I wasn’t able to build CD paranoia on the Mac…) I’ll figure this out (any hints accepted though - all I want is some Mac utility where I put a CD in the drive and it prints the cddb id of that CD…)

But I’m not able to get the JUCE build to recognize my changes - because it seems as if JUCE_USE_CDREADER isn’t turned on in the XCode JUCE build by default (which seems a little strange to me…)? What’s the “government approved” way to turn it on - should I be using the new JUCER on JUCE itself, or should I just change the XCode by hand (but then, each time I update my JUCE, I’ll have to turn this on again…)?

    • UPDATE: I can’t attach the files because, GRRR, “The extension h is not allowed” - unfortunate, since this is a C+±oriented discussion forum. I’ll push this to my open source repo “presently”
#8

Update: I found a reference CD to use and manage to reproduce freeDB’s CDDB id for it from my code - which I then put into the test. Yowza!

I’ll upload at some point soon the code for you to peruse…

#9

Cool, thanks!

#10

All right, we have code here, with a unit test (using Google’s gtest facility).

I structured everything as include files because it was easiest to write the tests but it could be done any way you like…

#11

So this is no longer my last word on the subject of “fixing up AudioCDReader’s getCDDBId()” - please see this more general thread here.

#12

Cool, I’ll give that a whirl as soon as poss…

#13