Apple DV codec & ProMax DV Plus
Pix: Sampling
Pix: Artifacts
Pix: Defects
Pix: Generations
> Pix: Codecs <
Text: The DV Format

updated 2005.11.10 - images no longer mirrored at 2-pop

posted 22 October 2000
updated 25 October: more details on DV Plus in YUV mode(s)
updated 26 October: remember-folks-these-are-beta-codecs!
Images relocated 26 October due to excessive traffic!
updated 2 November with more operational issues

26 October 2000 21:00 GMT: While images may be worth a thousand words, they cost an average of 100,000 bytes each. Due to the unexpected volume of traffic this review generated, my webhosts's bandwidth was overwhelmed. To reduce traffic to an acceptable level, all the images were relocated to 2-pop with their kind permission.

10 November 2005: 2-pop's mirror has been discontinued. The Promax codec is no longer available and Apple DV has evolved considerably since these tests were performed; there is no longer a need to view the test images, but the discussion has been retained here for hysterical reasons.

Testing Process
Operational Issues
Images (unavailable)


The October 2000 release of Apple's QuickTime 5 Public Preview for Macintosh brings with it Apple's much anticipated new DV codec. The new codec is a vast improvement on Apple's previous efforts; it's one of the best DV codecs I've tested. This page discusses the improvements both in quality and speed, and contrasts the new codec with its predecessors.

I also compare Apple's codec with the DV Plus codec in ProMax's DV Toolkit, which heretofore has been the only viable alternative for Final Cut Pro users requiring high quality DV output (Premiere users and EditDV users also had the choice of Radius / Digital Origin's SoftDV codec, but that's a different story...).

Reminder: neither of these codecs is a finished, complete version. The Apple DV codec appears to be nearly so, but the DV Plus codec is definitely a work in progress. Both codecs are subject to changes and improvements; read this review as a "snapshot" of progress, not a definitive comparision of shipping products!


The original DV codec shipped with Final Cut Pro 1.0 was embarrassingly awful; the improved version shipped with QuickTime 4.0.3 eliminated a vertical striping interaction with Sony hardware, but was otherwise unimpressive.

The translation between DV's YUV color space and the RGB color space used in Final Cut Pro and Premiere was very poor, leading to a blocky "posterized" look, desaturated colors, and slight but noticeable drops in overall brightness. Additionally its compression quality was horrible, with huge amounts of mosquito noise and quilting artifacts, to the point where fine detail such as small text was often obliterated.

The RGB translation used mapped black to 0,0,0, and white to 255,255,255, so that any "super-white" highlights in the picture were truncated from 110 to 100 IRE (NTSC) in processing.

ProMax came up with the DV Toolkit (DVTK), a reworked version of the DVSoft codec to be used as a substitute (DV Toolkit also offers a low-res "offline" mode and the FireSNAP stills-capture utility, but those are beyond the topic of this discussion). DV Plus' default "clamped luma/chroma" mode worked exactly the same way as Apple's codec, but with much higher quality; DV Plus and its DVSoft ancestors (also available on the PC as part of the DPS Spark package) have been reference standards for compression quality, though both suffer from a 2-pixel leftward chroma shift on every decompression operation.

Additionally, DV Plus offers a "full-range luma / clamped chroma" setting to allow super-white preservation, and a "full-range luma/chroma" mode that kept excessively saturated colors intact, too. Both the full-range modes traded RGB precision for RGB range; as the nominal black-to-white range occupied less of the fixed, 0-255 RGB range, the accuracy of the YUV/RGB translations suffered slightly.

With Final Cut Pro 1.2.5 and QuickTime 4.1.2, a YUV processing mode was added. By keeping the digital data in the YUV color space for many processing tasks, the RGB/YUV conversion step can be avoided. FCP 1.2.5 users (though not Premiere users) thus avoided the darkening, desaturation, and blocking of the previous codec, but the compression quality was still distressingly bad.

QT 4.1.2 also broke DV Plus, which prevented many people from upgrading FCP to 1.2.5 as it required QT 4.1.2. In September 2000 ProMax started quietly shipping a beta version of DV Toolkit to existing DVTK users asking for it; the new DVTK is compatible with QT 4.1.2 and also (with some limitations) with QT 5 Public Preview.

In October, Apple released QT 5 Public Preview. This release contains a "late beta" version of Apple's rewritten DV codec (although the rest of QT 5 was described as "pre-beta" by a QuickTime team member at the 25 Oct. L.A.F.C.P.U.G meeting).

I am in the process of performing detailed tests on a variety of DV codecs to supplement or replace earlier comparisons. I started off with the new and preceding Apple DV codecs, and DV Plus as well. As time progresses I will add images and observations of SoftDV (Digital Origin), Matrox, Canopus, and Microsoft codecs, but for now, here's a detailed look at the current state of affairs for two Apple-platform codecs for Final Cut Pro and Premiere (2005 update: while such tests were performed, they took months, and new versions of codecs were emerging constantly; it turned out to be impractical to consider keeping such a site updated while still holding down a paying job. As of 2005, Apple, Avid, Canopus, and Matrox have best-of-breed codecs; Promax, Adaptec, and Radius codecs have been discontinued, and even the Microsoft codec, once the laughingstock of the field, is fairly decent in current incarnations).

Testing Process

I've run five generations of recompression on a variety of test images. While most production situations rarely require more than one generation of decompression/recompression, multigeneration tests serve two purposes: they emphasize subtle defects that might be missed otherwise, and they reflect what may happen to a clip over multiple “repurposings” over an extended period of time, as clips are edited, laid off to tape, recaptured, and reused.

The test images included several synthetic images, imported as TGAs, to stress specific aspects of the codecs:

Several one-second camera-generated images were also used to show real-world performance. All the images were shot with the Sony VX1000: These images were strung together as one-second clips on the timeline, an identifying text block was added, and the timeline rendered to a Final Cut Pro movie. That movie was then imported, the text block was superimposed again (both to identify the test and to force a recompression), and the timeline was re-rendered. This last step was repeated three more times, resulting in five generations of rendering through the codec under test.

The time it took to process these ten-second movies was recorded using a stopwatch, starting when the "Save" button in the "Export FCP Movie" was clicked and stopping when the rendering progress bar vanished. Times were taken both for the first generation render of the original elements (40% of which were TGAs and thus only needed compression, not decompression), and for the second generation where all the source material (aside from the superimposed text boxes) was already in DV form. "Recompress always" was never checked, nor was "Make Reference Movie".

Timing tests were also run performing dissolves, color-correction filters, DVE-like stretches, and text superimpositions. The time it took to process these ten-second movies was recorded starting when Option+R was pressed to render the timeline and stopping when the rendering progress bar vanished to be replaced with the “preparing video for display” progress bar. All these tests were run with “simple” and “complex” clips. The simple clips include large areas of flat color and very little detail; the complex clips are foliage shots with nothing but fiddly little details. As expected, the codecs labored longer over the complex images than they did over the simple images. In practice, people usually say how long it takes to render a one-second dissolve (for example), but without saying how “busy” the source clips were such figures are of little use.

All the timelines in these tests (as in the multigeneration tests) lasted for ten seconds, so the results from these tests are directly comparable in timings. The table below is an average of all the tests run.

All tests were run with OS 9.0.4, VM and AppleTalk turned off, the screen in 1024x768, Millions of Colors, with FireWire connected to a Sony DHR-1000 (or other DV device), on a PowerBook G3/266, a G4/450 "Sawtooth", and a borrowed dual-CPU G4/500 of unknown ancestry (it has a CD-ROM drive, for example!).

The version of DV Toolkit used with QT 4.0.3 was the release dated 27 January 2000, which I'll call DVTK 3.0. The version used with 4.1.2 and 5 is labeled 5.5, although the DV Toolkit Init shows version 3.0.1 and is dated 19 September 2000.

The software combinations tested were:

All tests done to date have been in "NTSC": 720x480, 4:1:1 DV.



The following chart compares render speeds for the "2nd+ generation rendering", in which a 10-second clip has a small text box supered on it.
chart, rendering times for various configurations

Chart 1: Ten-second Text Supers
Combinations of FCP/QuickTime/codec vs. time

The Apple codecs are Altivec/VelocityEngine-aware, and thus run much faster on the G4s compared to the G3 than mere clock speed differences would indicate. DV Plus, however, does not take advantage of Altivec (nor multiprocessing), so its performance can be used as a rough baseline for comparing changes in machines and changes in QT / FCP versions. Even so, the DV Plus time moving from G3 to G4 is 48%, not 59% -- remember that the bus speed and disk subsystems in the minitowers are faster than those in the Wallstreet PowerBook, and that there are other architectural tweaks in the G4 beyond Altivec.

The DV Plus codec is insensitive to clamped/full mode setting as far as speed goes (YUV runs about 15% faster than RGB modes); QT 5's DV codec about 10% slower in RGB mode than in YUV mode. All Apple times shown are for YUV mode renders, while all DV Plus times are shown for RGB renders.

FCP 1.2, QT 4.0.3 FCP 1.2.5, QT 4.1.2 FCP 1.2.5, QT 5 pvw
G4/450 / G3/266 32% 38% 33%
same, using DV+ 48% note 1 note 1
DP G4/500 / G4/450 113% (!) 81% 64%
same, using DV+ 108% (!) note 2 88%
Table 1: Speedups
Time spent rendering, one configuration over another one, measured as a percentage. Averaged over all tested tasks. Smaller numbers indicate more of a speedup.

Note 1: Unable to preview out FireWire in these configurations; test aborted.
Note 2: This combination was simply not timed, so no comparison is possible.

Some interesting (and occasionally counterintuitive) information can be gleaned from these numbers:

Image Quality

Bear in mind that both the codecs reviewed here are essentially beta versions: Apple's DV codec is part of the QT 5 "Public Preview" (a public beta, perhaps, but one for which you don't need for fork over $29.95, grin?) while DVTK 5.5's DV Plus is, as it were, a "silent beta" -- it's not advertised for sale by ProMax, it's being supplied only on a need-to-have basis, and it comes labeled as a beta. Don't be surprised if the "final" versions of these codecs differ from the versions I've tested -- but then, don't be surprised if they don't.

Refer to the images for a few visual details. Only a small subset of rendered images has been posted due to constraints on time (mine making the pix, yours downloading 'em) and space (my server's disk allocation is getting filled up), but I've tried to make sure they're the most telling ones. Additionally, some of the test clips show their stuff best when in motion; when stills are extracted they fail to adequately represent the information they give.

Please note in what follows that for the most part the errors and artifacts that I'm discussing are minor and subtle. The Apple DV codec in QT5 is among the best I've seen on any platform; when I'm picking nits, they tend to be small nits indeed.  Much of my critical artifact monitoring is done inches away from a  PVM-1342Q monitor with black levels raised into visibility and with the Aperture control (high-frequency emphasis or "sharpness") turned up all the way, specifically to make defects stand out. I'll also put up two images side by side on the computer screen at 200% magnification, or invert one and superimpose it on the other at 50% opacity to emphasize any difference between them. I note with some amusement that many of the defects I rant about are barely visible in the extracted stills attached to this page.

Likewise, DV Plus in clamped/clamped mode continues to be a very good choice, though its leftward chroma drift remains a nagging problem for multigenerational work and repurposing, and its full-range modes suffer in comparison to either clamped mode DV Plus or Apple DV in QT 5. DV Plus YUV mode isn't yet ready for prime time -- but remember, it's a work in progress.

Apple DV

Apple has come a long, long way. In YUV mode, there is almost no detectable image degradation after the first compression. Generations 2 and up are so close to generation 1's quality that I had to peer very closely at the pix to find any differences at all. Apple has eliminated any tendency towards the quilting artifacts that characterized their earlier efforts, and brightness/saturation shifts are a thing of the past.

Compared to DV Plus, Apple DV in QT 5 appears to throw off slightly more mosquito noise on out-of-band information in its first compression. "Out-of-band" information consists of sharp, "digital" edges present in unfiltered, unaliased text and the synthetic images I used; it's not typically present in camera-captured material.  The mosquito noise is most visible as the bobbly dots around the text in the informational overlay which, being superimposed every time, is always a first-generation addition. (All the informational text is rendered in FCP directly, with no softening or blur applied; it's a worst-case stressor.)

On camera-captured material, or on recompressions of previously compressed synthetic images, Apple DV added very little artifacting of any sort; overall I judged it better than DV Plus in multigeneration "mosquitoing" and in transparency overall.

Furthermore, on those occasions when Apple DV throws a few more spurious pixels around, it appears to do less damage to the image while doing so. This is most noticeable on the NoiseTest image, a pathological stressor if there ever was one.  Apple DV "made more mosquitoes," but it degraded the text (and the rest of the image) less in the process. Odd, but true.

On closer examination, I've come to the tenuous characterization that Apple DV throws off more widely-dispersed, high-frequency mosquitoes, leaving the underlying image fairly intact. DV Plus keeps the damage in closer, with more tightly-packed, bulkier mosquitoes, but in the process the sharp edges and fine details are more adversely affected.

In RGB mode, Apple DV fares less well. The ColorSmooth test image clearly shows errors after a few generations, and in a couple of the test clips these errors (in hue, saturation, and occasionally in brightness) start to become visible by the 4th or 5th generation. To put this in perspective, though, all the errors were orders of magnitude less apparent than in earlier Apple DV codecs.

Apple DV in QT5, like previous Apple codecs, applies a slight gamma correction to the image when it's converted to/from RGB. I'm told this is done to make the image on the computer screen more accurately reflect the grayscale of the same image on a TV screen. When processing precompressed DV clips it's a nonissue, as the correction occurs symmetrically and the recompressed image has the same gamma it started out with. It's an issue, though, if you're feeding it TGA files or the like: if you've set up the image with a precise grayscale (as in my linear test ramps), the midtones will "brighten up" a bit when seen on video. I remain undecided on whether this feature is desirable; it makes my life as a tester and calibrator more difficult, true, but in real life I'm not sure if it causes graphic artists as much grief. One should be aware of it, though; no other DV codec I'm aware of performs this gamma correction, so if your eyes are "calibrated" to DVSoft, SoftDV, Canopus, Matrox, or the like, you'll need to readjust your thinking when working with Apple DV (or precompensate by adding a gamma correction of about 1.2 to incoming graphics).

DV Plus 5.5

DV Plus in clamped/clamped mode remains a highly-ranked codec, with excellent multigenerational stability and accuracy -- as long as you can live with chroma drift. It throws off slightly less mosquito noise than Apple DV does on pathological image detail, and over multiple generations this RGB-mode codec arguably performs better than Apple DV in RGB mode does. Quilting artifacts aren't added by DV Plus, and accuracy is top-notch: levels and colors don't change from generation to generation.

In full-range/clamped mode, however, the accuracy of rendering starts to slip. Over five generations, I noticed black levels starting to creep up; observation of the linear ramp signal showed a small "step" in the otherwise smooth slope at around 59 IRE on the waveform monitor (i.e., around 60% of the full-white level), below which levels were slowly creeping up. It's as if some math error for any Y value below 59 IRE was rounding up one bit with each generation.  Color accuracy remained excellent over multiple generations.

In full/full mode, DV Plus suffers more. Here, a noticeable step occurs at 80 IRE, below which levels increase over the generations about twice as fast as in full/clamped mode. Chroma starts desaturating, especially along the Y and G vectors and to a lesser extent on Cyan, while Red and Magenta stay strong. The effect is for the image to go pale and magenta, and it's visible in the first generation (and will be visible to the careful observer when entering/exiting effects like dissolves).

To put this in perspective, however, it's less noticeable than the comparable color/brightness shift that occurred in Apple DV using 4.0.3, and it's only a problem in the full-range modes.

This puzzles me. DV Plus version 3, running under QT 4.0.3, showed much less degradation. The creep-up in black levels was less apparent. Desaturation occurred only slightly, and evenly throughout the hues. In full/full mode the worst visible effect was a slight tendency towards a green shift over time (true with many codecs). I'm not sure what to attribute this change to: is it in the codec, or in my test procedures? As I've had some difficulties getting DV Plus and QuickTime to cooperate (see below), I can't rule out the latter. But since the clamped/clamped testing resulted in pix that seemed identical to the same tests done with DVTK 3 under QT 4.0.3, I fear that some fell change may have befallen DV Plus. As DV Plus is still in its beta stage, of course, I hope that the release version will live up to the high standards of the previous versions.

In all RGB modes, DV Plus continues to suffer from a lateral chroma drift: with each succeeding recompression; the color information gets displaced leftwards a pixel or two. This has always been a problem with DV Plus (and DVSoft before it). It's typically not visible in the first generation, but if you (or anyone else) repurposes your material at a later point, you'll likely see it, as you will if your production involves a couple of separate renders in FCP or Premiere in conjunction with AfterEffects or the like.

DVTK 5.5 offers a YUV mode in its control panel, which I was told by ProMax tech support not to use. I have to agree with ProMax, at least with this beta version.

Indeed, compression quality and "character" were so different from the RGB modes of DV Plus that I'm not convinced I had set up my test systems correctly. Also, in my initial testing, it really looked like DVTK's YUV mode "passed through" to Apple's codec, but Miles McNamara of Puccini Films suggested otherwise: he was seeing a dramatic difference. I retested, and agreed with him. In the meantime, he tried to reproduce his own results, and failed, saying it was passing through to Apple DV! My best guess is that there are interaction and setup issues we're not yet on top of, and we need to wait for the release version before coming to any conclusions. The results below should be considered tentative at best.

Running atop QT 4.1.2, selecting YUV in both FCP and DVTK appeared to use the Apple codec, at least in terms of interaction. Indeed, I could toggle through all the settings in DVTK, and the video and waveform monitor images didn't change (in FCP RGB mode, changing DVTK modes results in changes in levels, contrasts, and gammas depending on the DVTK setting selected). Likewise, the linear ramp in the DVStressTest image showed the characteristic Apple gamma correction, not the linear slope that DV Plus's RGB modes (and most other codecs on the market) render.

When rendered through multiple generations in YUV/YUV, the image looked reasonably good in the first generation: better than QT 4.1.2's pix, if not as good as DV Plus in clamped/clamped mode or QT 5 in YUV mode. Over multiple generations, though, the images were degraded as much as with the QT 4.1.2 codec, although the artifacts were a bit different (quilting artifacts on detailed, moving images were possibly the worst I've seen). Times were a bit shorter than DV Plus in RGB mode, but longer than Apple DV in YUV mode. Unlike DVTK's RGB modes, there was no lateral chroma drift in YUV/YUV rendering.

(These next two combinations of modes are probably not intended to be used, but with no documentation available yet for DVTK's YUV mode I felt it was worth trying them to see what happened. In the reproduced images, I only show results from the YUV/YUV testing described above.)

With FCP set to RGB mode, but DVTK set to YUV, the image fell apart equally quickly and with similar artifacts, but the midtones of the image were depressed with each succeeding generation, almost as if all the images (not just the stills) were being subjected to an "inverse Apple DV gamma correction." Peak whites were clipped in RGB/YUV rendering; there was no lateral chroma drift. In the first generation, though, the linear ramp stayed linear.

With FCP set to YUV mode but DVTK set to any of its RGB modes, my FireWire preview goes solid pink whenever previewing a DV clip (stills on the timeline show up properly), and attempts to render result in a "codec not found" message when a precompressed clip is encountered.

With FCP set to YUV and DVTK set to "Apple DV", images were rendered exactly as if DVTK were not installed at all, which is what one would (and should) expect.

Operational Issues

2 November 2000 update:

1) Dual-CPU Macs with OS ROM version 5.5.1 can freeze up with QT 5, and the FireWire output's quality can be reduced on certain scenes. See for details. (My tests were run on a DP Mac with OS ROM version 4.9.1 and I didn't see these problems on this older version.)

2) Many people are reporting dropped-frame problems with QT 5. At least one FCP user found that the Radius SoftDV codec extension installed with Media Cleaner was causing his problems, and that when he uninstalled it the problems went away.
_ _ _

I've run across a few issues during the three weeks I've been doing these tests.

After installing QT 5, I was unable to successfully revert back to QT 4.0.3 with DVTK 3.0 on any of my three test machines (fortunately I had run my DVTK 3.0 tests first). While I could install everything and use DV Toolkit's Control Panel to select a codec, I wasn't able to make everything work properly. At one point, it appeared that DV Plus was decompressing (lateral chroma drift) and Apple DV 4.0.3 was compressing (horrible artifacting). All other attempts resulted in huge brightness level changes, and chroma blow-out using the full/full mode (also implying that the decompress and recompress weren't going through the same pathways). It's probable I wasn't properly clearing all the memory I needed to; I may not have been throwing out DV Toolkit Prefs (DVTK 5.5), FireMax manager prefs (DVTK 3.0?), QuickTime Prefs, FCP Prefs, AND the kitchen sink to be on the safe side. I haven't tried this for a bit; as time has worn on I've become more savvy about what prefs to toss when upgrading and downgrading, so I might have better luck now... Just be cautious.

When changing QuickTime versions (at least between 4.1.2 and 5.0) it doesn't appear to be necessary to deinstall DVTK first. However, it is helpful to toss the DVTK prefs, and later reinstalling QT it's important to at least invoke the DVTK control panel and select a codec prior to running FCP or Premiere. I also toss out QuickTime prefs (be sure to record your QuickTime Pro user name and serial number first! I put them in Note Pad so they'd be easily copyable/pasteable for the reinstallation) and FCP Prefs.

I've been able to change codecs on the fly using the DVTK control panel. However, sometimes FCP gets confused, and I wind up scrolling through a few frames with the brightness and contrast characteristics of the previously-selected codec (when using DVTK, the Viewer and Canvas windows look dark and washed out when a full-range codec mode is chosen). On at least one occasion, these errant frames got recorded into a rendered movie, don't ask me how: I hadn't rendered any previews!  To be safe, it's best to exit FCP or Premiere, change the codec, and then re-open your project.

I wasn't able to use DVTK atop QT 4.1.2 or QT 5 on my G3/266 powerbook and still have FireWire previewing. Gray screens with struggling small blocks of green and pink pixels were the result. My guess is that the added bloat of QT 4.12+ and DVTK 5.5 pushed my poor PowerBook a bit beyond what it can keep up with in real time. Remember, Apple doesn't even qualify this ancient, slow machine for DV under FCP!

QT 5 appears to work properly with FCP 1.2.5, with or without DVTK 5.5, with the following caveats:

Changing QuickTime versions, whether upgrading or downgrading, is best done by using the installer of the installed version to uninstall it first. Thereafter, you can use the new version's installer to do a full install. Deleting the various Prefs files as discussed previously -- certainly the FCP and DV Toolkit prefs -- seems to be helpful, too. I haven't run a full suite of version-changing tests to find out what's really necessary, but I've uninstalled/reinstalled a lot recently and deleting the prefs files is simple, quick, and leads to predictable behavior.

I have not seen any image quality differences dependent on machines: G3 vs. G4, one CPU vs. two CPUs. Speed differences are noticeable, of course!


Finish all revenue-generating projects before upgrading! I've had no problem opening projects created under earlier versions of FCP and QuickTime (and I've done that a lot in the past three weeks), but why take the risk?

Why take the risk at all? If you're currently running with the Apple DV codec from QT 4.1.2 (or earlier), adding DVTK 5.5 or upgrading to QT 5 Public Preview will give you a quantum leap in image quality, that's why!

I can't stress this enough: if you aren't using either DV Plus or the Apple DV codec in QT 5, you simply don't know how good DV NLE can look. I would not (and have refused to) use FCP for any sort of professional work without one or the other of these codecs.

At first glance, you might wonder why I don't just say "get QT 5" and be done with it. However, DVTK's clamped/clamped mode has a few niche applications where it may do better. Thus there are choices to be made; here's what I would suggest:

Anyone not falling into the above categories will have to make the difficult choice taking into account the following factors: If you're happily working away with FCP 1.2 or Premiere, both atop QT 4.0.3 and DVTK 3.0, you may want to wait for either or both of these codecs to stabilize a bit. The only compelling reasons to upgrade to either QT 4.1.2/DVTK 5.5 or QT 5 preview are (a) the enhanced features of FCP 1.2.5, like native 16:9 support and display, (b) avoidance of QT 4.0.3's crackling-audio-over-1394 issues*, (c) speed, or (d) ability to preserve super-whites while keeping the default black level at black, instead of super-black.

If you don't fit into that category, though, upgrading to one or the other is a no-brainer: just do it. Yes, both are beta versions; yes, there are tradeoffs. But both of these codecs rock!

And remember: neither of these codecs is finished yet. My suggestions apply for the codecs available today; what eventually ships from Apple or ProMax may well be different from what I've tested. Apple's RGB mode may yet improve and the operational issues with QT 5 will almost certainly diminish; and what I've seen in DVTK's YUV and full-range modes may look nothing like what ProMax winds up shipping.

* Using FCP 1.2 with QT 4.0.3, I capture audio & video over 1394 into the Mac. I play it back over 1394 to the DV device. If it's a DSR-20 or DHR-1000, it sounds fine on the tape playback, but if I recapture it into FCP, it crackles and pops subtly.

If instead I capture the output video into a DPS Spark NLE on the PC, using a very early software codec with no error concealment, it screeches horribly, and the waveform shows lots of full-scale negative excursions (DV audio's error code).

If I play the original audio out to my early-model VX1000, the screeching occurs immediately. and the peak-overload LED flashes almost continuously.

Upgrading to QT 4.1.2 and performing exactly the same operations resulted in perfectly clean audio. Downgrading to 4.0.3 brought the problem back. On two different machines. Thus, I infer it's a QT 4.0.3 problem.

Other Resources

Copyright (c) 2000, 2005 by Adam J. Wilt.

You are granted a nonexclusive right to reprint, link to, or frame this material for educational purposes,
as long as all authorship, ownership and copyright information is preserved and a link to this site is
retained. Copying this content to another website (instead of linking it) is expressly forbidden. Home SW Engineering Film & Video Production Video Tidbits >DV<
Contact me via email

Updated 2005.11.10.