Cassette Deck Repair, Round 1

A lot of the equipment I work with is shared between the MIAP program and the Cinema Studies department’s Film Study Center archive. As one of oldest film studies programs in the country, NYU has been acquiring movies for screening and teaching purposes for decades, so we’ve amassed a considerable collection in a variety of formats (though the content may not be overly unique – there’s a lot of copies of, say, Taxi Driver). We also house the department’s internal records, which includes a lot of audio and video recordings of lectures, conferences, and other events hosted by Cinema Studies over the years. These archival materials often offer me a sort of testing ground for equipment and resources that will end up getting demonstrated in MIAP classes. This is extremely helpful, given that archival education needs to be very hands-on, and as much as MIAP does a fantastic job of teaming up with other cultural institutions to get that direct experience, having in-house opportunities to practice what we preach is invaluable.

We’ve been slowly reformatting our audio cassette collection for at least a few years now on our Digital Audio Workstation (nicknamed “Bigfoot” with affection?). We run on a workhorse Tascam 112MKII cassette deck, patched into an Analog-to-Digital Converter and capturing preservation-level audio files (uncompressed WAV at bit depth of 24 bits and 96kHz sample rate) in WaveLab 8. It’s slow going, since you have to capture audio in real time and we’re only running the one deck, but it’s a great project and there’s some really cool material I hope we’ll be able to make available some day.

But we hit a hitch last week when our reliable old Tascam deck broke down. Tapes would still safely rewind and fast forward, but hitting the play or pause buttons started producing discouraging sounds and a full-fledged freakout from the lights on the front panel display, after which the tape would either come to a full stop or start playing through at high speed.

IMG_2136.JPG
Doooooooooooooooooooom

The loud clattering noise and the fact that the buttons were still responding, if not functioning normally, gave me hope that this was a mechanical issue and not electronic – as I mentioned in my first post, I’m woefully inexperienced with circuit boards or sussing out electronic signal issues, but mechanical issues are usually far more visible and therefore diagnosable, if you’ve got the bravery and some spare parts (or creativity).

But this was nothing that I could fix as long as the Tascam was still mounted on our DAW, so my first priority was to set up the students working on this digitization project with an alternative deck while I took out the Tascam for some TLC.

IMG_2137
I’m sorry, Bigfoot.

We had a spare Tascam CC-222 in one of our back rooms, which was originally intended as a cassette-to-CD dubbing machine. The transport worked fine and the signal was acceptable (we’re not overly concerned with preserving the quality of these tapes per se – honestly they’re pretty rough recordings to begin with – but the content is super), so all I needed was some RCA-to-TT patch cables to get this auxiliary deck running. The digital meters are unideal for monitoring compared to the Tascam’s analog meters, and it’s essentially impossible to calibrate (there’s no easy way to adjust the angle of azimuth on the playback head, for instance), but it’ll do for now.

IMG_2205.JPG
That “No Disc” warning has probably been on since 1999.

Meanwhile I did some more digging and found we had a Tascam 122MKIII sitting in storage – a model almost exactly the same in mechanical design as the 112. When I hooked up this deck it was completely unresponsive, meaning there’s probably an electrical issue and I could feel pretty safe in condemning it for scrap – with luck whatever mechanical parts were broken in the original 112 would still be intact on this spare 122. Time for a transplant!

IMG_2171
swag

Opening up the cover on the 112, I could now visibly observe the issue with the transport unit rather than just listening. The clattering sound was mostly coming from a fitful spring, but that didn’t actually seem to be the problem – tracing the motion back through the unit, I could finally see that indeed, one of the gears connecting the transport unit’s motor to this spring (which in turn lifted the deck’s playback head up to make contact with the tape path during normal “play” or “pause” mode) was broken. Glancing over at the 122, it had the same gear – in one piece.

So far so good – but now, how to get this gear out?

I wish I could be a little more specific here, but honestly even with a service manual at my disposal, the only strategy ahead seemed to be to start methodically unscrewing everything in sight – or even out of sight – while at least avoiding messing with the motors.

IMG_2178.JPG
This asshole right here took a solid 10 minutes alone.

Now someone with a little more foresight might have started disassembling the backup 122 deck first. After all, that’s the scrapped deck anyway, right? I could mess up that machine however I wanted and it would make no difference. But no, for some reason I plowed ahead, fiddling with the 112, apparently operating as if the broken gear was literally cancerous and the disease would spread to the other gears if I didn’t get it out IMMEDIATELY.

What this meant is that halfway through disassembly, which was already a laborious process thanks to my apparently less-than-steady hands and their tendency to drop tiny screws into the bowels of the deck…

IMG_2179
*Is it water on the knee? Oooooperaaation…*

…I realized that I was entirely unsure if I would ever be able to put this thing back together correctly even if I did manage to reach and replace the broken gear. Indeed, just idly trying to fit the transport unit back into its original place in the deck, the eject mechanism was now stuck, and it was entirely unclear if the pressure pads (which sense a tape is in the deck and allow the transport buttons to work) were still functional.

IMG_2188
Hard to see, but this thin metal piece should not be there. Why is is there now? Absalom, my son, what have I done?

So that meant a couple painstaking hours of, essentially, reassembling the deck in order to fix the damage I myself had impatiently inflicted – never mind the original problem that I had set out to deal with. Which, by the way, it turns out I couldn’t have dealt with today even if I’d wanted to – one of the most essential-to-remove screws, holding the gear mechanism in place, is totally stripped, and in a very awkward position to get any leverage with a screwdriver. So the upshot of all that is a detour while I try to purchase a screw extractor drill bet set for our power drill.

IMG_2185
I mean for real how did this even happen?

Chalk that up as a learning day. At the end of it all, I at least now have a much clearer idea of how to remove the transport unit as a solo piece from the deck without interfering with its mechanical function. That is, I should be able to access the broken gear this time without taking away the machine’s ability to eject or communicate with the front panel buttons. And I will do it all on the 122 first – to make sure I have a healthy heart before cutting out the bad one.

IMG_2186.JPG
“Kali maaaaa…kali ma shakti de….”

Under the Hood

It’s a common theme in moving image archiving and preservation that we are always running out of time. Tapes shed, files corrupt, bits rot, film reels turn into whatever the hell this monstrosity is (image credit: David Neary). Our job as archivists is a never-ending struggle against fundamental and inexorable forces that will, eeeeeeever so slowly (or, really, not so slowly), pummel the materials we have been charged with protecting for future generations into fine-grained, slightly dank dust.

It has also become something of an open secret lately that the problem of time is not just an issue for audiovisual objects themselves. The legacy equipment necessary to archive A/V content (whether to play back the original material for identification, or to reformat to a digital format for preservation and access) is also becoming increasingly rare, as manufacturers have long since moved past analog technology. You can stockpile as many 3/4″ U-matic tapes as you want in perfect, climate-controlled storage, but if all of a sudden your Sony BVU-950 breaks a gear and the tape transport mechanism refuses to budge, those tapes are now as useless to you as they are to the modern consumer. Maybe you’re lucky enough to have another deck lying around that you can cannibalize for that one particular gear – maybe some oblivious sap happens to be selling the 2-cent piece of plastic you need on eBay for $85. Odds are, unless you can find someone who really knows what they’re doing with this equipment and has connections to the materials necessary for repair, you’re out of commission.

IMG_2163
Pictured: Sony BVU-950 with no broken gears, thank god.

And that in turn leads us to the last item in the Trifecta of Things Archivists Are Really Really Scared to Lose: the people who actually know how to maintain and fix legacy equipment. Technicians who know how to properly calibrate an audio cassette deck are getting fewer and farther between, not to mention far more rare and specialized tech like a 2-inch Quad machine or an obscure Time Base Corrector.  In fact this pool of collective knowledge might be getting even smaller than we think, and without them other archivists, even those who know how to use this stuff, are going to be increasingly grappling in the dark when it comes to peeking under the hood.

I was slightly sensitive about this when I was hired last fall as the technician for NYU’s Moving Image Archiving and Preservation program. I am not one of those few industry veterans hanging around with expert opinions and decades of hands-on experience; I have never soldered a circuit board or clipped cables for a terminal block. Thanks to graduating from this program myself, I have a broad familiarity with a very wide range of A/V preservation technology, from 16mm film projectors to the latest disk imaging software, but the idea of maintaining all of the legacy and contemporary media equipment owned by our department and used in our curriculum is daunting, particularly when faced with that dwindling community of possible support.

On the other hand, the first few months of the job have given me hope that we may, at least ever so slightly, be overstating the extent of the crisis (it is, after all, a bit of a habit in the preservation field to hyperbolize – it tends to help when trying to get someone to give us money to do our jobs). Yes, the number of expert A/V technicians out there is getting smaller – but, if we do this right (and by “this” I mean archival education and professional training), so is the number of archivists with no tech ability at all. And that is no small thing, because I now firmly believe that a great deal can be accomplished and learned by archivists (whether professional or amateur) who are willing to just dive in and get their hands dirty.

IMG_2165
Maybe more dusty than dirty.

Because at the end of the day, “troubleshooting” is a fancy word for “trying stuff and watching what happens.” The tech who has been at your institution for 40+ years? He/she (probably he, but that’s another conversation) was not born knowing how to adjust the azimuth on a 1/4″-tape recorder. There was no mystical rite of passage involving secret readings from the Gospel of Alexander M. Poniatoff. They read manuals. They pushed a button. They tightened a screw, then pushed the button again. They went back to the manual. Then they pushed a different button. And on and on and on, until it worked.

I want to demystify the technical side of preservation, whether it’s working with analog or digital equipment. I want to be more transparent about the things I’m trying, even (especially!) the efforts that don’t work. I want to be able to ask others what they’ve tried, and why. I want my peers in the field, and our students here at NYU, to be unafraid to lift up the hood.

Screen Shot 2016-04-06 at 3.50.02 PM
Hoods aren’t always physical, by the way.

So that’s why I’ve started The Patch Bay. If all goes to plan, I’ll be posting what and when I can about my projects here in NYU-MIAP – about equipment and tech requests I get from our students and faculty, and what I do, step-by-step, based on my resources and abilities, to fulfill those requests. Maybe I’ll throw a problem out there to the wider community, when I come across a total stumper. I hope, if I can, to write and illustrate my posts in a way that’s accessible to professionals, students of moving image archiving, and maybe even interested layfolk. If you have any questions about my processes, please don’t hesitate to get in contact – in the end, it’s all just about trying to make connections.

IMG_2161
It’s like a pun or something geddit

PowerPC Mac Emulation

A couple weeks ago Mona Jimenez asked me to step into her course on Handling Complex Media, to help a student group with a tech request (business as usual). Going back to the lab, I had a hint of what was coming from the whiteboard:

IMG_2166
Uh oh.

Yes, as it turned out, the students were working with a piece of multimedia artwork/software that required a PowerPC version of Mac OSX (10.0 through 10.5) in order to run. Normally, this wouldn’t present much of an issue, as MIAP’s “Old Media Lab” still has several old Power Mac G4 desktops and even a couple Macbook laptops running various early versions of Mac OSX. However, the students would only have access to the digital materials on-site at the partner institution for this project, and could not bring the software back to NYU. They could (and might still, if it comes to it) just bring the laptops to the site and run the software in the native environment, but that’s unideal for a couple reasons: first, I’m always somewhat hesitant for department equipment to leave campus; and second, having old hardware running these old operating systems natively is something of a luxury, which our students may very well not have in the future as equipment continues to age, or if they work at an institution with shallower pockets for digital preservation.

In order to access software or digital files created for obsolete systems, the primary solutions these days are emulation and virtualization – two slightly different methods of, essentially, using software to trick a contemporary computer into mimicking the behavior and limitations of other hardware and/or operating systems. Emulation has gotten incredibly sophisticated recently – the Internet Archive has even made it possible to run thousands of vintage MS-DOS and Windows 3.1 programs from an emulator inside your web browser, no additional downloads required, which is really an incredible feat of programming. Emulators for early Mac systems (anywhere from 1.0 to 9.x) are relatively simple to set up in OSX 10.10 (Yosemite) or 10.11 (El Capitan), likewise virtual machine software like VirtualBox (all topics for another day).

But right now the early, PowerPC versions of OSX seem to be something of an emulation/virtualization dead zone. I’m not the person to ask why – I’m assuming that the shift from PowerPC to Intel processors (starting with OSX 10.6, Snow Leopard), shifted the system architecture dramatically while the operating system remained relatively the same, resulting in a particular hardware/software configuration that just confuses the heck out of current setups, even through an emulator. It’s clearly possible – sift through the forums of Emaculation or other emulation enthusiast sites and you’ll find five-year-old boasts of people getting OSX Puma to run in Windows XP, or whatever – but documentation is sketchy and scattered even by internet standards, and replication therefore a crapshoot.

So, how do I help these students get a PowerPC version of OSX on one of their (Intel Mac) laptops? Anytime we need new Mac software in the department, I try it out first on my office computer, a mid-2011 iMac running OSX 10.10.5.

Screen Shot 2016-04-07 at 9.18.20 AM
Note: I can’t even use some of this stuff, but it’s cluttering up my desktop anyway.

I eliminate using VirtualBox almost right off the bat – the makers of VirtualBox explicitly state that the software does not support PowerPC architecture, which, again, doesn’t mean it’s impossible, but it does mean that unless I magically have the same computer setup as a random YouTube user, I’m completely on my own. Instead I’m going to use PearPC, an old PowerPC architecture emulator (it hasn’t been updated since 2011), but one with some solid documentation to get started. I’ll be trying to install OSX Tiger (10.4) in PearPC, as we still have a couple original installation discs for Tiger still lying around the department, and Apple install discs are otherwise hard to come by (if you don’t like going to/supporting super dubious torrent sites, or buying overly expensive copies off Amazon).

PearPC recommends installing Darwin as your client OS (the OS running inside the emulation software) first, to properly partition and format your virtual hard disk (the fake hard drive the emulator will use to make the OS think it’s being installed directly on to a piece of hardware). But I immediately just ignored that because WHAT THE HELL IS DARWIN?! So, I skip to just downloading the PearPC 0.5 source archive for Unix (e.g. Mac) systems.

Uh oh. A source archive means the software needs to be compiled before it will actually run. Normally I would immediately turn away and go find someone who had already compiled a packaged OSX build FOR me, but the PearPC documentation includes some seemingly straightforward command-line instructions for this step. So, I open a Terminal window, navigate into the PearPC-0.5 directory, and attempt a default configuration and make with

$ ./configure && make

Lots of Terminal gobbledygook aaaaand PearPC seems to automatically detect my system configuration fine:

Screen Shot 2016-04-07 at 9.46.37 AM

But then in the make….

Screen Shot 2016-04-07 at 9.47.55 AM

Oops. I have no idea what this ‘MAP_32BIT’ identifier is, nor how to change it, nor if that’s really even the issue here. So ends my efforts to self-compile – pretty please, tell me someone has already done this for me?

Screen Shot 2016-04-07 at 9.50.17 AM.png
“I’ll save you, Ethan!”

Huzzah! Google directs me to this very nice Dutch expert (who is also apparently secretly a cat on his 7th life) in the Emaculation forums has already compiled an Intel Mac OSX build of PearPC. YOINK.

Per the Dutch Cat, I still need a configuration file and a blank hard disk image. So it turns out to be good that I downloaded that Unix source archive, even if the compiling didn’t work, because I can just steal the “ppccfg.example” configuration file from that directory and move it into my OSX build directory. It’s just a simple text file, so I can rename it whatever I want for clarity’s sake.

Screen Shot 2016-04-07 at 9.58.26 AM.png

Now I need the blank hard disk image. Back in the PearPC documentation, we’ve got some handy details on the specs needed (a multiple of 3GiB size, in particular), and how about that, a sample dd command to make one. When I did this I just used 3GiB, but I’d recommend the 6GiB size, just to make sure you have room for the installation of OSX Tiger and something leftover:

$ dd if=/dev/zero of=~/Desktop/pearpc_osx_generic/PearPCTiger.img bs=516096 seek=6241 count=0

My OSX build directory now looks something like this in a Finder window:

Screen Shot 2016-04-07 at 10.03.36 AM.png

Dandy. Now I just need to set up the configuration file, so the PearPC application is directed to the blank hard disk image and the OSX Tiger install disc (currently sitting unmounted in my iMac’s optical drive) when it tries to boot up. So I open the configuration file with a simple text editor (TextEdit, Xcode, even Word will do) and find and change the comment lines that correspond to the hard disk image and install disc paths (you can find path to your mount point for an optical drive by running the command “$ diskutil list” in a Terminal window, then running “$ umount /path/to/disc/drive/” to make sure your host computer unmounts the disc – in most cases, if your desktop/laptop just has a hard drive with one partition and one optical drive, the path will be /dev/disk1)

Screen Shot 2016-04-07 at 10.45.05 AM.png
Save the configuration file and we’re ready to go, right? Back to Terminal, because PearPC is a command-line application, navigate into the OSX build directory, and run the executable file in the build with

$ ./ppc_osx_generic “osxtiger.rawr”

Screen Shot 2016-04-07 at 10.23.09 AM.png

Aaaaand nothing happens. I’m just sitting on the cursor. Why? Tell me, Dutch Cat Man!

Screen Shot 2016-04-07 at 10.26.54 AM.png

As it turns out, the X in “OSX” doesn’t just mean “10.” It also refers to the X Windows System, a development framework for making applications with graphical user interface windows on Unix systems. It’s a standard component in OSX (indeed, in pretty much all Mac OSs over the years), but you need to download some extra software to allow cross-platform software like PearPC to run on it. This software!

Screen Shot 2016-04-07 at 10.35.55 AM.png
So many Xs.

All right, XQuartz is now installed, and since I forgot to terminate PearPC and it’s been running this whole time in the background, suddenly XQuartz opens, PearPC starts running and booting from the OSX Tiger install disc.

Screen Shot 2016-04-07 at 10.46.48 AM.png

I get the classic gray apple screen, then after a moment, some terrifying-looking text appears. Then…it just sits there. For too long.

Screen Shot 2016-04-07 at 10.50.47 AM.png

That can’t be good. Perhaps I’m getting too fancy trying to boot off the physical disc in my host computer’s optical drive – what if I make an image of that instead, and plug it into the PearPC configuration file? There are many options for making disk images, and that’s a whole other topic. I’m going to run the absolute simplest of my command-line options right now and see how that goes:

$ cp /dev/disk1 ~/Desktop/pearpc_osx_generic/Mac_OSX_Tiger_Install_DVD.iso

Once that’s finished running, I go back into the configuration file and edit the line that corresponds to the install disk image:

Screen Shot 2016-04-07 at 10.59.34 AM.png

What happens if I run the PearPC executable again now? I’ve booted back to the scary text screen again, but…

Screen Shot 2016-04-07 at 10.54.59 AM.png

This time it keeps running! I let things scroll for a minute and eventually am greeted by a very familiar sight….

Screen Shot 2016-04-07 at 11.03.04 AM.png

A Mac Installer wizard! We did it everybody!

brad-pitt

Well, not quite yet. I start to move through the Installer but we haven’t actually formatted that blank hard disk image to make it capable of having Mac OSX installed on it yet. So, when stuck at the “Select Destination” screen with no options for where to install the OS, I’m going to head into the “Utilities” tab and enter Mac’s Disk Utility software.

Screen Shot 2016-04-07 at 11.05.28 AM.png

In order to format my blank hard disk image, I’m going to select the image from the left-hand menu, navigate to the “Partition” tab, then select “1 Partition” in the Volume Scheme and “Mac OS Extended (Journaled)” as the Format, and click Partition in the lower-right to execute.

Screen Shot 2016-04-07 at 11.08.51 AM.png
Please do not ask me why Disk Utility is shouting at me in German.

Once that’s finished, I’m able to exit Disk Utility and return to the Installer – and the formatted hard disk image is now available to select as an installation destination. Now, OSX Tiger needs about 4.8GB of space to install in its entirety, which is why I told you to make a 6GiB image earlier. If you’ve made a smaller, 3GiB image as I did, you’ll have to de-select some of the installation packages. It’s not that big a deal – a ton of space is taken up by non-essential features like device drivers and extra languages.

Screen Shot 2016-04-07 at 11.14.26 AM.png
And I was so looking forward to doing this again in Russian.

OSX Tiger is now ready to install. Now, if you’re following along, you may have noticed at this point that PearPC runs slooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooow

44a5f1b6b0dce7c0e0b3a658756533f62481c1e05da3c693841ec7f6ec682a7c

So yeah, this installation takes a while. Like possibly hours, plural. I went off to do some other work and forgot to tell my host computer not to go to sleep, which made PearPC just pause the installation for about an extra hour. Don’t do that.

OSX Tiger did successfully install, however, but here’s the kicker – as I went through the initial setup, it turns out that PearPC did something COMPLETELY WONKY to the mapping on my keyboard during that installation. So, when trying to set up a user account and just typing like a normal person, I got this nonsense:

Screen Shot 2016-04-07 at 1.11.15 PM.png

I wish I could tell you that I solved this problem, but no, I just had to painstakingly poke at one button at a time until I figured out that now while in PearPC, e=delete, 4=n, v=9, so on and so forth. When I finally got into the OSX Tiger desktop and was able to go to System Preferences, I thought I had fixed it by switching to a Canadian keyboard layout (why do you even have a separate keyboard layout, Canada?), but now every time I boot back into PearPC it resets. So that’s a mystery and if anyone has ideas how to fix this I’m all ears.

Screen Shot 2016-04-07 at 1.15.26 PM.png

But, for the moment I’m calling this mission accomplished. Again, OSX Tiger in PearPC runs AS SLOW AS DIRT, so this is not ideal, and I would still like to figure out how to crack the VirtualBox solution for all this. But from what I can tell that might involve this mysterious Darwin operating system that apparently makes all my Apple computers work…and given how this post has already turned out much longer than I intended, that’s a topic for another day.

128px-hexley_the_platypus-svg
WHAT ARE YOU

If you’ve had any success setting up a PowerPC Mac OS in an emulator or VM, I’d love to hear about it!