Talk:SMPTE time code
|
|
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
=======================
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)
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.
===========
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