Talk:SMPTE timecode

Correcting time codes

I don't believe most devices could correct the time codes. This prevents editing to the same frame. That's why I deleted the following text:

Most timecode processing devices check for internal consistency in the sequence of timecode values, and use simple error correction schemes to correct for short error bursts. As a result, the boundary between discontinuous timecode ranges cannot be determined exactly until several frames of code have been read after the timecode boundary. User:Ray Van De Walker

Ray, I can assure that they do. You cannot ever use the current frame's LTC for editing: by the time you've read it, the frame's already gone by, and it's too late to make the edit. So you use the number of the frame before, and infer it.

And if you're going to do that, you might as well use the previous N frames, and do a "flywheel" filter to reject bad values. Which is what LTC readers do. you can do a Google search for "timecode flywheel" for more on this.

Thanks, Ray

Frames per second

From the article:

Some of the bits also tell whether the timing is for 24 frames/sec (film), 25 frames/sec (European video), 30 frames/sec (black & white NTSC (archaic)), or 29.97 frames/sec (30/sec drop-frame color NTSC).

Wrong. There are colour frame and drop-frame bits, but they don't tell you the basic frame rate. Indeed, the drop-frame bit is not necessarily meaningful in a 25 fps timecode. However, you can always tell the underlying frame rate, as you are either using an LTC decoder (in which case you can get the rate from the underlying bit-rate, or from watching the rate of arrival of decoded frames, or decode it from watching the frame count rollover) or are using a VITC decoder (in which case you either already know the rate, or can read it from the hardware, or infer it from the rate of arrival of code frames, or decode it from watching the frame count rollover)

Needs careful proofreading

Note: this is a seriously complex field, with a mixture of good and bad engineering over many decades combined with a certain amount of retconning, with different standards being bastardised and re-combined in different parts of the world. This needs lots of proof-reading and going back to references to get right.

Timecode differences in Production and Presentation Domains

One of the important concepts not mentioned is that timecode can be used in two different domains. In production, (editing) timecode is principly used to identifying video frame sequences, but in (master control) presentation, the focus is upon synchronizing activities along a timeline. Part of the beauty of the notion of timecode is that is can be used as a good enough, but not perfect, bridge between the production and presentation aspects of television. Where this is most noticeable is in timecode math:

• In production, if a clip starts at 01:02:03:04 and ends at 01:02:03:05, the clip is two frames long

 01:02:03:05 - 01:02:03:04 = 2 frames

• In presentation, if a clip starts at 01:02:03:04 and the next one starts at 01:02:03:05, the clip is one frame long

 01:02:03:05 - 01:02:03:04 = 1 frame

Until recently, as production and presentation were essentially separate, so this difference was not significant. But as new technologies start to move timecode data across these domain, it is more important to acknowledge and accommodate the expectations of users in different domains. Adamelk

Flywheel

I have revered this edit. My understanding is that flywheel synchronization is for error handling. If there's a dropout in the timecode due to error, a reader can keep reporting timecode filling in the missing code with flywheel reports based on an internal clock running at the rate prior to the dropout. I'm afraid I have not yet been able to scare up any sources to verify this. ~Kvng (talk) 15:07, 1 May 2026 (UTC)

It's two facets of the same algorithm. Both knowing what timecode a frame will have before you've parsed the whole frame and the dropout datection/compensation are part of it. You must, in realtime applications, be in phase-locked ascending sequence for a timecode to be valid, and you cannot read a frame's timecode until the frame is already past, unless you have a valid flywheel and are willing to believe the sequence will continue. The whole thing has been called the 'flywheel' since at least the 1960s, well before the adaptation of aerospace timecodes to create what became SMPTE timecode. See https://www.google.co.uk/books/edition/FM_Handling_and_Analog_to_digital_Conver/0M2rjkV9WesC?hl=en&gbpv=1&dq=timecode+flywheel+nasa&pg=PA9&printsec=frontcover See also this: https://tf.nist.gov/general/pdf/153.pdf for flywheeling radio timecodes. — The Anome (talk) 22:24, 1 May 2026 (UTC)