[HECnet] VaxHaven CD-ROM image archive issue (and solution)

[G.]

Hello everyone,

	some time ago I discovered that several images downloaded from the
VaxHaven CD-ROM image archive appear to be corrupted. Actually they are not
really corrupted: they just include not only sector data from the original
media but also CD-ROM sector preambles and error-correcting codes which are
usually skipped when dumping discs with e.g. the UNIX 'dd' command.

In other words, CD-ROM raw sectors are made of a 16 byte preamble, a 2048
byte data area, and a 288 checksum (Reed-Solomon) for a total of 2352 bytes
whereas audio CDs use the whole 2352 bytes in another way (channel frames).

See https://en.wikipedia.org/wiki/CD-ROM for more information.

Since I usually mount these disc images directly on VMS with the LD driver,
I wanted to find a native way to "clean" them which would not require any
additional software besides whatever is available on a standard VMS system.

After downloading and unpacking some affected image, the first thing to do
is to ensure that it has some sensible RMS attributes:

$ SET FILE /ATTR=(RFM=FIX,LRL=2352,RAT=NONE) AG-Q2PLL-XE.ISO

Then we will use the Sort/Merge utility to fix it. To do so we need a file
to instruct the utility on how to manipulate data records both in input and
output. Let's call it CDFIX.SRT and store it with the following lines:

/FIELD=(NAME=HEAD, POSITION=   1, SIZE=  16)
/FIELD=(NAME=BODY, POSITION=  17, SIZE=2048)
/FIELD=(NAME=TAIL, POSITION=2065, SIZE= 288)
/DATA=BODY

Finally we could run the utility to extract the good portion from every
record of the original image:

$ MERGE /NOCHECK /STAT /SPEC=CDFIX AG-Q2PLL-XE.ISO AG-Q2PLL-XE_FIXED.ISO

This is the result on a somewhat slow system. Note the input and output
record length on the right column:

                  OpenVMS Sort/Merge Statistics

Records read:      304468          Input record length:     2352
Records sorted:    304468          Internal length:         6761
Records output:    304468          Output record length:    2048
Working set:        65536          Sort tree size:             0
Virtual memory:       416          Number of initial runs:     1
Direct I/O:         81792          Maximum merge order:        1
Buffered I/O:           8          Number of merge passes:     1
Page faults:           35          Work file alloc:            0
Elapsed time: 00:04:25.92          Elapsed CPU:      00:00:32.98

Anyway, a friend of mine provided me with a short Python program which
achieves the same result:

with open("AG-Q2PLL-XE.iso", "rb") as fr:
    with open("AG-Q2PLL-XE-fixed.iso", "wb") as fw:
        byte = 'somedata'
        while byte != "":
            _ = fr.read(16)
            byte = fr.read(2048)
            fw.write(byte)
            _ = fr.read(288)

I didn't test any of the above with every image in the archive, but I
suppose that the "corrupted" ones have all the same problem.

HTH, :)
G.