CDs

This is just a random note if any of those of you who read this are geeky types. Really geeky types…

The issue is if you are the sort who would ever download and run software off the internet. Now, I am certainly not, I just pop off to my local EB and buy whatever I need. It is a four hour long plane flight, but it gives me the solace of knowing all my software is legal.

I have this friend though and much as I have tried to correct his wayward ways he continues to use those evil P2P filesharing programs. He has been having trouble with stuff he downloaded though and I decided to help him even though it would taint my soul.

He was downloading cd images that should, in principle, be ready to burn onto a cd. When he tried though they wouldn’t work.

On a Linux system if a file is a valid ISO9660 image, you should be able to mount it on the loopback with the command:

mount -o loop filename mount_point

This wasn’t working out though. Upon running the command:

hexdump filename | head

I got output which looked like this:

0000000 ff00 ffff ffff ffff ffff 00ff 0200 0100
0000010 5245 0002 0b00 da0a 0100 0100 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000210 4d50 0000 0000 0200 0000 0100 0000 0200
0000220 524d 534b 0000 0000 0000 0000 0000 0000
0000230 0000 0000 0000 0000 0000 0000 0000 0000

Now, if you’ve ever looked at an ISO image, you know that the whole first bit of the thing is 0′s (like the first several thousand bytes). That this one starts with data means something is amiss. So, I went searching the internet for info on CDs and found that another common format for CD images is a straight binary copy of the disk. ISO images are fine, but they can only represent a single ISO filesystem. There are miltisession discs with multiple filesystems, or more frequently with games, a data track and then audio tracks. A straight binary copy simply gets all the data on the disk and then often relies on an external file to say where exactly the different tracks begin on the disk.

CD-ROMs are not as infallable of devices as one might think. It turns out that getting a disk spinning thousands of times a second and then hitting an exact spot with a laser is sort of difficult. This is the reason that you have problems with buffer under-runs with CD-Rs. Data has to be fed continually to the burner so that the laser can be kept on. If the laser is turned off the drive isn’t precise enough to start back up just where it left off, so voila, coaster.

This same problem exists when the drive is just reading normally. To counter it and allow the drive to properly find its position, there is extra data written to the disk to counter “jitter.” Those first bytes you can see in the hexdump are those jitter correction bits.

My friend had somehow gotten his hands on a binary image incorrectly labeled as an ISO filesystem image. This leaves me with a couple choices. I am burning under Linux using cdrecord which has a raw option that should permit me to write this image straight to disk. As it is though I know that the disk has only a single data track and I would like to be able to mount it on the loopback. Also, since there are an extra 304 bytes for every 2048 bytes of user data, so there is about 15% unnecessary info in the image. I had to delete stuff just to get this image onto my machine, so for a couple 700mb images, that 200mb of wasted space is something I’d like to have.

As I mentioned before, my friend doesn’t have the index file. Fortunately though for a single data track, creating one is trivial:

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

Other modes were possible, but mode 1 is the most common. Just to verify though, checked what data was present at what would be the end of the track if it was being written in mode 1. I have to skip the 16 byte header and then the 2048 bytes of user data:

hexdump -s $((16+2048)) -n 288 filename

0000810 13c5 2b68 0000 0000 0000 0000 f700 f500
0000820 0000 0000 0000 0000 0000 0000 0000 0000
*
0000860 0000 0000 0000 3552 7db8 0000 0000 0000
0000870 0000 f500 f400 0000 0000 0000 0000 0000
0000880 0000 0000 0000 0000 0000 0000 0000 0000
*

Most of this is checksum stuff, but bytes 5-12 should be 0s and they are. One more check is to see if the position that should be the start of the next track is one of those syncronizing frames.

hexdump -s 2352 -n 16 filename

0000930 ff00 ffff ffff ffff ffff 00ff 0200 0101

Sure enough it is. So, all I do now, knowing that I’ve got the right format is run the image through a program to strip off those checksums and synchronization bits called binchunker:

bchunk img_filename index_filename output_filename

And I now have a nice little ISO image that I can mount and burn no problem.