The Format War

I finally found a suitable tape deck. I bought 4 decks before running into a Technics RS-T230. This is a double tape deck that is capable of duplication. I found it at a local business that sells antiques and oddities for 20$. I brought it home, cleaned the heads, lubed it up, and ran a test.

I recorded the same fugue I used for other tests onto a tape. I tested the playback in the same deck and my Walkman and couldn’t hear any wow or flutter. The deck is newer (1988-89) and seems to be in excellent condition. The belts don’t seem to be cracking, and the tape heads don’t show the wear that some of the other decks did.

Since the audio test and various other tapes sounded great I decided to continue testing and look at the performance of different SSTV modes. I want the quality of the tape I give to my friend to be as high as possible with the setup I have and the setup my friend has.

One variable I had some control over is the mode of SSTV signal used to encode the images. I previously limited myself to a subset of the modes supported by pySSTV, but I expanded my selection to the formats supported by QSSTV. To keep the testing brief I limited the mode variants to the “normal” resolutions of 320x240 and 320x256: Martin M1, Scottie S1, PD 50 and 90, and Robot 36 and 72.

To compare performance of modes I ran a simple test:

1. Encode the test image with QSSTV or pySSTV using each mode
2. Join the encoded images into a single track
3. Record the track to tape using a tape deck
4. Play the tape using the test device (see below) into a phone running the app “Robot36”
5. Compare the decoded images by visual inspection

I repeated step 4 for with a Technics RS-T230 and a Walkman WM-FX10. I tested with a Walkman because my friend will be using a portable cassette player to view the tape. I used a version of the PM5544 TV test card to test mode performance. Although this card was intended for PAL broadcasts, I still found it useful for identifying tape artifacts. I have compiled the output images into a single image to make visual comparison easier (view at full size).

This test revealed several software bugs. All images were generated using QSSTV except Martin M1 and Robot 36 which were generated by pySSTV. The implementation of these modes in QSSTV is buggy: Martin M1 starts near the end of the image and Robot 36 seems to have timing or synchronization issues. PySSTV’s implementation of Robot 36 also has a bug and causes color information to be sent incorrectly.

At first I was surprised by the results of the test. I was anticipating the PD modes would look best due to the tuning error correction feature of the modes. Ultimately the Robot 36 mode degraded the most gracefully. I suspect this is because the mode has the shortest scan-line duration of all modes. Playback on tape poses 2 major problems for synchronization: minor speed fluctuation due to wow and flutter, and difference in line speed due to difference in record and playback speeds. Wow and flutter introduce a periodic timing error that distorts vertical lines in the image. Playback speed difference causes a scan-line length difference that results in color separation and distortion most noticeable on the right side of the image.

Robot 36 is far from high resolution, but is has the highest scan-line speed (Table 4.3) of all the modes tested. Since synchronization is performed at each scan-line, cascade of timing error should be reduced at higher scan-line speeds. I accepted the resolution trade-off for improved consistency on different playback devices. The only downside of Robot 36 was the presence of bugs in both encoders I tried. I didn’t want to keep searching for software, so I forked pySSTV and fixed the bug (lucky for me it was a very simple fix). Now all that remains the addition of a commentary/music channel to the make script.