Blog

Dealing With MiniDV

What a pain this is. All of the problems of VHS and all of the problems of magnetic media, all on a miniature scale. While I do appreciate the digital nature of MiniDV makes it possible to get a good copy of the video, in theory at least, decades of tape decay and camcorder mechanism wear makes it more difficult than I'd like.

I did have access to the camcorders that originally recorded the tapes, but they were all broken. The JVC models both had cracked spools, which misleadingly resulted in "remove battery" error messages. Some Internet searches revealed that it was a very common issue, to the point that a class action lawsuit was being considered in the USA. I couldn't find any judgements, so I suspect it was merely vapourlaw.

Anyway there's no viable replacement for the spools, so the recorders are just rubbish now. I had to buy a used Canon MV530i model to play the tapes with instead.

I wanted to use the program DVRescue to record the tapes, because it has a feature that rewinds the tape whenever errors are found. However, I couldn't get it to work. The developers primarily use Macs, and Linux/Windows support is limited.

"The command line interface (CLI) supports capture on Linux and Windows (Windows PCs require a dual boot with Ubuntu to work with dvcapture)." - Source, preserved on the Internet Archive

Sooo... does the Windows CLI binary support capture or not? (Spoiler: not.) That could have been worded better. But hey, I can install Linux no problem, especially Ubuntu, except that it couldn't detect the camcorder. I ended up using the WinDV workaround listed on the same page, which does work, but I don't get to have the rewind feature.

My new strategy was therefore to record two or three passes of each tape, and then use the merge feature. This is supposed to detect and use the error-free blocks for every frame for a specific timecode, resulting in the best possible quality video output. It had issues.

Firstly, it was upset that 5 frames were "missing" for every second of my videos. As an open source project I was easily able to check the source code, and I found a line that hardcoded it to use 30fps NTSC instead of 25fps PAL. I'm way too lazy to assemble the necessary toolchain to recompile from source, so I used IDA to modify the value directly.

28552 285900 00:15:53:00 0 M
28553 285912 00:15:53:01 0 M
...
28575 286176 00:15:53:23 0 M
28576 286188 00:15:53:24 0 M
28577        00:15:53:25   M ( 5 frames)
28582 286200 00:15:54:00 0 M
28583 286212 00:15:54:01 0 M
...
28605 286476 00:15:54:23 0 M
28606 286488 00:15:54:24 0 M
28607        00:15:54:25   M ( 5 frames)
28612 286500 00:15:55:00 0 M
28613 286512 00:15:55:01 0 M
...
28635 286776 00:15:55:23 0 M
28636 286788 00:15:55:24 0 M
28637        00:15:55:25   M ( 5 frames)

I assumed I'd be able to feed it all of my whole tape recordings in order to get one whole tape output, but not so fast! That only worked for the best tapes.

On tapes with dropouts or significant error sections, the merge algorithm would insert frames from other areas of the tape due to corrupt or missing timecodes. It made a mess. Sometimes I did get Max Headroom-esque jitters, which were admittedly amusing, and sometimes it would just concatenate whole chunks of video together instead of merging.

In the end I cut most of them by hand. I used the analyse part of the GUI to see the graph of errors for every pass, then chopped out the best error-free areas using AVIDemux. Fortunately every frame is a keyframe, so there were no concerns about joining them all back up.

I've kept the passes safe in case DVRescue can properly handle them in the future, but for now the videos I have are acceptable. Despite the hitches I encountered, I believe it will mature into a very useful project for others seeking to recover their family footage in the future.

Return to Blog Index