Zum Inhalt springen

Audio läuft asynchron im Video — so behebst du Drift und Sync-Probleme

Ton läuft 500ms vor oder hinter dem Bild? Burst am Anfang? Das sind keine Player-Bugs, sondern Container-Probleme nach Reparatur. Mit ffmpeg-Befehlen und automatisierten Lösungen.

J

Jonas Becker

Codec-Research · Tech Writer · 19. Mai 2026 · 4Min Lesezeit

Du hast eine kaputte Video-Datei repariert (mit untrunc, VLC oder einem anderen Tool), und das Bild ist da — aber der Ton läuft synchron-versetzt. Manchmal vorher, manchmal nachher. Manchmal mit einem ohrenbetäubenden Rauschen am Anfang. Das ist nicht dein Player, und es ist auch keine Encoder-Eigenheit.

Es ist ein Container-Reparatur-Artefakt, und es lässt sich beheben — aber du musst verstehen, was passiert.

Warum Audio-Drift nach Reparatur entsteht

In einer MP4-Datei sind Video- und Audio-Samples interleaved im mdat-Block gespeichert. Die Sample-Table im moov-Atom sagt für jeden Audio-Sample: “Beginnt bei Byte-Offset X, ist Y Bytes lang, gehört zu Timestamp T.”

Wenn moov fehlt und ein Tool wie untrunc den Index rekonstruiert, muss es raten, wo der erste Audio-Sample im mdat-Stream beginnt. Bei den meisten Codec-Kombinationen klappt das. Bei zwei spezifischen Fällen versagt es vorhersagbar:

Fall 1: Sony XAVC mit 24-bit PCM (klassische Drift)

Sony schreibt bei XAVC den Audio-Stream als 24-bit PCM mit einem Pre-Roll von ein paar hundert Samples vor dem ersten Video-Frame. Diese Samples gehören technisch zum Video-Sync-Track. untrunc-Default zählt sie als “normaler Audio” und schiebt damit den gesamten Audio-Stream vor das Bild — typisch 480ms im einfachen Fall, bis zu 640ms bei hard cases.

Fall 2: Header-Bytes als Audio gelesen (Noise-Burst)

Wenn der Audio-Decoder nicht weiß, wo der erste echte Audio-Sample liegt, fängt er manchmal mitten in den Container-Header-Bytes an zu decodieren. Diese Bytes sind kein gültiges Audio — der Decoder rendert sie aber trotzdem, was zu einem ohrenbetäubenden Vollausschlag-Clipping in den ersten 400–1050ms führt. Bei vielen Sony- und Canon-Files passiert das vorhersagbar.

So erkennst du Drift und Burst

Drei Tests, die du in 30 Sekunden machen kannst:

  1. Spiele das Video ab und klatsche dabei in die Hände (real, vor dir). Wenn du das Klatschen in der Wiedergabe verschoben hörst, hast du Audio-Drift.
  2. Hör auf die ersten 2 Sekunden bei mittlerer Lautstärke. Wenn der Anfang ein Vollausschlag-Rauschen hat, hast du einen Noise-Burst.
  3. Spiele das Video in VLC ab und schau in die Statusleiste (View → Audio Filters → Spectrum oder so). Manche Player zeigen den Audio-Track-Offset relativ zum Video.

Manueller Fix mit ffmpeg

Bei einer einmaligen Datei mit klar gemessener Drift kannst du das mit ffmpeg manuell beheben. Der -itsoffset-Flag verschiebt den Audio-Stream relativ zum Video.

# Beispiel: Audio läuft 480ms vor dem Bild → verschiebe Audio 480ms NACH HINTEN
ffmpeg -i input.mp4 -itsoffset 0.480 -i input.mp4 \
  -map 0:v:0 -map 1:a:0 -c copy output.mp4

# Beispiel: Audio läuft 300ms NACH dem Bild → verschiebe Audio 300ms NACH VORN
ffmpeg -i input.mp4 -itsoffset -0.300 -i input.mp4 \
  -map 0:v:0 -map 1:a:0 -c copy output.mp4

Das setzt voraus, dass du die Drift exakt gemessen hast — was in der Praxis schwierig ist. Eine Schätzung von “irgendwie 500ms” reicht oft, lässt aber subtile Drift im 50ms-Bereich übrig, die bei Sprach-Aufnahmen stört.

Noise-Burst mit ffmpeg entfernen

Der Burst am Anfang lässt sich brutal mit Silence ersetzen:

# Erste 1 Sekunde stumm setzen
ffmpeg -i input.mp4 -af "volume=enable='between(t,0,1)':volume=0" \
  -c:v copy output.mp4

Das ist eine grobe Lösung — die ersten 1000ms Audio sind weg. Bei Aufnahmen mit Klatsch-Anfang oder lautem Anfang fällt das nicht auf. Bei Atmo-Aufnahmen schon.

Eine sauberere Methode ist Per-50ms-Peak-Scan: Jeder 50ms-Audio-Block wird geprüft, ob er über −3dB liegt. Wenn ja → das ist wahrscheinlich Decoder-Müll, nicht echtes Audio → stilllegen. Mit padding von 50ms vorne und hinten, damit der Burst-Übergang weich wird.

Mit ffmpeg ist das eine Pipe aus mehreren Filtern und nicht trivial in einem Befehl auszudrücken. Es ist genau die Art Algorithmus, die Haven automatisch macht.

Vollautomatisch mit Haven

Bei Haven läuft die Audio-Reparatur als 3-Stufen-Pipeline nach jeder Container-Reparatur:

  1. Per-50ms-Window Peak-Scan jeder Audio-Spur. Alles über −3dB im 1-Sekunden-Fenster nach Datei-Start wird als Burst markiert und gestillt (mit Padding für Übergang).
  2. Cross-Korrelation zwischen Audio-Stream und Video-Frame-Pulsen (aus dem mdat extrahiert) misst die Drift millisekundengenau.
  3. Audio-Track wird verschoben (-itsoffset intern) und auf Video-Dauer truncated.

Das Ergebnis: Alle Audio-Streams sind exakt video_duration, kein Burst, kein Drift. Das ist der eigentliche Differenzierungs-Vorteil gegenüber generischen Repair-Tools.

Haven herunterladen →

Tabellarisch: ffmpeg vs Haven beim Audio-Sync

Problemffmpeg manuellHaven automatisch
Drift messenEigene Schätzung, oft ±50msCross-Korrelation, ±1ms
Drift korrigieren-itsoffsetAuto
Burst entfernenGrob mit volume=enablePer-50ms-Scan mit Padding
Multi-Track Audio (4-Spur FX3)Pro Track manuellAlle Tracks parallel
VerifikationTrial & ErrorVisueller Preview

Sonderfall: Drift bei iPhone Cinematic-Mode

Bei iPhone-Cinematic (Dolby Vision Profile 8.4) gibt’s einen weiteren Audio-Drift-Pfad: Der Audio-Stream hat einen eigenen Track-Edit (elst Atom) mit Pre-Skip, der bei der Container-Rekonstruktion oft verloren geht. Das resultiert in ~50ms Drift, der nicht von Sony-XAVC-Drift stammt, sondern eigene Ursachen hat. Haven erkennt iPhone-Files anhand des mvhd-Brand-Identifiers und wendet die richtige Korrektur an.

Siehe auch: iPhone Video reparieren

Zusammenfassung

Audio-Drift nach Video-Reparatur ist kein Player-Bug, sondern ein Container-Artefakt. Die wichtigsten Erkenntnisse:

  1. Sony XAVC hat fast immer 480ms Drift nach naiver Reparatur — ist eine Stream-Pre-Roll-Eigenheit
  2. Noise-Burst am Anfang kommt von Decoder-Müll-Bytes — lässt sich mit Peak-Scan automatisch entfernen
  3. ffmpeg kann beides manuell beheben, ist aber Trial & Error
  4. Automatisierte Tools (Haven) machen das per Cross-Korrelation und Per-50ms-Scan in einem Schritt

Für eine einzelne Datei mit gemessener Drift reicht ffmpeg. Für mehrere Files oder unbekannte Drift-Größen ist die automatische Pipeline schneller und genauer.

Audio-Drift in deiner Datei prüfen →

Mehr Kontext: MP4-Container verstehen erklärt, warum die Sample-Table die zentrale Rolle bei der Sync-Problematik spielt.

Über den Autor

J

Jonas Becker

Codec-Research · Tech Writer

Hintergrund in Informatik mit Fokus auf Video-Container und Stream-Parsing. Schreibt bei Haven die Deep-Dives — von HEVC NAL-Unit-Strukturen bis zu Dolby-Vision-RPU-Metadaten.

Spezialgebiet · HEVC · ProRes · Container-Standards · NAL-Unit-Analyse

Newsletter

Wenn neue Reparatur-Anleitungen erscheinen — eine Mail. Maximal monatlich.

Keine Marketing-Sequenzen, keine Werbe-Mails. Nur Notification, wenn ein neuer Pillar-Guide, ein Codec-Deep-Dive oder ein Vergleichs-Review live geht.

Kein Spam. Abmeldung mit einem Klick aus jeder Mail.