First the sampled tape wave audio files from Tom were converted to such digital timing format -tapes that is typical for emulated Commodore computers, a.k.a. TAP-file. The wave files contain the tape data as sinewaves of varying frequencies. Standard Commodore tape format consists of three different frequencies that define short, medium and long "bits", which when combined in certain ways, are interpreted by the system as markers and bits. The TAP file contains values that are the frequencies, sort-of.

Typically a program (in this case what is built into the Commodore operating system) reading a tape calculates time in one way or another and the frequencies, or rather intervals created by the frequencies, set a flag in the system which then checks how much time has passed since the last interval and then knows if the value was short, medium or long.

The tape in its current condition was either not playing at the required speed, or perhaps something it the setup that originally wrote the tape has had issues, so the frequencies keep changing, sometimes so much that the generated intervals start occurring outside the range the loading program is expecting them. The defaults loader in Commodore computers can adapt to slow changes of tape speed, but I have no idea if it would've worked with this tape.

As the timing of bits shifts outside the expected standard ranges, normal tools made for managing TAP-files are likely to fail extracting the data without errors. Tape degradation at magnetic level can also cause the signal to get noisy or fade out which would cause random frequencies which will then results as more inconsistent intervals in the timing and are much more difficult to repair. My wave to TAP conversion is also very simple and will generate these kind of errors if the analog signal has fade outs or extra frequency components (noise) "modulating" the signal.

Now, the basic Commodore tape format codes the data such that each byte is always made from same amount of short, medium and long intervals; byte marker + 8 bits of data + parity bit from a pair of intervals of long + medium as the marker, short + medium for bit 0, medium + short for bit 1. So a single byte of data always has 20 intervals coding it on to the tape. The a long + short to signify the end of data.

Having this in mind I made a short program which simply starts parsing the intervals for data bits from the first byte marker, only checking if the first data bit interval in the pair is shorter or longer than the next one and defining the bit as 0 or 1, also ignoring the parity pit. This approach is completely immune to the shifting of the frequencies in the wave file. The games having been written in basic also made analysing the resulting data quite a lot simpler than if they'd been written in assembly language. I also exported a report telling me what intervals the program is processing so I was able to clearly see if the marker intervals always happen at the start of each byte so I was able to detect if there were noise or other interference generating random intervals breaking the data.

The basic Commodore file on tape consists of a header which contains the name of the file, file type, loading address and the length. The header is stored twice for redundancy. Data is stored the same way, twice for redundancy. Both header and data also contain a checksum byte as the last byte. The checksum is a simple xor of all the bytes, but atleast it's something.

This way I can compare the extracted data to see if the two copies match, where they possibly differ and if the checksum is ok, along with the multiple samples Tom had made from both sides of the tape. I had some bit errors in the first game most likely due to the simplicity of my wave to TAP converter, and was able to correct them comparing the two copies.

After I had all three games extracted from the wave files Tom then gave me the digital TAP files of the tape he had also made separately directly from the tape to compare. The digital timing data looked much worse than what I got from the wave files, yet in the end I was able to use the same method of counting the bits to extract all three games correctly from the digital files on the first try.