How plausible is this data corruption on an IBM 9-track tape?

Question

Preamble

For a while, I had a copy of a BESM-6 Pascal compiler which worked only on very simple programs, like "Hello, world", and would throw a division by 0 exception on anything more complicated, and, on another disk image, a copy of a slightly older revision of the same compiler which worked perfectly.

Last week, I got a chance to figure out what was going on by doing a comparison of the two compiler binaries; luckily, they synchronized quite well except for a slight difference in offsets in procedure calls.

The difference was in a couple of instructions, which were completely nonsensical in the bad version. After replacing them with the corresponding instructions from the good version (correcting for a procedure offset), the problem went away.

Question

As far as I remember, the IBM 9-track tape with the disk image was given to a guy who had a tape drive in his garage, and he had sent back the result, so it is unknown if reading of the block with the corruption was flagged as I/O error — because of the differing parity of the bytes between the good and the bad version — or not.

How plausible is a media corruption of an 800 bpi (NRZI, I guess) 9-track tape which would cause reading of the byte sequence ... 10 D9 8C 45 32 6E ... instead of the correct ... 10 00 35 D9 8C 6E ...?

Answer 1

Comparing the two set of bytes suggests there might have been a problem where the tape physically "stuck" and then "jumped", reading erroneous data:

10 10
   00
   35
D9 D9
8C 8C
45
32
6E 6E

Of course there is no way to know what conditions the tape had been stored in, how well the tape reader had been maintained, and how the reading software would have handled hardware errors (including parity errors).

Answer 2

There is no easy answer without way more information - especially as it's a non-IBM machine.

In any case, a bit flip on 9 track is of course possible, like with any media. Detecting it depends on a lot of factors not mentioned so far - for example what format is used, what block structure, if at all, and what additional checking this block structure offers.

Without seeing the parity bit noting can be guessed from the byte sequence shown.

Basic to all formats is only a single parity bit per character. Already a double bit flip within the byte will pass undetected. Only additional protection like record and block checksums/CRC may detect such - if used. Basic recording on 800 NRZI 9 track does operate with records and no additional error check information. If the data is recorded in basic record format, an I/O error will only be be raised on single (or any uneven) bit flip within a single byte.

Long story short, it would be helpful to know more about the higher format layers used and see the raw header data (CRC in block formats is stored at block start).