OBS Audio Sync Calculator — fix audio delay in milliseconds and frames

Audio drifting out of sync with video is the most common defect viewers notice and the easiest one to fix precisely — if you measure first. Guessing an offset by re-watching and nudging values produces drift of its own, because human reaction time is far coarser than one video frame. This calculator converts a measured offset into the exact value OBS needs, expressed both in milliseconds and in frames, with the correct sign for the direction of the drift. Enter how far off the audio is, select the frame rate, choose whether audio leads or lags, and the tool gives you the number to type into Advanced Audio Properties.

What the tool actually computes

OBS exposes one correction knob per audio source: Sync Offset, in milliseconds, in Advanced Audio Properties. Positive values delay the audio; negative values would advance it — but advancing audio is physically impossible, because you cannot play sound before it was recorded. So the direction of your problem determines what is possible:

• If audio is early (you hear the clap before you see the hands meet), the fix is a positive sync offset: delay the audio until the video catches up. The calculator returns your measured value as a positive number of milliseconds, plus the equivalent frame count at your chosen frame rate.
• If audio is late (voices arrive after lips move), OBS cannot move the audio earlier. The practical fixes are to delay the video source by the same amount, add latency to the video pipeline, or fix the capture chain upstream. The calculator returns a negative number as a signal, and tells you to apply the correction on the video side.

The frame count is simply offset milliseconds ÷ 1000 × frame rate. At 30 FPS each frame is 33.33 ms; at 60 FPS each frame is 16.67 ms. That framing matters because lip-sync tolerance is usually judged in frames: broadcast references often cite ±1 frame as imperceptible, and anything beyond roughly 45 ms becomes noticeable to most viewers.

How to measure the offset correctly

Do not estimate by watching a conversation. Estimate with a deliberate sync event:

1. Clap method. Record yourself clapping once, sharply, on camera. In an editor, find the frame where the hands meet and the audio sample where the transient spikes. Count the frames between them and multiply by the frame duration (33.3 ms at 30 FPS, 16.7 ms at 60 FPS).
2. Slate or flash method. A visual flash paired with a sound spike — a finger snap on camera, a clapperboard, a phone flashlight blinked next to an audible click — works the same way and is easier to spot in waveforms.
3. Measure in the editor, not in the player. Players buffer and smooth; a timeline with frame-accurate scrubbing and a visible waveform is the only reliable measuring instrument.

Measure at three points: the start, middle, and end of a longer recording. If the offset is constant across all three, you have a fixed delay and a single sync offset fixes it. If the offset grows over time, you have drift, and a constant offset will only fix one point in the timeline — that is a clock or sample-rate problem, addressed in the troubleshooting section below.

Three worked examples

Note for obs-audio-sync-calculator: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — typical measurement results, not measurements of named recordings.

Example 1 — wireless microphone on a podcast. A clap test at 30 FPS shows the audio transient landing 4 frames before the visual contact. Four frames at 30 FPS is about 133 ms, audio early. The calculator returns +133 ms. Enter 133 in Advanced Audio Properties for that microphone source, re-record ten seconds of clap, and verify the transient now lands on the contact frame. Wireless systems often introduce a fixed decode delay exactly like this, and a one-time offset corrects it permanently for that rig.

Example 2 — capture card, audio late. A console capture at 60 FPS shows lips moving two frames ahead of the voice: audio late by about 33 ms. The calculator returns −33 ms and the guidance to delay video instead, because OBS cannot advance audio. The correct move is a video filter or source delay of 33 ms on the capture source, or reducing audio latency at the capture-card settings. Entering −33 into the audio sync field would either be rejected or silently clamped depending on OBS version — another reason the direction matters.

Example 3 — growing drift across a long recording. A 2-hour lecture measures 0 ms offset at the start, +80 ms at the midpoint, and +160 ms at the end. A constant offset cannot fix this: setting +160 makes the beginning late, setting +80 leaves both ends wrong. The calculator will happily output any single number you ask for, but the measurement itself is the diagnosis: drift means two clocks running at slightly different rates. The fix is forcing one sample rate everywhere (48 kHz on the device, in OBS, and in the OS), or replacing a USB mic that resamples internally. After the fix, re-measure; the offset should be flat across the timeline, and then a single constant value from this tool finishes the job.

Why drift happens: clocks, resampling, and USB audio

Constant offset and drift have different causes, and the cure differs.

Constant offset comes from fixed latency in a chain: wireless mic receivers, audio interfaces with monitoring DSP, capture-card buffering, or an OS audio stack that adds a predictable delay. Fixed latency is exactly what the sync offset control was built for, and one measured number fixes it forever.

Drift comes from two devices disagreeing about time. If the audio interface thinks a second is 48,000 samples but its actual clock runs 0.01 percent fast, it accumulates roughly 3.5 seconds of drift per hour of recording relative to video clocked elsewhere. USB microphones are frequent offenders because several of them resample internally to match the host clock, and cheap resamplers introduce slow wandering. The remedies, in order of preference: lock every device to one sample rate; use an interface that can word-clock to a common source; or, for very long recordings, plan a resync pass in editing rather than relying on a single offset.

OBS's own audio subsystem can also contribute: mismatched sample rates between a source device and the OBS setting force OBS to resample, and older resamplers were a classic drift source. Set OBS audio sample rate to match your interface exactly — 48 kHz for almost all modern setups.

Common mistakes

• Correcting in the editor every time instead of fixing the source. Post-hoc sync works, but doing it for every episode means paying the same cost forever. A fixed offset in OBS is set once.
• Measuring with a player instead of an editor. Player buffering hides or creates offsets. Measure on a timeline with a waveform.
• Applying offset to the wrong source. In OBS, sync offset belongs to the audio source, not the scene. If the microphone appears in two scenes, the offset is set once in Advanced Audio Properties and applies everywhere.
• Using one offset for two different rigs. A wireless kit, a USB mic, and a capture card each have their own fixed latency. Store offsets per source, not per show.
• Chasing 1 ms. Below one frame at your recording rate, correction is inaudible and invisible. Round to the nearest frame and stop.

How this connects to WeaverClip — without bullshit

Sync offset is a recording-time property; clip tools downstream inherit it. WeaverClip's transcript and clip suggestions align words to audio, so a constant offset set correctly in OBS means captions and highlight timings land on the right frames without manual nudging. If your recordings carry drift instead of a fixed offset, no downstream tool can fully fix it — the fix belongs in the capture chain, and this calculator is the measurement step that tells you which of the two problems you have.

FAQ

Positive or negative — which way delays audio? Positive. OBS Sync Offset delays the audio by that many milliseconds. If your audio is already late, there is no negative-delay fix on the audio side; delay the video instead.

How many frames is 100 ms? At 30 FPS, 3 frames. At 60 FPS, 6 frames. At 24 FPS, 2.4 frames. The calculator does this conversion so you can sanity-check against what you counted in the editor.

Should I measure on the streaming output or the recording? On the recording. Streaming adds its own buffering, and the sync offset you set applies to the source as OBS sees it; the recording is the cleanest measurement of that path.

Does the offset need re-measuring after OBS updates? Usually not, unless the audio subsystem or device drivers changed. Re-measure once after any driver or OS audio update, then trust the stored value.

Can sync problems come from the editor rather than the recording? Yes — importing VFR footage into a project with a mismatched frame rate can create apparent drift that was never in the source. If the raw file measures in sync but the timeline does not, the project settings are the suspect, not OBS.

Frame values at every frame rate this tool supports

The frame conversion is exact arithmetic, not a lookup table: frames = offset in milliseconds ÷ 1000 × frames per second. The calculator supports the five frame rates OBS users actually record in, and each one assigns a different duration to a single frame:

1. 24 FPS — 41.67 ms per frame
2. 25 FPS — 40.00 ms per frame
3. 30 FPS — 33.33 ms per frame
4. 50 FPS — 20.00 ms per frame
5. 60 FPS — 16.67 ms per frame

The same measured offset produces different frame counts depending on which of those you record in. A 140 ms drift is 3.36 frames at 24 FPS, 3.5 frames at 25 FPS, 4.2 frames at 30 FPS, 7 frames at 50 FPS, and 8.4 frames at 60 FPS. That is why the milliseconds value is the one to type into OBS, while the frame count exists for cross-checking: if you counted four frames in a 30 FPS timeline, the calculator's 4.2 frames confirms the measurement instead of contradicting it.

Two practical consequences follow. First, a fractional frame count is normal and not an error — offsets rarely land exactly on frame boundaries, and OBS accepts any millisecond value, so there is no need to force whole frames. Second, if you re-measure an offset at a different frame rate than the original recording, the milliseconds should stay the same while the frame count changes. If both change, one of the two measurements was wrong.

How much offset viewers actually notice

Correction targets matter, because chasing zero costs time nobody can perceive. The broadcast reference most cited for lip-sync tolerance is ITU-R BT.1359, which defines two bands from viewer testing:

• Undetectable band: audio up to about 45 ms early, or up to about 125 ms late, relative to the picture. Inside this window, test audiences do not report a problem.
• Unacceptable band: audio more than roughly 90 ms early, or more than roughly 185 ms late. Between the two bands sits a gray zone where some viewers notice and most do not.

The asymmetry is real and consistent across studies: viewers tolerate late audio much better than early audio. A voice that arrives slightly after the lips move reads as natural room echo; sound that arrives before the event reads as broken. If you must leave residual error, leave it on the late side.

Content type shifts the practical threshold. Sustained speech masks offsets that hard transients expose instantly — a hand clap, a door slam, a drum hit, a gunshot in gameplay. A podcast interview can hide 80 ms that a percussion tutorial or a firearms video would make obvious in the first five seconds. Measure using a transient, because that is what will betray you; then judge the residual against the band above rather than against zero.

At 30 FPS, one frame is already 33 ms — inside the undetectable band for late audio and near its edge for early. So the common advice to "get within one frame" is not perfectionism; it is the point where further correction becomes unmeasurable by audience. Round to the nearest frame, verify once, and stop adjusting.

Where the number goes in OBS, step by step

1. Open Advanced Audio Properties: right-click any audio source and choose it, or click the gear icon next to the mixer.
2. Find the row for the affected source and the Sync Offset (ms) column.
3. For early audio, type the positive millisecond value the calculator returns. Press Enter; the change applies immediately to the live mix.
4. Record ten seconds of clap test and re-measure before trusting the value.
5. Leave the offset in place. It is stored per audio source and applies to every scene that uses that source — you do not set it again per scene, and you do not lose it when switching scenes mid-recording.

Two behaviors worth knowing. OBS can only delay audio; it cannot advance it. That is why this tool returns a negative value for late audio as a flag rather than as something to paste — the correction for late audio belongs on the video side (a source delay or a filter on the video source), and depending on OBS version a negative number in the offset field is either rejected or clamped to zero. Also, the offset moves audio within the mix after monitoring taps, so what you hear while recording changes too — if your monitoring chain adds its own latency, the next section covers why those two numbers differ.

What typical fixed latency looks like by device class

Note for obs-audio-sync-calculator: The latency ranges below are hypothetical, illustrative expectations for sanity-checking a measurement — typical orders of magnitude per device class, not measurements of specific products.

Knowing the plausible range for your gear tells you when a measurement is suspect before you act on it:

• Analog microphone into a USB audio interface. Conversion and driver buffering usually land single-digit to low-teens milliseconds at 48 kHz with a current driver. A measurement of 200 ms on this chain is almost certainly a measurement error or a monitoring-path artifact.
• USB microphone. The built-in conversion and any onboard processing typically add somewhere around 10–30 ms of fixed delay. Models that resample internally to match the host clock are also the classic drift source described earlier — fixed offset today, growing offset next month.
• Wireless microphone systems. Analog RF kits stay modest; digital systems add codec and buffer delay that can reach into the hundreds of milliseconds on consumer gear. A large, perfectly stable offset that never changes is the signature of a wireless receiver, and it is exactly the case a single sync offset corrects permanently.
• Capture cards. Embedded audio from HDMI sources frequently trails by tens of milliseconds because the card frames video before it releases audio; console output over HDMI inherits whatever processing delay the console adds. Measure per console and per card, because the number belongs to the chain, not to your show.
• Bluetooth anything. Codec buffering puts Bluetooth microphones and headphones in the 100–300 ms class. Recording with a Bluetooth mic is technically possible but the offset is large enough to survive editing; a wired path is the fix most of the time.

Use these bands as a plausibility filter. A measured offset wildly outside the expected class for your chain usually means the clap was misidentified in the timeline, the wrong audio source was measured, or a monitoring delay leaked into the test.

Monitoring latency is not recording offset

A confusion that generates endless nudging: the delay you hear in headphones is not necessarily the delay in the file. Monitoring passes through a separate path — interface direct monitoring, OBS monitoring output, or OS audio routing — each adding its own latency after the recording decision was already made. Three situations result:

• Sounds late in headphones, measures fine in the file. The recording is correct; the monitoring path is slow. Lower the monitoring latency in the interface or driver settings instead of touching sync offset.
• Sounds fine live, measures offset in the file. The recorded path carries fixed latency the monitoring path does not. This is the case the calculator exists for: apply the measured value to the source.
• Both sound and file are off by different amounts. Two independent latencies. Fix the file first with the measured offset, then address monitoring separately, or you will chase an error that moved.

OBS's own monitoring output adds delay to what you hear only — it never changes what gets written. So the golden rule holds: measure the file, correct the file, and treat headphone impressions as a separate problem with its own fix.

Verification protocol after applying an offset

Applying a value without re-measuring converts one guess into two. The verification loop takes under a minute:

1. Record 10–20 seconds containing one sharp clap or slate snap.
2. Import into any frame-accurate editor with a waveform view.
3. Measure the gap between the visual contact frame and the transient. Expect residual within one frame of zero.
4. If residual exceeds one frame, add it to the applied value and repeat once. Two iterations that still miss means the error is not constant — re-read the drift section.
5. Write the final value down next to the source name (a note in your recording template works). Rigs change latency only when hardware or drivers change, so a documented offset survives until the next gear swap.

Re-verify once after OS updates, audio driver updates, or OBS updates that touch the audio subsystem. Otherwise the stored number is durable.

Decision tree: which problem do you actually have

• Offset constant across start, middle, end → fixed latency. Apply the calculator's value once and archive the problem.
• Offset grows or wanders over time → clock drift. Lock sample rates to one value end to end, or replace the resampling device. No constant number fixes this; the calculator is the wrong tool by design.
• Recording measures fine, live stream is off → the error is downstream of OBS. Encoding and platform buffering are not corrected by source offset; check stream-specific audio settings instead.
• File fine in one player, off in another → player quirk. Trust the timeline measurement, not the player.
• Two microphones, one recording, different offsets → per-source values. Each mic gets its own row in Advanced Audio Properties; align both to the same clap and their offsets will differ by exactly the latency difference between the two chains.

Why sync matters at clipping time

Downstream tooling inherits whatever the recording carries. Transcript word timings align to the audio track, caption cues anchor to those timings, and clip boundaries snap to spoken beats — so a correct constant offset set once at the source keeps every later alignment honest automatically. Drift is the opposite case: because it changes across the timeline, no single downstream correction can absorb it, which is why the measurement step in this calculator doubles as the diagnosis. Knowing whether you have a constant or a growing error is half the fix; the number itself is the other half.

FAQ — extended

Can I fix drift with a bigger offset? No. A sync offset is constant by definition, while drift keeps growing. Any value you choose is only correct at one moment of the timeline and wrong everywhere else. Fix the clock disagreement first, then use this tool for whatever constant remains.

Does the frame rate change my offset in milliseconds? No. Milliseconds are absolute; only the frame count changes with frame rate. Re-record at a different FPS and the same physical delay measures the same milliseconds but a different number of frames.

Why does the calculator show fractional frames? Because most real offsets do not land on exact frame boundaries. OBS accepts fractional milliseconds of precision in practice, so type the ms value and treat the frame count as the cross-check against what you counted.

One recording, two mics — one offset or two? Two. Each audio source has its own Sync Offset row, and each chain has its own latency. Clap once, measure both, and enter both values.

I applied the offset but the live preview still looks off. Confirm where the error lives: record a clap and measure the file. If the file is right, the preview's own monitoring or playback latency is fooling you, and the recording — the thing that ships — is already correct.