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.

Incorrect subcarrier

I noticed that you've got the NTSC colour subcarrier wrong, its 3.58MHz not 30Hz as you state. The reason for the 30/1.001 frame rate is to do with colour information (at subcarrier frequency) being interpretted as lumniance information by B&w tellys (as they don't know better), with 30Hz frame rates the dot pattern created is a lot more obvious with than with the slightly reduced frame rate. I'm in the process of versing a better explanation for the NTSC page as its kinda glossed over there as well. I haven't edited the page as I'm not sure how much detail you want to go into here... its possibly better just to link to the explanation on the NTSC page (when I've written it!!).

Cheers,

Richard (Rvodden 19:06, 27 Aug 2004 (UTC)) - 27/08/2004

Resolved

Now says 3.57954545 MHz ~Kvng (talk) 19:17, 23 August 2021 (UTC)

bad math or datum?

A friend reports:

The wiki has some inaccurate info!

"the 3.58 MHz (actually 313/88 MHz = 3579545.45 Hz) color subcarrier"

Please note that 313/88 = 3.556818182, therefore the 313 and/or 88 numbers must be rounded from the actual value(s)!

That's off by almost 2.3%, so my guess is that the error is in the numerator. Multiplying it back out, I get 315/88, so maybe it is a typo?

I'll leave it for someone who knows this stuff to correct the text.

Google shows enough responses for 315/88 color that I went and fixed it. --Damian Yerrick 21:20, 19 November 2005 (UTC)

Different guy here; maybe I'm doing this wrong, editing someone else's comment, but the freq. is 3.579545, not 3.57954545.— Preceding unsigned comment added by 67.86.73.92 (talk • contribs) 18:36, 17 April 2011 (UTC)

It's actually 3.57954. I have updated to side step any disputes about how many significant digits to include. ~Kvng (talk) 19:38, 23 August 2021 (UTC)

Needs cleanup

I can appreciate that this is a complex field, but this article is virtually incomprehensible to the layperson right now. It needs some introduction and context, and more definition of terms. Perhaps a chronological approach would make it easier to explain? Start with who invented it, then add on each layer of complexity as people started adapting the technology? I wish I understood this well enough to edit it more myself, but I'll help where I can if some of the experts can polish up the substance. — Catherine\^talk 17:15, 19 September 2005 (UTC)

Agreed. Starting out with a concrete example might help. I.e. a specific kind of media and a specific encoding of time into the frames, or whatever. --NealMcB 22:39, 13 January 2006 (UTC)

• A half-decade later, and it reads pretty well (although I do admit to being a video/film engineer), and the intro gives a decent summary of timecode's purpose and applications. I did notice a shift between US-English and UK-English in the use of "color framing" versus "colour framing" in the same section. The YouTube music video "explosion" and affordable HDTV camcorders has created a lot of interest in this and related topics. Just judging from my Yahoo!Answers Q&A experiences, technical writing with an eye for keeping things layperson-friendly is the way to continue in this area. — DennisDallas (talk) 16:10, 3 April 2011 (UTC)

almost a decade on, & there's *still* nothing about who invented it, or when, or how, or how long it took for smpte to ratify it & for manufacturers to start working on incorporating it- VITC, extra audio channels, miniaturising the generators & readers, doing useful things with the user-bit area, & so on. I might have to dig out my robinson (the bible on VTR) where there's a good chapter on tc.

& the part about it leading to the development of non-linear systems is so wrong that I don't quite know where to start. if anything, smpte tc being carried over into non-linear production is a legacy of past workflows- there is so much more scope for attaching metadata to file-based content that tc begins to look positively crude & dated.

duncanrmi (talk) 21:12, 22 December 2020 (UTC)

So impatient!! :) DBaK (talk) 22:20, 22 December 2020 (UTC)

Anyone can edit. Feel free to add the missing information from the sources at your disposal. Also, anyone can complain. If that's all you're up for we're OK with that. ~Kvng (talk) 14:50, 26 December 2020 (UTC)

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

subtitle timecodes in relation to drop-frames

Nice article, but some clarification would be good.

I'm writing scripts to convert subtitle files between various formats (and perhaps framerates), so i need to be clear about the practical difference between 30 fps and 29.97 fps.

What does this mean: "only timecode frame numbers are dropped. Video frames continue in sequence."

Where are drop-frames used? Analog broadcasts for NTSC TV receivers, yes. But what about Digital broadcasts, and DVD video?

[I live in Australia and work with video producers in Europe, so only occasionally come across a video at 29.97.]

--Jim Hill au (talk) 00:01, 17 December 2007 (UTC)

Timecode is in HH:MM:SS:FF. Because NTSC video presents slightly less than 30 frames each second, there are sometimes 29 only labeled timecode frames (FF) in each second (SS). ~Kvng (talk) 19:48, 23 August 2021 (UTC)

You are counting from 0, so there are always 30 frames, from 0 to 29, drop, non-drop, integer, fraction framerate, multiplies of 30, all of them. As for drop-frame it is not usable because it starts accumulating 1 additional frame every 9 hours 15 minutes. Valery Zapolodov (talk) 16:05, 30 August 2021 (UTC)

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)

Obsolete video stuff

The stuff about video tape editing seems pretty irrelevant right now, outside of a history section. I'm not sure about the claim that in an all digital system you can't decode timecode before the frame has passed - surely modern computers can do this without any kind of lag. I came here to learn about timecode and this all seems rather out of date 78.17.11.233 (talk) 01:04, 30 September 2018 (UTC)

In an all digital system there is rarely any SMPTE timecode. There is a timestamp on each frame or audio sample. This could be considered a form of timecode and the Timecode article is definitely a bit slim. ~Kvng (talk) 02:46, 24 August 2021 (UTC)