Read TOC problem with the USB drive emulating like a CD-ROM drive(in MAC system)

Hello ,
I am trying to emulate a USB drive to appear like a CD-ROM drive. I used a tool to generate an ISO image. Then I dump the image to a usb drive, setting the drive as CDROM type by SCSI command . All the host(Windows,Linux,MAC) will also sends Read TOC command to get the TOC data. Since I emulate the USB device as CDROM drive, I just emulate it as single track.

Here is the discuss thread I refer to :

And below is the data I respond to a Read Toc command(all Hex)

The command to the drive:
43 00 00 00 00 00 00 03 24 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 0X00)
00 (reserved)
14 (adr, control)
AA (track being described (leadout))
00 (reserved)
00 00 0C 6C (lead oout start logical block address 0xC6C)

This works fine in both Windows and Linux system, but can’t be mounted in MAC system.:sad:

At the same time , I get a USB device which could be emulated as CDROM in MAC system. I get the data back from the USB analyzer and see its response data is as followed (MSF is 1):
00 2E (TOC data length)
01 (First track number)
01 (Last track number)
01 16 00 A0 00 00 00 00 (TOC track descriptor ?)
01 00 00 01 16 00 A1 00 (TOC track descriptor ?)
00 00 00 01 00 00 01 16 (TOC track descriptor ?)
00 A2 00 00 00 00 03 14 (TOC track descriptor ?)
34 01 14 00 01 00 00 00 (TOC track descriptor ?)
00 00 02 00 (?)

Till now I have no clue about its meaning.Morever amazingly, I used this TOC data for my ISO image and MAC system could recognize it !!

Is there any special meaning in this TOC data ? Do anyone knows the meaning of this set of TOC (I can’t parse its meaning from MMC-6).

Thanks in advance.

sorry , I just notice that the command from MAC system is :
43 02 00 00 00 00 00 FF FE 80
which is different to from Windows :
43 02 00 00 00 00 00 03 24 00

The 7th and 8th bytes means the allocation Length , so it’s normal that different system issue different value.
But the last byte (which means control byte) in MAC is 0x80 and in Windows is 0x00 .
MMC-6 does not define this byte . But SFF-8090 defines the highest 2 bit of this byte as vendor specific . Any one knows what does MAC require from this ? And What is the diffent between them(0x00 and 0x80) ?


I spent way over 1 hour typing and reading specs, when finished I hit ‘Submit Reply’ button just to get an error message and lose all my typed data. This forum sucks some times…:frowning:

To make it short, the TOC data you list from the MAC is in format 2 ‘Raw TOC’. I see you list the command as having format 0 but the data is certainly format 2. You can find the info in the MMC for format 2 data returned.


Thanks RM,

Double checked and see that the command packet does send format 0.Maybe MAC has its specific definition on the command packet , like set vendor specific bits in byte 9 to ask for the Raw TOC ? I can’t find any documents about this.

Thanks so much on your information. Now I can study further on how to fill the response data . :slight_smile:

Sorry to keep bringing up this topic cause I am still not so clear about the sample data.
I parsed the sample data as below :

00 2E (number of bytes below = 18 decimal)
01 (First track number)
01 (Last track number)

01 (session number)
16 (ADR/Control)
00 (TNO)
00 (Min)
00 (Sec)
00 (Frame)
00 (Zero)
01 (PMIN)
00 (PSEC)

01 (session num)
16 (addr/ctrl)
00 (tno)
A1 (point)
00 (min)
00 (sec)
00 (frame)
00 (zero)
01 (pmin)
00 (psec)
00 (pframe)

01 (session num)
16 (addr/ctrl)
00 (tno)
A2 (point)
00 (min)
00 (sec)
00 (frame)
00 (zero)
03 (pmin)
14 (psec)
34 (pframe)

01 (session num)
14 (addr/ctrl)
00 (tno)
01 (point)
00 (min)
00 (sec)
00 frame)
00 (zero)
00 (pmin)
02 (psec)
00 (pframe)

questions :

  1. POINT A0,A1,A2,01 are mandatory ?
  2. What does “Absolute time” mean ? MMC said it’s “Running time in the Lead-in”, but I can’t catch the idea.
  3. A2’s PMIN,PSEC,PFRAME has to fill the Start position of Lead-out. I inspect from my sample data it is 0x03, 0x14,0x34 . However ,the actual value should be 0x03,0x14,0x33. Why the PFRAME is one more than actual value?


In format 2 TOC, A0, A1 and A2 are mandatory as well as an entry for each track.

There are 2 types of time on CD, A-Time and R-Time. The A-Time means from beginning of disc. In program area, after leadin, the A-Time starts counting up all the way to leadout. The R-Time counts down to zero during the pause of a track and then counts up until the end of the track.

In leadin you can pretty much ignore the time as each title can be different depending on the mastering encoder.

How do you know that the leadout is wrong? Where do you get the other A-Time for leadout?


Thanks for your kindly help.
I read from the content of the ISO file. It shows the total sector as 0x3A35 ,converting it to MSF is 0x03, 0x14,0x33. Also , the response data to Windows is 0x03,0x14,0x33. I just wonder why it’s one frame more when responding to MAC .

I can’t find any spec saying that the 9th byte of the command from MAC means it request for format 2 data. But at least when I respond the format 2 data,MAC will recognize it. Does anyone knows any information about this ?

Thanks a lot.

Hi ChiauEng and all (especially RichMan), could you tell me more about TOC data response? Is the leadout track description mandatory? If it is what the start logical block address shall be? I tried the next value of the last user data LBA but Windows (XP SP3) cannot recognize it. Windows can’t stop the process to recognize the drive til I remove the drive out.

Many thanks!

Huhm, maybe, i found the reason of this bug. It may be because of the MSF bit of 1 but I responded a LBA instead of MSF adress. Well, so does anyone know how to intruct Windows to recognize this drive as normal data drive to send ReadTOC with MSF=0?

Many thanks!

Hi Neo3F,

Yes, leadout is mandatory in both format 0 and format 2 TOC data. If Windows (or any software) sends the ReadTOC command with the MSF bit set to 1 then you need to obey this and return the data in the TIME format. Likewise, if the command has MSF set to 0 you should return the data in LBA format. You have no control over the software issuing the command in this case. You just have to reply correctly.


Hi RichMan,

1stly, thanks for your help. But I still wonder about the way Windows (using its default drivers and management software) recognizes a CDROM as a data disk, audio disk or combinational one. There must have been something in the enumeration process telling Windows about that. I think so because I got both READTOC with MSF=1 and MSF=0 from Windows. (but don’t remember what parameters had been changed)

Software (Windows) does not know what type of disc is in the drive until it reads the TOC. So, it all depends on the data you return to the ReadTOC command.


So why does Windows sometimes send ReadTOC w/ MSF=“1”, sometimes “0”? I keep thinking that Windows must rely on certain parameter(s) to determine whether MSF is a one or zero. Anyway, you’re right, our firmware has to care about both.