How to fix audio delay in a video by shifting the sound

To fix audio delay in a video, shift the two tracks back into line and save a new file: if the sound comes late, cut the delay off the start of the sound; if it comes early, cut it off the start of the picture. With Sume, when the clip is already hosted on Sume, detach its audio and render the clip over it in Timeline 1.0, with the delay as audio.source_in for late sound or as the slot's source_in for early sound.

The facts come from the Timeline 1.0 and Audio detach docs and the field descriptions in the Sume API reference, read on 2026-09-27. Anything described as current behavior is read from Sume's code.

Is the delay in the file or in the player?

Check before you edit. If the same file plays in sync in another player, the delay comes from playback, and a new render will not change it. The fix below is for a file whose sound is off by the same amount from start to end. If the gap grows over the clip, a single shift lines up only one point.

Measure the offset yourself at a sharp moment, such as a clap or a hard consonant: note when it is seen and when it is heard. The difference is the delay d in seconds.

How do I shift the audio with Sume?

The clip must already be your workspace's media.sume.com artifact or asset, such as an earlier Sume job's output; Sume has no public upload route for a file on your computer (which URLs each endpoint accepts). Detach its audio with POST /v1/audio-detach. The default output is a sample-exact wav, the file a Timeline audio.url wants, and the result reports its duration_seconds. Then render the clip over that wav with the delay in one of two fields:

curl -X POST https://api.sume.com/v1/timeline-1.0/render \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: resync-clip-001" \
  -d '{
    "audio": {
      "url": "https://media.sume.com/artifacts/artf_demo/clip.wav",
      "source_in": 0.3,
      "duration_seconds": 59.7
    },
    "output": { "width": 1920, "height": 1080 },
    "video": [
      { "source_url": "https://media.sume.com/artifacts/artf_demo/clip.mp4", "start": 0, "duration": 59.7 }
    ]
  }'

What can make the shifted render go wrong?

The example fixes a 60-second clip whose sound is 0.3 s late. These rules keep it valid:

• audio.source_in works on a single audio.url spine. The output still runs duration_seconds, so the file must hold source_in + duration_seconds, or the render fails audio_source_in_exceeds_source.
• For early sound, drop audio.source_in and give the slot source_in: 0.3 instead. Keep the slot's source_in plus duration within the clip, because a slot that runs past its clip is filled by render.pad_mode.
• The default output is 1080×1920, so set output to the clip's size.
• In the current compiler a render's sound comes only from its spine and an optional soundtrack, so the clip's old, out-of-sync track is not mixed back in.

What does the fix cost, and what does it cut?

The new video is d seconds shorter. For late sound, the first d seconds of sound and the last d seconds of picture are dropped; for early sound, it is the other way around. Each step bills on its own, plus a 5.5% agent fee by default. Detach bills per job at the rate in GET /v1/catalog, and the render reserves $0.10 per output minute on API pricing, counted as ceil(audio.duration_seconds / 60) minutes; it never charges more than its reservation.

To replace the sound instead of shifting it, see replace or remove the audio in a video.

• Detach reads sources up to 1,800 s and writes at most 900 s. For a longer clip, detach two ranges and pass them as audio.parts[]. For late sound, put the delay on the first part's own source_in: a top-level audio.source_in with parts is refused with audio_source_in_requires_single_spine.
• A render outputs 1 to 1,800 seconds.