FCP duration listing inconsistent with itself

The story of fractional frame rates is long and complicated going back to approximately 1951 when color television was being "invented". They needed a way to apply the "chroma signal" to the video being broadcast (*over the air*) within a certain (restrictive ~ 5MHz) bandwidth so that people who had already spent a small fortune on B&W television sets wouldn't be abandoned and forced to buy newer, more expensive, color television sets (which by today's economy would cost several thousand dollars for the "console models"). The frequency of television sets used household current (60Hz in the US) as the "clock" to translate the over-the-air signal — it wasn't built into the receivers. Since the video information had to be **interlaced** that split the 60Hz timing into two passes requiring 30Hz for both. [Side note: European electrical systems run on 50Hz.)

Adding the chroma signal should have been easy, except it caused noticeable interference with the B&W signal, so somebody came up with the "ingenious" idea of slowing the broadcast signal down by 1%... or (ta dah) 29.97 frames per second. This is NTSC.

This is all fine for analog signals... not digital. Forcing fraction frame rates on a digital system is also a "hack" -- but also just plain insanity. Digital broadcasting became the "norm" in 2009 with ATSC.

If you know anything about computer programming, try to reason out the process of accommodating fractional frame rates. First: there is no such thing as a fractional frame. Second, there is not a computer in the entire universe that can accurately represent the fractions required since they are all infinitely repeating decimals. Third: the solution is a rather sorry hack (run 29.97 for 1 minute, then skip 2 timecode values - going from 59:29 to 1:00:02 and every 10 minutes, NOT skipping those timecode values... that's a somewhat taxing calculation [and a bleeding headache!!].) And this is just for 29.97 - the others have their own issues.

"That's the way it's always been done" is the concept most people under the age of 60 think of fractional frame rates — and probably what they've been told by those that went before.

And camera makers who kowtow to public ignorance (and/or just laziness) continuing to make cameras that use FFRs for the reason just stated — it's what most people expect and they don't want to have to think about it.

Life is just so much easier when dealing with digital and computers when numbers are integers. 24, 25, 30, 50, 60, etc... At the very least, set your projects to those values. FCP does a rather outstanding job of conforming fractional frame rate video to full frame rates... *most* of the time (as long as it's a close fit, like 29.97 to 30).

Which frame rate to use? If you're producing video for somebody else... like a job... by all means ask! Otherwise:

24 is supposed to be "cinematic"

25 is European broadcast

30 is USA, Japan (and others) broadcast (in general... also 720/60).

Even multiples of the previous basically apply the same, however people complained about The Hobbit (at 48fps) for being "too realistic" — higher frame rates tend to be more sharp as motion blur is less prevalent. Higher frame rates allow for other options, like slow motion when used in 30 or less frame rate projects. YouTube and other services will have "preferred" or recommended frame rates posted with recommended encoding settings (all the YouTube frame rate recommendations are integer values — but when I started, it was just 30).

Oh... and Timecode is NOT time... it's code. It is a numerical way of labeling/tagging individual frames while making it easier to keep track of "real time" since it resembles clock time.... But it is just numbers... and not continuous for digital fractional frame rates.

Michel's answer is exactly correct. It points out that in a fractional frame rate the time indication may not match, precisely due to the non-dropframe issue.

Your media is 23.98 fps, but is counted as if there were 24 frames in each second (from 0 to 23). At some point, that 0.02 adds up and you end up with the problem you are showing.

For example, I just threw a bunch of clips to a test 23.98fps timeline (again, this is just for testing, I would never make a video at 23.98, just use 24 if that is the case).

With the display at HH:MM:SS:FF, I put the cursor at exactly the 1 hour mark: 1:00:00:00

Then I switched to "Frames". It showed 86400.

Is that right? Well, 3600 seconds (one hour), times twenty four frames per second yields... 86400. So this would be perfect, if only the number of frames per second were 24, not this weird 23.98.

Then I switched to "Seconds". In any sane timekeeping system, this would be 3600, right?

I get 3603.60. Multiply this by 23.98/24 and you get about 3600...

This is all the effect of using this (clever at the time, but stupid now) fractional frame rate...

There is no easy answer to this situation since fractional frame rates are deeply embedded into current production workflows, camera hardware, and the ASICs (Application Specific Integrated Circuits) that make those cameras.

Some current-generation professional cameras incur tradeoffs when shooting at 24.0 fps. This may include focus behavior, aspect ratio when shooting at high frame rate, etc. E.g, my documentary team has several fully-built Sony FX6 rigs and the Ronin R4D. As configured, those are all $10k cameras. Yet they have some narrow feature limitations if shooting at 24.0. Even the $25k Sony Burano has certain restricted features on 24.0 fps.

If you are a solo operator, you can do whatever you want. But if you are shooting as part of a team (or might be in the future), there are issues of commonality, standardization and collaborative post-production efficiency. Even with a new-generation camera fleet, having them all on 23.98 avoids certain problems.

A big issue is intermixing 23.98 and 24.0 material. Since those clips must be rate-conformed, on a 23.98 timeline, the NLE will force the 24.0 clip to run faster to match frame-by-frame. On a 24.0 timeline, the 23.98 clips will run slightly slower. That means the audio from those clips won't stay in sync with each other or with external audio recorders.

My team regularly leverages the hundreds of terabytes of 23.98 material we've shot over the past 10 years. Even if all our cameras worked perfectly at 24.0, we would then be facing a constant issue of editing mixed 23.98 and 24.0 material. For us, it's easier and safer to just keep shooting 23.98.

If all our pro cameras could shoot at 24.0 fps with no tradeoffs, and if we had no issues with 23.98 archival material, we still might not use 24.0. That's because lots of cameras today simply cannot shoot 24.0. We prioritize using the pro cameras, but we often are forced to use material from mirrorless cameras that can only shoot 23.98 fps. We don't want the hassle of constantly editing mixed frame-rate material except for unavoidable cases.

The issues about measuring real-world playout time on fractional frame rate material are well known and are unrelated to FCP. Even back in the days of FCP 7, the manual described these in Appendix D:

"Remember that these [timecode] 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."

"The Difference Between Frame Rate and Timecode:

The frame rate of your film or video describes how rapidly frames are photographed or played back. It refers to the physical speed of image capture and playback. 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. Before you start a project, be certain that you understand the difference between these two terms." (emphasis added)

Hi(bonjour),

May be it’s related to drop frame or non-drop frame timecode setting in FCP.

You can set your timecode display to second, frame, etc, in FCP pref: general settings.

https://www.tella.com/definition/drop-frame

https://cloudinary.com/glossary/drop-frame

Michel B.

To calculate actual elapsed playout time from the listed timecode duration on a fractional frame rate timeline, there is a free timecode utility designed specifically for this. This was written by an FCP editor for himself, but he made it freely available for all. Google this string (in quotes): "timecodecalculatorbythepostage.netlify.app"

From FCP Help Glossary:

drop frame timecode

NTSC timecode that skips ahead in time by two frame numbers each minute, except every tenth minute, so that the timecode agrees with the actual elapsed clock time. (Timecode numbers are skipped, but actual video frames are not skipped.) This skipping corrects for NTSC’s actual frame rate of 29.97 fps, which causes non-drop frame timecode to lag behind actual elapsed time by 3 seconds and 18 frames per hour. To avoid confusion, drop frame timecode should be avoided in film-based productions. See also non-drop frame timecode.

non-drop frame timecode

Timecode in which frames are numbered sequentially and no timecode numbers are dropped from the count. In the case of NTSC video, the video frame rate is actually 29.97 fps, and non-drop frame timecode is off by 3 seconds and 18 frames per hour in comparison to actual elapsed time. See also drop frame timecode, NTSC format.

Your Project settings affects the timecode displayed in viewer.

<rant>why don’t fractional frame rates die already?</rant>

There is no reason ever to use fractional frame rates in digital productions. They were a hack introduced when color was added to analog tv in the middle of last century.

23.98 is always NDF. I'll examine the above case.