#76 TOC File support

[Benjamin Leggett]

Currently Dosbox provides CD image mounting capabilites for iso and bin+cue files. However, a lot of CD copying software uses bin+toc, which is almost exactly the same except for the .toc file's different format.

Dosbox doesn't work with .toc files as it does with .cue files, and on non-Windows systems, conversion between .toc and .cue is problematic. I realize that dosbox can't support all image formats, but since toc+bin is only trivially different from cue+bin, it would probably not be that hard to do.

[Qbix]

do you still need this now that you have discovered toc2cue ?

[Benjamin Leggett]

Yes, toc2cue isn't terribly robust. The image I'm using is a mixed-mode data/audio type, and toc2cue specifically says that it doesn't work with these, since the byte order on the data track will be wrong after conversion. I tried it anyway, but as expected, it doesn't work.

[Stephan Sokolow]

For anyone who wanders in from Google, it's not that toc2cue isn't robust, per se, it's that it doesn't know how to translate BIN files and TOC and CUE make contradictory assumptions.

Also, it's actually the audio tracks that are in the wrong order. (Each audio track is a raw stream of 16-bit (2-byte) samples and CUE and TOC use opposite endiannesses)

Back around 2009 (when my code was much uglier and I wasn't as learned in how to write low-level stuff properly), I wrote a Python script which solves that by parsing the CUE subset that toc2cue generates and then making a copy of the BIN file with the AUDIO tracks byte-swapped. (Though you still need to either edit the CUE file or rename the new BIN file to the old name)

http://ssokolow.com/scripts/index.html#swab.py

It's still CPU-bound when it should be I/O-bound, but I just updated it to be a little smarter about reading from the disk and doesn't take too long to convert a BIN file now.

I can confirm it works because I use it to play games like Afterlife and Rayman Gold in DOSBox after dumping them as BIN/TOC pairs on Linux using cdrdao and I just re-tested it by re-dumping some CDs like The Even More Incredible Machine.

(Trust me. You'll know if the endianness of your BIN files is wrong. The background music in your game will sound like white noise.)

[Stephen Clark]

I'd like to add my opinion on this, as this is a discussion I had with the devs of PCSXR (PSX emulator). There is a lot of mis-information surrounding the topic of BIN/CUE/TOC files.

Whether it's an audio CD or a mixed mode CD, audio tracks are, by standard, little endian. However, and quite strangely, software like cdrdao rips audio tracks as big endian by default. This behaviour can be changed by adding a command line option:
--driver generic-mmc-raw:0x20000
... thus produing a BIN file with little endian audio.

TOC and CUE files are synonimous (albeit slightly different syntax and layout), and are just text files containing data that specifies (on a basic level) where tracks begin and end within the BIN file. TOC and CUE files have nothing to do with the byte order of the audio tracks. That is down to how software, such as DOSBox or PCSXR, interpret their usage.

The disclaimer that toc2cue displays about byte order is also misleading.

Audio tracks should be assumed to be little endian. It should not matter whether you use a TOC file or a CUE file or how the audio tracks where ripped in the BIN file.

The solution here should be how the devs of PCSXR did it. A simple option that allows the byte order of the audio tracks to be reversed (assume big endian).
Example:
imgmount D GAME.CUE -t iso -be
The -be (big endian switch) can be used if the audio tracks play as static. Omitting the -be switch will assume the tracks to be little endian.

This would be a much simpler approach for the DOSBox devs to implement without worrying about how byte order should be handled.

So, is there any chance TOC support could be added, along with the big endian switch?