What Causes Audio to Drift Out of Sync Only After Transcoding?

Audio drifts after transcoding when the generated audio timeline no longer advances at exactly the same rate or timestamp boundary as the video.

Direct play can hide the problem because the client consumes the original container and its native timing instructions, while transcoding decodes, resamples, re-encodes, timestamps, segments, and remuxes one or both streams. Start by deciding whether the error is a fixed offset, a gradually increasing drift, or a jump introduced by seeking or resuming. Those patterns point to different parts of the media pipeline.

Classify the Sync Error Before Changing the Transcoder

Play from the beginning without seeking and record the offset near the start, middle, and end. Use a scene with a visible impact or speech consonant rather than estimating from background music.

A fixed offset that remains constant suggests an initial timestamp, edit-list, receiver delay, or client setting. A gap that grows steadily suggests mismatched clock rates, frame-rate interpretation, audio stretching, or resampling. A sudden jump after seek or resume points to segment and restart timestamps.

Repeat the measurement with subtitles disabled and with the client’s manual audio-delay setting at zero. Correcting a moving drift with one static offset only hides the symptom at one timestamp.

Prove That the Original File Is Synchronized

Play the source locally in a trusted desktop player and direct play it through a compatible media client. Test the same timestamp range that drifts during transcoding.

If the source also drifts locally, inspect or repair the media file before changing the server. If the source remains synchronized everywhere except the transcoded path, preserve the file and capture the media-server playback decision, FFmpeg command, and client version.

Use a second file with the same codecs and a known-good timeline as a control. One problematic title points toward source timestamps or container metadata; many titles failing on one client point toward a common transcoder, segmenter, or player path.

Identify Which Streams Are Actually Being Converted

Check whether the session performs audio-only transcoding with video stream copy, a remux with no codec conversion, or a full video-and-audio transcode. These paths create different timing boundaries.

Audio-only conversion can still desynchronize after a seek. A Jellyfin issue reproduced audio desync after seeking when E-AC-3 or DTS was converted to AAC while the video stream remained copied.

Switch to a client-supported audio track while keeping video, quality, and subtitles unchanged. If the session becomes Direct Play and the drift disappears, focus on audio timestamps, resampling, channel conversion, or the generated delivery container rather than video encoding performance.

The ZimaSpace overview of the audio transcoding pipeline provides the adjacent mechanism for interpreting this stream-level test.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Test Playback From the Start, After Seeking, and After Resume

Run three controlled sessions with the same client and file: uninterrupted playback from zero, a seek beyond the buffered region, and resume from a saved position. Record exactly when synchronization changes.

Transcoded 4K playback has been reported to remain synchronized from the beginning but shift after scrubbing, chapter changes, or resume. The distinguishing condition is a timeline change during transcoding, not the raw ability to decode the media.

A separate Jellyfin report shows resume-specific desynchronization even when the source file itself is correct. That pattern isolates resume handling before any library-wide remux.

If only seek or resume fails, test another delivery container or client player when the application exposes that option. Keep uninterrupted playback as the control so the result is attributable to timestamp restart behavior.

Inspect Source Timing, Frame Rate, and Audio Stretch Metadata

Use a media probe to record video frame rate and time base, audio sample rate, stream start times, duration, negative timestamps, edit lists, and any track delay or stretch values. Compare the first and last presentation timestamps.

Some Matroska tracks intentionally carry a linear timing adjustment to match audio from a source with a different frame rate. A Jellyfin issue describes linearly drifted audio tracks that remain usable in the original container but are mishandled during transcoding.

If the audio duration differs proportionally from the video duration, create a corrected test copy that explicitly resamples or time-stretches the audio once, then remux it with clean timestamps. Preserve the original and test one title before applying any batch repair.

Check HLS or fMP4 Segment Timestamp Behavior

Inspect the transcoder command for seek flags, timestamp copying, negative-timestamp handling, HLS segment type, segment duration, and whether a new transcoding process starts after the client moves beyond buffered content.

A Jellyfin timestamp investigation found that imprecise seek behavior could restart an HLS stream at an offset from the original timeline. The key failure was misaligned transcoded timestamps, which then affected client-rendered timing.

Do not copy command-line flags from an unrelated version into a production container. First update or roll back the server and client within supported paths, clear only regenerable transcode segments, and compare MPEG-TS, fMP4, or native-player behavior when the application provides those choices.

Apply the Smallest Fix and Run a Full-Duration Verification

Use the branch proven by testing: select a compatible audio track or client, avoid the failing seek/resume path, change the supported streaming container, update or pin the media-server build, or normalize one source with broken timing metadata.

Do not re-encode every movie because one television app drifts. A client-specific failure should be corrected at the client or playback-profile layer, while a source-specific linear drift belongs in that file’s timing repair.

Verify the repaired path from start to finish, then repeat a seek and resume near the original failure point. The issue is resolved only when the offset remains stable across the full duration, generated segments preserve the expected timeline, and the same settings survive a client restart and server recreation.