---
name: "dvbackup"
section: "1"
platform: "linux"
package: "dvbackup"
version: "1:0.0.4-11"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/dvbackup"
---

# dvbackup(1)

Converter from arbitrary data to a DV stream

## NAME

dvbackup — Converter from arbitrary data to a DV stream

## SYNOPSIS

**dvbackup** \[**--version**\]  \[**-n\|--ntsc-mode**\]  \[**-d\|--decode**\]  \[**-t\|--verify**\]  \[**-b\|--set-backup-title=TITLE**\]  \[**--set-picture=PPM-FILE**\]  \[**-v\|--verbose**\]  \[**-p\|--prefix=COUNT**\]  \[**--test=COUNT**\]  \[**-r\|--recover**\]  \[**--enable-audio**\]  \[**-?\|--help**\]  \[**--usage**\]

## DESCRIPTION

This manual page documents briefly the  **dvbackup** tool.

This manual page was written for the **Debian** distribution  because the original program does not have a manual page.

As you probably know, current digital  camcorders can save approximately 13 GB of data on those tiny DV  cartridges at a speed of 3.6 MB/second. That's fast. Very fast. It's  faster than most DAT streamers which only work at 1 MB/sec or less. We  can not use all of the data, but 10 GB should be good enough for  everyone.

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.

Then there is the audio data, which is written uncompressed onto the  tape. That means: We tell the camcorder at the beginning of each frame,  that we won't use audio at all but fill the space reserved for it with  data. Easy, but somewhat hacky. In fact, I don't know, if this works on  every camcorder and not only on mine (a Sony VX700). Your mileage may  vary.

To finally bring the data on tape, you have to use an additional  utility, called dvconnect, which is (hopefully soon) included into  libdv. Take a look at the patch manager if it's not in already. And  then it's time to rock and roll:

Advantages of dvbackup over other backup technologies

-

  relatively cheap (the cheapest camcorder will be enough, but if you  have already one...)

-

  the tapes are quite cheap

-

  open standard: if your streamer, aah camcorder dies you can rescue  your data with any other one (except PAL/NTSC need to fit), you are  not bound to a special company

-

  it's faster than many streamers and it will be more comfortable -  you can use the search-index function to "jump" to a recording

-

  tapes (re)wind faster than many streamers

-

  you do not need to rewind the tape to eject it

Disadvantages of dvbackup

-

  you do not get any warranty :-)

Usage of the Unix client

-

  Press record on your camcorder. (Or use your favorite avc control  program for this. For the VX700 this doesn't work and you have to  hack something together, that uses LANC. I might publish my  "solution" for this soon...)

-

  Type "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" Alternatively, you can write the data in  several parts on tape. Just go experimenting, and mail me the  resulting backup scripts...

-

  Stop your camcorder and rewind.

-

  Now it's time to verify: Press play on tape ;-)

-

  Type "dvconnect \|dvbackup -t" and watch for crc errors. The data  corruption bug mentioned for version 0.0.1 seems to be fixed so  there is no excuse in not using this little nifty program ;-)

-

  If you want to restore: Do a simple "dvconnect \|dvbackup -d\|cpio  -imV". CPIO will also happily tell you about CRC errors. So you  might want to check using cpio's archive test mode too. But keep in  mind, that cpio's CRC function is not that fast!

## AUTHOR

This manual page was written by Robert Jordens jordens@debian.org for the  **Debian** system (but may be used by others).  Permission is granted  to copy, distribute and/or modify this document under the terms of  the GNU General Public License, Version 2. On  Debian systems, the full text of this license can be found in the  file /usr/share/common-licenses/GPL-2.