FLummoxing CLeverness

You wouldn’t think it’d be so difficult to rip a few DVDs. Well, it isn’t, unless you’re trying to do it in a way that’s far too clever for your own good.

A refresher for those of you who haven’t committed my personal computing resources to memory: I have two computers, holly and kryten. (No points for guessing the naming scheme.) holly is my eight-year-old former desktop computer, now relegated to running MythTV. kryten is my four-year-old tablet that I use for pretty much everything else.

Ripping and encoding DVDs is a CPU-intensive process, so naturally I wanted to do the job on kryten, whose wimpy 1.7 GHz Pentium-M is still quite a bit better than holly’s mere 933 MHz Pentium-III. The problem is, kryten doesn’t really have a DVD drive per se. I have a DVD drive that connects via the PCMCIA slot, but it’s slow (as in, too slow to play a DVD real-time) and sometimes hangs the Linux kernel when you eject the card.

My clever plan to get around this was to read the DVDs on holly, copy the raw data over to kryten via the local network, and do the actual encoding from there. Pretty much any program on Linux that reads from a DVD is just as happy to read from a directory where you copied a DVD’s files to, after all.

For the first disc, this worked just fine. For the second one, not so much. For some reason no program could read the VOB files on the DVD without projectile vomiting error messages to the system logs. (I wound up with 600+ MB of error messages in each of three system log files when all was said and done — log files that are typically around 50 KB for a week’s worth of data. So yeah.)

Since the VOBs are where the actual video content of the DVD is stored, this was a bit of a problem. I ran into the same problem with the third disc I wanted to rip. Thinking it might be a flaky DVD drive or driver, I tried rebooting holly (soft and hard), but no change. First disc fine, second and third not. Each disc played perfectly in my set-top DVD player, so the discs themselves were clearly undamaged. kryten’s external DVD drive wasn’t any more successful.

My best guess as to what was going on was that the discs in question had deliberately bad sectors to serve as copy protection to prevent someone from doing exactly what I was trying to do. But if that were the case, you’d think that all three discs would have had it, since they were all part of the same three-disc set. It doesn’t make much sense for only some of the discs to have copy protection. But if it wasn’t deliberate, it’s awfully suspicious that only the VOB files on the two discs were affected.

I wound up ripping the two problematic discs the easy way, doing everything on holly and having MEncoder read from /dev/dvd directly instead of mounting the UDF filesystem and reading that. Lo and behold, that worked, albeit taking longer to encode because of the slower processor. Whatever method programs use to read from the DVD directly instead of via the filesystem apparently never tries to access the sectors causing the errors.

Given that holly is effectively headless (given the “quality” of ATI’s Linux drivers, I didn’t want to switch from MythTV to the console if I could help it), this posed the question of how to figure out which titles on the DVD were the ones I wanted to rip, and not previews or special features or copyright notices or anything. The solution? Playing each title one by one in MPlayer, running in AAlib mode to render the video in glorious ASCII art though the SSH session from kryten to holly. Converting uncompressed DVD-quality video to ASCII art is a lot more bandwidth-friendly than sending it across the network directly, and while it is hardly the way I’d want to watch a video, it’s good enough to recognize the opening scene is what you’re looking for.

But finally, I now have the videos shrunk down into a format my portable media player is happy with. All it took was to stop trying to be so clever about how I was doing it, and thus avoiding whatever the underlying problem was.