Help in understanding drop-frame time code
Isaac Wingfield
timing. We're MPEG guys, and while we've known about drop-frame for some
time, this is the first time we've really had to *understand* it. If anyone
could help, we'd sure appreciate it.
Here's what we *think* we understand, and what puzzles us -- of course, we
could be wrong anywhere along the way:
Drop frame time code counts 30 frames per second, but skips 2 frame counts
every minute, except minutes divisible by 10. In a 24 hour period there are
1440 minutes, so when the time code goes for 24 hours it drops (really it
skips counts) (1440-144) * 2 = 2592 frames, and there are 24 * 60 * 60 * 30
- 2592 = 2589408 frames in the "24 hours."
Given the color subcarrier as spec'd by RS170A, a frame time is ((455/2
cycle/line) * 525 lines/frame)/3579545 cycles/sec = 0.03337599...
sec/frame.
Then the time for 2589408 frames is 86399.925 seconds, or 23 hours, 59
minutes, 59.925 seconds.
So given a dead-on frame rate, marking time using drop frame time code is
about 75 msec per day fast.
What is done in practice when the time code is used continuously,
uninterrupted day after day, to keep the "house time" in sync with real
time (whatever that is - GPS? UTC?)
Are there some longer intervals in which frame counts are skipped (or not)?
Or do such places just run about 3 Hz (of color subcarrier) slow? Or what?
Thanks for any help,
Isaac
Gary Woods
>Are there some longer intervals in which frame counts are skipped (or not)?
>Or do such places just run about 3 Hz (of color subcarrier) slow? Or what?
Yes; there's a whole pretty lengthy list I got in CMX school (we had to watch out for low-flying
Pterodactyls).... there are some exras skipped out there to keep everyghing right. Don't know what
other magic happens, but you can get (we have) a unit to sync local TC to GPS. Presume it fudges as
necessary.
Gary Woods, acting interim web guy, and technician at LARGE
Peter Sjöström
> A colleague and I are trying to figure out some aspects of SMPTE drop-frame
> timing. We're MPEG guys, and while we've known about drop-frame for some
> time, this is the first time we've really had to *understand* it. If anyone
> could help, we'd sure appreciate it.
>
> Here's what we *think* we understand, and what puzzles us -- of course, we
> could be wrong anywhere along the way:
The important thing to understand is that the tape speed is NOT 30 fps in NTSC.
There are only "29.97" frames per second in NTSC TV standard. Any attempt to
use 30 fps timecode is actually an error as the hours, minutes and seconds will
start to drift as time passes. Historically, 30 fps was still sued because they
couldn't easily make electronics that counted "drop frame" timecode, the *real*
way of counting NTSC frames.
Today this is no problem of course, and most equipment can handle drop frame.
I'm not going to check your assumptions, just remember the key here, the tape
is actually NOT 30 fps.
More on http://www.inforamp.net/~poynton/notes/video/Timecode/index.html
I quote "Counting frames at the NTSC frame rate of 29.97 Hz is slower than real
time by the factor 1000/1001, which, if left uncorrected, would result in an
apparent cumulative error of about +3.6 seconds in an hour. To avoid this
error, timecode systems are designed so that on average once every 1000 frames
a frame number is dropped, that is, omitted from the counting sequence. Of
course, it is only the timecode number that is dropped, not the whole frame!"
/Peter
Bill Elswick
wrote:
>What is done in practice when the time code is used continuously,
>uninterrupted day after day, to keep the "house time" in sync with real
>time (whatever that is - GPS? UTC?)
>
What is typically done is to jam sync the timecode at midnight against
an accurate reference.
--Bill
John Fleetwood
>
> A colleague and I are trying to figure out some aspects of SMPTE drop-frame
> timing. We're MPEG guys, and while we've known about drop-frame for some
> time, this is the first time we've really had to *understand* it. If anyone
> could help, we'd sure appreciate it.
>
http://www.leitch.com/AppNotes/timecode.pdf
This is a very clear tutorial on the issues you're grappling
with.
Peter Sjöström
> Here's what we *think* we understand, and what puzzles us -- of course, we
> could be wrong anywhere along the way:
>
> Drop frame time code counts 30 frames per second, but skips 2 frame counts
> every minute, except minutes divisible by 10. In a 24 hour period there are
> 1440 minutes, so when the time code goes for 24 hours it drops (really it
> skips counts) (1440-144) * 2 = 2592 frames, and there are 24 * 60 * 60 * 30
> - 2592 = 2589408 frames in the "24 hours."
>
> Given the color subcarrier as spec'd by RS170A, a frame time is ((455/2
> cycle/line) * 525 lines/frame)/3579545 cycles/sec = 0.03337599...
> sec/frame.
> Then the time for 2589408 frames is 86399.925 seconds, or 23 hours, 59
> minutes, 59.925 seconds.
This must be where you calculation goes wrong. The drop frame method is used to
compensate for the correct number of frames in NTSC, which is a perfect match
over 24 hours. You can find the details at
http://www.inforamp.net/~poynton/notes/video/Timecode/index.html
/Peter
Charles Poynton
> The drop frame method is used to compensate for the correct number of
> frames in NTSC, which is a perfect match over 24 hours.
Dropframe does not achieve a perfect match to clock time, just a very good
match: Counting dropframe code at 30/1.001 frames per second is about
86.4 ms late (slow) over 24 hours. If the residual error were left to
accumulate over 11 or 12 days, timecode would fall about one second later
than clock time.
If a timecode sequence is to be maintained longer than 24 hours,
timecode should be jammed daily to reference clock time at an
innocuous moment. No standard recommends when this should take place;
however, the usual technique is to insert duplicate timecode numbers
00:00:00;00 and 00:00:00;01. Editing equipment treats the duplicate codes
as a timecode interruption.
C.
--
Charles Poynton
<mailto:poy...@poynton.com> [Mac Eudora/MIME/BinHex/uu]
<http://www.inforamp.net/~poynton/>
Cliff Benham
<pj...@ludd.luth.se> wrote:
>Isaac Wingfield wrote:
>
>> Here's what we *think* we understand, and what puzzles us -- of course, we
>> could be wrong anywhere along the way:
>>
>> Drop frame time code counts 30 frames per second, but skips 2 frame counts
>> every minute, except minutes divisible by 10. In a 24 hour period there are
>> 1440 minutes, so when the time code goes for 24 hours it drops (really it
>> skips counts) (1440-144) * 2 = 2592 frames, and there are 24 * 60 * 60 * 30
>> - 2592 = 2589408 frames in the "24 hours."
>>
>> Given the color subcarrier as spec'd by RS170A, a frame time is ((455/2
>> cycle/line) * 525 lines/frame)/3579545 cycles/sec = 0.03337599...
>> sec/frame.
>> Then the time for 2589408 frames is 86399.925 seconds, or 23 hours, 59
>> minutes, 59.925 seconds.
>
>This must be where you calculation goes wrong. The drop frame method is used to
>compensate for the correct number of frames in NTSC, which is a perfect match
>over 24 hours. You can find the details at
>http://www.inforamp.net/~poynton/notes/video/Timecode/index.html
>
> /Peter
>
Drop frame time code was developed to compensate for the difference in
"clock" time and the "duartion" time of programs recorded on videotape
in the NTSC 59.94 format. The difference is 3.6 seconds per hour. By
dropping frames, the time code reading from the tape will always
correspond to "clock" time. If frames are not dropped (non-drop frame
time code) the taped program will be shorter by 3.6 seconds at the end
of one hour of playback than the indicated "clock" time.
The original name for time code was Manchester bi-phase mark code and
was developed in the 1960s at AMPEX.
Cliff