Read TOC problem with USB flash drive emulating optical drive




I’m not sure if this is the right place to post this but I’ll give it a shot anyhow.

Anyway, I’m developing the firmware for a USB bridge chip to be used in a USB flash drive. The drive supports CD-ROM emulation as well as loading in of an ISO-9660 image file. This requires support for the “Read TOC” SCSI command. This has been implemented this and it works for most cases. However, whenever any software that has any drive letter access feature is running, the system either crawls(99% CPU usage by the process “System”), or gives me a BSOD. I’ve isolated the problem to my Read TOC implementation, since when I take it out, it works(but no ISO-9660 support).

I’ve read the SCSI MMC-3 specification regarding Read TOC response, but I still don’t get what exactly I’m supposed to return. Wondering if anyone could give me some help on what the response should be, byte by byte.



Can’t find the edit button…

I’ve looked at the MMC specs in more details, and it seems that I should be looking at the command’s parameters, especially the format and TIME, and then deciding what to send back based on this. Right now the code I have just sends a hard coded response regardless of the incoming parameters. I guess it works for most cases but not some.

However, I’m still confused on the various fields in the response data, even with the descriptions on the MMC specs. Stuff like first & last track number, ADR/CONTROL, etc…how do I know what to send?


Moved to Optical Drive Technical Discussions.


What you send certainly depends on the command received. If you are dealing with only CD-ROM emulation here, then you will only have 1 track and it will start at LBA = 0 or MSF 00:02:00. You have to check the incoming commands MSF (or Time) bit to know what format the calling app expects. You also need to calculate a proper start address for the AA (leadout) track. For ROM, the ADR/CONTROL is 14. So you have:

first track = 01 and starting at LBA 0 or MSF 00:02:00
last track = 01

Here is the buffer data I get back from a Read Toc command of a single track ROM CD.

The command I issued to the drive:
43 00 00 00 00 00 00 09 30 00

Data returned by the drive (with comments):
00 12 (number of bytes below = 18 decimal)
01 (first track)
01 (last track)
00 (reserved)
14 (adr, control)
01 (track being described)
00 (reserved)
00 00 00 00 (start logical block address 0)
00 (reserved)
14 (adr, control)
AA (track being described (leadout))
00 (reserved)
00 00 A2 8A (start logical block address 41610)

Hope this helps,


Thanks Richman. I will try that out.

I’m wondering what software are you using to send the specific command to the drive, and where can I get it?

Also, how do I calculate/obtain the “track being described” and “start logical block address”?


Actually if all I’m doing is basic CDROM emulation, do I need to handl session info, full TOC, PMA, ATIP and CD-TEXT or can I just ignore all formats other than 0(TOC)? I’m thinking of just returning an error sense data on the other formats, but again, not sure which sense data to send back. INVALID FIELD IN CDB maybe?


The software I used was something I wrote and use at work. I’m not allowed to distribute it. Sorry.

Since you are emulating a ROM CD, you only have 1 track and it will start at LBA 0. The only thing you have to calculate is what LBA to give to the AA track. This will vary depending on the size of the ISO file that was ‘mounted’.

As for supporting the other MMC commands, I guess that depends on what software will be trying to send commands to your virtual drive. You might get away with just returning an error, but there are many commands (not just Read TOC) that are considered ‘mandatory’ in the spec.



Thanks again. I guess it will be tricky to calculate the LBA to give to the AA track since the ISO file mounted is not fixed and there’s no way of me knowing how large it is…however so far I seem to be able to get away with an arbitary LBA, at least in Windows…

Any idea what kinds of software sends which command formats?


If your software is the one doing the mounting of the ISO, why can’t you find how big it is? You must get the path and file name in order to mount the file.

It’s possible that reporting the max LBA possible for the AA track will work in most all cases. Most programs don’t care where the leadout track is anyway, they just want to parse the ISO file system and get the files.

There’s not much way to know what commands any particular software will send to a drive. But like I mentioned before, some commands are mandatory to support by all CD/DVD devices. Maybe returning an error on the ones you do not support will not cause problems. You’ll just have to try I guess.