Skip to content


Category: Preservation

I was making backups of old turbo-tapes to disk and noticed that the quality was very poor on some tapes. I have a LOAD-IT datasette with a signal meter. Problem with it was, that I could turn the knob (head alignment) 45 degrees and still have same two(lousy) bars on the meter. There was a need for something more accurate when adjusting the alignment to get the best signal while reading the tapes.


My solution was to implement an analogue VU-Meter to show the signal strength and a possibility to listen in on the signal to determine if its data or other information(music).
Update 2015-04
Information on how to build a VU-Sette :


Down right, a 22 mm hole is drilled for the (obvious) VU-Meter.


The VU-meter itself is from a batterytester, hence the text 🙂


In action


FinalTAP Result
A quick comparison with FinalTAP on two .tap images. Left tape has been read with “VU-Sette” and right tape with LOAD-IT. I tried several reads with LOAD-IT but the result was pretty much the same. There is nothing wrong with LOAD-IT, as long as you got a good signal on the recorded media.

In my case, “VU-Sette” allowed me to adjust the head more precisely and get out a (much)better read of the tape. For you who are not familiar with FinalTAP, its a tool for examining, cleaning and restoring digitized data cassette tapes (TAP files) for the Commodore 64 computer.




While making backups of some disks(Commodore 5,25 disks with a Zoomfloppy) I noticed that the reading error-rate was very high. The disks are from the mid 80;s but they can survive depending on how they have been stored and what not.

I could get a big variety of errors on totally different sectors while (re-)reading a disk. I cleaned the R/W head, disks, used different transfer-programs, speeds, copied disks to another media on the native system etc. (even had some ridiculous amounts of read retries) and yet nothing helped.

Another thing that was a bit concerning was the mylar coating (recording media) took some serious beating for every read. I could see on the surface where the R/W head had passed. Some disks even lost the coating, leaving a transparent plastic behind.


…condition after a couple of reads, Track 18 “visible” in the middle.


It was obvious that these disks didn’t have unlimited reads and with the varying read results I decided to gather some data.

To make a long story short… the disks are stored as image-files ( .d64) and include a separate block for the error-information. This is where I started looking.

First I made a tool to visualize the data and then I extended it to gather sectors from different disk images(same content) and combine them to as close to a whole image as possible.
Read # 1. Errors: 26


Read # 2. Errors: 10


Read #3. Errors: 10


Images 1 and 3 combined. Errors: 7


Images 1, 2 and 3 combined. Errors: 1


Combining the data from the three images resulted in an image with (just)one bad block.





* Version v1.0 does not support 40 track disks.