So you’ve just gone out and brought a funny looking PSX game, and a CD drive for your fancypants computer. You plug it in, put the disk in, and then wow! The files magically appear.
It can’t be this easy right? You go and copy and paste the files onto your computer then…
You may think the game is broken, but the disk looks fine to you! What could it be?
Well, I’m pretty sure this is something to do with the weird block sizes that these disks had back in the day, and Disk Utility freaks out a little.
This is just a quick reference for anyone out there who’s having trouble finding out how to dump their games from a CD to their (Apple Silicon) Mac.
Guide
The tool we’ll use is called cdrdao,
which we can pull from Homebrew.
brew install cdrdaoThis tool will read our CD (CDR) in “Disk at Once” (DAO) mode - I’m no expert, but I’m sure this’ll prevent Mac being like “I don’t know what this is” as it wont be confused by random gaps in the data that might appear due to the odd block sizes.
Once we have this installed, the next step is to find out which disk we’re
pulling data from. There are ways to do this, easiest is probably diskutil
diskutil listWe’re looking for the CD Drive. For me, it’s /dev/disk4 but make sure you
find the correct one. Alternatively, you can use drutil status and it might
give you the right disk.
Once we have the disk, we need to now tell Finder to leave it be. This’ll be
because it’ll try to hold a lock on the disk, and cdrdao will complain.
Easiest way to do this is
diskutil unmountDisk /dev/disk4Now we’re ready to pull the data off of our disk. To do this, use the following:
cdrdao read-cd --read-raw --datafile "output.bin" --driver generic-mmc:0x20000 output.tocThis is all self explanitory, except the driver. This is also getting into some
hairy disk standards, but the 0x20000 is also pretty poorly explained. Basically,
the docs of cdrdao tell us to use it if “the byte order of your audio is
weird.” All the games I’ve dumped so far require this option, so it’s probably
the nature of the audio format.
Once this completes, you should have two files: output.bin and output.toc.
Most emulators require bin and cue files, so we can easily convert the
output to cue with the following command:
toc2cue output.toc output.cueAnd now your game is on your computer!
That’s it! I’m hoping to put up a post soon about digging through some games, first of which is a murder-mystery visual novel called Kindaichi - but more on that later.
Thanks for reading!
Update (July 2024): LSN
Sometimes it’s helpful to find the Logical Block Address (LBA) or the Logical Sector Number (LSO) of an item on the disc, and cross reference it with addresses you might find in the PSX executable.
On Windows, you can use an ISO tool like UltraISO, but for Mac it’s a little harder. A Google search will often tell you just to use the in-built ISO reader, but as we found above, that will not always work. Not to mention, I’m yet to find a helpful way to list the LSN of the ISO itself.
In the previous step, we extracted a bin and cue file, and with these we
can recreate an ISO image file that we can then feed to another program
to print out their LSN.
We’ll need two tools for this, bchunk which converts bin/cue back to iso,
and GNU’s libcdio which is a library for interacting with CD and ISO file
formats. Both of these can be pulled from homebrew
brew install bchunk
brew install libcdioThen, we convert our files to ISO
# this will output a file output.iso01.iso
bchunk input.cue input.bin output.isoAnd then use a tool as part of libcdio called iso-info to get information
from our output file:
iso-info -l output.iso01.infoThis will print out the LSN of your files in your game. If you want to spit some of this information out in a script, you can use the C library directly, or make use of these Python bindings.
Do note, though, that LBA/LSN are only sometimes used interchangeably. In
case of libcdio, you will have to add 150 to the output value to get the LBA -
PSX games often use LBA over LSN, as described by the ever helpful
Hilltop.