Tape Digitizer

Several years ago, while discussing the prospects of a “real” web site for my church with my pastor, I brought up the idea of putting our backlog of recorded services online. We discussed ways to digitize a copy of the feed which was already going to a recordable CD. This naturally led to a question about what we wanted to do with all the old tapes we had lying around in white boxes stuffed in various corners of the church, and I took it upon myself to look into getting them converted to some sort of digital format.

30 Years of Preaching Tapes (give or take)

So I scoured the internet for information on how to digitize old cassette tapes. There are a couple services out there that will convert them to CD’s and/or MP3’s. I found that they were running $5 to $10 per tape. Well, with something close to 2000 tapes to convert, this becomes… prohibitive for our church.

Another option I found was from a now-defunct company who once made equipment for doing exactly this sort of thing. However, it was quite expensive. Even the used gear I could find on Ebay now was running from $5,000 to $10,000. Interestingly, it consisted of a card that you put into your computer, a machine for running the tapes, and a big cable to run between the two. We’ll come back to this later.

The last option was the most obvious, but the least practical: run the tapes, by hand, in real time, from a standard tape deck, into the computer, and convert them manually. Again, with so many tapes involved, we’re talking about many thousands of hours of time. Even if they just run without interaction for a large part of the process, and then get switched in between, the hassle would be enormous.

So I went back to my pastor, and told him what I had discovered. It was clear to me that the church had neither the time nor the money to convert the tapes, and asked if I should just pitch them all. He kind of slumped in his chair. I asked him what that gesture was about, and he said, “Well… that’s my life’s work,” and explained that those tapes are, practically, the only tangible thing he could point to as his “output” for 25 years of work. We commiserated for a minute. I saw it from his side and became sympathetic to his point of view, but there was really no answer. I filed the situation in the back of my brain, and moved on to other matters.

“A rock standing out, in an ocean of doubt, and compromise”

Fast forward a couple of years, and I’ve taken a job with a new company. One that does advanced data acquisition and analysis. In fact, you could say that it’s really the backbone of the company business. Additionally, a big reason that the company has succeeded in this field is because there are a lot of really talented people there. One day, out of nowhere, two and two came together, and I realized that all the bits and pieces of the cassette-tape-digitization problem were lying around me in plain sight.


At our church, we had always had a high-speed tape duplicator to make copies of the tapes for people who weren’t in service. I got the idea that I could tap into the duplicator and intercept the recording head’s signals on their way to the copy, and feed them into a sound card in a computer. Then I could slow down the recording, and then convert it to an MP3.

I opened up the duplicator and started studying the electronics. This only got me so far, so I ordered a service manual for the unit, complete with schematics. I made some test probes with a voltmeter, but nothing was very clear, as my $15-Radio-Shack special wasn’t giving me a lot of info. So I finally admitted a certain amount of defeat, and asked the owner of the company I was working for (who is an expert at electronics) to look at my schematics. He immediately started recognizing the various sub-circuits, and explained to me what was going on with the signals as they passed through the various stages of processing. He drilled down to where he thought I should take the signals.

I cut off the phono ends of an audio converter cable, soldered them to one of the boards in the duplicator, and then plugged that into my computer’s sound card. I recorded what was coming from the duplicator, fed it into a really cool audio editing program on Linux, and slowed the recording down. It was a disaster. I had a strong, persistent noise that I couldn’t get rid of, and everything sounded muffled. I immediately recognized that my computer’s sound card was trying to record audio at 16x speed: something it simply could not do. All it could capture was the low-end frequencies, which, to it, seemed like high-frequencies when playing at 16x normal speed.


I needed a real digital acquisition card. I studied National Instruments’ product lineup for hurs and hours! I finally decided on one card that would work for my purposes, if I allowed a couple corners to be cut. The problem was that the card sold for $2,700! I guess that’s fine if you’re a big company doing things that will make a lot of money, but this was just a hobbyist trying to do something for fun. What’s worse is that the no-compromise card for this project retailed for $4,000! Fortunately, I found a card like I needed for about $130 on Ebay.


I bought one, along with a breakout board and cable. With that, I understood that I was making the same sort of equipment that I had seen on Ebay for thousands of dollars. So I grabbed the duplicator and all the old tapes from the church, to keep them safe from being thrown out, and I started to work on the idea.


I think National Instruments is a really cool company. They make some really cool hardware that does really interesting stuff, and they make really cool software to run it too. Although their LabView software is really expensive (and, again, amazingly cool), they support all of their cards on Linux with their C-based driver library, and they have extensive examples and an abundant help forum. There were a few twists and turns, but I finally got the program written. It acquires the data, and produces two WAV files: one for each side of the mono tape.

After taking the signals comes the post-processing. At a minimum, the second side of the tape has to be reversed and appended onto the first side. However, while I’m doing this, I go ahead and chop off silence at the ends of the both sides to get rid of the dead space due to the tape leaders, normalize the volume, and resample to a standard bitrate. (I even developed a “multiband compander” to try to remove most of the Dolby noise reduction effect that our recording deck put on the tapes, but I don’t think I’ll use it in production because of variances between tapes.) For all of these functions, I use a wonderful open-source tool: SoX, “the Swiss Army knife of sound processing tools.”

The sonic effect of Dolby B Noise Reduction

Everything Needs a Webapp

After getting this far, of course I needed a webapp to manage the metadata for the tapes. After all, it’s sort of what I’ve been doing professionally for the past 7 years or so. The church had paper records of the oldest recordings, probably for half of them. There were Word docs for the rest. I scanned and OCR’ed the paper, and merged that info with the Word docs into a big spreadsheet. Then I manipulated the data until is was “clean enough,” and stuffed it into a database, where I did some more cleanup. Then I finally put a Rails frontend on it, and the cleanup continued.

As an aside, I needed to install everything by hand on CentOS to get Rails running. I needed to download and install Ruby, rubygems, the Rails gems, and the mysql gem. It was a lot less scary than I thought it would be, and makes me think I should be using RVM in general. Anyway, for my own reference, and yours, I also needed to follow this advice, and install the “ncurses-devel” package to get the gems compiled.

Now I’m not going to sit here and run these tapes by hand, changing them every 6 minutes. So, as a first pass at automating the process, I needed to get control of the duplicator by the computer. I wired into the start switch relay, and the run-and-rewind logic circuits on the duplicator’s board. The DAQ couldn’t generate enough current to trip the duplicator’s relay, so I had to buy a 5v solid state relay from Radio Shack. However, the DAQ didn’t have enough juice for it, either, so I tried building an op-amp based voltage follower. This wasn’t the best option, but it was all I had been taught in school. Unfortunately, while trying to get it going, I crossed some wires checking voltages with my multimeter, and fried my DAQ! (If you look closely at the picture above, you can see a big hole blown in the side of the top right chip.) It also taught me about the usefulness of zener diodes…

So I bought another DAQ on Ebay again, took some advice from my boss — who has a masters in EE — and built a transistor-based current amplifier. I run that with a USB-based power supply I put together from a kit from SparkFun. I felt like I was back in the 70’s, building a radio from parts ordered from the back of pulp comic books.

The Wired-Up Duplicator, with a Digitally-Triggered Start

As a second pass at automating this process, I wrote a script to run a batch of tapes. I can put a list of tape dates in a text file to convert. The script looks up the date, finds the service, generates a full name for the recording file, runs the digitizing program, calls the post-processing, and then checks the completed files (compressed and uncompressed) into the webapp.

There’s one more step to fully automating this process: some sort of robotic tape changer. Actually, this may be the key to the whole thing. I’ve already had several ideas. I had bought a three Armatron robot toys thinking I could use them to move tapes around. However, I destroyed two of them in the process of figuring out that they just wouldn’t work for my application, and we gave the other one away.

Improved Catalog Application

Next, I got out my old trunk of Lego. I had a few Technics sets back in the day, and I thought I would be able to make some sort of robotic tray out of them. I’m inspired by this Eli Carter‘s floppy-disk archiving robot. However, it’s clear that I don’t have enough parts to make a real attempt at doing this, and I don’t want to spend the money on a Mindstorms set.

I eventually pulled the trigger on a “real” robot arm. I put it together, and could drive it with some outputs on the DAQ. I made a tape “magazine” with LEGO, to try to pull from the bottom of a stack, and then insert it into the tape duplicator. However, the little catch-the-top-edge-and-push-the-bottom-into-place the duplicator’s slot requires was just too much for either me to manage with the DOF at my disposal, and the grip strength of the “hand.” Ultimately, I sold the thing on Ebay.

Real Robot Arm

What I finally, finally did was ask a lady at our church — who absolutely LOVED preaching tapes from all over our organization — and who was home-bound for medical reasons — to load the tapes, and hit the button. I setup the rig at her apartment, and, over the course of a couple of months, I carted in new tapes, and lugged out the processed ones. Like a soldier, she ran them all.

Reconciling Tapes
The Labels. Oh, The Labels

UPDATE: I’ve finally thrown out the machine and the computer. I kept the DAQ for the sake of it, but the rest is gone, except for the hard drive I have it all on. I’m pretty sure that if I ever hook that up in anger, to get to this stuff in earnest, it will have suffered from irreversible bit rot. So for historical purposes, I’ve put the digitization code I wrote out on GitHub. The file digitize4.c contains the last, most-feature-complete version, and is an approachable example on how to write a low-level signal acquisition program with National Instruments equipment, using 4 types of I/O at once (if I do say so myself).