I just finished splicing together a video demonstration of an artchive.
In the video I play a demo tape into an adapter attached to an Android tablet and a laptop (offscreen). On the tablet I decoded SSTV signals with Robot 36 and recorded the screen with Du Recorder. On the laptop I recorded the audio from the tape using Audacity. I recorded the beginning of the video using my smartphone attached to a tripod with some lightweight bonding material. After I gathered all the source material I spliced it together using Kdenlive.
The audio on the tape I played in the demonstration was generated by this make script. The repository contains instructions on how to make a custom artchive and contains the source material used to create the one shown in the video. I'll be sending this demo tape to my friend along with the tape I am currently working on for him.
I've amassed a bit of equipment and parts from this project, which should make future tape endeavors a bit easier. I would like to explore more uses for the medium, especially reliable data storage using consumer-level equipment.
Today I recorded and presented my first tape artchive (to a very small audience of 2 in my apartment). In the last couple days I worked on finishing up the make script and put together some demo content. I didn't want to publish my friend's art, so I prepared a tour of the planets of our solar system.
I sourced images from the NASA Images collection on the Internet Archive. I also sourced facts about planets from the NASA Solar System Exploration pages. I don't make a very good voice actor, so I used Festival to generate speech for the slides. I recorded the artchive over an old self-help tape I found in a large set while dumpster-diving.
In previous tests with the Walkman I noticed playback speed could vary depending on the orientation of the tape player. When the player was on its side the tape made a scraping noise in its shell and slowed playback just enough to affect picture quality. I trimmed the length of the tape to 10 minutes to reduce the drag of the tape in the shell.
Since testing I also found the speed adjustment pot on the Walkman. I used the test tape as a calibration tool to set the Walkman's playback speed. You can see in the captured image where colors are separated pre-adjustment, and where the colors align post-adjustment.
After adjusting the Walkman's speed the higher resolution modes looked a lot better. I am still going to use the Robot 36 mode because it is resilient to minor speed differences, and has a very short transmission time compared to other modes.
Once I film the solar system demonstration tape I can wrap up the public portion of this project and get my friend's art compiled. Stay tuned for a demonstration soon.
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:
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.
Today I received the package of assorted tape drive belts in the mail. None of the belts in the package were a direct fit for either set of pulleys so I trimmed the next largest sizes and spliced them with super glue.
The trimmed belts seemed to fit well, but there was still a very noticeable fast flutter present in playback. I searched for more causes of flutter and found that a poorly oiled capstan bearing may be to blame. I oiled the pinch roller and capstan bearing on the Sony with synthetic 0W-20 oil. I found that a lightweight motor oil was recommended on a couple forum posts.
I didn't hear an improvement after oiling the bearings so I started to grease the plastic parts. I took apart enough of the mechanism to remove all the plastic pieces then cleaned them with alcohol. I got too heavy handed with one of the plastic gears and broke it during cleaning.
I made an attempt to glue the gear together with superglue, but I did so carelessly and ended up misaligning the pieces. I put the deck back together with the sloppy gear with poor results. The tape repeatedly jammed and got stuck in the roller.
I have ruined the Sony deck -- not beyond repair, but beyond care. The Sony TC-FX160 isn't a great deck to begin with. I simply don't wish to put anymore time or money into trying to get a $3 thrift shop find working.
I would switch to the Panasonic deck, but the transport on it needs work. I'm pretty tired of blindly hacking at cassette decks or I would give a shot at lubricating it. I'm still in search of a decent recorder for this project and long term use. Hopefully I'll have some luck junk shopping soon.
I managed to pick up a few critical parts while out shopping today. I found a 3.5mm TRRS auxiliary cable and a small mint tin to act as an enclosure for the cassette-to-phone adapter.
The original purpose of the adapter was just to adjust the signal out of the tape player to the level of a smartphone microphone input. I dislike the idea of only using a single stereo channel, so I decided to use the extra channel for music or commentary. I came up with a design that allows the left tape channel to be used for SSTV signals and the right tape channel to drive a pair of headphones.
This adapter tricks a smartphone into detecting a connected microphone by placing aresistance across the second ring and sleeve of the TRRS connector. A capacitor prevents DC current from traveling between the player and phone and prevents the attenuator created by the 10kΩ and 100Ω resistor from decreasing the resistance observed by the phone. This capacitor also creates a high-pass filter combined with the 2.2kΩ resistor, but the filter has a cutoff frequency around 7Hz so performance should be unaffected.
I used a small breadboard to prototype the circuit. I cut the TRRS cable in half and soldered each side to header pins to make them easier to work with. I bridged the second ring and sleeve of the TRRS connector going to the tape player because I needed it to behave like a TRS connector and didn't know which contact the tape player's headphone jack would connect to.
I tested this adapter and found it to work with my Honor 5x Android phone as well as an iPhone 5S. After testing, I put assembled the circuit on a small piece of proto-board and placed it in the metal mint tin. The wires are secured with zip-ties that are epoxied to the inside of the tin. This provides no strain relief, but does secure the wires from being moved.
I also added added a small screw to keep the lid from accidentally being opened. Here is the adapter ready for labels.
I'm still waiting on belts for the Sony tape deck to arrive. Once I have those I'll be able to run some format tests. While I wait I'm going to work on adding the commentary/music track support to the make script.
At the end of the previous log I stated I reduced the flutter of the Sony tape deck to almost nothing. This was a hopeful statement that was proven wrong when I tested out the deck with a different recording. The recording I initially tested with was full of low range instruments with vibrato, which made it difficult to detect the flutter that was present. When I recorded piano music a high-pitch flutter was noticeable on long notes.
I eliminated a lot of the flutter by switching to a less elastic belt material, but a good amount of it remained. I thought the remaining flutter was due to the natural shape the belts take because of the way the bracelet cord is packaged. The cord is wrapped around a cardboard back which causes visible bends every few inches. The belts made with the cord take an oval shape instead of a perfectly round one.
These bends could cause the speed of the motor to slightly change when they are flattened around a pulley causing a small frequency deviation. To try and fix this I straightened a length of cord and made another set of belts.
To straighten the cord I placed it in a bath of boiling water for about 30 seconds then removed and stretched it. I repeated this process 5 times until I had a fairly straight cord.
I cut and measured the belts from the previous log since they appeared to be around right size. The capstan belt measured 143mm, and the fast-forward belt measured 176mm. I made new belts from the straightened cord. You can see how the new belts (pink) look much more round than the old belts (blue).
I ran another testing using Bach's Fugue in G Minor. To my disappointment these belts caused the same flutter the other ones did. I tried making different measurements of belts to see what effect they had on the flutter. First I tried a larger capstan belt, but the flutter worsened and reduced in frequency. This led me to believe a shorted belt would help.
I tried several more sizes of belt without much of an improvement. The results ranged from very slow flutter with looser belts, to a fast flutter with tight belts. The flutter never completely left, and got worse as I tried smaller and smaller belts.
It seems that the elastic cord wan't as good as I thought it was in the previous log. I'm giving up on making belts for now to focus on other parts of the project. Hopefully I'll be able to buy a large pack of real belts soon and try with those.
Last night I got the Sony deck working again by replacing the missing belts with rubber bands. This seemed to work, but introduced a lot of flutter, and put tension on the pulleys. This made me unhappy so I went in search of a better solution. I scoured Hifi Engine for a service manual, but I didn't find an exact match. I did find a few units similar in appearance; notably the TC-FX110. The exploded view of the cassette mechanism looked like the one in the TC-FX160:
I goofed by guessing the belt placement in the previous log. The exploded view shows the correct placement of the belts and also shows part numbers for the belts (3-390-855-01, 3-390-816-01). I googled around a bit for replacements, but decided to try out a different rubber band approach.
I split a large folder band into two almost square strips that looked about the same size as the original. I wrapped the band around each set of pulleys and cut the two belts from it. I joined these belts at the edges with superglue and marked each with a different color to mark where they went.
I installed the bands according to the exploded view. The belts were much easier to install this time around.
The new "belts" made the problem worse. Flutter was now very obvious on the tape I tested with. Not all was bad, though; fast-forward was no longer broken. I think this arrangement of the belts is correct, but the elasticity of the rubber bands causes the flywheel to fluctuate in speed.
I tried replacing the rubber bands with thread tied onto the pulleys. This looked promising with no tape in, but the tread slipped under load.
Not wanting to give up I went to Wal-Mart to look for potential belt materials. I found a product called "Princess Elastic Cord".
This is a cord made of a rubber-like material, but seems less elastic than rubber bands. I used the rubber band belts as a guide to cut belts from the elastic cord.
I installed the belts and played the test tape. The flutter was very reduced -- but still there. The belt driving the capstan was a little loose, so I removed a couple centimeters and tried again.
This was it! The test tape had very little audible flutter compared to other playthroughs (I don't have golden ears, YMMV). I'm curious to see how these belts hold up. Now that I have a working recorder I can focus on getting the sound from a tape player into a mobile phone.
This was not it. The recording I used for testing fooled me into thinking there was very little flutter. I have since tried a different recording and found the elastic belts to be very poor. The next log has more details about this realization.
The end of the previous log stated I would be working on format comparisons this log, but that isn't true. This log will be focused on the Sony TC-FX160 stereo cassette deck that I picked up at a thrift shop today.
This deck appears newer than the Panasonic deck from my previous logs. The Sony deck is a single-purpose device where the Panasonic was a radio, phono pre-amp, and amplifier. I plan to use the better deck for recording and put the runner-up aside for a future project.
As I expected from a thrift shop find, the Sony deck didn't work. I tried playing a tape, but nothing in the player moved. I did hear a motor start when I pressed play, so I took the unit apart to look at the belts.
At first it looked like the belts were broken, but when I tried to remove them I got a surprise; they had gone so soft the texture was like uncured silicone. The belts disintegrated as I tried to remove it from the pulleys. I had to scrape for a little while to get most of the goop cleaned out.
I googled around a bit and found that rubber bands or string can be used as replacement belts. I didn't know how to install the bands as belts on this particular model because the old belts were completely gone. I couldn't find a service manual for this model, so I had to use the remnants of the old belts as a guide to place the rubber bands.
This seemed to work. The Sony deck will now play and rewind, but will not fast forward. I think this is because the rubber band attaching the top pulley to the motor pulls the pulley so that it does not fully engage when the fast-forward button is pressed.
I decided to run the same test as I did on the Panasonic to approximate the frequency response of the Sony deck. The following is a screenshot of audacity showing the spectrograms of a 20kHz to 20Hz sweeps on the decks.
The Sony responds to higher frequencies than the Panasonic. The Sony also sounds better and has much less noise. I'll be using the Sony deck to record the tape tests and the final tape (unless I see something really good out in the wild).
Recording information to a tape would be difficult or impossible with a dodgy setup. There are two issues with the recorder: the low audio level and the dirty AUX switch that yields a random audio level every time it's toggled.
To fix the low level issue I decided to try out driving the recorder with a USB sound card instead of with the laptop's builtin one. The laptop at max volume would only occasionally illuminate the -15dB LED on the "peak level" meter, while the USB sound card illuminates the +3dB LED at a little over half volume. These are rough measurements because I made them while gently "massaging" the AUX button so I could get a glimpse of the max peak levels.
The scratchy button was surprisingly easy to fix. The buttons didn't look easy to access or disassemble, so I tried a less direct method of cleaning. I pressed and released the AUX button rapidly for about a minute. After cleaning the contacts this way the random-level audio issue disappeared. My guess is that a thin layer of oxidation built up on the switch contacts over years of non-use. Depressing the switch quickly may have scratched some of that oxidation off, resulting in a better connection.
Since I hope to use this recorder for other projects I tested its response to the full recording range from 20Hz to 20kHz. I'm curious about the frequency response of the device and I'd like to see if there is any obvious distortion to the recorded waveform.
The test procedure was as follows: first record the sweep on to a cassette, then record the playback of the sweep with the computer, and finally compare the two recordings to approximate a response curve for the recorder. I used a sweep file I found on the UBC Physics website for the test. The level of the soundcard was set so the VU meter of the tape recorder read 0dB during the tape recording. The level of the tape player was set so audacity read 0db during the computer recording. The tape deck's Dolby NR setting was set to "out" for recording and playback so the waveform being recorded on the tape would not be modified. Below is a screenshot of the played and recorded sweep spectrograms in Audacity:
Bandwidth of SSTV signals is pretty narrow and frequencies used fall within 1200Hz-2300Hz (see this resource on SSTV stuff). This range on the recorder looks pretty uniform, but shows a strange (harmonic?) frequency. I am very curious to see what kind of image artifacts are caused by the characteristics of this recording setup.
This is a flawed test as I can't ensure my cheapo USB sound card has anywhere near a flat response, so I don't know where the recording artifacts are coming from. This test does, however, give me an idea of how this particular setup will perform for recording. Next time I'll be digging into testing individual SSTV formats with this setup.
I often assume the worst when I shouldn't. My last log stated that I would likely have to build a line to mic adapter to use the Panasonic tape recorder with an external input. I am happy to say I was wrong; the Panasonic tape deck has an auxiliary input.
At first I didn't realize the recorder had an external input. I began the hard way by taking the device apart and trying to understand the circuitry. After a long while of tracing leads with a flashlight and marker I decided it would be faster to understand the functionality of the device by experimenting with it.
I first connected a small speaker to the back of the deck, popped a fresh cassette in, then switched on the radio and pressed record. To my disappointment the ribbon and wheels in the tape sat motionless. The unit was still open from my attempted circuit exploration so I decided to play around with the tape mechanism to see if it would budge. On a whim I nudged the flywheel on the back of the tape compartment (see green arrow below) which caused the assembly to "click" and start moving as it should.
I started audacity on my laptop and played one of the recordings generated by the makefile mentioned in the previous log. To my delight the deck not only played the auxiliary input through the small speaker, but also recorded it to tape.
The joy of having a working recorder was negated by the almost non-responsive VU meter on the front of the deck. I tested the playback of the tape on my Walkman to find the levels to be extremely low and one channel to be louder than the other. The laptop I used for recording does a poor job at driving headphones very loudly which may explain the low volume issue.
I also noticed that pressing the "AUX" button on the front of the deck caused the VU meter to fluctuate between one bar and complete silence. I think this is caused by dirty contacts in the input selection switch and my also be the cause of the channel balance issue.
Admittedly this isn't an ideal setup for recording any reliable tests. Next time I plan to clean the contacts of the "AUX" switch and try recording again with a USB sound card to see if I can get better results.