Talk:SMPTE timecode
![]() | This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
|
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

- 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)
Leap Seconds?
I'm unclear on whether SMPTE ever records actual UTC timestamps in media. If so, what happens during leap seconds? Is a timestamp of 23:59:60 ever recorded? --NealMcB 22:39, 13 January 2006 (UTC)
- My impression is that SMPTE is a purely relative time coding format, ie. doesn't record UTC time or similar. (Time zero in SMPTE will mark the beginning of either some recording session, the finished film reel or similar.) Jiifurusu 22:57, 22 January 2006 (UTC)
- SMPTE may be indeed syncronized to real time (UTC, "wall clock time"). However, the time code gets resynced at regular intervals (typically daily at midnight). Clock inaccuracy in video/studio is also a slight problem; after 24 hours, the equipment will also be likely to be a few frames off the theoretical correct frame number. --Klaws 16:55, 10 May 2006 (UTC)
- Actually, the time code is typically resynced at 0215. Most broadcasts run through midnight and top of the clock is a busy time. Adamelk (talk) 05:13, 17 July 2010 (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
Frame rates > 30?
Can anybody confirm if source material in 480p, 720p, and/or 1080p formats uses timecode with frame numbers 0..59? The article mentions only frame rates up to 30 Hz. Thanks, Andrwsc 00:13, 17 November 2006 (UTC)
-- Yes. 720/60 cameras produce timecodes up to frame 59. There are 59.94 (double 29.97) rates on most of these cameras and presumably there is some variation on drop frame to deal with this; I'm not sure exactly what it is. —Preceding unsigned comment added by 91.84.66.6 (talk) 18:31, 19 September 2008 (UTC)
I can confirm this; the drop-frame scheme that seems to be used (at least on the JVC GY-HD series cameras) drops four frame numbers from the start of eligible minutes. This makes perfect sense; double the frame rate and double the dropped frame counts, but I'm not sure if this is in the SMPTE or EBU specs. I presume it is.
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)
"Studio"
The meaning of "studio" isn't clear to the general public. What is done in a studio, besides studying? Unfree (talk) 07:51, 31 August 2009 (UTC)
Cooperating standards
What distinguishes cooperating standards from other ones, and with what do they cooperate? Unfree (talk) 07:56, 31 August 2009 (UTC)
Question
Quotation: "That is, drop frame TC drops 2 frames every minute, except every tenth minute." In the very first minute (starting at 00:00:00:00) no frames are dropped. Should this be mentioned for clarification? Perhaps one could simply write "except minutes 1, 11, 21, 31, 41 and 51 of every hour" or something like this to avoid any misunderstanding.31.18.163.224 (talk) 20:27, 14 February 2013 (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)

- 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)
- All unassessed articles
- C-Class film articles
- C-Class filmmaking articles
- Filmmaking task force articles
- WikiProject Film articles
- C-Class Professional sound production articles
- High-importance Professional sound production articles
- WikiProject Professional sound production articles
- C-Class television articles
- Mid-importance television articles
- C-Class Broadcast engineering and technology articles
- High-importance Broadcast engineering and technology articles
- Broadcast engineering and technology task force articles
- WikiProject Television articles