Confused with timecode: 23.976fps vs. 24fps

[Jeremy Garchow]

NDF 23.98 does real not equal real time. 2 minutes of tc does not equal 2 minutes on the clock.

[Andreas Kiel]

As Jeremy said 23.976 (or 24 on NTSC) is not real time.
TC addresses a full frame of a video. So the number of frames in a 24 and a 23.976 sequence will be the same — playback time on NTSC will be longer.
The TC calculation you made, addressed the real time. If you would overlay your movie above a movie with 24 or 23.976 with the same amount of frames it won’t match.

Andreas

Spherico
https://www.spherico.com/filmtools

[James Heliker]

Hey Folks –

Okay, thank you for all the responses, I appreciate it very much. I thought I made it pretty clear in my post that I understand that 23.976 is actually a ratio (24/1.001):

[James Heliker] “23.976 (more accurately 24/1.001, or 23.97602397602398)
120.1201201201201 x 23.97602397602398 = 2880.00288000288

This is great! Exactly as expected.”

I also thought it was obvious in my original post that I understood that 23.976fps was not equal to real time:

[James Heliker] “Now, I exported a file from this sequence with an actual timecode track, (ProRes 422 HQ Quicktime file), running @ 23.976fps, comes out with a duration of 2880000mu /23976ts (120.1201201201201 seconds).”

Where things start to go gray for me is why 23.976 exists – I’ve been told that 23.976 exists so that there can be an easy math conversion to NTSC for monitors, broadcasting, etc. That makes sense as 23.976 converts to 29.97 (30/1.001!) mathematically (every fourth frame), whereas 24 does not.

If this is the case, I’m left with why we don’t use 23.976 timecode with 23.976 material?

My original two questions are this:

[James Heliker] “However, why is my timecode running at 24fps on a 23.976fps video file? In true 23.976fps math, my final frame (2879) should be at TC marker 00:02:00:03.

1. I was under the impression that 23.976fps video should be accompanied by 23.976fps timecode??
2. Why can’t I set the TCG to run at 23.976fps? What am I missing here?”

Please correct me if I am wrong, but it appears the answer to both of my questions is that 24 frame timecode is the industry standard, even for 23.976 fps material. ie. the TC addresses are simply sliding over time to account to for the difference in speed?

Thank you for your help!

Kind Regards,

-James Heliker
james.heliker@gmail.com

[Jeremy Garchow]

[James Heliker] “If this is the case, I’m left with why we don’t use 23.976 timecode with 23.976 material?”

There is no fractional frame timecode as there’s no fractional frames in video, they just get played back at a fraction of fps.

What would be handy is an honest to goodness SMPTE sponsored DF 23.976 tc, similar to 29.97 DF and NDF.

That way, the tc will equate more or less to real time.

[James Heliker]

Thanks Jeremy!

What you’re saying makes perfect sense – let me make sure I understand:

Video marked as 23.976fps is only the speed at which material gets played back (there are still exactly 24 individual frames of video)

There is no REAL 23.976fps video, and as such no 23.976fps timecode data?

Thanks for your help!!

-James Heliker
james.heliker@gmail.com

[Jeremy Garchow]

[James Heliker] “Video marked as 23.976fps is only the speed at which material gets played back”

…and recorded.

Lets back up a second.

Imagine for a second that there is no timecode, just video data. The material gets recorded AT A SPEED of 23.976 fps, but It’s not like that last fractional frame per second is only fractionally recorded. Video records in whole frames. Now, to keep track of all those frames, each frame gets assigned a number.

In the case of 24p (or 23.976) these numbers go from 0 to 23 and a new second of tc values begin.

Now the recording speed of the video starts to divulge from real clock time in a meaningful way pretty quickly. 1 hour of timecode values (which remember, are in essence only frame based metadata) does not equal one hour of real clock time.

Drop frame accounts for this time differential and a new frame number values get re-assigned to keep in time with real time. Frame numbers are actually skipped or not included in the count (but the next frame of video is, the information is still recorded/played back in succession, but the frame numbers are not). So DF does not represent a break in the recorded action, but rather a momentary discontinuous assignment of the tc number value of the frame.

For a more accurate example, in DF 29.97 tc, a tc value of 00:58:00;00 does not exist, the tc goes from 00:57:59:29 to 00:58:00;02. The loss of those two FRAME VALUES (not the actual recorded video frames) starts to make up the difference in assigned tc values vs measured clock time. These numbers (frame 00 and 01) get dropped every minute except they are included every 10 minutes, so 00:10:00;00 and 00:10:00;01 do exist as frame values.

So, the recorded frames and the actual time of those recorded frame don’t necessarily sync in NDF formats. Thats why a 23.98 DF format would help. Hope all that makes sense and I edited this for accuracy.

What do you need to do, exactly?

Jeremy