The images created by DiskUtility (or hdiutil, the command line version) contain headers that are specific to MacOS, which create problems when they are used on other systems.
The "CD_partition_scheme" is a synthesized device (marked by a * next to the size). It is there because CDs can have multiple tracks, each using different modes, and the operating system needs some place to store that information. On the disc itself there is no "partition scheme": it instead carries that information in the form of the lead-in and lead-out areas, which are inaccessible as data to the host. This additional information is also added to disk images when DiskUtility or hdiutil creates them, in a format specific to those tools.
An image of an IRIX CD comprises every 2048-byte sector in Track #1. When burned to a CD-R, it will function identically to the original (because although there may be some differences in ancillary data such as ATIP and MCN, only specialized burning software such as CDrecord can see them). The data is always on the first track using Mode 1 (2048-byte sectors). Some discs may have had additional audio tracks, but no additional data tracks as far as I am aware.
The way the data is partitioned from the SGI's point of view is actually irrelevant to making a perfect copy. It's just a blob of sectors.
To check if an image file is valid,
Code:
% hexdump -C SGI-IRIX-product.image | less -B
00000000 0b e5 a9 41 00 00 00 00 00 00 00 00 00 00 00 00 ....
This usually means the image was created correctly, although I have seen images on archive.org that began correctly but were prematurely truncated.
The "0b e5 a9 41" is a magic number used to identify the beginning of a MIPS/SGI disklabel.
An image of the sectors in a track has no internal indication of completeness. There are two ways to check if it has been truncated:
1. Check the length of the track on the original disc.
Code:
% drutil toc
Vendor Product Rev
PIONEER DVD-RW DVR-XD10 1.00
First session: 1
Last session: 1
First track: 1
Disc type: 0 (CD-DA, or CD-ROM with first track in Mode 1)
Last track: 1
Lead-out: 01:24.40
Session 1, Track 1: 00:02.00 data track, digital copy prohibited
Because the first track begins at 2 seconds, and the lead-out begins at 1 minute, 24 seconds, 40 frames, we can calculate the number of frames in track 1 (in this example, it is 6190). Multiply that by 2048 bytes per frame (sector), and this disc has a data area 12677120 bytes long. If the image is that size, it was not truncated.
2. The second way is to interpret the SGI disklabel to see if the image is long enough to contain all of the SGI partitions. This is more involved, but you can read the archived
Nekochan thread to see some ways to do it.