Archiving CD images using Toast 3 (1997)

[PL212]

Versions of Toast earlier than 3.x don't seem to include support for saving images from a physical CD-ROM. Toast 3.5 does, however -- in a variety of formats:

Mac Volume
Mac Files & Folders
ISO 9660
Mac/ISO Hybrid
Audio CD
---
CD-i
Video CD
Enhanced Music CD
---
SCSI Copy
Disc Image
Multitrack CD-ROM XA
---
Audio Tracks

Of these options, at least Mac Volume and SCSI Copy result in a file readable by DiskJockey -- albeit in different ways. It's not as clear to me if there's a viable path to a compliant ISO file, however.

I should mention first that there is an unfortunate entanglement between the format of the project, and the possible output format. We are used to thinking of .toast files as being interchangeable with .iso -- and perhaps they are, but Toast requires you to first define the format of the project, and saving it is almost an afterthought. This will let you easily create .toast files that in no way conform to standard iso formats.

Here are the results from 1994 CD-ROM from Apple:

Mac Volume:

SCSI Copy:

Note the macTOPiX name -- this was mastering hardware/software from Optical Media International. The size differences in the main partition are mainly due to the SCSI copy including the blank space, which is optional on the Mac Volume format.

ISO 9660 may look like a tempting choice, but you need to enable "Allow Macintosh Names" from the drop-down list on the Settings tab. (This is a poor UI choice, as Allow DOS Names and Allow Macintosh Names are mutually exclusive.) The "Use Apple Extensions" setting is checked by default, probably best to leave this one.

This does seem to result in a legitimate Mac ISO image -- at least, the Virtual CD/DVD-ROM Utility mounts the resulting file in System 7.1 without issues. However, icon positions and colors are not maintained -- I believe this is because Toast's file picker does not see or allow you to include the various Desktop files.

Amusingly, this iso also mounts in OS X 10.15 Sequoia, which it really shouldn't! Classic Mac CD-ROMs of this era should be in HFS, and generate an error on current systems. As stated above, Toast is sort of conflating the format of the files in the project with the output format here. (And as a final irony, DiskJockey can't make heads or tails of this iso...)

That's all I've had time to experiment with so far. I'd be curious if anyone has tips for generating forensic/correct/useful ISO images using 1990s copies of Toast under System 7...

 

[This Does Not Compute]

ISO 9660 may look like a tempting choice, but you need to enable "Allow Macintosh Names" from the drop-down list on the Settings tab. (This is a poor UI choice, as Allow DOS Names and Allow Macintosh Names are mutually exclusive.) The "Use Apple Extensions" setting is checked by default, probably best to leave this one.

ISO9660 is really a filesystem and not necessary a disc image container format -- it was designed to be cross-platform compatible, hence the reason it's still mountable on modern operating systems. If you pick this when creating a disc image, you're not *really* creating a disc image; you're telling Toast to simply copy all of the files/folders from the source into a new ISO9660 volume.

It's also important that care is taken, at least on bootable Mac CDs, to not just pick the HFS volume but rather the entire contents of the disc. I've misplaced the link but a while back I found a very helpful blog post that explains how bootable Mac CDs work -- basically, the CD-ROM driver is baked into the header of the disc (similar to how Mac hard drives have a "hard disk driver") to allow it to be read by the ROM before the OS loads. This exists outside the HFS partiton.

 

[PL212]

Thanks, this is all very helpful — for my actual ‘forensic’ work, I’m using the script somebody posted on Macintosh Garden, which I think does a really excellent job (and results in a helpful log file as well).

There is of course endless discussion/drama on MG about the “right” way to image CD’s — I’m sort of curious if there existed a good method in the mid 1990s, with software such as Toast? I sort of suspect there wasn’t, or at least not till later versions of that softare.

Side note — one of the more infamous early discs was Apple’s “CD-ROM Explorer”, circa 1988, which is really hard to image correctly. It’s got audio tracks, plus one or two Apple // ProDOS partitions, and appears to have been mastered before the finalization of the ISO standard. I have a physical copy, and am curious if there is any better way to image it than the Windows-centric BIN/CUE copy that’s currently on the Garden? (Nothing against that or the person who did the work to create it, of course).

 

[PL212]

Ah, turns out this blog post has a good writeup on use of Toast to create (nearly) forensic images. Looks like the "Disk Copy" option was introduced in 4.x, which is just one version newer than the 3.5.x branch I was one. Luckily 4 still runs on 68k so I'll give that a shot...

 

[MacKilRoy]

There is also a tool made by Astarte called CD-Copy. Its purpose is to extract 100% the contents of a CD, including any hidden data.

Use that to make an image rather than Toast, if you're doing this on a 68K Mac.

https://macintoshgarden.org/sites/macintoshgarden.org/files/apps/ASTARTECDCopy2.03e.sit_.bin

 

[phipli]

Ah, turns out this blog post has a good writeup on use of Toast to create (nearly) forensic images. Looks like the "Disk Copy" option was introduced in 4.x, which is just one version newer than the 3.5.x branch I was one. Luckily 4 still runs on 68k so I'll give that a shot...

There is also a tool made by Astarte called CD-Copy. Its purpose is to extract 100% the contents of a CD, including any hidden data.

Use that to make an image rather than Toast, if you're doing this on a 68K Mac.

https://macintoshgarden.org/sites/macintoshgarden.org/files/apps/ASTARTECDCopy2.03e.sit_.bin

Hey,

I wrote the linked post.

Toast copies the entire CD when done as described - completely, byte for byte including "hidden" data (I'm not sure what you mean by that, but if it is on the disk, it is getting copied). The one differences I was talking about is where Toast modifies part of the partition map that technically doesn't matter to stamp its name on it (I think it was a creator string? Something like that). The disk is completely functional and all the data remains identical, I just don't like them doing that because it makes checksums not match. I suspect they did it to help companies detect copied CDs.

I make most of my images on linux with K3b. Its pretty trivial to do and I end up with a perfect iso that I can throw up on Macintosh Garden.

 

[phipli]

one version newer than the 3.5.x branch I was one.

Have you tried using the menu option Format>SCSI Copy in Toast 3.5?

Click "Data...", then pick the CD...

then ... possibly click Options and deselect "Clear Driver Descriptor Map" - I'm not certain about this step, I tend to use version 4.x. I'd want to generate two images and compare them manually to see what it did (but I'm just looking in an emulator).

Click OK, Click OK again...

Then here :

Make sure "Blocks" is selected and the number in "Copy" says the same as the number immediately above ("Number of Blocks") in your version of this window. Make sure "Start at Block" says "0".

Click OK on this dialog and you're back to the main Toast 3.5.x window. Go to File>Save as Disc Image...

Name the file with a .iso extension and save it where you want to.

Then it will "write" a disc image for you :

And done :

This should be an iso image of the raw CD.

To be honest, I'm amazed I got this far in 68k QEMU

I'll do some more testing with this method and perhaps add it to my other post.

 

[phipli]

Here is the partition map from the CD I ripped on Linux :

... and here is the partition map from the CD I ripped using Toast 3.5.x :

But as with later versions of Toast, it very slightly modifies the file. This is the output of diff <(xxd ./My\ CD.iso) <(My\ CD\ Linux.iso) :

Interestingly, I think later versions of Toast actually make more changes.

 

[PL212]

Thanks for the post!

So Toast 3.5.7 refuses to do a SCSI copy of a “multi-track data disc”, not surprisingly. (This would be red book audio plus data).

A single-track (data) CD seems to be valid according to DiskJockey:

What linux command are you running above to get the readout of the partition map? I'll give that a try as well...

 

[phipli]

So Toast 3.5.7 refuses to do a SCSI copy of a “multi-track data disc”, not surprisingly. (This would be red book audio plus data).

Yes sorry, you can't create a iso image of this type of CD. I missed that that was what you were trying to do.

and am curious if there is any better way to image it than the Windows-centric BIN/CUE copy that’s currently on the Garden?

I wouldn't call it Windows-centric. A bin / cue image is basically an iso with a contents page (more accurately, what we call an iso is actually a .bin - the iso name only refers to the formatting inside the image - all isos are .bins, but not all .bins are isos... an iso is a single track bin?? I'm just rambling now). Open the CUE file in SimpleText and you'll see that it is just a list of locations to put the various blocks of data in the bin file.

But anyway - that I'm aware of, the bin / cue is the only cross platform format for storing multi track CD images, and so the only appropriate format for archival sites like Macintosh Garden and archive.org (for multi track discs).

To create a bin / cue image I use the command line tool cdrdao, with the following command :

cdrdao read-cd --read-raw --datafile cdimage.bin --device /dev/sr0 cdimage.cue

You'll end up with two files called cdimage.bin and cdimage.cue. Do not rename them unless you rename the reference inside the cue file too, or rename them in the command itself, not afterwards.

I am unaware of any other non-proprietary methods of fully capturing one of these type of CDs sorry. I do feel like there is excessive resistance to the bin / cue format. It really is a sensible format.

I've seen some people claim that Toast doesn't burn bin / cue, but I'm pretty certain it does (newer versions at least). I've just looked in my Toast 7 manual and page 95 covers BIN/CUE. This doesn't cover creating them, but page 18 and 19 does. Basically there is a format option for bin / cue when you save an image in Toast 7.

I'd grab a mixed media CD and see what Toast 3.5 thinks of it.

 

[phipli]

What linux command are you running above to get the readout of the partition map? I'll give that a try as well...

Its my own python script. Specifically "listPartitions.py", but it makes use of hfseditlib.py as well, so you need both files in the same folder.

GitHub - Phipli/HFS-Image-Inspect-and-Repair-Tools: This repository contains some small Python tools I made when I was inspecting and modifying classic Mac OS CD images.

This repository contains some small Python tools I made when I was inspecting and modifying classic Mac OS CD images. - Phipli/HFS-Image-Inspect-and-Repair-Tools

github.com

They're not a polished product and probably not for general use. I wrote them to help me fix non-bootable images other people had uploaded by splicing on the drivers from a bootable CD and modifying the partition map to correctly reference the new driver positions and partition numbers.

 

[PL212]

Great, this seems to verify that Toast 3.5.7 in "SCSI Copy" mode produces identical results to dumptoiso (which uses dd behind the scenes):

The target disc image file is... 1989-08 BMUG PDROM Vol1 1.2.iso
Num. Name Type Start Size
1 Apple_partition_map 1 2
2 Apple_HFS 3 683581
The target disc image file is... pdrom-toast357-scsi.iso
Num. Name Type Start Size
1 Apple_partition_map 1 2
2 Apple_HFS 3 683581

@phipli I agree with you about BIN/CUE actually, and thanks for the info about cdrdao! I'll use it to archive any complex CDs I come across..

 

[phipli]

Great, this seems to verify that Toast 3.5.7 in "SCSI Copy" mode produces identical results to dumptoiso (which uses dd behind the scenes):

The target disc image file is... 1989-08 BMUG PDROM Vol1 1.2.iso
Num. Name Type Start Size
1 Apple_partition_map 1 2
2 Apple_HFS 3 683581
The target disc image file is... pdrom-toast357-scsi.iso
Num. Name Type Start Size
1 Apple_partition_map 1 2
2 Apple_HFS 3 683581

@phipli I agree with you about BIN/CUE actually, and thanks for the info about cdrdao! I'll use it to archive any complex CDs I come across..

Take care - all you are comparing is the partition map itself, it isn't verifying data integrity. The other command I used was for that. That is a byte by byte comparison of the two files. "diff" compares strings, so I use xxd to convert the two binary files into a hex output, then compare the hex.