We have a bunch of old Digital8 tapes at home, and so far they
have been mostly sitting around on shelves. Since I had nothing
else to do and realised they were not getting better with age, I
set out to back them up onto our network storage.
The tapes were recorded using a late-90s Sony camcorder, which we
still have. It is an absolute juggernaut, still working flawlessly,
still feeling like a device from a more civilized age, and even
though it uses tapes, the recordings are stored digitally using DV,
enabling lossless transfer to the computer!
I had already undertaken a similar endeavour in 2010: after
discovering that both the camcorder and the HP Pavilion train wreck
posing as our PC featured a FireWire port, I connected them to each
other and tried to record video using Windows Movie Maker.
Back then, this used to work out of the box, and I was amazed by
this rock-solid technology. You could even control tape playback
remotely from your computer! That’s so cyber.
Most of this also applies to (Mini-)DV. On a superficial level,
Digital8 is the same thing, and Sony’s legacy camcorders even
behave identical to DV devices.
Now, ten years later, I wanted to take a serious and somewhat
professional shot at storing these memories for eternity. Or at
least until our NAS melts down in a fire.
Why am I even surprised?
Remembering my 2010 childhood memory of working with DV, I went
ahead thinking “well, it’s legacy technology so there will be lots
of fleshed-out drivers and hardware support in general, right?”, but
then it turned into the typical Linux-kernel-meets-crappy-hardware
odyssey that still manages to hit me by surprise, even though I
should know better at this point.
I started off with my main notebook,
the Lenovo X230T. It doesn’t
feature a FireWire port, but at least there is an ExpressCard
slot. So I bought an old FireWire expansion card. When dmesg
VIA as the chipset manufacturer, I should have
known better. Yet, somewhat naively, I stayed optimistic.
Doing some research, I noticed that
dvgrab might be
an ideal solution for my task, and I tried it out. It did not
recognize any kind of FireWire device, and in true Linux fashion, I
spent the next two days and nights reading about everything I didn’t
want to know about FireWire support in the Linux kernel. That didn’t
I then tried to use the Lenovo T400 – it too has an ExpressCard
slot! That didn’t work either.
I installed Windows onto the machine and tried to use the secret
video capture tool that comes with Sony Vegas. After all, it’s
proven Win32 baby boomer software! That, too, did not work.
Noting that the T400 has a dedicated FireWire port built into it,
I tried to use that one, and it actually worked! But the capture
tool dropped frames every now and then, even though the Core2Duo
should have been fast enough.
At that point, I was close to having a nervous breakdown, and had
probably bought three to five different FireWire cables, even paying
my local electronics store a visit, because they always have legacy
garbage in stock (but none of the things you actually need.) They
eventually told me their whole FireWire stuff had been thrown out
just two weeks ago.
Luckily, another FireWire PCI card arrived via parcel just in
time. I put it into my Windows desktop computer, and… it too
featured a VIA controller. You know what? It didn’t work.
I switched back to the T400, installed Ubuntu, used the builtin
port, and ran dvgrab. Thankfully, that worked flawlessly, but I was
past the point where you let out a relieved sigh and carry
on being joyful.
Messing around with dvgrab
Using dvgrab is very straightforward. After looking at
the manpage, I went
dvgrab -rewind -format raw -autosplit -timestamp
-rewind rewinds the tape before recording.
-format raw dumps raw DV as received.
-autosplit tries to detect the start of a new
-timestamp names the capture file according to
date / time metadata.
Then, I sat through the whole process.
In retrospective, using
-autosplit has been a bad
idea, because scene detection did not work reliably: there were some
video files containing multiple scenes which kind of misses the
-timestamp sometimes did not use the correct
date. For example, a recording from 2011 got saved
has been able to reliably extract the correct timestamp, which is
why I decided to run dvgrab without this option
a little script to rename the files using MediaInfo.
(No idea if the camera or dvgrab are at fault regarding these
issues, you have to find it out on your own.)
Anyway, the following command (followed by a call to my script)
is probably the safest thing to do:
dvgrab -rewind -format raw -showstatus
I just put each tape’s contents into folders named
TAPE01 and then shoved them onto the NAS
rsync. Having done so, I labelled a matching
sticker (we still had some sheets at hand) as
YYYY-MM-DD and slapped it onto the tape.
When I started this project, my intention was to let the camera
transfer the tapes in the background while I would focus on working
from home and getting paid. That didn’t work out, alas, as playback
would now and then enter a glitched state with a permanently
corrupted video and audio signal. I could reliably make it go away
by rewinding the tape a little and then restarting the recording
process, so it’s probably been a spec of dust on the playhead or
whatever. But this means that you need to
- A: keep an eye on the whole setup while it’s recording OR
- B: clean the innards of your camcorder before recording
As an impractical person, I went for Method A.
Takeaway and insights
There were some things that I learned from this journey into
legacy tech and my childhood.
First and foremost, fuck VIA.
Second, filling in the blanks on early childhood memories is
certainly interesting. For instance, there were recordings I have
never even seen before. Also, I was an adorable kid, but that
somehow fizzled out when I turned six.
Third, and that might be nostalgia as well, I love the fact that
you can stuff digital crap onto a tape. Modern flash memory is
robust and slick and all, but not as charming as a mechanical tape
rattling through the playheads, with you sitting in front of the
screen, telling it to enhance 34 to 36.
Fourth, if you like absurdity (not as in: dealing with Linux),
you might want to have a look
Daim, a recent film by Quentin Dupieux. It prominently features