Using Video Game Footage - Part 2

Overview

Ripping/Converting/Capturing the Videos

The first step in getting the footage is to convert the source files into AVI files. If the original file is already in AVI file format, or can be already read by VirtualDub, then you can skip this step. VirtualDub is the application that we are going to be using when we clean the footage.

In the realm of digital video you want to avoid recompressing the video files with a lossy CODEC (DV, MJPEG, MPEG, Indeo, etc) as much as possible. With each successive recompression, you lose a bit of quality. When ever possible use a lossless CODEC like Huffyuv in all of the intermediary steps, and only recompress the video with a lossy CODEC at the very end of the process.

Some times you can almost see it as an art form, a contest maybe. What is the least amount of lossy steps that you need to get the source footage into the destination footage? In a perfect world, you would convert your source footage directly to the destination, but if you have to use intermediary steps (like the editing of the music video from the footage, or the video clean up stage), as long as you keep to lossless compression, you will not lose anything and the steps will be “transparent”. Or if you can use intermediary files and simply recompile the video from the originals once done, it is only the amount of steps form the original to the final that matter, not any side steps. We will get to this later.

VirtualDub can only read AVI files and MPEG-1 files. ASF files cannot be read by VirtualDub 1.4 or greater. They have to be converted to an AVI file using some other tool; I use VirtualDub 1.3c or Graph Edit from the DirectX SDK.

For every conversion we want to keep the source file’s specs as much as possible: i.e. frame rate and resolution. If the source files were 320x240 resolution at 12 frames per second, you want your “original” file to have the same specs. Some tools allow you to upsample the video on extraction; I prefer to use VirtualDub’s tools during the second phase, since I have seen its output and trust its methods. There are a couple of different ways to change the resolution of video files, which will be gotten to later. Suffice to say, VirtualDub has some superior methods, and is what I trust.

For each method, your mileage may vary. Games vary in the details of how they store the files, so read into the methods, and try to adapt to the source files given to you. The basic rule is that you want to create a set of AVI files that have had as little processing done to them as possible. If you can do a stream copy, and there is a Microsoft Direct Show filter for its CODEC, then that is best, otherwise choose a loseless CODEC like Huffyuv.

About the only stumbling block I have come across is the 2-gigabyte limit on standard AVI files. Microsoft has implemented an OpenDML specification within its latest applications, but some of the older ripping packages still use Video for Windows. If that is the case, never hesitate to segment the video files, or divide them along 2-gigabyte boundaries.

In the end… adapt.

Directory Handling

Something I have found that helps a lot(and will become obvious later) is to keep everything related to a project in the same directory, using sub directories to organize everything. This keeps the clutter down, and also helps you to remember which version of the files are for what.

For an example: in my Utena project, I created a directory R:\Utena where I stored the project file, sound files, and other miscellaneous files. I then created a sub directory with the path R:\Utena\CPK where I stored all of the CPK files from the CDs. In R:\Utena\Original I put all of the direct conversion AVI files that I made from the CPK files. When I cleaned the video quality of the videos, I created a directory with the path R:\Utena\Baseline and put all of the baseline files in there. For my edit based files I created a directory called R:\Utena\Video that held all of the reduced resolution files I used for editing.

So I edited my video based on the reduced resolution files, and when finally done, replaced them with the baseline. We will talk about this in a later section.