This project is read-only.

[Question] bin/cue or bin/toc?

May 20, 2012 at 9:28 PM

Because of my background using the pSX emulator, which doesn't like .toc files, I'm used to converting all of my .toc files to .cue files using cdrdao's built-in toc2cue utility (I'm running Linux). This has never given me trouble until now, when I just ripped Rayman and found that the music in the game was replaced by terrible, terrible static.

I noticed this little disclaimer that comes up when using toc2cue:

"Furthermore, if the toc-file contains audio tracks the byteorder of the image file will be wrong which results in staticnoise when the resulting cue file is used for recording(even with cdrdao itself)."

When ripping Rayman, I noticed that it ~did~ have audio tracks, so I deleted my rayman.cue, leaving only rayman.bin and rayman.toc . This fixed my problem entirely! So, apparently, PCSXR reads .toc files, and, in this case, it was more effective?

It's my understanding that .cue and .toc files are simply two different standards that do the same thing: act as a map for finding particular tracks in a monolithic .bin file. I've opened them up as plaintext, before, to compare them, and they do seem mostly the same, although, apparently, toc2cue has some problem with the byte-order when using audio tracks, as I've just discovered.

Is there any reason for me to use .cue files with PCSXR? In the absence of a .cue file, does PCSXR actually use my .toc file (clearly, the .cue had priority, since deleting it solved my problem), or does it simply use some other method of locating data in the bin?

Thanks for your insight, and thank you to the devs!

-David Hernandez

May 22, 2012 at 5:00 AM

Thanks, Dario. I'm sorry to hear that your proposal was rejected, but I'm pretty sure that, in this case, the problem is with the toc2cue utility provided with cdrdao; after all, the problem that I was describing was detailed exactly in its disclaimer: I was hearing nothing but static when the CD-DA tracks were supposed to be playing. Still, maybe libcdio would have helped to forgo that issue, in which case I hope that the main developers soften at some point when you raise a discussion about libcdio again, haha.

As for my original question, it sounds like PCSXR doesn't have any particular need for .cue files when you have .toc's, and so, to anybody else having problems with static instead of music with their games, I'd suggest making sure that a faulty .cue file is not to blame, as toc2cue apparently cannot handle its business 100% of the time, haha.


May 26, 2012 at 6:20 AM
Edited May 26, 2012 at 6:27 AM

libcdio is an overkill (contains too much useless code) and does not support clonecd & alcohol 120% images.

a proper implementation for cue and toc parsing would be better (the current implementation is a simple hacked up version), not that I'll have the time to do that though and also this issue is not related with .toc/.cue parsing ;)

May 26, 2012 at 6:27 AM
Edited May 26, 2012 at 6:28 AM

the reason for this issue was cdrdao uses big-endian for CDDA data, while windows applications (which rips .bin/.cue images) uses little-endian.

as afaik there is no way to identify the endianness for CDDA data in both the image and the cuesheet, currently the cd image reader in pcsxr will only use big-endian when .toc file is used.

May 26, 2012 at 6:54 AM

Oh, I see. So, the reason that toc2cue gives that disclaimer about audio-track byteorder is that, even with a properly-parsed .cue file, a cdrdao-ripped .bin file's CDDA data is incompatible with .cue . Well, as long as PCSXR works without fault with a .toc file, that works for me; like I said, the only reason that I got the impression that I should prefer .cue to .toc was because the pSX emulator only read .cue's.

Thanks for all of your hard work with PCSXR, weimingzhi! It's really nice to be able to pick up cheapy PSX games at the local used-game market and play them on my PC. Have a good one!


Mar 6, 2014 at 11:22 AM
Edited Mar 6, 2014 at 11:29 AM
I hope no one minds me resurrecting an old thread, but I do have some information to add:

This appears to be a commonly misunderstood subject with users, and some 3rd party Wiki pages.
Audio tracks can sometimes play back as static. This is because audio on a Red Book Audio CD (including mixed mode) is little endian. A lot of ripping software seems to rip (at least by default) to big endian. I have found cdrdao can rip to little endian by appending the driver with the option 0x20000, thus:
--driver generic-mmc-raw:0x20000
Endianness is handled in PCSXR by assuming all audio is little endian unless you're loading a .toc file, in which case it assumes big endian. This, I think, has been done to try and satisfy bin files that have been ripped incorrectly, and also the badly written Wiki pages. This should not be the case.

I have also raised this as an issue, including a proposal to add an option somewhere in the GUI for the user to select either little or big endian,

EDIT: Just to add a note here, that .toc and .cue files are synonymous in the context we use them with PCSXR and have nothing to do with endianness. I don't know why toc2cue gives that disclaimer because, to be honest, it's confusing, and also quite inaccurate, as it only performs a conversion from the .toc file and not the .bin file.