Audio video sync offset calculator
The audio video sync offset calculator turns a measured sound lead or lag into an exact correction.
Run — free
Runs in your browser. Free, unlimited — your data never leaves this page.
Enter the detected audio offset in milliseconds using a positive value when sound arrives before the matching picture, or a negative value when sound arrives afterward. The result states whether to delay audio or delay video, gives the non-negative delay to apply, and preserves the signed measurement for reference. This makes a commonly confusing sign decision explicit before you configure an editor, transcoder, player, or muxing workflow.
Describe the detected offset with one consistent sign convention
Begin with a measurement that compares the audio event with the matching visual event. A hand clap, slate strike, door closing, or spoken consonant with a clear mouth movement can provide a useful reference. Enter a positive number when the audio is early: for example, enter 180 when the sound is heard 180 milliseconds before the corresponding frame. Enter a negative number when the audio is late: enter -240 when the picture reaches the reference event 240 milliseconds before its sound. This convention describes the position of audio relative to video, not an option copied from a particular editing application. That distinction matters because applications label offsets differently. Some tools ask when an input should begin, while others ask how much delay to add, and their positive signs may mean opposite things. By recording the detected relationship first, you keep the observation independent of any software interface. The calculator preserves that signed measurement in its result and separately provides the corrective direction and magnitude, so the original evidence and the action cannot be confused.
Apply the correction to the stream that arrives early
Synchronization is restored by delaying the stream that arrives first. When the entered value is positive, audio leads the image, so the result says delay_audio and returns that same magnitude as audio_delay_ms. When the entered value is negative, audio lags behind the image, which means video is early; the result therefore says delay_video and uses the absolute magnitude as video_delay_ms. The offset_ms field is always non-negative and expresses the amount of delay to apply. The other stream receives a delay of zero, making the intended operation explicit for automation. A zero measurement returns none because neither stream needs to move. This calculation does not stretch, resample, trim, or otherwise alter media. It computes a start-time alignment correction only. If synchronization begins correctly but drifts progressively during playback, a fixed offset is not sufficient; investigate mismatched sample rates, frame-rate interpretation, clock drift, or damaged timestamps. For a stable lead or lag, however, applying one delay to the early stream aligns the corresponding events without changing playback speed.
Transfer the result safely into an editor or muxing workflow
Use direction to decide which track or stream receives the delay, then use offset_ms as the magnitude. Before entering it into another tool, confirm whether that tool accepts milliseconds, seconds, frames, or timeline timecode. Convert units without changing the correction described by this result: 250 milliseconds is 0.25 seconds, while a frame conversion also depends on the project frame rate. If an interface uses a signed shift rather than a named delay, consult its documentation and map the named direction deliberately, because its sign convention may differ from the detected_audio_offset_ms convention used here. Test the corrected output around several sharp events near the beginning and end of the program. Multiple checks help distinguish a constant offset from gradual drift and reveal measurements based on an ambiguous sound. Keep the original signed measurement alongside the correction in job metadata or review notes. That record explains why a stream was delayed and makes later revisions reproducible. The calculation is deterministic, requires no media upload, and can be inserted into quality-control scripts that already receive an offset from waveform analysis or manual review.
What you can do with it
Correct a separately recorded microphone track
Turn a measured early or late microphone track into the exact stream delay needed before muxing it with camera footage.
Prepare an editing timeline correction
Convert a reviewer-reported sync error into an unambiguous delay direction and millisecond magnitude for an editor.
Automate media quality-control fixes
Feed a detector's signed offset into a pipeline and route the resulting delay to the correct audio or video stage.
FAQ
What does a positive audio offset mean?
It means audio leads the matching video event. Delay audio by the returned offset_ms value.
What does a negative audio offset mean?
It means audio lags the matching video event, so video is early. Delay video by the returned offset_ms value.
What happens when the offset is zero?
The direction is none and both stream delays are zero because no start-time correction is needed.
Can this correct sync drift over time?
No. It calculates a fixed alignment delay. Progressive drift usually requires correcting timing, sample-rate, frame-rate, or timestamp issues.
What does the calculation cost?
Each API request costs $0.002. The calculation is deterministic and does not upload or process a media file.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/video/mux-audio-offset \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"audio_offset_ms":180}'const res = await fetch("https://api.kit.forhosting.com/video/mux-audio-offset", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"audio_offset_ms": 180
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/video/mux-audio-offset",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"audio_offset_ms": 180
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/video/mux-audio-offset", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"audio_offset_ms":180}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"audio_offset_ms":180}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/video/mux-audio-offset", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"audio_offset_ms": 180
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "video.mux_audio_offset",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 500 |
max_minutes | 60 |
max_megapixels | 3.9 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |