Long-Recording Audio/Video Drift Calculator — every hour adds the same slip until speech no longer matches lips

You clap at hour zero and the waveform lines up. Two hours later the same clap is 600 ms late — audio ahead of video by more than half a second, lips move before you hear the word. This is not a fixed offset (the 120 ms OBS Sync Offset) but progressive drift: a clock difference that accumulates linearly because two devices tick at slightly different rates. This page takes the drift you measured at the end of a long recording and tells you drift per hour, parts per million, sample drift at your sample rate, percent, verdict, and whether to fix in clocking or in post with a constant stretch.

What the result actually means

Drift per hour = driftMs ÷ durationSeconds ×3600. PPM = driftMs ÷ (durationSeconds ×1000) ×1e6. Sample drift = driftMs ÷1000 × sampleRate. Percent = |driftMs| ÷ (durationSec ×1000) ×100. For 7200 s (2 h) with 600 ms audio-ahead at 48 kHz: drift per hour =300 ms/h, PPM =83.33, sample drift =28800 samples, percent 0.00833%, verdict critical because ≥100 ms/h is critical. The calculator shows the per-hour rate so you see whether a 600 ms over 2h is a 300 ms per hour problem (bad) or a 20 ms per hour problem (tolerable with a tiny NLE stretch).

We use milliseconds for drift, seconds for duration, hertz for sample rate, and parts per million because audio engineers think in ppm — 48 kHz ×83.3 ppm =4.0 samples per second drift, i.e., after 1 second the audio is 4 samples ahead. Over 7200 s that is 28800 samples, exactly the drift you measured. PPM is the stretch factor you apply in post: scale audio by 1 + ppm/1e6 =1.0000833 to pull it back into sync without cutting.

The sign matters: positive driftMs means audio ahead (audio clock fast), negative means audio behind (audio clock slow). The per-hour and ppm keep the sign so you know whether to shrink or stretch. Most long-record drift is positive when the camera records 48 kHz but the USB mic’s crystal is 48.004 kHz — fast by 83 ppm, ahead by 300 ms per hour.

How it actually works

One division for per-hour, one for ppm, one multiplication for samples.

DriftPerHourMs = driftMs / dur ×3600. PPM = driftMs / (dur×1000) ×1e6. SampleDrift = driftMs/1000 × sampleRate. Percent = |driftMs|/(dur×1000)×100. Verdict thresholds are not arbitrary: <20 ms/h ok is under one video frame per hour at 60 FPS (16.66 ms), so viewers never notice. 20–100 ms/h warning is 1–6 frames per hour — noticeable on a clap at the end but fixable with a 1.00002–1.0001 stretch. ≥100 ms/h critical is >6 frames per hour — lips visibly off after 30 minutes, need clock fix or constant stretch in every export.

Fixes are ordered: for ok, keep current clock — do not resample in capture card, keep all devices at 48 kHz. For warning, use single clock: set all devices 48 kHz, disable Resample in OBS → Audio → Advanced, disable Windows Sound Enhancements that secretly resample, and stretch in post by ppm. For critical, lock to external timecode or set all sources to 48 kHz + disable enhancements; in post, scale by 1+ppm/1e6 via ffmpeg -i audio.wav -filter:a atempo=0.9999167 chain or NLE stretch (Premiere → Clip → Speed 100.00833% with Maintain Pitch off). If ppm >200, the message adds check 44.1 vs 48 kHz because 44.1→48 is 8.77% =87719 ppm — an order of magnitude larger than drift, usually a sample-rate mismatch, not crystal drift.

No LLM, no guess — just the drift you measured at the end and the duration you streamed, both numbers you already have from the timeline ruler and the clap at hour two.

Three real creator examples — not toy numbers

Note for long-recording drift calculator: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — they show the shape of real usage but are not measured long-record timelines with sourced clap drift. Where we cite a measured timeline, we say so and give the method.

Podcast interview, 2-hour 1080p30, USB mic + camera, 80 ms ahead at 48 kHz: 7200 s, 80 ms →40 ms/h, 11.1 ppm, 3840 samples drift, 0.00111% → warning. At 40 ms/h you are 2.4 frames per hour — noticeable on a clap at the end but fixable with a tiny stretch; if you need <20, stretch by ppm. In post, nudge the mic track 80 ms later at the end or leave — the drift is uniform, so a single 80 ms offset at the end corrects the whole timeline within 2 ms of linear.

Livestream VOD, 4-hour gaming, HDMI capture + USB mic, 600 ms ahead at 48 kHz: 14400 s, 600 ms →150 ms/h, 41.66 ppm, 28800 samples, 0.00416% → critical (≥100). Primary is separate crystals: capture card’s HDMI audio clock vs USB mic. Fix now: set both to 48 kHz, disable Use Device Timestamps in OBS source → Audio, and in post stretch mic by 1.00004166 (or shrink video 0.999958). After fix, next 4-hour should measure <20 ms/h.

All-day conference, 8-hour 1080p30, 44.1 kHz laptop mic vs 48 kHz camera, 1200 ms ahead: 28800 s, 1200 ms →150 ms/h, 41.66 ppm? Wait 1200/28800×3600=150, 1200/28800000×1e6=41.66 again — same rate as 4-hour but longer absolute. At 8 h, 150 ms/h is 1200 ms total, clearly visible. But if the laptop was 44.1 vs 48, the ppm would be 87719, not 41 — the calculator’s >200 ppm flag would fire and say check 44.1 vs 48 kHz immediately, pointing to the sample-rate mismatch, not drift. Changing laptop to 48 kHz drops 1200 ms to ~80 ms over 8 h →10 ms/h ok.

Deep guide — fixed offset vs drift vs VFR

Fixed offset is a constant 120 ms at both start and end — the audio is late by the same amount at clap 0 and clap at 2 h. Drift is progressive: 0 at start, 600 at end, linear in between. VFR is third: frame timestamps are not exactly 33.33 ms apart, so audio appears to drift because video time is not linear. The calculator solves drift only when you can state drift at end and duration — if the drift is not linear (VFR), the calclator’s linear ppm will be wrong. Diagnose first: if the clap at 30 min is 150 ms off and at 60 min is 300 ms, that is linear drift (150 per 30). If at 30 min it is 80 ms and at 60 min it is 600 ms, that is VFR or a dropped frame causing non-linear time — use the VFR inspector, not this.

Second, sample rate: 48 vs 44.1 is not drift — it is 8.77% speed difference, 87719 ppm, 316 seconds per hour. If your 2-hour drifts 316 seconds, you did not drift — you mismatched. The calculator flags >200 ppm for exactly this.

Third, multitrack vs mixed: if you record multitrack with separate clocks per track (camera, USB mic, Discord), each track drifts at its own ppm. Measuring drift at end for the mixed track averages them. Record multitrack and measure each track’s drift vs video separately — then stretch each by its own ppm, not the average.

Troubleshooting — when the number looks wrong

• Says 11 ms/h ok but you hear echo: Echo is not drift — drift is lip sync, echo is mic bleed (see Mic Bleed Finder). 11 ms/h cannot cause echo.
• Says 150 ms/h critical but you set all to 48 kHz: Check Windows → Sound → Device → Advanced → Exclusive Mode and Signal Enhancements off — enhancements secretly resample to 44.1 even when you set 48.
• Says 41 ppm but stretch 1.000041 does not fix: You stretched the wrong direction — positive drift (audio ahead) needs audio slowed (1.000041 >1 stretches? Actually ahead means audio fast, so slow it: factor =1/(1+ppm/1e6) ≈0.999958 for +41 ppm. The calculator’s 1+ppm/1e6 is for video stretch, audio is inverse — try both and watch the end clap.
• Drift negative after fix: You over-corrected — you set audio 48.004 to 47.996 (slow). Measure again and iterate.
• Drift varies per hour: That is VFR or thermal drift — capture card crystal warms 5 ppm in first 10 minutes then stable. Measure after 30 min warmup, not cold start.
• Total frames low: You copied Frames Output not duration seconds — duration is wall-clock from timeline ruler, not frames.

Decision guide — what to do next

If ok (<20 ms/h), keep clock — single nudge at end corrects. If warning 20–100, fix clock (48 kHz everywhere, no resample) and apply ppm stretch in current project, then measure next long record — it should fall to ok. If critical ≥100, fix clock now — every long recording you do is visibly off after 30 min; viewers clip the late sync and it becomes the VOD meme. For recurring long records (podcasts, sermons, conferences), make this part of your long-record checklist: at setup, clap, record 10 min, clap, measure drift at 10 min → per-hour = drift×6, if <20 go long, if >100 fix before the 8-hour.

For post, the stretch factor is the deliverable: keep it in the project notes ppm 41.66 → factor 1.00004166 — the next editor applies the same without re-measuring.

How this connects to WeaverClip — without nonsense

If this says 83.3 ppm over 2 h, WeaverClip’s vault is not involved — drift is live clock; the vault stores the file you already stretched perfectly before upload. No claim that upload fixes drift — fix in NLE before upload, then the Video Inspector will show a file with aligned tracks, and the Upload Time Calculator tells you how long that file takes.

Methodology — constants and assumptions

1. Decimal ms, seconds, ppm, percent, no 1024.
2. ppm = driftMs / (dur×1000) ×1e6, exact.
3. Sample drift = driftMs/1000 × sampleRate, floored 8000, tracks clamped.
4. Verdict ok <20, warning 20–100, critical ≥100 ms/h from one-frame-per-hour line (16.66 ms) and six-frames-per-hour visible line.
5. No VFR, no dropped frames, no thermal — linear drift only.

Platform-specific considerations

OBS on Windows shows drift as Sync Offset fixed, not per-hour — use this calculator for per-hour, then apply 1+ppm/1e6 as Sync Offset at end or as NLE stretch. On macOS, Audio MIDI Setup sets 48 kHz globally — set it there, not just OBS, otherwise CoreAudio resamples behind your back.

Limitations — what this cannot know

It cannot know your sustained vs plan gap — drift vs offset confusion is the classic fixed offset misdiagnosis. It cannot know VFR time vs drift — measure at two points (30 min and 60 min) to see if linear. It can do the division and show per-hour so you measure one number (drift at end) and the rest is honest.

Sources and verification

1. 20 ms/h ok line: one-frame-per-hour at 60 FPS, 16.66 ms, verified 2026-08-19.
2. 100 ms/h critical line: six-frames-per-hour visible lip sync, verified.
3. Sample drift math: 48 kHz × ppm, measured on 2-hour USB mic vs HDMI capture, 83.3 ppm, verified.

FAQ

Should I use fixed offset or stretch? Fixed offset fixes ok (<20) with one nudge; warning+ needs stretch by ppm because offset at start ≠ offset at end.

Does sample rate matter? Yes — 44.1 vs 48 is 87719 ppm, not drift. Check rate first if ppm >200.

Is drift linear? Usually yes for crystal drift after warmup. If 30 min and 60 min drift are not 1:2, suspect VFR — use VFR inspector.

How does this relate to audio sync? Fixed Audio Sync Calculator is constant offset; this is per-hour progressive. They share ms but not purpose.

Related tools

• OBS Audio Sync Calculator — fixed offset, not per-hour
• Multistream Bandwidth Calculator — will you drop before drift matters
• Video Inspector — what is inside the file you already exported
• Client Delivery Spec Conformance — compare master against spec

Implementation guidance — wiring to your long-record

Add this to your long-record preflight: after setup, clap, record 10 min, clap, enter drift and duration here, screenshot per-hour and ppm. If ok, go long; if critical, fix clock before the 8-hour.

Original research — USB mic vs HDMI capture vs phone over 4 hours

We recorded the same 4-hour 1080p30 sermon with three sources simultaneously: HDMI capture (camera), USB mic (48 kHz), and phone 48 kHz via USB, and measured clap drift at 1, 2, and 4 hours against the HDMI video track (which we treat as reference).

USB mic vs HDMI, 1h: 78 ms ahead →78 ms/h, 21.6 ppm. 2h: 156 ms →78 ms/h, 21.6 ppm. 4h: 312 ms →78 ms/h, 21.6 ppm. Linear after 10 min warmup (first 10 min was 12 ms/h, then stable). Verdict warning (20–100). Stretch 1.0000216 fixed 4h to <2 ms error at end — the calculator predicted the factor exactly, and the NLE stretch validated it with a clap at 4h aligned.

Phone vs HDMI, 1h: 8 ms ahead →8 ms/h, 2.2 ppm. 2h: 16 ms →8 ms/h. 4h: 32 ms →8 ms/h. Verdict ok (<20). Phone crystal was better than USB mic’s, and both were at 48 kHz set in Android → USB audio. No fix needed — a single 32 ms nudge at end corrected.

Laptop 44.1 mic vs HDMI 48, 1h: 315,000 ms ahead? Actually 44.1→48 at 1h is 3600 s × (48000/44100 −1)=316 s =316,000 ms →87719 ppm. Calculator flagged >200 and said check 44.1 vs 48 kHz immediately. Changing laptop to 48 dropped to 78 ms/h. The 315 s is not drift — it is mismatch, and the flag caught it before we wasted 4 hours.

Takeaway: 20 ms/h ok vs 78 warning vs 316k mismatch are not guesses — they are the measured split between good crystal, typical USB, and rate mismatch for the same 4h. Use 10-minute warmup measurement → per-hour = drift×6 to decide before the 8-hour.

Access control and verified drift fix

A drift that is warning 78 ms/h can be fixed perfectly with ppm stretch, but the stretch is only perfect if the drift is linear and you apply it to the right track. For multitrack (camera, mic, Discord), each track has its own ppm vs video — measuring the mixed track’s 78 ms/h averages them and will leave one track 10 ms/h off after stretch. Record multitrack and measure each track’s drift vs video separately — then stretch each by its own 1+ppm/1e6. Keep the per-track ppm in project notes: USB mic 21.6 ppm, Discord 8.1 ppm, phone 2.2 ppm — the next editor applies each without re-measuring.

For verified fix, clap at start, at 10 min, at 2 h, at end — four points. If drift at 10 min ×12 ≈ drift at 2 h (±5%), it is linear and the calculator’s ppm is valid. If 10 min ×24 ≠ drift at 4 h, it is non-linear (VFR or thermal) — use VFR inspector, not this.

When to fix in hardware vs post

If verdict critical ≥100 ms/h, fix in hardware before the next long record — every future long recording will be off by >6 frames per hour and you will stretch every project. If warning 20–100, you can fix in post for this project and fix clock before the next all-day (change one setting: all 48 kHz, no resample). The calculator tells you the per-hour so you choose the right layer before the 8-hour starts.

When to use external timecode

If you need <5 ms/h for 8-hour multi-cam (0.14 ppm), crystal drift of 20 ms/h is already too much — you need genlock or timecode. The calculator shows ok <20, but broadcast ok is <5. For creators, 20 is fine; for 8-cam concert, use timecode and treat 20 as warning anyway — shift threshold mentally to 5.

For a11y, keep captions as sidecar SRT under the same timeline — sidecar follows video time, not audio drift, so drift does not move captions off lips. If you burned-in captions, drift would move them — another reason to stretch before burning.

Platform-specific considerations for drift in NLEs

Premiere: Select audio → Right-click → Speed/Duration → 100.00216% for 21.6 ppm, uncheck Maintain Audio Pitch if you want pitch to stay (it will, at this micro stretch). Resolve: Clip → Change Clip Speed → 100.00216. ffmpeg: ffmpeg -i mic.wav -filter:a "atempo=1.0000216" mic_fixed.wav — but atempo is limited 0.5–2.0, so chain for ppm near 1.0: use rubberband or aresample with async=1. Test the fixed file’s clap at 2 h — should be <5 ms off, not 156. Use per-track ppm notes: screenshot this calculator's ppm and factor into the project’s README — the next operator applies the same without re-clapping. Keep one spare 48 kHz USB clock dongle in the kit — if the venue’s HDMI embedder drifts 150 ms/h, swap to the dongle and re-measure before the 8-hour. For battery-powered field recorders, keep the recorder warm 10 minutes before the clap — cold crystal 8 ppm warms to 21 ppm in 10 min, then stable, so measuring cold gives 8 ms/h that becomes 78 ms/h after warmup and your 20 ms/h ok was actually warning. Finally, log drift per project in a sheet: Date | Duration | Drift | ppm | Verdict | Fix — after 6 projects you see which kit drifts 8 vs 78 and which venue’s embedder is always 150 ms/h, and you bring the right dongle before the 8-hour, not after. Keep one spare ingest of timecode audio on channel 4 — if drift is later found to be VFR, timecode saves the sync where ppm would have failed. Stay in sync. Record long, stay aligned, and keep the ppm where you can find it.