Abort, Rephrase, Ignore?

I used to spend a lot of time building my collection of music videos grabbed from Rage. Then it all went up in a puff of dead hard disk (the cobbler’s children’s shoes always have holes in their soles, you know) and I didn’t bother trying to rebuild.

This was about two years ago. I’ve started again, with a new and improved workflow. By documenting it here, maybe some hapless fool will come across it when they’re trying to figure out how to make this work.

First: I record using a Topfield TF5000PVRt, but once you get past the “getting it to a computer” step the same process should apply to any DVB-T source. I’ve simplified things a lot in the past year by adding a Icebox2 to our TV setup. This is a reflashed Asus wireless bridge with custom firmware set up to talk to the Toppy. You can get the same results with something like the Linksys NSLU2 but the Icebox comes ready-to-go.

So extracting the data is as simple as:

$ lftp 192.168.0.3
lftp 192.168.0.3:~> site turbo 1
200 TURBO is now on
lftp 192.168.0.3:/> cd DataFiles/
cd ok, cwd=/DataFiles
lftp 192.168.0.3:/DataFiles> get somefile.rec
[...]
lftp 192.168.0.3:/DataFiles> site turbo 0


The next step is to fix up any sync errors. The simplest tool for the job is ProjectX. This is a Java app, so you’ll need a Java runtime too. It runs just fine on Windows, Mac, Linux, whatever. In my case I’m running it on Solaris as that’s where my big chunk of spare disk lives.

The result is three files: somefile.m2v, somefile.ac3, and somefile.mp2. You can also get ProjectX to grab teletext-based captions and convert them to any of a range of formats, including bitmap streams suitable for DVD. Not going into that right now, maybe some other time.

I had hoped that I could do the main encode on the Solaris box as well, as that’d keep my desktop free of big compute jobs and available for Warcrack. Didn’t work out. mencoder managed to screw up the A/V sync even though ProjectX fixes that. There’s probably a way to make it work but frankly life is too short.

So the next step is to import the video (somefile.m2v) into VirtualDubMod on Windows. Set up an appropriate resize filter (I use 576×324 and the precise bilinear scaling algorithm), add the audio stream (somefile.mp2, though I suppose you could use the AC3 if you wanted but my goal is something that’ll play on the widest range of hardware possible), and set up a two-pass XviD encode of the entire file.

One small gotcha is that the default for the first-pass statfile is “\video.pass”, and at least on Vista this doesn’t work. You’ll need to explicitly set the path for the statfile, but the codec remembers this once you’ve set it for the first time.

Run any encodes you have via the batch job control system in VDM, this way you can run it overnight.

Once the whole thing has been converted to XviD, it’s time to clip out the bits you want. Avidemux has gotten a lot better since I last tried working with it, and the Windows port seems pretty solid. The “smart copy” feature is very nifty: if your start point isn’t on a keyframe it’ll re-encode the first little bit as needed.

I’m using the LAME audio codec via Avidemux as I save each music video. This means instead of a few seconds it can take a minute or two per clip but the results are quite good.

This may sound like a lot of work but it really isn’t. Most of it isn’t interactive, it’s just setting up a batch job and letting the machines do the work. The final step of cutting out the bits you want to keep is by necessity interactive but that’s unavoidable.

Why not just use VirtualDub’s editting functions? Because for every job in the queue it reloads (and reindexes) all of the streams. This really slows things down with 8GB of data coming off a network share! More efficient to just encode the lot then clip out the bits you want later.

Popularity: 44% [?]

Tags: Tech //