You’ve worked day and night for the past two weeks, composing a music score for a film project that could really make your career. You’ve paid meticulous attention to scene transitions and sound effects while reviewing your VHS work tape, and now your music fits the picture with absolute precision.

But the director has unexpectedly appeared at the editing facility to see the finished music synchronized to film. Suddenly, your music cues are a little off the mark and the climatic explosion is two seconds early. Everyone is glaring at you. You have blown it. Big time. And just before you run screaming out of the editing suite, you awaken and realize it was all just a bad dream. You don’t even begin the project until next week.

Unfortunately, the dream could be a prophecy. At some point in your career, a synchronization issue may arise that could determine the ultimate success or failure of a project. Luckily, a complete understanding of time code can prevent this nightmare from becoming a reality. Time code can be extremely confusing—and many manufacturers still don’t fully get it, either—so let’s clear the air on some common misunderstandings about synchronization and, in particular, SMPTE time code.

A BRIEF HISTORY OF TIME CODE
Time code was originally developed by the U.S. military to synchronize missile test firings in the early 1950s. A system was designed that divided each second into segments or frames—typically 10, 30, 60, or more per second. The code was transmitted in the form of a modulating audio tone (similar to the sound of a modem) to devices which could interpret the incoming data and trigger simultaneous launches.

Eventually, a 30 frames per second (fps) time-code standard emerged. This standard was based on the television-field rate, which was half the stable—and commonly available—U.S. wall current of 60 Hz AC. In 1981, the Society of Motion Picture and Television Engineers, or SMPTE, officially defined and adopted the 30 fps standard as a method of synchronizing various film, television, and audio elements. A 1986 revision to the standard, now commonly referred to as SMPTE, refined the code so that each of the 30 frames includes a digital word containing 80 bits of data that allow information such as tape location, reel number, and session dates to be stored and recalled.

Time code provides us with the vital location and timing information of a program, and it is expressed as hours, minutes, seconds, frames, and sometimes, subframes. (Occasionally, subframes will be displayed in a computer sequencer, but video and television are synchronized only to the nearest frame.) A typical time-code location appears as 01:17:45:12 (one hour, seventeen minutes, forty-five seconds, and twelve frames). If subframes are indicated, they are designated by a period and two digit number following the frames (01:17:45:12.67 or twelve frames and sixty-seven bits).

TIME-CODE FORMS
Time code is transformed into different forms for different applications, but each form adheres to the same basic rules of counting time. Therefore, each form is compatible with the others for synchronization purposes as long as the proper translation hardware is connected. Longitudinal Time Code (LTC) is the code that a MIDI interface or time-code generator spits out of its SMPTE output jack. It is characterized by an audible, warbling tone. LTC is used when you want to stripe a tape with time code and then feed it back into your MIDI interface for locking your sequencer to an audio or video recorder. You can also use LTC to print time code on the linear audio portion of a videotape. However, most broadcast devices and digital multitracks have a dedicated address track that outputs LTC and saves you from sacrificing an audio track for time code.

If you are dealing strictly with audio recording and will not be synching to video, you will probably only need to know about LTC and MIDI Time Code (MTC). MTC is generated from a MIDI device using a selected master time base (internal reference, incoming SMPTE code, etc.) that is transformed into timing data that can be transmitted through a MIDI cable. (MIDI cannot transmit audio signals, so LTC is not suitable for MIDI applications.) This data carries basically all the same relevant information about the current hour, minute, second, and frame location that LTC does, only in a form that is recognizable to a MIDI device.

A third form of code is Vertical Interval Time Code (VITC). This form of time code is actually buried into the image frames of a videotape (see the sidebar "Video Basics). VITC must be recorded onto the videotape dub simultaneously with the video image. Unlike LTC, which can be laid to an audio track at any time, VITC cannot be dubbed in at a later date.

However, integrating time code into the video signal has distinct advantages over LTC, because VITC does not require that you use an audio track on your recorder or VTR to store the code. Also, VITC can show—through a window burn time-code display recorded directly onto the video tape—the exact time-code location of a single video frame. This means that you can still read location numbers when the video is paused or when you're slowing scrolling through a scene. Because VITC is perfectly synchronized to video images, it is the preferred source of code when scoring to picture, even if it is often converted to LTC and MTC for the practical use of the composer or sound designer.

TIME-CODE RATES
A lot of confusion with time-code originates from a lack of understanding of this fundamental rule: time-code rate and type are independent of each other. Learn this, and don’t ever forget it. Go back, and read it again. You must know the difference between time-code rates and types and how to effectively communicate this information when working with others.

The rate of time code refers to the speed of the code or how many frames pass within a second of real time. There are only four rates (speeds) of time code: 30, 29.97, 25, and 24 fps. Most music-only productions—and some film-scoring projects—in the United States and Japan employ 30 fps code.

Way back in the days of black-and-white broadcasts, North American television ran at exactly 30 fps. After color TV was introduced in the 1950s, however, 30 fps was replaced by the slightly slower-running 29.97 fps rate. At the risk of oversimplification, this 0.1 percent speed modification allowed for easier color synching of new programs and the reproduction of older black-and-white programs with existing hardware. Today, all television and videotape equipment runs at 29.97 fps without exception.

The speed of time code in Europe is exactly 25 fps (called EBU time code after the European Broadcasters). This standard is because European video and television also runs at exactly 25 fps, making their broadcast time calculations based on time-code information very easy.

The speed of motion picture film is 24 frames per second, and most film shot at 24 or 30 fps is necessarily "pulled down," or slowed, to 23.976 or 29.97 fps when transferred to videotape. (Most film composers work from a videotape running at 29.97.) The only exception to this is if you happen to be one of the few composers who still scores to the actual film stock.

TIME-CODE TYPES
If you work primarily with NTSC video, the standard in North America and Japan, there are two practical time-code rates: 30 fps and 29.97 fps. So what’s the difference again? Remember, 29.97 code runs through frames at a slightly slower speed than 30 code. What does that have to do with time-code type? Well, one of the advantages of having an exact number of frames pass within a second, as with 30 fps or 25 fps code, is the ability to use the SMPTE counter as a measure of actual running time (also referred to as wall-clock time).

For example, at a rate of 30 fps, if a program starts at 01:00:00:00 (one hour) and ends at 01:01:00:00 (one hour, one minute) on the SMPTE display, the duration of the program is also exactly one minute long by the clock on the wall. However, with a time-code speed of 29.97 fps, when the elapsed wall-clock time is exactly one minute, the SMPTE display will read 00:00:59:28 (59 seconds and 28 frames). And after one hour of real time, the SMPTE display will only read 00:59:56:12, or 108 frames short of one complete hour. Obviously, a 29.97 fps rate can be problematic for broadcasters, who require exact program length information for precision timing of television commercials that are billed out by the second.

To reconcile the discrepancy between 30 fps and 29.97 fps in regard to wall-clock time, drop-frame code (or compensated-mode time code) was developed. Basically, drop-frame code recounts frames to allow the 29.97 rate to "make up" the 108 frames it falls behind every hour of real time. This feat is accomplished by skipping the two frames numbered :00 and :01 at every one minute interval, except the interval that falls every ten minutes. (No actual video frames are omitted, only the numbers used to identify each frame are altered.)

Using a 29.97 drop-frame rate, simply referred to as "29 drop" or "29d," means that the SMPTE display will be a near-accurate running record of the actual elapsed time. In other words, the time-code display now closely matches the wall clock, and the broadcaster won’t have to refund advertising money because the last two seconds of an automobile commercial was clipped off just before the six o’clock news. The most that the 29.97d SMPTE display will ever be off from wall-clock time at any given point in a program is two frames, or 66.73 milliseconds. However, continuously running drop-frame code drifts two frames per day, and broadcast facilities must recalibrate every few days to maintain accuracy.

Now, here’s where it starts to get a little tricky, so listen up. Technically, 30 fps code can also exist as two types: 30 nondrop (30nd) and 30 drop (30d). The easiest time code to work with is 30nd; traditionally designated as 30 fps, with no additional letter designation. With 30 fps, the SMPTE display reflects wall-clock time, making it an industry-preferred choice for music production. However, since television and video equipment do not run at 30 fps, a music bed for video created at this speed will not be in sync with the picture. Sorry.

However, if you are working on a music-only project and will not need your track to synchronize with video at a later date, you are clear to use good old 30 fps code. Your sequencer will happily chase along to whatever code you feed it, and the SMPTE display will neatly match wall-clock time. Also, MIDI-event editing is easier because you don’t have to take into consideration that certain frame numbers are missing in the event list, as with 29.97d code.
A rare and mysterious code is true 30d, running at exactly 30 frames every second, and employing the same frame number skipping scheme as 29.97d. You'll probably never encounter this type of code, as it has little use in the post-production or music worlds.

WARNING! WARNING!
A nagging problem within the time-code community is the unintentional misnaming of the various codes. For instance, the term "30 drop," or simply "drop," is sometimes used when someone is actually referring to 29.97d. Erroneous time-code designations are ocassionally propagated by manufacturers who fail to fully understand the distinctions themselves—or at least don’t always make the differences clear in their devices and manuals. The MTP Console software for Mark of the Unicorn's MIDI Time Piece II, for example, offers four choices for time-code generation: 30, Drop, 25, and 24. It is not made clear what "Drop" is in this context. A call to MOTU verified that it is 29.97d code and also revealed there is no choice between drop and nondrop generation at 29.97 fps.

The manual for Roland's DM-800, although correctly listing the four available code versions of 30 fps and 29.97 fps (drop and nondrop), incorrectly names both 29.97 types as "30DF" or "30ND," which is the same identification given to the 30 fps codes. In sort, four different time-code versions are sharing two names. However, Roland does state that the 30DF version of 30 fps is "usually generated only by mistake." Thanks for the clarification—and manufacturers wonder why users are confused!

To confuse matters even further, Emagic’s Logic offers the seemingly useless and problematic option of 30d code. After getting conflicting stories from Emagic, I was finally told that Logic's European programmers, being more familiar with EBU code than SMPTE, simply made all combinations of time-code rate and type available.

In addition, Logic offers an auto-detection mode that attempts to identify the rate and type of incoming time code. This is a feature that should not be trusted. On one occasion, Logic told me that incoming LTC from a videotape (29.97 fps without question) was running at 30 fps. Wrong. The potential for incorrect readings is great, especially if the master device is an analog recorder (almost all analog recorders suffer from transport speed inconsistencies). Fortunately, Logic's auto-detect feature can be deactivated.

Sometimes, a timing problem can be traced to the fact that all SMPTE generators are not created equal. Some MIDI interfaces, for example, should not be relied as stable sources of time code. They’re just not designed for it. Put your trust in video-referenced devices from companies such as Adams-Smith, Timeline, and Horita, or the code generated from MDM address tracks.

You should also be aware that there can be subtle differences between the internal clock speeds of time-code generators and computers. A case in point: if you have ever worked with drum loops, you know how tedious it can be to get a loop to retrigger smoothly and musically so that the loop grooves with the time center of the sequencer. Unfortunately, if you attempt to lock your sequence to questionable time code (from an unstable generator, playback from an analog recorder, etc.) your loop may cease to retrigger correctly. This frustrating glitch occurs because the new master time base is not the same as the internal clock of the computer that you were referenced to when you fiddled with your drum loops.
Could the internal clock of the computer be slightly unstable? That’s possible, too. I had to make an approximate 0.4 bpm change in my sequence tempo to get a loop to play correctly if I first tweaked out the loop in my computer and later locked it to time code generated by my MTP II.

PROBLEM SOLVERS
But don’t let these horror stories frighten you. Here are some guidelines that can sort out most of the potential code problems you'll encounter.

For starters, always use the originating time code as the master code for every device you want to synchronize. Remember the drum-loop problem? The work around for that situation is to tweak your loop while the computer is chasing the time code from the recorder, VTR, or synchonizer that will be your master time base, instead of relying on the internal clock of the computer. This is called resolving to the common reference.

When a device is resolved, it will speed up or slow down to follow exactly the time code being referenced. It doesn’t matter if you are trying to get a loop to groove to tape or match a music score to the designated hit points on a video dub. If you resolve your devices to the same master time-code source, you will eliminate most synchronization problems.

For example, if you stripe a 24-track, analog tape with 30nd code from an Opcode Studio 4 interface, always use that code for the rest of the project. It doesn’t really matter whether the MIDI interface generated code a little fast or slow or if the multitrack recorder was running a bit faster than normal. The point is, this code is now the master reference and every other device must be resolved to it. A slaving device will chase the code exactly as it was originally recorded, minor imperfections and all and will always be in sync with your master.

If you are going to score music to a video, you can use the master time code provided on the videotape, which is called the house sync, as your time base. Be sure to let the video-editing house know what type of video format you work with and any preferences you may have regarding time-code generation. I typically ask for a Hi-fi VHS tape with time code on both the linear tracks and the left channel of the Hi-fi tracks. (Any production audio is recorded onto the right channel of the Hi-fi tracks.) Of course, the type of code (drop or nondrop) being used for the project is usually decided by the director or editor. You already know what the rate will be, right? Ready for a pop quiz?

Once again, it is critical that you stick with the common reference to ensure your music will always be in sync with the picture. Let’s say you are given a videotape with 29.97d code on it and are asked to compose a 45 minute score. You set your sequencer to 29.97d, view the burn-in window on the videotape, and note all your hit points. You create a beautiful score, using the time code on the videotape to drive your sequencer while you watch the picture. All your hits line up and everything is wonderful. Now it’s time to record the score to tape.

If you mix your score to a time-code DAT machine, you can generate your own code to the multitrack master (or use the address track of an MDM), record the score, and mix—the DAT machine will chase the code from the multitrack. The DAT master can then be easily resolved to the house sync of the picture, and your music will be locked (or genlocked) to each exact frame of the videotape

However, if you mix to a non-time-code DAT, you must resolve the multitrack to video-referenced time code when you mix. This is necessary because your DAT mix will be freewheeling when laid-back against the picture in the post-production studio. But, as long as you are resolved, there will be little noticeable drift between score and picture once you start everything from the right spot (a job for the editing facility). Yet keep in mind that you are running wild. It is only the grace of the stable transports of the videotape players, MDMs, and DAT machines that keeps the sound of the slamming door in the right spot as the hero exits to catch the bad guy.

Time code generated by an MDM address track (like an ADAT with a BRC or DA-88 with a sync card) is rock-solid stable because these are video-referenced machines by design. You can use the internal time code from the MDM address track, record your score, and mix it to non-time-code DAT with excellent results.

A solid, clean source of time code is essential for keeping everything in sync throughout a project. If you wish to transfer house sync from the videotape’s linear track to an analog multitrack, it is likely the code will need to be reshaped. This process ensures that the code will be in the best possible condition when re-recorded, and can be read properly later on down the line. Most MIDI interfaces can regenerate house sync from a video tape to provide clean code for your recorder.
So, what happens if you suspect the time code has gone bad halfway through your project? Should you just restripe the tape with fresh code and find new offsets? No! Don’t ever restripe tape once you have begun a project. That is, unless you never want to be in sync with it again.

When code is not being read properly, it is often due to playback problems with the tape deck rather than a problem with the original recording of the code. Checking cable connections and playback levels, cleaning the heads, or adjusting the tape bias usually solves the problem. Occasionally, a touch of equalization can render the code readable again. However, if equalization seems to be the only fix, it is a good idea to go ahead and regenerate fresh code to a new track. By regenerating the code, all the original timing information will remain intact and match the tracks you have already committed to tape.

If you are using an MDM and you experience a lot of dropouts, digitally clone the tape as soon as possible. During cloning, the error correction process should restore the code to its original condition. If drop-outs persist, try playing the tape in another machine. Swapping decks often buys you that one "perfect" play back that will produce an uncompromised clone.

LOCK IT UP
Dealing with time code can be frustrating and confusing, but it is also an immensely helpful ally. The more you understand it, the better it can serve you. If you have questions, don’t hesitate to ask some accessible audio engineers or video editors for advice and insight. They are usually happy to offer assistance, as long as they know you have a grasp of the basics. So spread the knowledge around. Here’s to living in sync!

Composer/Producer Rob Shrock's original score for Texas Instruments recently won the Telecommunicator’s Corporate Film Image award. However, his greatest joy is being in sync with his wife, Lori. Special thanks to David Crigger and John Johns.

VIDEO BASICS
Wait a minute, how can you have time code mixed in with a video picture? Actually, it's not hard at all. You see, a video image consists of individual frames, or pictures, strung together and played sequentially at a specific rate. An NTSC video frame consists of 525 horizontal lines of colored dots created by an electron beam, or cathode ray, scanning across a picture tube. It takes two scans to create a complete frame. The beams draws the odd-numbered lines first, and then momentarily blanks out while it moves into position to begin drawing the even-numbered lines. Each of these half-images is called a field.

The time span between the drawing of each field, as the beam is blanked out and moving back into position, is called the vertical blanking interval. This interval is used to store timing messages that keep the two interlaced video fields in sync. It also serves as a place to store the VITC (Vertical Interval Time Code) form of time code. Thus, VITC is buried between the two fields of the video frames and remains perfectly in sync with the picture.

SYNC TERMS
So confused about time-code issues that you can't even cruise through the terminology? Then use this handy glossary to help bolster your powers of comprehension.
Absolute timing reference The master time code used to indicate tape speed and position as well as to synchronize various recorders (see house sync).
Black burst A black video signal used as a house sync source.
Burn-in window A visual display of the current time-code location derived from VITC or LTC and embedded into the video image. The window typically appears as a black box in the lower portion of the video screen.
Chase The act of a recorder or sequencer following—or "chasing"—time-code data to sync with a master machine.
Common reference The master time base; usually a video house sync generator or black burst.
Drop-frame A term for the method of "recounting" individual video frames that allows the elapsed time of the SMPTE display to approximately match elapsed real time. This process, also called compensated-mode time code, was developed to reconcile the speed difference between 30 fps and 29.97 fps time code, as related to actual "wall clock" time.
Frame In video or film, "frame" refers to one of the individual still images played back sequentially between 24 and approximately 30 times per second. In time-code parlance, a frame is a digital word interval corresponding to a single film or video image.
Frame rate The speed at which the time code runs (30 fps, 29.97 fps, 25 fps, or 24 fps).
Freewheeling Used to describe a device running wild after synchronization is lost. This situation is usually caused by a large dropout in time code.
Genlocking The procedure of directly locking time code to the actual picture frames of a videotape for perfect synchronization.
House sync The master time-base reference, usually generated by a video facility, that is used by all slaving devices as the common time-code source. The master time base can also be called the common reference.
Jam synching The act of regenerating fresh time code from a synchronizer/generator when the original incoming code experiences a dropout or other damage. The new code is created independently of the original code and is not synchronous.
Nondrop frame Also called uncompensated-mode time code, this process numbers each video frame sequentially. However, unlike drop-frame code, the frames are not recounted to match wall clock time.
Regenerate The act of taking incoming code and creating new time code based exactly on the timing information of the previous code. This procedure is essential when additional code is needed to match the common reference, such as when bouncing code to a new track.
Reshape The act of regenerating time code to regain the square-wave shape necessary for proper translation of the timing information. Also called refreshing, the procedure is often necessary to compensate for signal deterioration when time code is re-recorded in the analog domain.
Resolve The act of controlling the speed of a slave device by continuously comparing and matching the time-code output to the common reference.
Stripe The act of recording Longitudinal Time Code (LTC) onto an individual track of a tape recorder from beginning to end.
Video-referenced When a device is synchronized to the video frame rate.
Wild sync When two devices are running independently at the same time but are not dependently locked together or synchronized.

SMPTE DO’S AND DON’TS

• Do use the shortest, most stable signal path to and from the time-code source when generating or reading code.
  
• Do use an outside track for recording time code to analog tape and, if possible, leave an empty adjacent "guard" track between the code and your music tracks.
  
• Do keep the time-code recording level just hot enough to provide a stable sync source without bleeding onto the other tracks (Between -10 and -3 on the VU meter is typically a good range for analog recorders).
  
• Do stripe a tape in its entirety; do not interrupt the process.
  
• Do resolve all devices to video-referenced time code when scoring to picture.
  
• Do provide yourself at least ten seconds of preroll before your program starts (fifteen seconds is even better).
  
• Do notate your SMPTE rate, type, and offset in your sequence, and clearly label all tape boxes and track sheets accordingly.
  
• Do regenerate code when making analog transfers. In fact, always regenerate code instead of restriping.
  
• Don't change code settings once you’ve begun a project. Stick with one setting from beginning to end.
  
• Don't restripe code, unless you really know what you are doing.
  
• Don't freewheel or jam sync unless it is the only alternative.
  
• Don't refer to code simply as drop or nondrop. Such designations can lead to confusion, due to the fact that 30 fps and 29.97 fps code can exist in both forms, and all types are different.

RESOURCES
SMPTE Made Simple: A Time Code Tutor
By TimeLine Vista, Inc.
tel. (619) 727-3300
fax (619) 727-3620

Time Code Handbook
By Cipher Digital
tel. (800) 331-9066
fax (310) 695-3622

Synchronization from Reel To Reel
By Jeff Rona