Fixing Audio Drift in Variable Frame Rate Game Clips

You record a twenty minute match with the Xbox Game Bar, drop it on a timeline, and the first minute looks perfect. By minute twelve the gunshots land a beat after the muzzle flash. By the end, your voice is half a second behind your mouth on the facecam. Nothing is wrong with your editor. The file is lying to it.

This drift is one of the most common messages I get from people moving from casual clips to proper edits of their game footage. The cause is almost always variable frame rate, and the cure is a boring conversion step that most tutorials skip because their footage came from a camera, not a game.

Where the drift actually comes from

A camera records frames at a fixed interval. At 60 frames per second, each frame arrives 16.67 milliseconds after the last, every time. Editing software is built around that assumption: frame 3,600 is exactly one minute in.

Many screen and game recorders do not work that way. The Xbox Game Bar, phone screen recorders and some capture settings in other tools write a frame only when the game produces one. When your game runs at 60, the file gets 60 frames a second. When a loading screen drops to 24, or the game hitches during a big fight, the recorder writes fewer frames and stamps each one with its real time. That is called variable frame rate, usually shortened to VFR.

The audio, meanwhile, is a continuous stream at 48,000 samples a second that never dips. A player that reads timestamps shows both correctly. An editor that counts frames and assumes they are evenly spaced puts the video slightly early after every dip. Each dip is tiny, but over twenty minutes of a game that loads, stutters and alt-tabs, the error accumulates into something you can see.

That is also why the problem looks random. Two clips from the same session can behave completely differently, because one included three loading screens and the other did not.

How to confirm it before you waste an evening

Do not guess. Install MediaInfo, which is free, open the clip and look at the Video section. If you see "Frame rate mode: Variable" along with a minimum and maximum frame rate, you have found the problem. A clip that reports a minimum of 23.8 and a maximum of 60 will drift in almost any editor.

Some editors now warn you. Recent versions of Premiere Pro flag variable frame rate media in the clip properties, and DaVinci Resolve handles some VFR files better than it used to. Better, in my experience, is not the same as reliable. I stopped trusting the editor to cope after a client job where Resolve played the clip in sync on the first night and drifted after a relink the next morning.

The conversion that fixes it

The idea is simple: convert the recording to constant frame rate before it ever touches a timeline. The converter duplicates or drops frames where needed so that every second holds exactly the same number of frames, and the audio stays where it belongs.

1. Copy the original recordings into a folder called 01_raw_vfr and never edit from it.
2. Open HandBrake, load a clip, and on the Video tab set Framerate to the rate you intend to deliver, usually 60 or 30. Select Constant Framerate, not Peak Framerate.
3. Pick a quality setting high enough that you will not see compression. For 1080p game footage I use RF 18 with the H.264 encoder, which keeps fine detail like HUD text readable.
4. On the Audio tab, set the codec to passthrough if the option is offered, so the audio is copied rather than re-encoded.
5. Export to a second folder called 02_cfr, run MediaInfo on one output to confirm "Frame rate mode: Constant", then queue the rest.
6. Build proxies from the 02_cfr files, not from the originals, into a third folder called 03_proxy.

If you are comfortable on a command line, ffmpeg does the same job in one line with a forced output rate and constant frame rate mode, and it is faster for big batches. HandBrake is easier to hand to someone who edits for you.

Proxies after conversion, not before

Game footage is heavy. A 1440p60 recording from a modern capture tool is often encoded in a way that makes scrubbing a timeline miserable on a laptop. Proxies solve that, and I would push almost anyone editing more than half an hour of gameplay to use them. Our guide to organising an edit before the first cut covers the folder habits that make proxies painless.

The order matters. A proxy made from a VFR original inherits the problem, sometimes in a different way from the original, so your proxy and full resolution timelines no longer agree. Make proxies from the constant frame rate copies.

Plan for the storage. Apple's ProRes 422 Proxy at 1080p60 runs at roughly 90 megabits per second, which is about 40 GB for every hour of footage. DNxHR LB is in the same neighbourhood. That is less than the converted masters, but on a weekend of recordings it still adds up, so I keep the proxy folder on a separate drive and delete it when the project ships.

The advice I would push back on

You will see the suggestion to fix drift by cutting the clip into short pieces and nudging each one back into sync by hand. It works for a three minute highlight. For a long session it is a trap, because each manual nudge is a guess, and the drift between your nudges is still there. I have watched people spend four hours resyncing a podcast style commentary track that a fifteen minute HandBrake batch would have fixed.

The better fix is upstream. If your capture tool has a constant frame rate option, turn it on. OBS Studio records at a fixed rate by default, which is one reason it gives fewer sync headaches than built-in game recorders. When you capture short highlight moments, the advice in our post on capturing great game clips still applies, but note which tool made each clip so you know which ones need converting. Matching that output rate to the timeline is covered in choosing a timeline frame rate.

What conversion cannot rescue

Conversion fixes timing. It does not invent motion. If the game itself ran at 24 frames during a stutter, the converted file holds duplicated frames for those moments, and fast camera pans will look slightly choppy there. That is a true record of what happened on screen, and I would rather show it than smear it with frame interpolation that makes HUD elements wobble.

It also cannot fix a recording where the audio and video were captured by different devices with different clocks, such as a separate camera for your face and a capture card for the game. That is a sync problem of a different kind, solved by clapping on camera at the start and aligning waveforms.

Try it on one clip this week

Pick the longest game recording you already have, ideally one that includes a loading screen or a stutter. Run it through MediaInfo. If it says Variable, convert it with the settings above, put the original and the converted copy on two timeline tracks, and jump to the last minute. Seeing the gap between them once is usually enough to make the conversion step a permanent part of your workflow.