-
Is drop frame needed / relevant anymore?
-
[Jeremy Garchow] “you have to separate real time from NDF timecode. NDF tc, while expressed in hours/minutes/seconds, does not equal real time.”
Yes I agree with this. In fact the Apple page on timecode stresses this, and the confusion which can occur by referring to timecode values as elapsed recording time or “length”: https://bit.ly/1BlCL49
“Remember that these numbers don’t reflect time; they are simply unique identifiers. The first frame of NTSC video is labeled 00:00:00:00. The 29th frame is labeled 00:00:00:29, and the 30th frame is labeled 00:00:01:00. Again, just because a frame is labeled 00:00:01:00 does not mean that 1 second has passed. The frame could just as easily have been named AAABD, in which case there would be no temptation to read the label as a time value. Only the frame rate of the video can determine how much time has passed by the 30th frame.”
“Timecode is merely a method of labeling frames with unique identifiers to easily find them again later. It is a convenient way of giving each frame a name that can be referred to later without having to verbally describe and visually search for it. Even though frame rate and timecode are independent, people commonly confuse the two, which can lead to frustrating problems in post-production.”
Re measuring by elapsed recording time (not indicated time code) and equating this to frame count, both DF and NDF material with the same elapsed recording time will have the same frame count. This can easily be inspected with QT7 Pro, Invisor or other tools.
I still think there is a bug in how FCPX displays NDF 29.97 material. Even though the project and TC display format are set to NDF, it displays a shorter clip length in the timeline, as if it were 30 fps. Premiere CC does not do that. This is just another example of how you can’t trust TC readouts and referring to TC duration as program length can be misleading. It’s OK to refer to it as length for loose purposes but someone in the production — the DIT or 1st AE, etc — must know the nitty-gritty details.
-
[Joe Marler] “Re measuring by elapsed recording time (not indicated time code) and equating this to frame count, both DF and NDF material with the same elapsed recording time will have the same frame count. This can easily be inspected with QT7 Pro, Invisor or other tools.”
Sure, but that is impossible to tell someone (or more specifically, it would be impossible for a computer to find the right frame without the tc number, and using a frame number) because you’d never express a frame address in elapsed time because elapsed time could be relative to any starting point (or timecode!), or perhaps there’s a break in tc and the frame count wouldn’t calculate to the time. And you’d then have to do the math to say “go to 3 minutes elapsed time” as the frame count would NOT be the same on tape or in a file when calculating frames from the tc. So then the computer would have to ask itself, “what 3 minutes and where is it?”
Of course, if something is three minutes long, it’s going to be three minutes long, but that has nothing to do with NDF timecode. “3 minutes” of NDF tc and 3 minutes of DF tc will have different frame counts because they are different lengths. I don’t see how it would be necessary to express it any other way.
[Joe Marler] “Even though the project and TC display format are set to NDF, it displays a shorter clip length in the timeline, as if it were 30 fps. Premiere CC does not do that.”
This is with a DF source? I don’t know what you mean, exactly. Fcpx will add auto speed adjustments to keep whole frames, you can reset these auto speed changes. Is that what you mean?
-
[Jeremy Garchow] “This is with a DF source? I don’t know what you mean, exactly. Fcpx will add auto speed adjustments to keep whole frames, you can reset these auto speed changes. Is that what you mean?
“It’s possible I looked at it wrong. Unfortunately I have to go out of town a few days and can’t pursue it until I get back. Thanks for the discussion and I’d like to continue this later.
-
[Joe Marler] “Thanks for the discussion and I’d like to continue this later.
“Likewise!
Seems like forever since we’ve had a good ole fashioned timecode discussion around here! 🙂
-
I get the reason why fractional frame rates are required for NTSC equipment/broadcasts, but are they required under ATSC?
If so, why? One of the primary points of developing ATSC was to revamp the bandwidth to accommodate for HD video, but wouldn’t that have given them the opportunity to solve the problem that created the need for fractional frame rates to begin with?
I understand that ATSC can support fractional rates, but does it requirement them to broadcast or display?
-
If you shoot and cut 23.98, then it’s NDF (Non-Drop Frame) anyway, there is no such thing as 23.98 DF. That only exists in the 30fps world (well…59.94i or 29.97p). But then those of us in broadcast who need to get 23.98 to meet actual broadcast timings to a “T” need to either calculate what end time we need 23.98 to be to meet 29.97 DF timing…or use hand things like in Avid that allow us to monitor the 29.97 DF timing in a 23.98 project.
Drop Frame timing won’t be going away any time soon, not until broadcast dies completely…and even then, distributors for the web might still require DF timing. I’ve cut two projects that were web only and they still insisted on DF for accurate timing.
Shane
Little Frog Post
Read my blog, Little Frog in High Def
Reply to this Discussion! Login or Sign Up