Drop-frame timecode and 30/1.001

Want to know how something works? Harness the power of the Brainiacs!
Post Reply
dheidel
Posts: 2
Joined: Mon Sep 16, 2019 9:41 am

Drop-frame timecode and 30/1.001

Post by dheidel » Mon Sep 16, 2019 5:38 pm

Hello. I’m writing a blog post about 29.97 drop-frame timecode and trying to understand one point and I was hoping for a bit of help.

I know that NTSC is actually 30/1.001 frames per second, 29.970029 repeating. So that means even with drop frame timecode, over the course of a day, you still get off by about 2.5 frames.

Is that compensated for in some way when broadcasting across the day? If so, how?

Thanks in advance,
David

User avatar
PID_Stop
Posts: 645
Joined: Thu Apr 01, 2010 11:58 am
Location: Syracuse, New York
Contact:

Re: Drop-frame timecode and 30/1.001

Post by PID_Stop » Tue Sep 17, 2019 8:45 am

Master sync / timecode generators like our Evertz 5601MSC use a GPS reference, so not only is the video reference spot on for frequency, the time code is extremely stable. Nevertheless, at any given moment there will be some amount of error between the (drop frame) time code versus real time. The solution to this is called "jam sync", which essentially resets the time code, forcing it to match the real time once again. Some systems perform the jam when the error exceeds a set threshold; as you can imagine, this creates a fairly large jump and can be disruptive. Our equipment automatically performs the jam daily (ours takes place at 2am, when the automation doesn't care). Not only does this correct for the relatively small mathematical imprecision you notice, it also makes provision for events like leap seconds that occur from time to time.

Naturally, this is only significant for operations that use time code to reflect real time -- to control automation, or to index continuous recordings like air check systems. For time code within the context of specific program content, even shows that run several hours, uncorrected drop-frame code is accurate enough to run cleanly.

Jeff

dcwar
Posts: 4
Joined: Wed Jul 17, 2013 4:49 pm

Re: Drop-frame timecode and 30/1.001

Post by dcwar » Tue Sep 17, 2019 9:21 pm

The answer OP is looking for is literally in... the original publication of the timecode standard: ANSI C98.12-1975, which can be found in the July 1975 issue of Journal of the SMPTE.

From section 4.2: "Because the vertical field rate of a color signal is approximately 59.94 fields per second, straightforward counting at 30 frames per second (60 fields per second) will yield an error of +108 frames (+216 fields),equivalent to +3.6 seconds timing error, in one hour of running time. For correction of this time discrepancy, two methods of operation are allowed...."

User avatar
PID_Stop
Posts: 645
Joined: Thu Apr 01, 2010 11:58 am
Location: Syracuse, New York
Contact:

Re: Drop-frame timecode and 30/1.001

Post by PID_Stop » Fri Sep 20, 2019 2:28 pm

dcwar wrote:
Tue Sep 17, 2019 9:21 pm
The answer OP is looking for is literally in... the original publication of the timecode standard: ANSI C98.12-1975, which can be found in the July 1975 issue of Journal of the SMPTE.
Indeed. The only thing is, not everyone has access to SMPTE documents... and someone might be forgiven for wondering if a 44-year-old document still reflects current practice.

:)

Jeff

dheidel
Posts: 2
Joined: Mon Sep 16, 2019 9:41 am

Re: Drop-frame timecode and 30/1.001

Post by dheidel » Fri Oct 04, 2019 5:52 pm

Thank you Jeff and dcwar. I apologize for my slow reply, got sucked into a couple different projects.

Jeff, would it be okay if I quoted your answer in my final post with a link back to this forum thread?

dcwar, I was able to track down the standards document you referenced. I was pleasantly surprised to see that it’s actually available for free from IEEE (page 562). Unless I’m misreading it, section 4.2 is describing (and, I suppose, defining) DF and NDF timecode. It’s accounting for the 108 frame discrepancy over an hour between 30fps and 29.97 fps. The standard is silent on what I was asking about, which is the discrepancy between 29.97 and 30/1.001 fps. Jeff’s answer perfectly addressed how that’s compensated for.

Appreciate both of you taking the time to respond.

-David

User avatar
PID_Stop
Posts: 645
Joined: Thu Apr 01, 2010 11:58 am
Location: Syracuse, New York
Contact:

Re: Drop-frame timecode and 30/1.001

Post by PID_Stop » Mon Oct 07, 2019 8:44 am

dheidel wrote:
Fri Oct 04, 2019 5:52 pm
Jeff, would it be okay if I quoted your answer in my final post with a link back to this forum thread?
By all means -- information is made to be shared and used. If you would like a somewhat more authoritative first-hand reference, you might approach the folks at Evertz (www.evertz.com) for documentation -- for instance, the manual for our 5601MSC master sync / clock system addresses this precise issue. I'd send it to you, but it's copyrighted material for which they hold distribution rights pretty firmly.

Regards,

Jeff

dcwar
Posts: 4
Joined: Wed Jul 17, 2013 4:49 pm

Re: Drop-frame timecode and 30/1.001

Post by dcwar » Mon Oct 07, 2019 4:30 pm

Thankfully, if you Google "5601msc manual" the second result - from broadcastrental dot com - will give you the PDF for the 5601. This version of the manual is from 2012, and you'll definitely want to start reading on page 54 or so for the mechanics. :D

I was hoping you'd discover that the PDF was free - it's probably one of the few SMPTE standards that is, due to the way they published things back in the day. :)

(The root cause - which in my haste I mistakenly thought you were asking about - is due to the field rate adjustment made to NTSC for color transmission.)

Post Reply