Mode 2 CD-ROMs

[Dr. T]

Most physical data CD-ROMs I have come across have been Mode 1 CD-ROMs: these have 2352-byte physical sectors, each containing 2048 bytes of data, a sync pattern, headers and EDC and ECC data. On a Mac, it is possible to extract both the raw 2352-byte sectors, e.g. by reading the file /dev/diskN, or the 2048-byte sector data they contain, e.g. by reading the file /dev/diskNs1 (or sometimes it's /dev/diskNs0, I don't know how Mac OS X decides whether to call it s0 or s1 - does anyone know?). On Linux, I only know how to read /dev/sr0, which has access only to the 2048-byte-sector data but not the raw ECC etc. bytes.

On trying to archive some really old (about 20 years) CD-ROMs, I've come across some XA Mode 2 CD-ROMs, containing mainly Mode 2 Form 1 sectors: these (like all CD media) also contain 2352-byte physical sectors which contain 2048 bytes of data, a sync pattern, headers and EDC and ECC data, however it is arranged differently from Mode 1 CD-ROMs. To make matters more complicated, some sectors on these CD-ROMs are Mode 2 Form 2 sectors. I'm able to archive the raw 2352-byte sector data, however it's not possible to meaningfully extract 2048-byte sector data.

As far as I can tell, VirtualBox expects the 2048-byte sector data in its CD-ROM ISO files. However, VirtualBox seems to support DMG, CUE, RAW and VBoxIsoMaker files for the virtual optical media - but I can't find any documentation explaining what these different formats are supposed to be.

Is there a way to image my media so I can use virtual media files in VirtualBox, rather than using the physical CD-ROMs, which are starting to get a bit flakey, every time? And is there some place which documents the difference between DMG, CUE, RAW and VBoxIsoMaker as far as VirtualBox is concerned?

Thank you.

[mpack]

As far as I can tell, VirtualBox expects the 2048-byte sector data in its CD-ROM ISO files.

Uh... in fact it expects ISO data in its ISO files. That's what ISO refers to: the ISO-9660 standard for data CDs (and its various modern tweaks for long filenames and deeply nested folders).

Was this a special purpose CD format? ISTR that these strange CD formats all had special purposes that died out. There's music CDs of course (CD-A), Photo-CD, VideoCD etc.

[fth0]

FWIW, VirtualBox provides an experimental feature called passthrough mode, which lets you access a physical CD/DVD drive from within the guest OS. See 5.9. CD/DVD Support for details.

[Dr. T]

FWIW, VirtualBox provides an experimental feature called passthrough mode, which lets you access a physical CD/DVD drive from within the guest OS. See 5.9. CD/DVD Support for details.

Thanks - I know I can use passthrough mode to access a physical CD-ROM, and this is how I've been using these CD-ROMs to-date, but the physical CD-ROMs are getting very old and flakey. I've been able to image them in full, and now I'd like to access those images in VirtualBox.

I've tried using losetup with the idea of "passing through" the loop device, but losetup requires 512-byte sectors whereas a CD-ROM uses 2352-byte sectors.

[Dr. T]

As far as I can tell, VirtualBox expects the 2048-byte sector data in its CD-ROM ISO files.

Uh... in fact it expects ISO data in its ISO files. That's what ISO refers to: the ISO-9660 standard for data CDs (and its various modern tweaks for long filenames and deeply nested folders).

Was this a special purpose CD format? ISTR that these strange CD formats all had special purposes that died out. There's music CDs of course (CD-A), Photo-CD, VideoCD etc.

It's not s special purpose CD format, it's a standard CD-ROM format.

AFAIK, all CDs use 2352-byte sectors, see e.g. https://en.wikipedia.org/wiki/CD-ROM . CD-ROMs use these 2352 bytes as follows: bytes 0 to 11 store a sync pattern 00 ff ff ff ff ff ff ff ff ff ff 00, bytes 12 to 15 contain an address (minutes, seconds, frame), byte 16 contains the CD-ROM "mode" (only modes 1 and 2 were defined by standards, I believe) and the remaining 2336 bytes are mode-specific. Mode 1 CD-ROMs (those definitively supported by VirtualBox) follow this 16-byte header with 2048 bytes of data, 4 CRC bytes, 8 zero bytes, and finally 276 bytes for ECC. Mode 2 CD-ROMs do not specify a format for those 2336 bytes, but the CD-ROM XA extension defines two "forms" for mode 2 CD-ROMs: form 1, for example, fills the 2336 bytes as follows: 8 bytes for the sub-header, 2048 data bytes, 4 bytes for CRC and 276 bytes for ECC. The CRC and ECC algorithms are the same as for Mode 1 CD-ROMs. Mode 2, form 1 XA CD-ROM is substantially equivalent to a mode 1 CD-ROM, only the sub-header contains some additional information such as whether the 2048 bytes of data represent audio, video, data, etc.

All guest O.S.'s expect CD drives to provide them with the full 2352 bytes per sector. In order to support Mode 1 CD-ROMs, VirtualBox has to take the 2048 bytes available in an ISO file, and recreate the Mode 1 CD-ROM metadata (the 304 bytes of CRC, ECC and other metadata can be uniquely re-created from the 2048 bytes if you know the CD-ROM is Mode 1). That's more work than just taking a 2352-byte sector file as input and passing through all the 2352 bytes to the guest as they are - which would allow all CD-ROM's, including all Mode 1 and Mode 2 CD-ROMs, and possibly also audio CDs, to work in the guest.

CD-ROM XA Mode 2 CD-ROMs, I believe, were used by Microsoft quite a bit.

Since this is straightforward to implement (indeed, more straightforward than emulating a 2352-byte CD-ROM from 2048-byte sector ISO files), I'd be surprised if VirtualBox did not have support for this somehow?

[mpack]

Thanks. I'm not sure that the standard for physical CD formatting dominates in a discussion about the ISO image file format, but I have no direct experience trying to parse that format so perhaps it has variants that I'm not aware of.

But, I'm pretty sure (ok, I know for a fact) that ISO image files established by convention have a sector size of 2048, not anything else: i.e. the redundant sector marks and CRC needed by physical media is stripped off. VirtualBox is slightly more lax than the standard mandates: it will accept any ISO image file that is a multiple of 512 bytes in size.

[fth0]

I took a deep dive into the VirtualBox source code, and AFAIU the following holds true:

In passthrough mode, the 2352 bytes per sector are passed through transparently (as expected). If an ISO file is read from the host, VirtualBox creates CD-ROM Mode 1 sectors with the ECC bytes set to 0. A CUE file is only read from the host, if it contains CDROM Mode 1 sectors (or CDDA sectors).

Perhaps you could create a CUE/BIN file pair from the CD-ROM and use a virtual CD software on the host in combination with the VirtualBox passthrough mode. The CUE file format is documented on Cue sheet (computing). Follow the CDRWIN reference in the Wikipedia page for the original specification.

[Dr. T]

I took a deep dive into the VirtualBox source code, and AFAIU the following holds true:

In passthrough mode, the 2352 bytes per sector are passed through transparently (as expected). If an ISO file is read from the host, VirtualBox creates CD-ROM Mode 1 sectors with the ECC bytes set to 0. A CUE file is only read from the host, if it contains CDROM Mode 1 sectors (or CDDA sectors).

Perhaps you could create a CUE/BIN file pair from the CD-ROM and use a virtual CD software on the host in combination with the VirtualBox passthrough mode. The CUE file format is documented on Cue sheet (computing). Follow the CDRWIN reference in the Wikipedia page for the original specification.

Thank you very much for that. Yes, I also looked at the source code (and also spotted the dummy CRC/ECC creation code - I have the code to correctly create those bytes and am happy to contribute it - however, this code seems to be in a different file (DevATA.cpp) than the CUE file parsing code (CUE.cpp)). I also got the idea of creating a CUE file. I created a CUE file as follows:

Code: Select all

FILE "cdrom.bin" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00

I was able to attach this CUE file to the virtual machine, and VirtualBox correctly parsed it and determined the length of the BIN file, however, the guest O.S. did not recognize the attached CD-ROM image. This was a Mode 1 CD-ROM dump (with full 2352-byte sectors). I then extracted the ISO file (with 2048-byte sectors) from the BIN file outside VirtualBox and attached that to the virtual machine, and that worked - the guest correctly recognized it.

So, I haven't been successful even at mounting a Mode 1 CD-ROM when specified as a CUE/BIN file pair so far (any idea what I'm doing wrong?) - and my goal is ultimately to attach the same using a Mode 2 CD-ROM. It's not clear why Mode 2 CD-ROMs are not supported, since CUE.cpp contains some code referring to Mode 2, but it clearly does not support the parsing of Mode 2 directives in the CUE file.

It's not clear to me why VirtualBox limits itself in this way - in passthrough mode, it already supports simply passing through the 2352-byte sectors coming from the raw CD-ROM, supporting, presumably, any format CD's - so surely it could do the same if the data was coming from a disk file with 2352-byte sectors?

[fth0]

this code seems to be in a different file (DevATA.cpp) than the CUE file parsing code (CUE.cpp)

There is a general concept that you need to understand first: If you look at a physical PC, you usually have a physical device (e.g. CD-ROM drive) and an OS driver communicating with the physical device. Now you add a hardware virtualizer (e.g. VirtualBox) to the equation. VirtualBox uses its own VirtualBox driver to communicate with the host OS and the physical device, and provides a virtual device to the guest OS, which uses its guest OS driver to communicate with the virtual device. In consequence, VirtualBox combines a driver implementation and a device implementation for most virtual hardware.

So, I haven't been successful even at mounting a Mode 1 CD-ROM when specified as a CUE/BIN file pair so far (any idea what I'm doing wrong?)

No. I'm not even sure if the code in DevATA.cpp is correct, because it seems to only add 280 zero bytes after the data. But I only looked at it for a very short amount of time, so I did not try to understand it thoroughly.

It's not clear to me why VirtualBox limits itself in this way

AFAIU, Oracle usually implements only what is needed by the paying customers of VirtualBox, and VirtualBox development resources are quite scarce. But you/users are welcome to provide source code patches via the vbox-dev mailing list, see How to contribute for details.

PS: I'm not affiliated to Oracle or the VirtualBox development (like most Volunteers and Moderators).