One Second of Drift in a 40-Minute Lecture
A 40-minute lecture is recorded with a camera at 1080/25p and a separate two-track audio recorder. The camera's scratch audio is 48 kHz. The recorder was correctly set to 48 kHz for the last 22 minutes but was left at 44.1 kHz for the first 18 minutes. On the timeline the first segment starts in sync, then the recorder audio drifts progressively late, reaching about 1.1 s at 18:00; from 18:00 onward sync is stable. The lecturer's voice sounds normal in pitch throughout. The editor proposes selecting the whole audio clip and applying a 100.1% speed change, then exporting a 25 fps master and a 23.976 fps web version. The client also wants burned-in captions and a −14 LUFS web mix. There are two days before delivery and no second camera.
1. Is the drift caused by the 44.1 kHz setting? Calculate and conclude.
Read the worked answer
A true 44.1 kHz file played at 48 kHz without conversion would run fast by the ratio 48/44.1 = 1.0884, an 8.84% error. Over 18 minutes (1080 s) that would produce about 95.5 s of drift, not 1.1 s. It would also raise pitch by 12 × log2(1.0884) ≈ 1.47 semitones, which would be obvious on a lecture voice. The voice sounds normal, so this is not an uncorrected sample-rate mismatch.
The actual drift is 1.1/1080 ≈ 0.00102, or about 0.102%, which is typical of clock drift between two free-running devices, or of a recorder whose clock was slightly off before it was reset. The 44.1 kHz setting may have caused a resample on import, but the audible symptom is clock drift, not a sample-rate error. The diagnosis matters: treating it as a sample-rate problem would produce a wildly wrong speed change.
2. Give a repair workflow that preserves lip sync without audible artefacts.
Read the worked answer
Do not stretch the whole 40 minutes; the last 22 minutes is already in sync and stretching it would create a new error. Work only on the first 18 minutes.
- Split the audio at 18:00 and confirm the cut falls on a pause or a visual marker.
- Correct the first segment by 0.102% (speed it up slightly) so the end aligns. That is a pitch change of about 1.7 cents, effectively inaudible on speech. Use a high-quality time-stretch or vari-speed with pitch correction if available.
- Alternatively, cut the first 18 minutes into four or five chunks at natural pauses and align each chunk's waveform to the camera scratch. This avoids any stretch but risks small audible jumps at the cuts.
- Check sync at 5:00, 10:00, 15:00 and 18:00 against a hand-clap or a visible mouth closure, and check that the join at 18:00 has no click.
- Keep the camera scratch as a reference track, muted in the master, and lock the corrected audio to the picture before adding captions.
3. Advise on the 25 fps to 23.976 fps conversion and the audio delivery. What are the risks, and what would you deliver?
Read the worked answer
Converting 25 fps to 23.976 fps is a 25/23.976 = 1.0427 change, about 4.27% slow. If done by simply interpreting or retiming the file, the 40-minute programme becomes about 41.7 minutes and the audio drops in pitch by roughly 0.72 semitone. That is audible on a lecture and can make a presenter sound unnatural. Do not just change the frame-rate interpretation.
For the web, 25 fps is perfectly acceptable to browsers and platforms; the simplest safe delivery is a 25 fps H.264 file with 48 kHz AAC audio, captions burned in or supplied as a sidecar, and a −14 LUFS integrated mix. If the client genuinely requires 23.976, use a proper retime with frame interpolation or optical flow and pitch-correct the audio, then check for motion artefacts on hands and scrolling slides. For the broadcast master, stay at 25 fps/50i with EBU bars and 1 kHz tone, and deliver a separate −23 LUFS mix. Provide the client with a sync report and keep the 48 kHz project audio as the archive master.