Edit Suite: Deck Control, Once Over Lightly

by Jim Stinson
January 1998

Protocols are the hidden languages by which your VCRs and other editing hardware communicate via infrared pulses or electronic signals. In a way, they're like the chips that control your car's fuel injection: you're vaguely glad that they're doing their sophisticated thing in there someplace, but you don't care to know what that thing is.

Although that may be true about fuel injection, you need to understand editing protocols in two areas that directly affect your video post production: their compatibility and accuracy.

What Protocols Do
All editing protocols, from the simplest to the most sophisticated, use codes to control the operations of at least two VCRs, telling them when to go into their PLAY/PAUSE, PLAY, RECORD/PAUSE, RECORD, and STOP modes. By memorizing and then communicating strings of these codes, edit controllers can do two things:

• Perform edit sequences that would require an octopus to execute manually.
  
• Perform one edit after another to automatically assemble video programs.
  

The simplest protocols communicate in only one direction, sending these commands from the controller to the VCRs. (This flow is indicated by the red arrows in Figure 1.) More sophisticated systems also communicate information from the VCRs back to the controller, as the green arrows indicate. This information includes the place within the program on the tape in the VCR and sometimes the current mode of the VCR, such as RECORD, RECORD/PAUSE, etc.

More complex systems add the ability to control additional devices, like a second source deck for A/B roll editing and a digital effects generator to make transitions between the two. (See Figure 2.) The diagrams show the edit controllers as stand-alone boxes, but computers are increasingly taking on their functions.

What can this information and control communication do for you? When it's stored in the edit controller's memory, it could:

1. Specify the exact in and out points of a first shot on the A source tape and a second shot on the B source tape, along with the start point of the A shot on the record deck's tape.
   
2. Program a two-second wipe transition on the effects generator that is receiving video and audio from sources A and B.
   
3. Instruct the edit controller to execute this shot A/wipe/shot B transfer automatically.
   

When it sent that instruction here's what would happen:

1. Using information fed back from the decks, the edit controller presets the specified distances of the A, B, and record deck tapes ahead of their start points.
   
2. It places both source decks in PLAY/PAUSE and the assembly deck in RECORD/PAUSE.
   
3. It rolls all three decks at once. At the first programmed point, the record deck starts recording the A source. At the next point, the controller triggers the effects machine to make the wipe to the B source. At the memorized end point of the B source shot, the controller throws all decks into PLAY/PAUSE or RECORD/PAUSE.
   

If you have ever tried to manually synchronize and execute such an A/B roll transition through a DVE (digital video effects), you can appreciate the value of automating the process.

That automation is made possible by the hardware control and program information communicated through the editing protocol.

Protocol Compatibility
As mentioned previously, the simplest protocols have the control functions but not the information feedback. These one-way protocols (including Control-S, synchro edit and the infrared signals sent by a wireless remote) communicate only from the controller to the hardware.

At the prosumer level, we get into two-way protocols, including Control-L (LANC) and Control-M (Panasonic 5-pin). Typically, these protocols show where you are in a tape program via the control track time display, but some can use different types of time code (more about that in a moment).

Compatibility is a key issue with edit protocols because some manufacturers have developed proprietary systems that work only with their own hardware. So in order to plug a Sony camcorder into a Panasonic VCR and use an edit protocol, you'll need an edit controller that supports both of their proprietary protocols.

Compatibility is also an issue with systems that use time code, which labels each and every video frame with a unique address. (As we'll soon see, time code is absolutely indispensable to professional caliber editing.) Not counting digital and oddball analog formats, there are at least three major types: SMPTE linear, VITC (vertical interval time code) and RCTC (Sony's Rewritable Consumer Time Code). As a student of the laws of the immortal Murphy, you can easily guess that these three time code types are all mutually incompatible!

The bottom line is that you need to know which protocol(s)--and which type of time code, if any--you want to use, and then ensure that every component in your edit system speaks that language.

Protocol Accuracy
The most important separator of protocol sheep and goats is their accuracy--that is, how close to the specified frame they actually execute their commands and how consistently they are able to repeat them.

Why is this important? Because your human eye and brain can detect mismatched edits to within two frames or sometimes even one. Suppose you show a full shot of a golf swing and then cut to a closeup of the ball on the tee just as the number one wood smacks it. It's easy to pause the transferred full shot one frame before contact, but if the closeup comes in just two frames late, you'll see a hesitation in the swing that gives away the edit. Two frames early and the action will seem to repeat itself.

In the edit protocol pecking order, time-code-based systems are most accurate, wired control track systems are so-so, and infrared systems are, well, not all that hot.

Infrared control is accurate only to maybe five to ten frames, for two reasons. First, there's a lag between hitting the button and sending the pulse. Secondly, a pulsed command itself lasts longer than the 1/30th of a second devoted to a single video frame.

But before dismissing infrared control, you should know that some manufacturers have taken sophisticated steps to compensate for the built-in inaccuracy. JVC, for instance, uses a clever method of calibrating your particular hardware so that its edit controller will automatically adjust for inaccuracies.

Even so, infrared is a one-way system. Your edit controller never knows precisely where a tape is in its program, and that compromises its ability to locate shots accurately. Some infrared editors, however, use a smart way to fake it; they treat the start point of the first shot you mark as "0" and then locate every other shot on the tape by its distance from that first in point.

Note, however, that this works only if all your footage is on a single tape and you never remove that tape from the deck as long as the edit controller is using the shot list based on that initial in point. Another accuracy limitation is the fact that every distance from the first in point is guesstimated by the edit controller rather than supplied by the VCR, because, of course, the deck cannot report back to the controller.

The two-way communication provided by protocols such as Control-L and Panasonic 5-pin addresses this deficiency. Now the position of the tape is reported to the controller. The trouble is that in most cases, it's the control track that is identifying that position--the set of signals that keeps your picture in sync and, incidentally, operates the hour/minute/second numbers on your VCR's counter. This limits accuracy in two ways:

• The control track records an accurate time signal only once per second. The positions of the 30 separate frames within that second must be eyeballed by the edit controller.
  
• The one-second pulses have no individual electronic identities so there's no way to tell them apart. Push a cassette into the VCR and the counter resets to zero no matter where you are in the tape program. So here again, you can work with only one cassette per VCR and never remove it from the deck. There are some work-arounds that address this limitation, but none is entirely satisfactory.
  

Even with these limitations, a good two-way edit protocol using control-track shot identification can increase your average accuracy to plus or minus two to six frames, depending on the mechanical quality of your equipment.

But for single-frame precision, you need time code. If your hardware can read and write it, you can assign a unique address to every single frame of your footage. Now your edit protocol can create frame-accurate edit decision lists (EDLs) and your automated program assemblies will be perfect every time.

IF--and it's an all-caps if--your hardware is sufficiently accurate and consistent to perfectly execute those perfect instructions.

But that's a topic for another day.

• Digg This!
• del.icio.us
• Technorati
• StumbleUpon
• Reddit