WTF is a BD-ROM doing, pretending to be a CD?


We’re doing the beta for our application (which is going really well on both Mac and PC, and I have to thanks Juce for at least part of that…)

I went to some effort to make sure that I was able to recognize two CD readers, because some people have 'em (and I wanted to make sure that it at least didn’t do something bad). And that works.

BUT I have two reports of a phantom extra CD appearing on user’s machines! I got more information from one case, and it seems it’s coming from a “BD-ROM” which seems to be on their system - which seems to be a Blu-Ray CD-ROM.

What’s interesting is in both cases, FreeDB positively identifies the “CD” in the drive as being a German CD! I got a screen shot from one, identifying it as “Die Botschaft Meines Körpers/Dr. Diethard Stelz”.

I do quite a bit of error checking in my code to eliminate spurious CDs so I’m a little baffled as to how that could happen.

Here’s the actual code I’m using: StringArray names = AudioCDReader::getAvailableCDNames(); for (int i = 0; i < names.size(); ++i) { ptr<AudioCDReader> reader(AudioCDReader::createReaderForCD(i)); if (!reader) LOG(ERROR) << "Couldn't create reader for " << names[i]; else if (!reader->isCDStillPresent()) continue; else if (!reader->getNumTracks()) LOG(ERROR) << "No tracks for " << names[i]; else add(VirtualFile::CD, str(cd::getCDKey(reader.get())), volumes); // It's a CD. }

More than this, I’m actually going further and getting the track lengths to send to freeDB - or else they wouldn’t be seeing anything there - so this “BD-ROM” really has to look a lot like a CD.

Any thoughts welcome. It’s likely I’m going to find that CD key and then simply block those CDs from appearing but that’s pretty mysterious… :smiley:


That really is rather bizarre!

They’re not running virtual machines, are they? Could it be some kind of strange virtual CD-rom drive, e.g. the fake install CD that VMs provide for installing their drivers to the guest OS…?


Hmm, I think you’re close.

I’ve had two reports of this, as I said. One of them was from someone who appears to be a naive user, who I suspect just isn’t up to virtual machines and such. I’m going to try to get a little more information there.

The other is from someone I know, who referred to it as a “virtual blu-ray drive” mounted on his machine - but he’s running native Windows on a window box, I know this for a fact.

Blocking the CDDB key is hardly the worst thing to happen in the world - but the behavior is so specific that it’s excited my curiosity. :smiley:


All right! I have resolved this to my satisfaction, and if you read audio CDs in Juce, you should know about this special case. It might well be worth dealing with this in Juce…

It seems that in drives on some Windows machines (at least one is a BD-ROM drive), an empty drive results in the following:

[list][]AudioCDReader reader = AudioCDReader::createReaderForCD(i) is non-NULL,[/]
] reader->isCDStillPresent() is true,[/]
] reader->getNumTracks() is non-zero, but[/]
] reader->getTrackOffsets() returns an array with TWO elements, 0 and 0.[/]
] reader->getCDDBId() returns 0x2000001.[/*][/list]

It seems to me that getTrackOffsets() is not correctly formed?!

Anyway, it’s nearly trivial to avoid in code on my end, so I get to mark this bug as fixed…

EDIT: Changed the conditions of the bug slightly after a little more debugging.