Software design for tools that transfer DV from tape to file take one of two approaches:
Receives all the DV frames and writes them to disk as a DV stream.
The software receives a series of DV frames, analyzes them to understand their significant properties, and wraps those frames within a container format, such as mov.
Tools such as DVHSCap, Live Capture Plus, and dvgrab use the first method. The resulting frames are stored as a stream of DV frames. The result is very authentic to what was transmitted; however, there can be significant challenges to using this data. DV supports a variety of options within several characteristics.
Consider this scenario. A cameraperson recording an interview with a musician on MiniDV tape. The interviewee is frameds in a 4/3 aspect ratio and the audio is recorded onto two channels of audio with a 4/3 aspect ratio. During the recording, the cameraperson remembers that the interview is for a production with a 16/9 production, so adjusts the camera's settings and does a second take at 16/9. Following the interview, the cameraperson records a performance by the musician's band and adjusts the camera to record 4 channels of audio rather than 2 in order to capture more of the microphones. This DV tape could be transferred over FireWire to a single, continuous DV stream; however, the resulting DV file would have a variable aspect ratio, a variable sampling rate for the audio, and variable audio channel count. Some players could support some of these changes, for example VLC will adjust the framing as aspect ratio changes though QuickTime won't. The presentation will be inconsistent since the extent of this sort of variability is rarely supported.
Tools such as Final Cut Pro 7 use the second approach. The resulting QuickTime file contains the same DV frames that first method would result in, but stores them in a convenient container. However, when the incoming DV frames contain incoherency in the characteristics, either because the camera settings changed or the data is damaged, the software will generally stop the data transfer at those events. Software that was written to expect perfect DV frames may then start to break up a DV transmission into dozens of individual files with intermittent gaps or simply stop and give error messages.
In order to effectively preserve DV materials in a way that scales, we need to ensure that we can transfer all of the DV data in a manner that is verifiable and also produce audiovisual files that are well-described and interoperable. This requires a mix of the two approaches above. In the design of dvrescue, we use the first approach and initially just write all incoming DVdv streams into a file. This file is intended to be a digital copy of the data stream that the DV tape player produces and contains audio, video, camera metadata, metadata about frame characteristics and information on how well the reading of the tape went. After writing those DV frames to a file, we then analyze it with the dvrescue utility and produce a report on every incoherency in the file: including jumps in timecode, jumps in recording timestamps, or changes in properties like aspect ratio or audio channel count. With that resulting data, a subsequent script, called dvpackager, then uses that report and the original DV file, to selectively encapsulate every frame into an audiovisual container such as QuickTime or Matroska. There are options here, so a user could make one file for every time the camera had the start button hit (since all the recording metadata is preserved within the DV frames) or the DV frames could be divided only by changes in properties like aspect ratio or channel count.
The need for this sort of packaging is demonstrated by a recent example file shared with us by Morgan Morel at BAVC. Morgan transferred the DV data from a tape to a file using DVHSCap, which follows the most approach described above, writing the received DV frames into a file and that's about it. In QuickTime X, the file starts with about a second of grey frames and then cuts to a recording of an art installation. Some fan noise is heard in the background, but the audio is very choppy, like a mixture of noise and silence and the result is jarring to listen to. VLC creates a similar jarring presentation, where the video looks right, but the audio is painful.
This is a presentation of how QuickTime X decodes the audio of this DV stream. Wanna listen?
With dvrescue, we can figure out what is happening. The dvrescue utility will read the DV file and document events and changes that happen throughout the file.
Here we can see that at the beginning of the file, there are 19 frames that use a sampling rate of 48000 Hz, but then the subsequent frames use a sampling rate of 32000. The 19 frames at the beginning are the gray frames mentioned earlier, whereas the rest of the tape is a recording of an art installation. So QuickTime X is looking at those first frames and presuming that it's all at 48000 Hz, but then when it is decoding a DV frame that only has 32000 Hz of audio per second, that only fills ⅔ of a second, thus these large seconds of silence are interleave since the decode expects a certain number of audio samples per second, but isn't getting it.
For cases like this, we are working on a utility called dvpackager. It analyzes the stream to createget XML like (shown above) and then decides if and how to break that DV file into pieces to avoid the presentation issues that Morgan found.
After dvpackager does it's thing, we have two video files. One is very brief, just those gray frames and 48000 Hz audio. And then the recording of the art installation at 32000 Hz. When we unsplice these very different recordings from one another and handle them individually they both play well with their own unique characteristics. This approach uses the best of the two described above. We know that we got all the data, but by analyzing it and encapsulating all frames in the right way, we have content that is accessible, well-described, and ready to be sustained as digital files.
