Talk:SMPTE time code
From Wikipedia, the free encyclopedia
 |
This article is within the scope of Wikipedia:WikiProject Filmmaking, an attempt to better organize information in articles related to filmmaking. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion. |
| B | This article has been rated as B-Class on the assessment scale. |
 |
This article is within the scope of the Professional sound production WikiProject, a collaborative effort to improve Wikipedia's coverage of the technology, equipment, companies and professions related to professional sound production. If you would like to participate, you can visit the project page, where you can join the project and see a list of open tasks. |
| B | This article has been rated as B-Class on the assessment scale. |
Contents |
[edit] 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
-
[edit] 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)
[edit] 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.
[edit] 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
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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
[edit] 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)
