ClipReady Get ClipReady
Product menu

ClipReady

Why Final Cut says your 23.976 file is 23.81 fps

Last updated:

You know the film is 23.976. The disc says so, MediaInfo says so, and the player you watched it in said so. Final Cut Pro imports the MKV and the timeline says 23.81. Sometimes 23.95, sometimes 24.15. Compressor agrees with Final Cut and disagrees with everything else, the conform dialog appears, and you start wondering whether the file is damaged.

It isn’t. Nothing is wrong with your video. The problem is the clock the file is filed under, and it has a specific, boring cause.

What is actually happening

Matroska, the .mkv container, stores its timestamps against a timecode scale, and in practice that scale is one millisecond. Every frame has to land on a whole millisecond boundary.

A 23.976 fps film is really 24000/1001 frames per second, which is 41.7083… milliseconds per frame. That number does not fit in whole milliseconds. So the muxer does the only thing it can: it rounds. Frames land 41 ms apart, then 42, then 41, then 42, in a pattern that averages out close enough for a media player and not close enough for an editor.

When Final Cut opens that file it does not read a “frame rate” field and believe it. It measures. It looks at the actual distance between presented frames, averages what it finds, and reports that. Average a jittering 41/42 ms cadence and you get something in the region of 23.81 fps, a number that exists nowhere in your film and nowhere in the disc it came from.

This is why the value moves around between tools. Every application samples a different part of the file, or averages differently, so the same MKV can read 23.81 in one place, 23.95 in another, and “variable frame rate” in a third. They are all measuring the same jitter.

Why the usual advice does not work

“Just rename it to .mov.” The container extension is not the container. Renaming changes nothing inside the file, including the timestamps, so the frame rate reads exactly the same, when it opens at all.

“Re-encode it in HandBrake.” This does fix the timing, because encoding lays down a fresh, regular set of timestamps. It also re-encodes every frame of your picture to do it, costing you a generation of quality and an hour of your machine. You paid a very high price for a clock repair.

“Use ffmpeg -c copy.” Closer, and this is the right instinct: it copies the video without touching it. But a straight stream copy copies the timestamps too. The 41/42 ms jitter goes across into the new file intact, and Final Cut still reads 23.81. You changed the wrapper and kept the bug.

The actual fix

The timestamps need to be rewritten onto an exact grid, every frame at precisely 1001/24000 of a second from the last, while the encoded picture is carried across untouched. That is a timestamp operation. No pixel is decoded, nothing is re-compressed, and the output is the same video it always was, filed under a clock that can express what it is.

Once the grid is right, Final Cut reads 23.976, the conform prompt stops appearing, and your timeline settings match the footage.

What ClipReady does about it

ClipReady is a Mac app built around exactly this repair. Drop in the MKV and it will:

  • measure the real cadence of the file before promising anything, and say so if the timing is genuinely variable instead of merely quantized;
  • snap every packet back onto the exact 24000/1001 grid;
  • carry the H.264, HEVC, or MPEG-2 picture across without decoding it, so there is no generation loss and no long transcode;
  • write the result as a MOV or MP4 with a real SMPTE timecode track, which an MKV has nowhere to store.

It shows you all of that as a plan before it runs, and it checks the finished file back through Apple’s own decoder before it saves anything.

There is one honest limit worth stating. If a file’s timing is genuinely irregular, such as a variable-frame-rate screen recording rather than a constant-rate film quantized by its container, ClipReady says so and leaves the timing alone. Forcing a grid onto footage that never had one would be guessing, and guessing is how you end up with drifting audio.