They are not the same frame rate. True 24 fps is exactly 24 frames per second. What editors and software usually call 23.976 is 24000/1001, about 23.976024 frames per second, which is about 0.1% slower. On a timeline the two look interchangeable, but the same frames last longer at the slower rate: 2,400 frames take 100 seconds at 24 fps and 100.1 seconds at 24000/1001.
The practical question is rarely “which is better?” It is whether a change should preserve the existing frames and accept a different runtime, or preserve the elapsed time and accept repeated, dropped, blended, or synthesized frames. The answer depends on the source footage, the workflow, and the written delivery requirements. If nothing requires a change, keep the clip at its existing rate.
What the names actually mean
| What you see | Usually the actual rate | Practical meaning |
|---|---|---|
| 24, 24p, 24 fps | Exactly 24/1, but some cameras and apps use the label for 24000/1001 | Don’t trust the label alone. ProVideo Coalition documents camera menus that call 23.976 “24.” |
| 23.98, 23.98 fps | 24000/1001 | Display rounding to two decimal places. Same rate as 23.976. |
| 23.976, 23.976 fps | Usually 24000/1001 | Display rounding to three decimal places. |
| 24000/1001 | 23.976023976…, exact | The rational form software typically stores. In the generated test below, ffprobe reported this exact fraction for the 23.976 file. |
| 23.976 as a literal decimal | Exactly 23.976 | About 0.000024 fps away from 24000/1001. Over 2,400 frames that is 100.1001 s versus 100.1 s, roughly 0.1 millisecond. |
So “23.98” appearing in one panel and “23.976” in another is normally the same rate shown at different precision. The exact rational form matters in calculations. The analogous 30-family comparison is covered in 29.97 vs 30 FPS.
The same frames under two clocks
Elapsed time is the frame count divided by the actual frame rate:
elapsed seconds = frame count / actual frame rateThese are calculations, not measurements from a camera, editor, or website tool. Each uses the exact fraction 24000/1001.
| Frame count | At 24/1 | At 24000/1001 | Difference |
|---|---|---|---|
| 2,400 | 100 s | 100.1 s | +0.1 s |
| 86,400 | 3,600 s (1:00:00) | 3,603.6 s (1:00:03.6) | +3.6 s |
| 129,600 (90 minutes at 24 fps) | 5,400 s | 5,405.4 s | +5.4 s |
The playback-speed ratio is the new rate divided by the old rate, and it is easy to apply backward:
| If the same frames are reinterpreted… | Playback speed | Runtime |
|---|---|---|
| From 24000/1001 to 24 | ×1.001 (0.1% faster) | ÷1.001, so 100.1 s becomes 100 s |
| From 24 to 24000/1001 | ×1000/1001 ≈ 0.999001 (about 0.0999% slower) | ×1.001, so 100 s becomes 100.1 s |
The slower rate always means the longer runtime. Two clocks that start together drift apart by one frame about every 41.7 seconds (1 ÷ (24 − 24000/1001)), which is 1,001 frames. In a 100-second shot that is about two and a half frames by the end.
One more consequence of the fraction: 10 seconds at 24000/1001 is approximately 239.76024 frames, and a frame is indivisible. Converting arbitrary seconds to frames always involves rounding to a whole frame. To compare frames, timecode, and elapsed seconds at 23.976 using the actual 24000/1001 rate, use a calculator that does the rounding explicitly rather than multiplying by 23.976 by hand.
Conform versus convert: preserve the frames or the elapsed time?
Two different operations get called “conforming,” and they have opposite priorities.
| Reinterpret (relabel the frames at another rate) | Convert (resample to another rate) | |
|---|---|---|
| Frame count | Unchanged | Changes slightly (frames repeated, dropped, blended, or synthesized) |
| Elapsed time | Changes by 0.1% | Approximately preserved |
| Motion | Every frame still appears once, 0.1% faster or slower | Cadence changes; occasional repeats or skips |
| Typical menu names | Adobe Premiere: Interpret Footage, “Assume this frame rate”; Apple FCPXML: “rate conforming” for some rate pairs | Final Cut Pro: Rate Conform > Frame Sampling; FFmpeg: the fps filter |
Adobe’s help page says that changing a clip’s frame rate this way changes the audio as well as the video, and changes the duration in proportion; its example turns a 10-second 24 fps clip into 5 seconds at 48 fps (Adobe Premiere Help). It also separates the project-wide interpretation from a Speed/Duration change on one timeline instance.
Apple uses the word both ways. Its FCPXML documentation lists 23.98p media in a 24p timeline, and 24p media in a 23.98p timeline, among the pairs where rate conforming converts the media rate and also adjusts duration. Its user guide describes conforming frame rate through frame-sampling methods: floor, nearest frame, frame blending, optical flow, and machine learning. Not every application uses “conform” the same way, so read what the specific control does to duration.
A small conversion check
A video-only 2,400-frame synthetic clip at 24000/1001 was regenerated with FFmpeg 6.1.1. FFprobe counted 2,400 decoded frames and a stream duration of 100.100000 seconds. Converting it with fps=24 produced 2,402 frames and a reported stream duration of 100.083333 seconds. The small duration difference reflects the output frame grid and end-of-stream handling.
That result illustrates duration-preserving cadence conversion. It is not an editor benchmark, a universal output-count rule, or an audio-sync test. The same-frame duration table above is arithmetic; the conversion figures here are a separate observed experiment.
Why source rate, timeline rate, export rate, and timecode are separate
| Setting | What it controls | What goes wrong when it’s confused |
|---|---|---|
| Source (file) rate | How the file’s frames are timed | Treating a label like “24” as proof of the actual rate |
| Timeline or project rate | How many frame slots exist per second while editing | Clips at another rate are reinterpreted or resampled to fit; the method varies by application |
| Export rate | The rate written into the delivered file | A different export rate can trigger cadence conversion, depending on the application and its settings |
| Timecode display | A label counted in frames, with a nominal base of 24 for both rates | Reading timecode as if it were seconds |
Timecode counts frames. At 23.976 with a nominal base of 24, a display of 01:00:00:00 is 86,400 frames, which is 3,603.6 seconds of elapsed time (calculated above). The label and the stopwatch only agree at true 24 fps. Drop-frame timecode, which exists to correct this kind of mismatch for some other rates, is a separate topic and not covered here.
Changing a project’s frame rate after editing has its own risk: Apple’s guide warns that doing so can shift edit points in time (Final Cut Pro User Guide).
A constant fractional rate is also not variable frame rate. Constant frame rate means every frame interval is the same. 24000/1001 is constant: each interval is 1001/24000 of a second. Variable frame rate means the intervals differ from frame to frame, and it can occur at any nominal rate.
Audio and sync
When the video and separately recorded audio begin synchronized, changing only the video's playback speed can make them drift apart. If a 100.1-second picture sequence is reinterpreted to last 100 seconds while the audio remains 100.1 seconds long, the endpoints differ by 0.1 second. That is a calculated consequence of leaving the audio unchanged, not a measured editor failure.
Check how your application treats linked audio. A speed change and pitch-preserving time stretch are different operations; product settings and versions matter. Do not assume every clip-interpretation control leaves audio untouched. Check identifiable events at the beginning, middle and end after making a change.
For the exact numbering convention, see drop-frame versus non-drop-frame timecode. Changing a label convention is not an audio repair.
What should I do with this clip?
| Situation | Sensible default | Watch for |
|---|---|---|
| Clip rate, timeline rate, and delivery rate already match | Leave it alone | Confirm the exact rate, not just the label |
| A written delivery spec names a rate | Match the spec at the timeline or export | Use the spec document itself, not a general rule or a platform’s marketing copy |
| A few clips at one rate inside a timeline at the other | Decide per clip: reinterpret if a 0.1% speed change is acceptable and audio can follow; convert if runtime or sync must hold | Application behavior differs; test one clip and compare its timeline duration with its source duration |
| Video with separately recorded audio | Keep video and audio on the same clock | If video is retimed, retime audio equivalently and check both ends |
| A runtime must hit an exact duration | Preserve elapsed time (convert) | Repeated or dropped frames, roughly one per thousand |
| Animation, VFX, or graphics made at one rate for use with another | Render at the project’s rate from the start | Re-timing finished renders can reintroduce the 0.1% change |
| You only need still frames or frame-accurate review | Keep the original untouched | Frame-to-time mapping uses the actual rate |
| You don’t know the rate | Inspect before changing anything | A sampled estimate is not proof of an exact fraction |
| Camera originals or archival masters | Keep untouched; work on copies |
A command-line conversion example
For a duration-preserving video-only copy at 24 FPS:
ffmpeg -n -i input_23976.mp4 -map 0:v:0 -an -vf fps=24 -c:v libx264 -pix_fmt yuv420p output_24.mp4This re-encodes video and deliberately excludes audio with -an; it is not a finished audio/video delivery recipe. Keep the original. The command's fps filter changes the picture cadence; it does not simply relabel the existing frames. See the FFmpeg filter reference for rounding and end-of-stream behavior.
For a full diagnosis of unequal timestamp spacing, use the CFR/VFR guide. A constant fractional rate does not itself imply VFR.
Before you change anything
Write down the clip’s exact rate, frame count, and duration. Check the video’s reported frame-rate estimate for a quick sampled read, and treat it as an estimate rather than proof of an exact fraction. Read rate fields and presentation timestamps with a tool such as FFprobe. Dividing a count by a duration can cross-check an average only when the duration and counting boundaries are well defined; it does not prove uniform timing.
Find the delivery requirement in writing, from the document that applies to your destination.
Compare the clip rate with the timeline rate and the planned export rate.
Decide whether you need to keep the frames or keep the runtime. You cannot keep both once the rates differ.
Test one short clip first. Compare its duration before and after, and step through frames one at a time at the start and end, subject to your browser’s codec support.
Check audio sync at both ends of the clip.
Keep the originals.
The tools linked here inspect, count, and extract frames. They do not convert frame rate, conform footage, stretch audio, or repair synchronization.
Questions people ask
Is 23.976 a variable frame rate? No. 24000/1001 is a constant rate with equal frame intervals. Variable frame rate describes files whose intervals differ.
If it’s only 0.1%, why does it matter? The speed change is small. The consequences are cumulative and concrete: runtime (3.6 seconds per hour), sync with separately held audio, and alignment with other media made at the other rate.
How do I know a file is exactly 24000/1001? Read the rate fields, time base and decoded presentation timestamps. A count divided by an appropriate full duration can cross-check an average, but no single summary field proves exact per-frame timing.
Can I just change the timeline setting to match? Sometimes, but the method varies by application and version, and changing a project’s frame rate can shift edit points. Make the change before editing where you can, and test first.
Exact-rational calculations and a 2,400-frame synthetic conversion were checked with FFmpeg 6.1.1. Editor and real-audio behavior is documentation-based, not a claimed application test.
Examples and calculations are scoped to their stated settings. Source links support the instructions; an illustration is not a screenshot of an application test.