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

Wrong number?

This meant that an "hour of timecode" at a nominal frame rate of 29.97 frame/s was longer than an hour of wall-clock time by 3.59 seconds ...

1 hour at 30 fps equals 108,000 farmes; 1 hour at 29.97 fps equals 107892 frames - the difference is 108 frames. 108 frames at 29,77 fps take 3.60... seconds - so I am puzzled about the 3.59 seconds value. 31.18.215.19 (talk) 21:51, 19 February 2013 (UTC)

Resolved

The math is 3600-3600/1.001 = 3.596403596403200712527678... So it should be reported as 3.6, 3.60 or 3.596... The article currently says 3.6 so we're good. ~Kvng (talk) 20:02, 23 August 2021 (UTC)

You used some kind of very bad calculator, without infinite precision arithmetic :( . It is actually just 3.596403 https://www.wolframalpha.com/input/?i=3600-3600%2F1.001 As for the other value, if you were to use 108000/29.97 it will give you 3.603 seconds and 108000/30*1.001 will give you perfect 3.6. Valery Zapolodov (talk) 20:58, 18 September 2021 (UTC)

Valery Zapolodov, I used Python. I thought that was a good calculator. ~Kvng (talk) 12:34, 21 September 2021 (UTC)

Well, it is not, though you can use pyGMP. https://stackoverflow.com/a/11523077/11173412 Though better to outright use GMP in C. Or even better this or Wolfram Alpha: https://github.com/lcn2/calc/blob/a86d62998263a8d7fa76cd89c59314b9aaf4b72e/cal/factorial2.cal#L630 Valery Zapolodov (talk) 13:20, 21 September 2021 (UTC)

Wrong history

The history statement is incorrect in the HISTORY section of the SMPTE Timecode page. How do I correct it? Cbaudio (talk) 04:45, 30 July 2023 (UTC)

The History section is currently unsourced. The first thing to do is find some reliable sources that can be used to support corrections. ~Kvng (talk) 14:05, 4 August 2023 (UTC)