Audio Out of Sync After Trimming a Video?

Audio goes out of sync after a trim because the cut was made without re-encoding. A stream-copy trim can only start video on a keyframe, but audio can start at the exact second you picked, so the two streams begin at different times. The fix is to re-cut the original file with a tool that re-encodes, which makes video and audio start at the same instant. [Trim Video](/trim-video) does this: it decodes up to your start point and re-encodes with H.264 and AAC, so the cut lands on the exact frame. Cut from the untouched original, not from the already-broken trim, or the offset is baked in. If the drift grows over the clip instead of staying fixed, the cause is different, covered below.

Video is stored as keyframes plus frames that depend on them. A copy-mode cut cannot start on a dependent frame, so it begins at a keyframe, while audio has no such limit. We tested it: a synthetic 20 second clip with a keyframe every 5 seconds, cut at 7 seconds for 6 seconds with ffmpeg -c copy. In the result, audio started at 0.012 s but video did not start until 3.000 s, a gap of about 3 seconds where sound plays over nothing. A cut placed before the input instead gave streams that both start at 0, with video 6.10 s long against 6.00 s of audio. The offset equals the distance to the nearest keyframe, so a source with sparse keyframes shows it worst.

Two commands tell you which problem you have. First, compare stream start times: run ffprobe -show_entries stream=codec_type,start_time -of csv=p=0 on the trimmed file. If video and audio start times differ by more than a few hundredths of a second, the cut was keyframe-snapped. Second, check for variable frame rate on the original: ffprobe -select_streams v -show_entries stream=r_frame_rate,avg_frame_rate. If the two numbers differ noticeably, the source is variable frame rate, which is common in phone and screen recordings. A fixed offset at the start points to the keyframe cause. Drift that grows the longer the clip plays points to variable frame rate. Our synthetic test file reported 30/1 for both values, so it was constant frame rate.

Load the original file into [Trim Video](/trim-video), drag the handles to your start and end, and run it. The tool places the start offset after the input, so ffmpeg decodes from the beginning of the file and discards frames until your start time rather than jumping to a keyframe. It then re-encodes with libx264 at CRF 23 and AAC at 128 kbps. We ran those same arguments on the test clip above and got video and audio both starting at 0.000 s and both lasting 6.000 s. It accepts MP4, MOV, WebM and MKV up to 2 GB and always writes an MP4. Everything runs in your browser, so the file is not uploaded.

A frame-accurate cut is not lossless. Re-encoding is slower than copying, because the browser has to decode and encode every frame, and a long or high-resolution file takes noticeably longer. It also makes a second lossy generation, so quality drops slightly, and file size can go up instead of down for sources that were already heavily compressed, as [trimmed video bigger than the original](/blog/trimmed-video-bigger-than-original) shows with measured numbers. If sync matters more than speed, accept that trade. If you must keep the original streams untouched, cut at a point that sits exactly on a keyframe, though finding one without a dedicated editor is awkward.

A drift that widens as the video plays is usually variable frame rate, not the trim. Phone cameras and screen recorders vary the frame spacing to save space, and some players and editors assume a constant rate, so audio slowly pulls ahead or behind. Trimming did not cause it, but it can expose it. The most reliable fix is to convert the original to a constant frame rate before or while cutting, with an ffmpeg command using the -r option, then trim the result. For plain format changes, [Convert Video](/convert-video) is the place to start. Also test in a second player first: a file that looks wrong in one app and fine in another is a player problem. If the picture also looks rotated, [videos turning sideways after converting](/blog/video-sideways-after-converting) covers that separate metadata issue.

The same rule applies in any app: a fast trim that finishes instantly is probably copying streams and can shift the picture, while a trim that exports slowly is re-encoding and stays aligned. Quick cut modes in file managers and cloud storage preview players are the usual culprits. If you trim inside Dropbox, [how to trim a video in Dropbox](/blog/how-to-trim-a-video-in-dropbox) explains what that editor does with your file. After any trim, play the first few seconds with attention on a clap or a spoken word, since that is where an offset is easiest to hear.