Die Sony FX3 ist eine fantastische Kamera — aber sie schreibt mit Bitraten, die SD-Karten an ihre Grenzen bringen. XAVC-I 4K50p schiebt 480 Mbit/s, und nicht jede V90-Karte hält das durchgängig. Wenn da ein Buffer-Underrun oder ein Karten-Crash passiert, bekommst du eine Datei, die in keinem Player läuft.

Dieser Artikel zeigt dir die spezifische Reparatur-Strategie für FX3-Aufnahmen — von der Karten-Sicherung bis zum erfolgreichen Export. Basiert auf einem realen Fall, den ich in der Memory dokumentiert habe (file000328 — 50p Class 480 nach DiskDrill-Recovery).

Was die FX3 anders macht

Sony XAVC ist nicht “einfach MP4 mit H.265”. Drei Eigenheiten machen FX3-Reparatur tricky:

1. uuid-Header mit Profile-Bytes

Bei jeder FX3-Aufnahme sitzt direkt nach ftyp eine uuid-Box mit Sony-spezifischen Metadaten. An Byte-Position 0x6e steht das exakte Codec-Profil:

7A 10 33 = Profile 122 Level 5.1 = 25p Class 240
7A 10 34 = Profile 122 Level 5.2 = 50p Class 480

Wenn nach einem Karten-Crash oder DiskDrill-Recovery diese Bytes falsch sind, wird die Reparatur das falsche Profil annehmen — und liefert Müll.

2. Multi-Track Audio mit iPCM 24-bit

Die FX3 nimmt 4 Audio-Spuren parallel auf (XLR-1, XLR-2, internes Stereo). Alle sind 24-bit PCM (Sony iPCM). Bei der Reparatur müssen alle vier Spuren parallel resynchronisiert werden — sonst hast du zwei Spuren im Sync und zwei nicht.

3. Bekannter 480ms Audio-Drift

Wegen eines Sony-spezifischen Pre-Rolls im Audio-Stream haben FX3-Files nach naiver Reparatur (untrunc Default) fast immer einen 480ms-Drift. Bei Hard-Cases bis zu 640ms.

Der Karten-Crash: erste Maßnahmen

Wenn deine FX3 während des Drehs einen Schreibfehler meldet, oder die Karte beim Auswurf “Schreibfehler” wirft:

Karte raus, FX3 ausschalten.
In den Reader (CFexpress Type A oder SD-Reader, je nach Karte). Bei FX3 ist meist SD-Karte verwendet, aber neuere Firmware unterstützt auch CFexpress Type A.
Komplette Karte als Image: sudo dd if=/dev/diskN of=~/fx3-backup.dmg bs=1m status=progress
Ab jetzt nur noch am Image arbeiten. Karte zur Seite legen, beschriften, nicht wieder verwenden bis Reparatur fertig.

Datei-Struktur auf der FX3

Im PRIVATE/M4ROOT/CLIP/-Ordner findest du:

C0001.MP4 — Hauptaufnahme
C0001.XML — Sidecar mit Metadaten (Timecode, Ratings, etc.)
C0001M01.XML — Multi-Track-Audio-Mapping

Die XML-Sidecars sind wichtig: Sie helfen bei der Reparatur, weil sie die Aufnahme-Settings explizit dokumentieren. Wenn die uuid-Bytes in der MP4 zerstört sind, kannst du aus der XML die richtige Bitrate-Class und Framerate ablesen.

Im PRIVATE/M4ROOT/SUB/-Ordner gibt’s parallel Low-Res-Proxies (für schnelle Vorschau in Catalyst Browse) — die sind oft intakt, auch wenn das Haupt-File es nicht ist. Verwende sie als Bestätigung, dass die Aufnahme tatsächlich stattgefunden hat.

Reparatur-Workflow

Schritt 1: Datei-Analyse

Lade die kaputte C0001.MP4 in unsere kostenlose Online-Diagnose. Sie sagt dir:

Ob ftyp + mdat vorhanden sind
Wie groß der mdat-Block ist
Ob das moov-Atom fehlt (häufigster Fall) oder beschädigt ist
Approximate Dauer

Wenn das ergibt “moov missing, mdat XX GB intact” — go.

Schritt 2: Referenz wählen

Du brauchst eine intakte FX3-Aufnahme mit exakt denselben Settings: Auflösung, Framerate, Bitrate-Class, Picture-Profile.

25p Class 240 ist nicht dasselbe wie 50p Class 480 — die SPS/PPS-Parameter unterscheiden sich.
S-Log3 ist nicht dasselbe wie Cine 2 — Color-Primaries und Transfer-Function-Header unterscheiden sich.

Wenn du dir nicht 100% sicher bist, sammle 2–3 verschiedene Referenzen und probiere alle.

Schritt 3: untrunc-Versuch (optional, kostenlos)

untrunc -n -s referenz.MP4 C0001.MP4

Bei FX3 oft erfolgreich beim Container, aber Audio-Drift wird mitgeliefert. Du müsstest dann das Audio noch manuell um ~480ms verschieben. Siehe Audio-Drift im Video beheben.

Schritt 4: Haven für saubere Reparatur

In Haven läuft das automatisch:

Beide Files reinziehen (kaputte + Referenz)
Haven erkennt FX3 am ftyp XAVC und der uuid-Struktur
Verifiziert das Profile durch Cross-Check von uuid-Bytes UND mdat-Frame-Struktur — falls die uuid widersprüchlich ist (DiskDrill!), zeigt Haven eine Warnung und schlägt das korrigierte Profil vor
Rekonstruiert moov mit den richtigen SPS/PPS aus der Referenz
Korrigiert Audio-Drift via Cross-Korrelation aller 4 Spuren
Entfernt Noise-Burst, falls vorhanden
Preview, dann Export

Resultat: ein C0001_repaired.MP4 mit synchronen Audio-Spuren und korrekten Color-Metadata.

Haven herunterladen →

Konkretes Beispiel aus der Praxis

Realer Case: file000328.MP4 (DiskDrill-Recovered von einer formatierten FX3-Karte). Größe ~18 MB. ftyp + mdat intakt, moov fehlt, uuid-Header zeigte 7A 10 33 (25p Class 240).

Erster Reparatur-Versuch mit C2221.MP4 als Referenz (auch 25p Class 240) → unbrauchbar, Bild war Müll.

Cross-Check der mdat-Frame-Struktur ergab 24 Frames pro 0.48-Sekunden-Block → das ist 50p Class 480, nicht 25p. Der uuid-Header war aus einem anderen Sektor reingemischt.

Zweiter Versuch mit C2297.MP4 (50p Class 480) → erfolgreich. 15.16 Sekunden Video bei 50fps, 15.20 Sekunden Audio nach Drift-Korrektur. Eine 0.36s-Lücke in der Mitte (Frame-Drop durch SD-Karten-Underrun) war unvermeidbar.

Lesson learned: Bei DiskDrill-Recovered FX3-Files niemals dem uuid-Header blind vertrauen. Immer Profile via Frame-Struktur verifizieren.

Siehe auch: DiskDrill-Recovered Video reparieren für die generische DiskDrill-Strategie.

Was die FX3 robuster macht

Drei Workflow-Änderungen, die nach diesem Vorfall meine Standard wurden:

CFexpress Type A statt SD. Schnellere, zuverlässigere Karten — bei der FX3 ohne Aufpreis nutzbar.
Proxy-Recording aktivieren. Die FX3 schreibt parallel Low-Res-Proxies. Bei jedem Crash hast du wenigstens das.
Backup nach jedem Dreh-Block. Nicht erst am Tagesende — alle 1–2 Stunden Material aufs RAID.

Sony FX3 nach Karten-Crash: Schritt-für-Schritt zur Wiederherstellung