Audio drifting out of sync? Convert variable frame rate to constant

Phones, screen recorders and game captures write variable frame rate video: the gap between one frame and the next changes as the scene changes. Most editors assume the gap never changes, so they lay the frames out on an even grid, and the picture slowly slides away from the sound. The fix is a transcode to a fixed rate. It cannot be remuxed away, because the frame timestamps themselves have to be rewritten.

That is also why the drift grows. A file that is in sync at the start and half a second out after five minutes has a rate mismatch, not a delay.

The signature: drift that grows

Before you convert anything, check that you have the problem this page describes. There are two ways audio and video come apart, and they need different fixes.

Only the first row is a variable frame rate problem. If the offset is constant, transcoding will change nothing and you will have spent an hour discovering it.

How to confirm the file is variable

The clearest tell is an average frame rate that is not a round number and not one of the standard broadcast rates. Drop the clip on our in-browser video converter and it reads the header on your machine — the file is never uploaded — then prints the container, codec, resolution, duration and frame rate before you convert anything. A readout of 30, 29.97, 25, 24, 23.98, 60 or 59.94 is a normal nominal rate. A readout of 29.87, 58.3 or 26.41 is an average of a rate that kept moving, and that average is the fingerprint of a variable file.

Two caveats. A variable file can still average out to exactly 30, so a round number does not prove the file is constant. And the average alone does not tell you how far the rate swung. If you want certainty, MediaInfo reports a field called Frame rate mode that reads either Constant or Variable, and ffprobe gives you the same answer by disagreeing with itself: when r_frame_rate and avg_frame_rate are different numbers, the file is variable. The guide on checking what codec is inside a video covers reading these fields without installing anything.

Why recordings are variable in the first place

Variable frame rate is not a bug. It is a sensible answer to a hard problem, in three different situations.

Phone cameras

A phone camera has to hold the exposure long enough to get a usable image. In good light that is a few milliseconds and the sensor comfortably delivers its nominal 30 or 60 frames a second. Walk into a dim room and each frame needs longer, so the camera quietly slows down rather than handing you a dark picture. It speeds back up when you walk out again. The file records what actually happened, frame by frame, with a timestamp on each one. iPhone and Android footage both do this, which is one of the reasons a clip that plays perfectly on the phone behaves oddly elsewhere — the same root cause behind several of the problems in the guide on iPhone video that will not play on Android.

Screen recorders

A screen recorder has nothing to capture when nothing on screen has moved. Writing sixty identical frames a second of a still document is a waste of bytes, so most capture tools write a frame only when the picture changes and stamp it with the time it changed. Over a long recording of a mostly static screen, the average rate can end up far from the number you set in the settings.

Game and console capture

A game renders as fast as the hardware allows. If the encoder is fed rendered frames rather than a fixed clock, the capture inherits every stutter, every loading screen and every drop below the target. That is why a long gameplay clip is the classic case: the recording is fine to watch, then falls apart the moment it enters a timeline, and it is usually also too big to share, which is a separate fight covered in the guide on sending a large video on Discord without Nitro.

Why the error accumulates

An MP4 or MOV does not store a frame rate as such. It stores a table of durations — how long each frame is held before the next one. A constant file has one entry repeated; a variable file has a table that changes. A player walks that table and shows each frame at the time it says. That is why variable footage plays correctly in VLC, QuickTime and every phone gallery: they read the timestamps.

An editor that assumes a constant rate does something else. It counts the frames, takes a single rate from the header, and places frame number n at n divided by that rate. The per-frame timings are discarded. Audio is untouched, because audio has no frames — it is a continuous stream of samples at a fixed sample rate, and its length in seconds is fixed by arithmetic that cannot drift.

So you get two clocks. Suppose a screen recording set to 30 fps actually delivered an average of 29.87 frames a second across ten minutes. That is 17,922 frames. Laid out at 30 fps, they occupy 597.4 seconds against 600 seconds of audio: the picture finishes about two and a half seconds early, and the gap opens steadily the whole way. Change the length of the clip and the number changes with it, which is exactly why the problem feels worse on long recordings and invisible on a fifteen-second test.

A remux cannot fix this

This is the part that catches people out. Most of the conversions on this site are stream copies: changing a MOV into an MP4 repackages the streams without touching a pixel, because the codec inside is already legal in the new container. It is instant and it is genuinely lossless.

A copy also carries the duration table across unchanged. That is the point of a copy. So converting a variable MOV to an MP4, or an MKV to an MP4, gives you a file that is still variable and still drifts. The frames themselves have to be re-timed onto an even grid — some duplicated where the camera slowed down, some dropped where it ran fast — and re-timing frames means decoding and re-encoding them. There is no shortcut, and any tool that promises an instant fix for this is fixing something else.

Setting a constant frame rate in your browser

Open the converter on the homepage, add your clip, open the advanced options and set Frame rate. The engine is FFmpeg compiled to WebAssembly running in the page, so the footage stays on your machine — which matters when it is a client's, or a recording of your own desktop with your email open in the corner.

Choosing a frame rate hands FFmpeg an explicit rate to render to, which forces every frame onto a fixed grid and writes a genuinely constant file. Two honest limits on that control:

• The choices are Original, 30, 24 and 15. There is no 60 and no 25.
• The setting is applied only when the rate you pick is lower than the rate your file reports. The tool will not invent frames to speed a clip up to a rate it never had.

That covers the case that matters most often: a 60 fps game or screen capture brought down to a rock-solid 30, which is what almost every timeline and every upload target wants anyway. It does not cover conforming a 30 fps variable clip to constant 30 — same number in, same number out, so there is nothing lower to select. For that one, use the desktop options in the next section.

Leave Audio on keep, so the sound is copied across untouched and keeps its original timing. Set quality to High if the clip is going back into an edit; a re-encode is a generation loss, and it is worth spending bytes to make it a small one. The same reasoning applies to the trade-offs in the guide on converting MKV to MP4 without losing quality.

The phone app cannot do this job at all. It converts between MP4, MOV, AVI, MKV and 3GP with three quality settings and no frame rate control, so there is no way to ask it for a fixed rate. This is one of the few tasks where the browser is the right tool and the app is not.

When you need the rate you already have

To conform a variable clip to a constant rate at the same nominal value — 30 in, constant 30 out — you need a desktop tool.

In HandBrake, the Video tab has a Framerate control with radio buttons beside it. Choose Constant Framerate rather than Same as source or Peak Framerate, and pick your number explicitly. Peak looks reassuring and is not what you want here: it caps the rate but leaves the file variable underneath. The guide on using a HandBrake alternative in the browser sets out which jobs each one is better at.

With FFmpeg on the command line, the modern flag is -fps_mode cfr alongside an explicit -r — on older builds the same switch is spelled -vsync cfr. Something like ffmpeg -i in.mp4 -fps_mode cfr -r 30 -c:v libx264 -crf 18 -c:a copy out.mp4 re-times the video and leaves the audio alone.

Check the result before you cut

Re-probe the output and confirm the frame rate now reads as the exact number you asked for. Then scrub to the very end of the clip and look at a moment with a hard sync point — a clap, a door, a mouse click with a sound. If the end is in sync, the whole clip is, because this class of error only ever grows.

Do this before you start editing, not after. Once a drifting clip has been cut into forty pieces on a timeline, each piece carries its own share of the error and there is no single slip that repairs them. Re-import the conformed file and relink, or rebuild the sequence. It is faster than it sounds and far faster than nudging clips one by one.

Finally, if the clip also refuses to import, you may be looking at two problems stacked. Codec faults and rate faults are unrelated and show up together often — the guides on DaVinci Resolve refusing an MP4, Premiere Pro refusing an MKV and CapCut reporting a file as not supported each cover the import side, and a single conversion can fix the codec and the frame rate in one pass.