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

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.