Time Code and HD cameras

Time code, while seemingly pretty straightforward is actually ripe for many a disaster if you're not ready for them. These days, for as many different HD formats and time bases as there are, there are things that can go wrong with your time code - synced cameras that keep drifting apart despite re-jamming every hour or two, time code that randomly dropping frames, audio drift on master tapes, etc. I've been researching this for awhile and as usual, because of the abundance of information and conflicting points of view out there it's difficult to assess what's really at the root of some of these problems.

First and foremost, time code errors can be rectified in post (if you're willing to spend the time/money), video SYNC (Gen Lock) problems cannot. Errors in video sync result in a damaged recording that cannot be fixed - ala' the dreaded "green frame". That said, a general rule of thumb is NO sync is better than bad sync.

Aren't time code and gen lock one and the same? This seems to be a topic of endless debate but I'd say they're 2 faculties of the same function. Time code is the clock data which is recorded parallel to picture information. This gives each frame an exact location and address. Time code is frame accurate but not all camera's internal generators run at the same speed or even run at a perfectly consistent speed. This causes drift when syncing multiple cameras or syncing a camera's time code to an audio recorder's time code. This is why cameras and devices get jam synced - to create a singular time code for the entire recording. In situations where jam syncing isn't accurate enough, you can use an external time code generator with a very stable oscillator such as a Clockit box to ensure frame accuracy. Gen Lock works WITH time code in that it locks the camera's phase (start of picture scan) TO the time code ensuring that all synced cameras are scanning and laying down picture information at the exact same time. By my understanding, that's the simplest way to explain and differentiate the two.

Not only does time code provide an accurate address for picture information, it also allows for picture and sound information to sync up. Here in North America, our electrical power runs at 60 cycles per second (60 Hz). Because video and sound are electrical recording media, they must operate in reference to one of the various electrical currents - be it 50 Hz in Europe or 60 Hz here in North America. So if the current here in the states is a full 60 Hz then why do our cameras and recorders reference 59.94 Hz? What does this relationship have to do with 23.98 and 29.97 time code bases?

In regards to this peculiar phenomenon, this is where the confusion comes from. Alternating current here in North America is a solid 60 cycles per second. That was established before television technology was invented. When black and white television became widely available, the frame rate was a solid 30 fps in reference to the 60 cycle AC. With the advent of color television some years later, engineers wanted to maintain compatibility with monochrome sets but the color portion of the video signal required an additional 0.3 seconds to transmit. Sync was assured with the creation of Drop Frame Time Code, which throws out occasional time code labels effectively slowing the time code reference to 29.97 frames per second. This new frame rate needed a new electrical reference and this became 59.94. 29.97 multiplied by 2 equals 59.94 interlaced frames traveling on 60 cycles per second electrical current. This whole notion of 29.97 and 59.94 is an analog NTSC issue and actually does not apply to HDTV images. Because HDTV is digital and not analog, there is no reason HD images can’t run at a solid 24 or 30 fps in reference to the true 60 Hz electrical current. The unfortunate reason HDTV must continue to reference 59.94 is more Legacy Baggage, an attempt to maintain compatibility with existing equipment. When designing the new standards, the Society of Motion Picture and Television Engineers decided that there were still far too many displays and engineering setups that are incapable of dealing with images other than 29.97 or it's derivatives. Because of the existing equipment legacy, they decided to play it safe and stick with 29.97 and 23.98 fps even though it’s now totally irrelevant. Unfortunately, it seems we’re stuck with it forever.

This is of course an overly simple explanation coming from a person with little formal engineering training. There are some good articles on Wikipedia regarding SMPTE time code. Another great resource is the SMPTE website.

So why do some cameras actually record 24 fps and not 23.98? Why do some cameras say 24 fps when they are actually running at 23.98? As you can see, this gets complicated quickly which is why communication between camera department, sound department, and post is so vital.

So how does these video time code bases relate to sound and picture sync?

Despite the fact that a good deal of digital production will be shot in 24p, there's a good chance you're going to encounter audio recorders in the field that don't support 23.98 time code. These devices' time code base is 29.97 which is also the time base for HD cameras that do not support native 24p recording (HDV cameras, Varicam, HDX900, etc.) If that's the case, you have nothing to worry about because the time code will be identical. In the event you're shooting native 24p, how do you marry 23.98 to 29.97? It's actually surprisingly simple and there is a fantastic article on how this works at Digital Cinema Society. To summarize - TIME IS TIME. There are no real frames in audio so all frame rate affects is TIME CODE COUNT. 23.98 and 29.97 will match each other perfectly because they both reference 59.94 Hz. I would definitely recommend reading the DCS article which has a much more thorough explanation than you'll find here. And if you want more, here's another excellent article of how time code works in relation to electrical frequency.

In a nutshell, 29.97 matches up to 23.98 but 29.97 does not match up to 24 without introducing 3-2 pulldown or resampling the audio by .1%. This is because 24 and 30 are based on 60 Hz and 23.98 and 29.97 are based on 59.94 Hz which is the true frequency of our electrical current here in North America. What is Hz? Hz is a unit of frequency (events per second) or TIME. It is a time base so this explains why 24 won't sync up to 29.97 - they are referencing 2 different things. What this means is that 23.98 and 29.97 can not only be used together but can also be cross-jammed. When cross jamming however, only the 1st frame of every second will be the same to account for the different time base. The hour, minute, and second columns will all match up perfectly.

Here's what can go wrong: production is planning on shooting HD but doing a film out so DP insists on shooting 24fps because he thinks that it SHOULD result in a frame accurate film print. If sound is 29.97 and you're recording audio to camera tape, you're setting yourself up for sync problems because of the inherent time base discrepancy. If audio was sampling at a pure 60 Hz (48.048 KHz) and your post environment was at a pure 24 fps (including the offline), you could get away with shooting at 24 fps but the minute you enter the 23.98/29.97 world you're in for trouble. The simple solution - always run cameras at a safe 23.98fps and keep your audio time base at 29.97 (or if you can, 23.98) and you should be able to keep both perfectly synced without ever having to re-time or introduce pulldown to compensate. The Digital Cinema Society article I linked to explains this perfectly. Also, a well known engineer and audio recordist named Wolf Seeberg has written a lot of very useful books and articles about this.

Here's something else that's important: in order to gen lock, HD cameras use tri-level sync as opposed to bi-level which is what standard def cameras use. To understand video sync problems with HD cameras, you've got to understand how tri-level sync works.

A few definitions (taken from Digital Cinema Society):

Tri-Level Sync: High Definition video uses what is called Tri-level sync. This signal consists of a three level sync pulse (0 V Blank, -.3 mV pulse, +.3 mV pulse) followed by the video image data. This signal is repeated every scan line to make up the video frame. HD cameras do not gen lock or reference to a NTSC/PAL video sync signal.



Bi-Level Sync: The NTSC video signal consists of a Blanking Pulse (sync pulse + color burst + back porch) followed by the video image data. This signal is repeated every scan line (525 NTSC, 625 PAL) to make up the video frame.

This post isn't so concerned with bi-level sync (or anything SD for that matter) so but I thought I'd list a few very common problems that occur with tri-level.

-Bad Cable can ruin your day and is often overlooked as the culprit. With Clockit boxes especially - check you cables. Time code and sync must be transmitted flawlessly to work their magic and if you've got crummy, beat up cables, there's a good chance they're causing the problems you're experiencing. I'd say generally, checking cables is a good place to begin for any engineering trouble shooting.

-Green Flash Frames: Here is the best definition I've been able to find of what the green frame is (from Peter Gray's amazingly informative website) "If there is any interruption to the external Tri-level sync fed to the camcorder, a green masking frame is inserted whenever there is not enough information to build and display a normal frame of image. The problem is made worse by say, an intermittent problem in a faulty cable or connector, that causes the system to flip flop back and forth between internal and external. So if any interruptions to the Tri-level sync feed is not detected and corrected at the time of shooting, the editor may be presented with unsalvageable material in post. Special care needs to be taken to make sure all external sync feeds are 100% clean and 100% continuous to avoid possible "green hickup" problems. The sort of things that can cause an interruption to the sync feed is, for example, a failing battery in the Ambient or Denecke Tri-level "Lockit" box, or a faulty cable or connector, or similar." Over at CML there is endless discussion about this phenomenon and what to do about it (like this). Many engineers insist that gen lock is not necessary on HD shoots, time code is enough. Others swear by it. The green flash does not seem to happen though from TC alone, it is only when introduce external tri-level sync as well that this issue shows its ugly face.

And here are some general time code related issues as well.

-Non-Drop Frame vs. Drop Frame: Generally when working with HD cameras, use Non-Drop for all time code. Though you can use Drop Frame, you are less likely to have sync/drift issues if all cameras and recorders are running jam synced Non-Drop time code. NOTE: that 29.97 and 23.98 are the frame rates that were derived from Drop Frame. These days though, that doesn't necessarily mean that those frame rates actually drop frames. They now come in drop frame and non-drop (NDF). Use 29.97 or 23.98 NDF.

-Audio Sync issues: I think I pretty much addressed this above. If shooting single system, make sure to shoot at 23.98 and keep your audio at 29.97 and you should be good to go.

-Multi-cam drift: Camera's internal time code generators can be wildly inconsistent. Jam in the morning and after lunch. More if necessary. Some engineers say that TC without without gen lock won't hold for more than 2 hours so if that's the case, do it ever few hours or so. If that doesn't hold, try a Denecke SB-T or an Ambient Clockit Box.

-Post Production software and operator errors: Is the project the correct time base for the media? 3-2 pulldown or 3-2-2-3 pulldown? 48 KHz or 48.048? I've heard of Avid software issues scrambling time code and doing weird things to it like automatically regenerating after a specific frame. Software is buggy and post systems are complicated to set up. There's a lot of things that could be wrong on their end.

That's about all I've got for this. If there are mistakes in this post, please bring them to my attention. I know some of this info is very basic but the reason I do this blog is to provide a place to get this kind of information. It's out waiting to be discovered but you really have to do a lot of digging to get it. Since I've taken the time to dig, I might as well share what I've found here. Enjoy!