Audio that is out of sync needs a different fix depending on whether it is displaced by a steady amount or drifting further out over time. Measure a visible and audible event near the start, middle and end before editing, then verify the corrected copy in the playback path you intend to use.
A single timing shift can correct a stable offset, but it cannot align a file whose audio and video run at different rates. Keep the original, work on a copy, and choose a correction from the measurements rather than applying a delay value borrowed from another file.
Diagnose a steady offset or growing drift
Start by describing what you see and hear, not by opening an editor and moving a track. Pick an event that has a clear visual moment and a sound at roughly the same point: a clap, a drum hit, a door closing, or a spoken word with a visible mouth movement. Check it near the beginning and then compare one or more later events.
If the sound is late by roughly the same interval at each point, the file has a constant offset. The audio may, for example, follow every drum hit by the same small gap. A measured shift of the audio can then bring those events into closer alignment across the file.
If the sound starts close to the picture but falls further behind, or moves progressively ahead, you are seeing drift. A single shift can make one point look right, but it will leave another point wrong. The correction needs to address the timing rate or timestamp handling, not just the starting position.
There can also be a third case: the file appears synchronised in one player but not another. Variable-frame-rate video stores timing information with frames; a player or editor that handles those timestamps differently may display the same file differently. Before altering the source, check whether the issue follows the file into more than one player or only appears in the software you use to prepare the stream. A constant-frame-rate re-encode can sometimes be a case-specific workaround for software that mishandles variable-frame-rate timestamps, but it is not a general remedy for all sync problems.
Capture problems can create progressive drift too. Audacity’s recording troubleshooting notes that differences between application, operating-system and sound-device rates can make tracks run at different speeds. Its guidance is about recording and overdubbing, not a claim about YouTube playback, but the distinction matters: latency correction cannot repair a rate mismatch that grows across a recording. Read the Audacity recording troubleshooting notes if the file came from a recording workflow.
Measure sync near the beginning
Use a copy of the file for diagnosis and note the event you are measuring. A waveform can help locate a sharp transient, but do not rely on waveform shape alone: the relevant question is when the audible event occurs relative to its visible counterpart. Listen and watch the same moment, then estimate whether audio leads or lags and by how much.
Choose an event close to the start, but not necessarily the first frame or sound in the file. Intros, fades, silence, black frames and room noise can make the opening misleading. If a presenter says a word while turning away, for instance, the mouth movement may not give a precise cue; a hand clap or a clearly struck instrument is easier to compare.
Write down the direction and approximate size of the mismatch, and repeat the observation rather than trusting a single impression. Headphones, display delay and the player’s buffering can affect what you perceive during playback. The goal is not laboratory precision at the first pass; it is a repeatable reference that lets you distinguish a stable displacement from a change over time.
Do not assume file metadata tells you whether content is in sync. Tools such as ffprobe can report a stream’s start time, which is useful for understanding how streams begin relative to one another. It cannot reveal an offset already embedded in the recorded pictures and sound. A file can have matching-looking start metadata and still show a clap that occurs before or after its sound. The FFmpeg documentation describes its stream and timestamp controls; use them to inspect and process media, not as a substitute for checking the content.
For a playlist of several clips, keep a short measurement note for each file. A file that begins late may need one correction, while the next file may be aligned at the start and drift by the end. Applying one playlist-wide delay because one clip needs it can make the other clips worse.
Check the middle and end
Repeat the same comparison at a point around the middle and near the end. Use a clear event at each location; it does not have to be the same type of event, but you should be confident that the sound and image refer to the same action. For a long devotional video, a sharp cymbal strike can serve as a useful cue early on and a later hand-clap or beat can show whether the relationship has changed.
Record the observations together. A simple note such as “sound slightly late at start, similar gap in middle and end” suggests a fixed offset. “Near together at start, sound increasingly late by the end” suggests drift. If the sound changes from late to early, or the measurements are inconsistent, check more events and consider whether the player, edit points, fades, or ambiguous cues are confusing the diagnosis.
The amount of change across a known duration helps estimate the rate problem. You do not need to invent a correction from a single impression. Measure at separated points, make a tentative correction on a working copy, then inspect the same points again. If the gap shrinks at one point but grows elsewhere, the correction is not yet right.
When the symptom occurs only in one editor or playback application, check the file in a second one before re-encoding. Some software may mishandle variable-frame-rate timestamps even when those timestamps are correct. Converting to constant frame rate may help in that particular workflow, but it changes the video and may require re-encoding. It should be a deliberate compatibility choice, not the automatic response to any audio delay.
This distinction is especially useful when one clip sits inside a longer playlist. The guide to looping a long rain video in OBS focuses on a different format of stream, but its concern with checking how a source behaves while looping is relevant here: inspect a clip’s end and its return to the beginning, not only a convenient moment in the middle.
Correct a measured fixed offset
Once repeated checks show about the same displacement from beginning to end, shift the audio by the measured amount. If it consistently arrives late, move it earlier; if it consistently arrives early, move it later. The direction may sound obvious, but write it down before changing anything: confusing “audio ahead” with “audio delayed” is an easy way to double the problem.
In an editor, move the audio track as a whole while leaving the video and the audio’s internal timing unchanged. In a command-line workflow, FFmpeg offers timestamp and offset controls, but the appropriate option depends on the input streams and the output you need. Its -itsoffset option is one tool for a measured stream offset; examples in general guides are not universal commands. The FFmpeg Cookbook sync guide discusses offset approaches, but treat any example as a starting point to adapt and verify, not as a value to copy.
A shift can expose another issue. If the file begins with silence or a fade, moving audio earlier may place sound before the visible clip begins; moving it later may leave silence at the opening. Decide whether that is acceptable for the programme, trim or pad thoughtfully if needed, and check transitions. Do not trim away a useful opening simply to make a measurement look tidy.
Make one correction at a time and export a new file rather than overwriting the original. Recheck the same start, middle and end events. If the gap remains roughly steady but is still noticeable, adjust the measured offset on the next working copy. If the gap now changes across the file, stop treating it as a simple offset and investigate rate or timestamps.
Correct timing rate or timestamps for drift
A growing gap means the relative timing changes with elapsed time. A constant shift changes where audio starts, not how quickly it proceeds. You can align the clap at the beginning with a shift and still have the final song or spoken passage far out of place. Do not try to solve that by shifting the track again; it merely chooses which part of the file will be wrong.
First ask where the file came from. If audio and video were recorded separately, check the capture application, operating system and device sample-rate settings, and whether the same device or clock was used throughout. If a new recording track progressively moves away from an existing one, Audacity’s manual says latency correction will not synchronise it over its full length when their speeds differ. Correcting the recording cause can prevent recurrence, but it does not by itself repair a file already exported with drift.
For an existing file, estimate the timing-rate adjustment from observations at separated points across the duration. The measurements need to show both direction and how the error changes. A video or audio stream with incorrect timestamp treatment may call for a timestamp-aware remux or a case-specific re-encode; audio whose actual duration differs may need a rate or time-stretch correction. Those are not interchangeable fixes, so identify whether the content’s timing is wrong or a tool is interpreting its timestamps incorrectly.
FFmpeg includes filters and stream controls for media processing. Its rubberband filter can change duration while preserving pitch, but only if the particular FFmpeg build includes librubberband; the FFmpeg filter documentation records that requirement. Time-stretching can alter sound quality, particularly on music or sustained tones, and re-encoding may be involved. Listen to representative passages after processing rather than assuming the output is transparent.
A constant-frame-rate copy is another possible answer when the evidence points to software mishandling variable-frame-rate timestamps. It may require re-encoding video as well as audio, takes time, and can affect quality. Use it only when a second-player comparison supports that diagnosis. A file with genuine audio-rate drift is not automatically fixed by changing the video frame-rate mode.
If you cannot establish a sensible rate correction from the measurements, do not guess. Keep the original, gather clearer sync events, inspect the source settings, or ask someone experienced with the particular format to review the file. A plausible-looking command is not evidence that the resulting copy is correct.
Export a corrected copy
Use filenames that distinguish the source from each attempt, such as evening-loop-source.mp4 and evening-loop-sync-check.mp4. Keep a note of the tool and settings used. This makes it possible to compare versions and return to the untouched source if a correction causes a new problem. It is sensible workflow practice, not a special format requirement.
Export using settings your streaming workflow can handle, and avoid changing unrelated properties unless there is a reason. For a fixed offset, the objective is to preserve the content while moving the audio timing. For a rate correction, any resampling, time-stretching or re-encoding should be intentional. Re-encoding audio can change its sound; re-encoding video can change visual quality and takes additional processing. There is no single export recipe that fits every source format and playlist tool.
After export, open the new file independently and check the same measured events again. Watch the start, middle and end, then listen through a representative musical or spoken passage. A sharp transient may align while a voice still feels wrong, or vice versa. Include fades and transitions in your check, particularly if one clip is meant to follow another without a pause.
If the playlist repeats a clip, inspect the loop point as well as events within the clip. A small gap, abrupt cut, or tail that overlaps the next start may be a separate edit issue rather than sync drift. Fix it as a separate decision; changing the audio rate to hide a poor loop can damage timing elsewhere.
For a channel built around separately recorded audio, the guide to separate OBS audio tracks may help you think through where sound is routed in a live production. It does not replace correcting timing embedded in a prepared file, but it can help you separate a file problem from a capture or routing problem.
Verify it in the intended streaming path
A local file preview is necessary, but it does not establish how every streaming setup will play that file. Test a representative corrected clip through the same playlist source, encoder and monitoring route you plan to use. Check the actual stream, not just the preview window, and confirm a clear event near the beginning and later in playback. Different buffering, timestamp handling or monitoring delay can make the path behave differently from a desktop player.
If you use OBS or another local streaming application, confirm which media source is being played and whether its loop, restart or playlist behaviour matches the planned broadcast. Avoid judging sync from a delayed preview alone; compare the stream’s picture and sound consistently, and use a known event. For a channel that depends on a computer remaining on, the electricity-cost guide for a 24/7 stream on a mini PC in Delhi is relevant to the separate operating decision, but power planning cannot correct a file’s timing.
Where the channel uses an uploaded-file workflow rather than a computer running the playlist, the corrected copy still needs to be checked before it is used. StreamNeo can remove the need to leave a personal computer running the upload-to-stream process, but that does not change the need to prepare and verify a synchronised file. A service’s playback route and your chosen source file are separate parts of the result.
Repeat the test if you change the export settings, swap the playlist player, or replace the source file. Keep the final verified copy clearly labelled and use that copy in the playlist. If the sound is out of sync only in the actual stream, return to the source and path checks rather than compensating blindly with another edit.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How can I tell whether audio needs a shift or a rate correction?
Compare a clear audio-and-picture event near the start with events later in the file. About the same gap at each point suggests a fixed offset; a gap that grows or shrinks suggests drift. Check more than one event before editing, especially if the cue is not visually clear.
Can I fix growing drift by moving the audio track once?
No. Moving a track changes its starting position but not its rate, so one part may align while another remains out of sync. Measure across the file and investigate the timing rate or timestamp handling instead.
Does FFmpeg metadata show whether the recorded content is synchronised?
Stream start-time information can describe how streams begin, but it does not show whether a clap or spoken word is already offset inside the content. Compare visible and audible events in the file itself, then verify the processed copy. Use command examples only after adapting them to the measured case.
Should I trust a local preview before using the playlist?
Use it to catch obvious problems, then check the file through the intended playlist and streaming path as well. Playback tools can handle timestamps or buffering differently, so a local preview alone cannot establish what a particular stream setup will do.