Welcome to the home of ISOCOMP/2, an ISO (and RAW and RSJ track) image comparison utility, part of the XCOMP/2 package. A port for WIN32 is also available (for those who are sometimes forced to use Windows, but you need OS/2 to get access to that port!)..
When invoking ISOCOMP.EXE without commandline arguments, the help is displayed:
Well, above explanation should be self explanatory. ISOCOMP/2 assumes that an ISO image file (2048 Bytes/Sector) has been specified unless a file has the extensions:
There are basically 2 variations for the commandline:
A sample run to compare the contents of a CD-ROM media with the ISO image file it was burnt from may output (though we are comparing ISO images, we refer to it as being a file, because OS/2 treats them that way):
Another example to compare the contents of a CD-ROM media with the RAW image file it was burnt from:
Or, another example to compare the contents of 2 medias in 2 CD-ROM drives:
Or finally, an example on how to view the checksums for the contents of a CD-ROM media:
One note about the line containing the Throughput measurements. Above example shows about 607kB/s throughput on the Source CD-ROM drive, which says the CD-ROM is performing at a speed of about 4x (a througput of 150kB/s is rated as 1x speed). 4x seems to be a little bit low for today's CD-ROM drives, but the media used was a CD-RW media, and writeable or especially rewriteable medias tend to be much slower than mastered CD medias, for both reading and burning (for factory mastered medias you should get the top performance of your drive)!
The performance given for Source and Destination is just the raw performance of the OS/2 DosRead() APIs without accounting for overhead of the comparims itself (for the CD-ROM drive that gives you a good hint about the raw performance of your CD-ROM drive, e.g. if you have a 32x drive and use factory mastered medias, you should get near to a 32x speed). The Total performance does include all overhead, that is the timer is started when the files are opened and stopped when they have been compared. Thus, don't take the performance specified too serious!
ISOCOMP/2 is a multithreaded application, that is the Source and Target file are read by different threads concurrently to speed up performance. As usually you won't compare an ISO image from the contents of a CD-ROM drive with the image stored as a file on the same drive (if you could do that, you might already be within the singularity of a black hole ;-) this is a default option, however you can force ISOCOMP/2 to use only 1 thread by the commandline option.
You may also notice that you may have a different buffer size. This is normal, because ISOCOMP/2 takes the amount of physical memory into account to be efficient on one hand and to limit swapping on the other hand. Using the option /TINY ISOCOMP/2 will use 2 64kB buffers instead of a percentage of the RAM installed. This might be useful if you are running a memory constraint system (or a last resort on buggy drivers, that can't partition the buffer in multiple 64kB DMA requests).
Finally, to ensure that you can notice the progress, a percentage indicator, and if required a retry counter, will be displayed while comparing ISO images that are larger than the given buffer size.
When comparing using CD, CD-R or CR-RW media (increasing probability in this sequence), you may get alarmed by miscompares which disappear during one of the retries or when running ISOCOMP/2 once again. I'm not sure what causes that, but from my experience I suspect that misreads of the drive (e.g. weak bits) occurred (when thinking about the requirements of the hardware regarding the exact timing and positioning of the head for writing one bit, increased by the use of some media like e.g. 700 MB CD-R/CD-RWs, 800 MB CD-Rs and high-speed CD-RWs, on surfaces that are indeed sensitive to scratches, to I'm not really surprised. Reading the same files again may just cause different read results due to the drive's head repositioning in a different way, ISOCOMP/2 does reposition the head automatically during its retries, to ensure best results. You may also get different results for different drives, as a rule of thumb I thing the more modern a drive, the lesser the number of problems you'll get.
Assume that our CD-ROM drive is located at drive letter Q:
|
ISOCOMP/2 thus allows you also to create an ISO image file out of the contents of a CD-ROM. | |
|
ISOCOMP/2 thus allows you also to create an RSJ track image file out of the contents of a CD-ROM too. | |
|
| |
|
If the comparison succeeds, you have an exact 1:1 copy. | |
|
If you have downloaded an ISO image from the Internet and the checksums were also given there, you could verify that your download had no bit errors (though for both FTP and writing the file onto media this is very unlikely, you can be sure). | |
|
It's your decision if that's really useful, as you need about twice the disk space. |
If you found any problem or have a suggestion, please don't hesitate to tell me.
An ISO image is just the datastream in a single file that makes up the contents of a CD-ROM session from the beginning to the end. An ISO image thus is a way to save and/or transmit the contents of a CD-ROM without any data loss. In contrast to that, you could create of course another CD-ROM out of the files contained on a CD-ROM, but that way you may miss probably some information of the original CD-ROM (e.g. the capability to boot, or some information MS supposedidly has written on their Windows XP CD-ROMs to track warez copies).
If you have only an ISO image (e.g. downloading an ISO image is the way IBM has made available the Aurora and Merlin Convenience Pack 2 CD-ROMs to its employees a few weeks before the official release via Software Choice - thanks at this place for that service!), you can't be easily sure that the contents of the CD-ROMs you've burnt are really exactly the same as the source ISO image. That was the motivation for me (and my experience of having burnt CD-ROMs that contained errors) to write ISOCOMP/2 (in fact comparing the newly burnt CD-Rs of ACP2/MCP2 with the ISO image files downloaded was the first productive use of an ISOCOMP/2 prototype).
One way to compare the file contents of a burnt CD-ROM with the original ISO image is using Linux and the loopback device to mount the ISO image as a filesystem, and then using normal filesystem tools to do the comparison. Similar tools also exist for Windows.
Under OS/2 you could use the ISO image and RSJ track image plugins from NetDrive (available e.g. on Hobbes) to mount the ISO image (or RSJ track image) file as a filesystem, and then use e.g. XCOMP/2 to do the comparison of the file contents.
Again, both methods only allow you to ensure that the file contents are equivalent, but not information that is stored on a CD-ROM outside the filesystem! ISOCOMP/2 allows you to compare everything, on success you can be sure to have a 1:1 copy!
A RAW image consists of an ISO image enhanced by data that is usually filled in by the CD-Recorder during recording. A RAW sector looks like:
As you can see, a RAW sector can be converted into an ISO sector and vice versa, though ISOCOMP/2 only supports the direction RAW to ISO (as I don't know how the Sync and EDC/ECC is calculated and I'm not sure if supporting that would make sense at all).
You likely will encounter RAW image files, if the image you'll burn should be an exact copy of the original one, because if the CD-Recorder does not calculate the EDC/ECC data itself, it will even burn errors (which may be used as a copy protection measure). You'll likely find CD images in RAW format in the alt.binaries.warez.* newsgroups.
Under OS/2 you write RAW image files with CDRDAO, which is also available on Hobbes.
As I haven't yet found a (free) source for the specification of data CD-ROMs, that is the ISO 9660 specification, ISOCOMP/2 relies that the format and behaviour for data ISO image files is consistent to what I've seen in my own environment. However, some of my assumptions may be wrong!
Basically, I assume, that:
If you know some additional information about ISO images and want to share it or want me to enhance ISOCOMP/2, you're welcome to e-mail me!
The following items have changed between V1.20 and its predecessor 1.10:
The following items have changed between V1.10 and its predecessor 1.00:
The calculation of CRC32 and MD5 checksums is based on what that seems to be the standard algorithm used on the Internet. As I'm certainly not an expert in cryptology, and thus can't tell how good the quality of the CRC32 and MD5 checksums is (AFAIK it's rather good) , I used the sample codes I found on the Internet after a little searching as a starting point.
The CRC32 implementation I dereived from some freely available sample codes, the MD implementation is derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm sample implementation, which is also freely available if above identification is included on materials based on it.
ISOCOMP/2 is part of the XComp/2 toool, which you can also download from my site.