A Problem With Digidesign's PostView

A Problem With Digidesign's PostView

Evan T. Chen
October 17, 1996

Digidesign's Pro Tools III is one of the most popular digital audio workstations used today for audio editing, but behind all the hype and glits and glamour is a box that could definitely use some improvements, particularly in its application in feature film post-production. The most recent addition to the list of ever-expanding Pro Tools complaints is PostView, Digidesign's digital picture sidekick program.

I stumbled across an anomaly as I was in the midst of adding head and tail beeps to the two reels I had just edited. In "grid" mode, Pro Tools allows the cursor to snap to the nearest grid setting1; once the grid setting is set to a single frame one navigates the cursor by exactly this amount. Be aware that a film frame lasts longer than a video frame so depending on which timeline setting is being used -- feet and frames or timecode -- the duration of a "frame" varies. When switching between film and timecode timelines Pro Tools automatically lines up the edge of the first film frame with the first video frame2. Assuming we're working with a film timeline, we can move in exactly one film frame increments, that is move frame by frame. This is exactly what I was doing, trying to determine the LFOA, when I noticed certain frames were being missed. Curious. Upon further investigation and some careful testing, I realized what was happening: PostView was skipping every fifth digitized video frame3. Now, it is necessary that PostView skip a video frame when working in NTSC since the duration of four film frames is the same as the duration of five [pulled-up] video frames. The problem is that PostView skips the wrong one! Figure 1 illustrates this problem [but to fully comprehend it and its detrimental effects on audio post-production one should be knowledgeable of the theory behind telecine transfers], and its consequences are many. One of the most blatant is that 50% of the time Pro Tools displays a footage count different from the burn-in in PostView's digitized picture! So which footage can we trust4?

As you can see, editors must be extremely careful when working with Pro Tools' feet and frames timeline and grid mode. What amazes me is that after three years (possibly more?) out on the "professional" market, no one has caught this blatant mistake in PostView5! Hmm... makes one wonder doesn't it? Undoubtedly, the errors have already been made. Next time when editors are exasperated over rubbery sync and frantically pointing fingers at everyone except themselves, here's one culprit to keep in mind.


1Actually, there is a catch to this -- the fluent Pro Tools users know what I'm talking about -- especially when switching from "slip" to "grid" mode. I won't go into details now, but I recommend editors to thoroughly familiarize themselves with "grid" mode before using it. Otherwise, one risks creating major sync problems.

2 Already, one has a 50% chance of being out of sync by 1/5 of a film frame. My article entitled "Accurate Sound Editing for Film using Digital Audio Workstations" deals with this discrepancy in much more detail. As far as I know, every digital post workstation with audio capabilities has this problem, and much of it stems from ignorant telecine operators, software programmers, and of course sound editors.

3 What PostView considers a video frame is actually one digitized video field, probably the first.

4 There IS an easy and correct answer to this dilemma, none of which can't be found by simply understanding and then analyzing the problem. I refuse to just give the solution away however.

5 The fix to the NTSC problem is simple: in A and B sequence transfers, skip every fifth digitized video frame beginning with the third. For C and D sequence transfers, skip every fifth starting with the fourth.

[Note: Quicktime movie features have now been integrated into Pro Tools, rendering PostView obsolete. I have not tested to see whether this problem still exists in the more recent versions of Pro Tools. -- Evan 4/23/00]

Copyright © 2010 by Evan T. Chen. All rights reserved.