This is incredible, nicely done. It looks like "Figure 8" was changed to a smiley.

About locking and modifying:
You lock the image after it's created? What would that protect against? Couldn't you do that yourself after download if its important?

Very comprehensive manual indeed. What about us regular folks running SheepShaver on a low end X86 host?

Oh, I think I get it now: You lock the disk image because the IMAGE gets modified when you mount it as a disk, which messes it up the next time anyone mounts it.

Great hints, thank you very much!

Ugh, in 10.4.11 I have to click "Session 1" to create a CD/DVD master. Selecting the drive itself (disk1) won't work, so disk1s1 does fine.

Technically, Disk Utility is just a front end for select Terminal stuff...like $ dd... and $ unmount...so it may be appropiate to cover all bases with your writeup on how to do it in Terminal (especially if someone is doing a lot of them, but then other software usually steps in at that point). If you were doing it in batch Terminal mode, you could just press the up arrow, edit the of= name and press Enter.

Wash, lather, rinse and repeat.

@Protocol 7: I've made this topic a "sticky" (don't know why it wasn't before now).

Unfortunately imageshack is no good as a click-to-view depository any more. Would you be able to create a new "app" page, add the pics, labeled Fig 1, Fig 2, Fig 3, etc, into a zipped archive and up them to the new page? - I'll get them inline into the topic's body in a permanent position and local to the MG (I'll deal with the "app" page afterwards).

@MikeTomTom. With reference to your edits on how to deal with CDs with audio, I use UltraISO for making a bin/cue. The full version is not free like ImgBurn, but neither is Alcohol

I'd like to nominate toast for OS X as well, it seems to do a much better job when handling hybrid discs... but it could also be my imagination

Unfortunately, the future of the Toast application is uncertain to me.

I still use Toast 10, the latest version that can burn newly created HFS Standard media,
and I hope it still works with my new Mac which requires 10.12 minimum.

Let's see when I need to use it then.

Toast 10 is a 32 bit application that no longer will work with upcoming macOS versions,
as they can run 64 bit applications only, as it has already been announced.

Parts of Toast are in AppStore now, but I don't trust them.

Pop in your CD and launch Disk Utility. Click on your CD/DVD drive (not the volume) in the drive list (Fig.1) and then click on the "New Image" button on the toolbar. Set the output type to "DVD/CD Master" with no encryption and save it out (Fig.2).

Have these options changed in later (or earlier) versions of Disk Utility than what was used here?

I'm using Disk Utility in Leopard (the only Mac OS X I have access to, currently) and I don't see any of the above options to set the output type to "DVD/CD Master" after clicking the "New Image" button.

MIke, the box to write in is getting so narrow that I am continuing this thread afresh in a lovely wide box.

I suspect the problem of md5 from the Toast image-->burn-->image process is to do with the way Toast reads the CD. I don't know much about this but I found the following comment in here under the heading "How can I verify the downloaded ISO images and written optical media?":

"The problem with the verification of written optical media is that some media types will possibly return more bytes than those found in the ISO image. This trailing garbage is impossible to avoid with CD written in TAO mode, incrementally recorded DVD-R[W], formatted DVD-RW, DVD+RW, BD-RE, and also with USB keys. Therefore, we need to read exactly the same number of sectors of data from the media as are found in the ISO image itself; reading any more bytes from the media will alter the checksum result."

My searching around (see here) indicates that Toast deals with a CD in TAO mode (Track-at-Once) where the tracks are consecutive sets of sectors that subdivide the CD content. Consequently, if the actual data ends part way through a track, some garbage data will be read/written from/to disc. You can find more information on various modes such as TAO here.

So, in summary, I expect that the real data is preserved properly by Toast and that the different md5 values is due to random garbage between the end of the real data and the end of the last track read. One way to check this is to calculate the md5 in a similar way to that described in the first link above. (I have not done this yet...have to find "isosize")

That is my understanding (all based on what I have read in the above links).

Well, I have made some progress. "isosize" is part of the util-linux package. From this, I compiled "isosize" on Mac OS X 10.6.8 and ran it with option -x and argument being the path to FMPROCA3.ISO. This returned sector count of 4892 and sector size of 2048. I can email you a copy of "isosize" if you like.

I then burned two CDs from FMPROCA3.ISO, one using Toast 7 and the other using LiquidCD. For each CD I did the following:

1) Mount CD
2) run the command df in the terminal and note the device name for the mounted CD
3) unmount the CD volume (I used Disk Utility)
4) In the terminal, execute the following:

dd if=device_name_we_noted_before count=4892 bs=2048 | md5

This will read the correct number of bytes from the CD for FMPROCA3.ISO and pipe it to md5

I found that both CDs returned the same md5 value but surprisingly that value was different from the md5 of FMPROCA3.ISO. Presumably the ISO file has certain information in it that is not part of the data that is destined for the CD, and that the extra information in the ISO file depends on the application that creates it.

Since both Toast 7 and LiquidCD both produce identical CDs, as determined by the md5 of the CD, from the same ISO file, and because you have concluded that LiquidCD makes reliable copies of the CD, I conclude that Toast 7 also makes reliable copies (in the sense that burning a CD will give a correct copy)

This probably needs more testing. For example, what happens if we burn a CD with Toast, then make a new image using Toast and then burn it back to another CD? Is the md5 of the first CD the same as the second CD? Similar testing can be done with other software.

jackpot! Thanks for the ImgBurn logs, Mike

Firstly, it does seem that "isosize" does not read the size of the whole hybrid Win/Mac disc image. I suspect it just reads the Win ISO part.

So I used the sector_count = 13540 taken from your ImgBurn log when I ran the dd command on the CD. However, I was still not getting it right. Then I realised that the device name I was using was only for the Mac volume that was mounted. In my case that was /dev/disk1s1s2. But I then guessed that the s2 part of the name pertained to the Mac volume and so this device name was not for the whole CD. So I tried /dev/disk1s1 instead and bingo the md5 of the two CDs that I was testing (one made with Toast 7 and the other with LiquidCD) gave identical md5 values to the md5 value that ImgBurn reports (d95dbb073ed8dc1267c6bba43bc3439e).

To summarise, to check the md5 of CDs burned from FMPROCA3.ISO, I followed steps 1-4 in my previous post (#42) with the dd command being specifically

dd if=/dev/disk1s1 count=13540 bs=2048 | md5

and this gives

d95dbb073ed8dc1267c6bba43bc3439e

which is what we are hoping for. The device name might be different in your case.

So it seem highly likely to me that a Toast image does what it is supposed to do; namely, allow one to burn a CD on which the data is identical to the data on the original source CD. A conclusive test of this would be to start with a source CD, determine its md5, make a disc image with Toast, burn another CD and determine the md5 of that. The two md5s should be the same.

Possible to update images in the instructions? Looks like they are long gone. Thanks

I've removed the "dead" external links to pix in the main topic and elsewhere, as they were phoning home each time the page was opened by someone, despite their absence from those locations.