You're viewing a partial stream (from 11/07/03 to 11/07/03), you may want to view the entire stream.
Whoa, Backup There
Was talking to a friend today, and the conversation turned to backing up large files. Really large files. Like DV quality video footage.
While keeping the 'original' DV tape around is always a good idea, it's not always the best 'backup'. Example: Say you're mixing a multiple camera project. Usually that requires almost (if not actually) frame 'exact' editing. So sure, you could save the project file and later dump the footage again. But what if the file starts just a few frames (or worse - a few seconds) before or after the original (and now deleted) file.
There goes all the cuts. Even worse if you had two tapes you had synced up.
Well, it's not that bad. In reality, if the STMP code is accurate - and is captured with the video (and I think it is? I guess?) - you should be able to pad or 'unpad' the file to make it match the original.
But who wants to do that? So you could just back up all your data on a large storage device. [Err, it's not really a backup, in reality you can't have many DV editing projects on the editing computer all at once. Unless you have like a terabyte or two of storage.] Large storage meaning tape, not DVD. At least not when DVD-R(W)s hold less than 5 gig.
So we're talking tape drives. "Tape drive expensive. Me think I better just save footage. Then make it fit right. Bam bam. It fit now." Sure that's not the easiest way to do it. But it works. And you don't have to buy more equipment.
But wait, how do we store that data to begin with? Hmm...on a tape. And to get it off the camera...we...that's right, we 'stream' it to a computer. Isn't that how a tape drive works?
That's nice, but how can we use this to save data on it? And here comes the fun part: If you read the DV documentation carefully, you will notice that the AC DCT coefficients of the video data blocks (8x8 pixels in size) get a fixed amount of space in the DV data stream, but can be terminated earlier with a certain code sequence. So let's have some fun: We terminate the AC coefficients immediately leaving only the DC coefficient for a fancy penguin picture and use the rest for our backup data. Future implementations could easily add a little picture showing the currently written file or something like that.
Yeah, that's pretty much what I was thinking. And the interface for this open source project is incredibly easy.
"find . |cpio -o -H crc |dvbackup --prefix=125 |dvconnect -s"to stream directly to your camcorder. This most likely does only work on very fast harddisks and filesystems. You might try something like
"find . |cpio -o -H crc |dvbackup --prefix=125 |dvconnect -s -b 500"
And for the windows users:
It should compile at least with a windows version of GCC. The only thing you need then is a RAW-DV to AVI converter.
Okay, it's not in the most usable form. But there is some MAC shareware out there that does the same thing.
Upon thinking this out, I'd have to say, just keep the original DV footage. If you got two cameras, copy the video for backup. If you can't rely on the STMP codes (because the backup video shifted them, or some other reason), well, that's why they have them funny looking boards with the swinging thing on the top that they bang before shooting a scene. Yup, to provide both visual and audio cues for syncing. Originally used for syncing the audio to the video, but the concept should apply just as well to synicing footage back to your project.
But this little thought process has reveled something that is perhaps useful. I've been thinking about getting a tape backup for my data. Maybe I should buy a video camera instead.