Maybe I am a bit paranoid about data integrity, but since between
first several CDs I made almost half had data errors, I suppose
careful verification if the data is correct is not a big paranoia.
I am using mainly Linux and plain DOS, therefore my info, and
especially programs will be most helpful to people using these
system, rather than e.g. to users of Windows (some of them can
be used on Windows as DOS applications; but cd2file cannot).
DOS programs here are executables compiled using Borland TC1.5
and usually containing their source (extractable by PKUNZIP).
Linux programs are as C source or bash scripts (plain text).
A 'dir' or 'ls -l' usually shows image size in bytes, mkisofs
tells it in 'extends', which are 2048-byte sectors on the CD to
be written, and CD recorder software tells the CD size as time.
Most likely you need conversion between these CD size measures.
I wrote simple bash script 'isosize.bash' which extracts size
from ISO image, and displays it, as well as size of the image.
If invoked with a number as arg, and the number is not filename,
it converts the number (assumed to be sector #) to playing time.
For DOS I wrote an utility 'cdimgchk' (DOS does not have so
powerful shell) which displays ISO image size information, and
(may be useful) allows to add several sectors at its end.
CAUTION: it does not check if the file it deals with is really
ISO image, and while I know it works correctly with images
I had I cannot promise it to work correctly with other images.
Both of these display size in sectors, and as time 'mm:ss.ff'.
WARNING: I noticed CeQuadrat WinOnCD (3.50, for Windows NT)
sometimes incorrectly recognizes size of ISO image; usually it
is not a big problem if it writes even few hundreds sectors more
than needed, it can be fatal error if it truncated the image by
hundred megabytes (it told bad size for SlackWare 7.1 install
disk, and I did not try to record it - I fixed the problem using
debugger, then wrote cdimgchk to do it easier way in future).
Using my utilities and comparing their result against image size
recognized by WinOnCD you can detect the problem before recording.
CAAUTION: I tried it successfully on CD-s with single session.
For multisession CD-s it is more complicated, and I still don't
know well enough how to write programs which would do it. (the
problem is to find where to read the next session and how much)
On Linux, or probably every Unix, it is simple: you can just
read data from CD drive using 'dd' (I recommend it rather than
'cat'), like 'dd if=/dev/cdrom bs=2k count=ccc', where the ccc
is number of blocks to read (without specifying the count, dd
would read until error, at least if the CD was not closed and
you still can add next session to it; also it is possible to
read more than the original image had, and get wrong checksum).
Pipe the command with 'cmp' or 'md5sum' to compare it to image,
or verify its MD5 digest matches value of the image.
For DOS, and probably ATAPI drive only (I do not have any SCSI)
I wrote a program 'cd2file' which can read track from CD and
either copy or compare it to disk file. And I use it to verify
the CD exactly matches the image. I need check if sector count
displayed matches image size - the program does not tell if the
CD has less data than the image.
For DOS and other systems capable to run DOS programs: I wrote
a 'shrcmpt' program to compare entire trees of files, it takes
two mandatory args: starts of these trees; and optional arg for
log name. Its initial purpose was comparing database files while
they were used, therefore it operates in 'shared' mode, and it
is reflected by its name: SHaRed CoMPare of file Trees.
Unfortunately, file comparing can be used only when their names
and directories are the same - on CD some names may be changed.
On Linux and other Unices: you can use 'find /mnt/cd -type f' to
find all files on the CD, then compare them to original files or
checksum them. Checksumming takes more time (I suppose), but it
has some advantage if checksum values are long enough (e.g. MD5)
to identify these files: you can checksum all files which were
to be put on a CD, then write the CD, then checksum files on it,
and finally check if all checksums of original files are between
checksums of files on the CD; if yes, you can assume all files
are backed up to the CD, if no, you have list of missed files.
This is a technique which I use for backups: I keep MD5 checksums
of all files I have on CD-s, and I compute MD5 checksums of all
files on disks, then find values not present on the CD-MD5-list,
select files of these MD5 checksums and copy them to temporary
disk; when I collect enough of them, I write them to a CD, then
compute MD5 checksums of files on the CD, and so on.
This way I can verify all files to be somewhere on backup CD-s.
To make checksumming easier, I wrote 'md5list.bash' script which
reads filenames from STDIN and writes 'md5sum' output to STDOUT,
and 'md5tree.bash' script which gets tree start as its argument
and writes to STDOUT; the first probably better handles strange
filenames; use it in pipe: 'find dir -type f | md5list.bash'.
For DOS I wrote 'md5tree' utility which scans a directory tree
and computes MD5 checksums of all files found.
Yet another problem is comparing lists of MD5 checksums.
I cannot do it in pure DOS because of limitations of 'sort', and
I always use Linux to sort checksums. It would produce identical
lists of checksum for original files and files on CD if they were
the same, but there is some problem if you use, say, mkisofs with
-T option which produces files TRANS.TBL, and in case of error
it would not say which files were wrong. Therefore I wrote yet
another utility, and while I wrote it for Linux it most likely
will work on any system with standard C compiler: 'md5bool' which
needs few sorted files containing MD5 checksums in format md5sum
or md5tree produces, one on STDIN and one or more 'additional',
for every STDIN line it check how many additional inputs contain
the same MD5 checksum, writing the line to STDOUT if the number
matches defined criterium which is 'below N' or 'at least N'.
This way I can tell, say, which files were backed up 3 times or
more, or which files were backed up once or not at all.
I use the program to select files for backup, and to check if the
backup is correct - e.g. 'md5bool -b cd-md5-sums < disk-md5-sums'
shows all files which were not written correctly to CD.
On Linux, file checksumming can be done on CD image before burning
CD: mount the image by 'mount image-file mount-dir -o loop', and
you have read access to files in the image - it can be a check if
mkisofs wrote the image correctly, but I do not recall any error
which could be detected this way (maybe omission of some files
which were planned to be on the CD is likely). Errors I have seen
were errors of copying image or data files to the system where the
CD was recorded, or of CD writing - therefore checksumming the CD
image before and after network copying I assume more reasonable.