Sony FX3 After a Card Crash: Step-by-Step Recovery

The Sony FX3 is a fantastic camera — but it writes at bitrates that push SD cards to their limit. XAVC-I 4K50p pushes 480 Mbit/s, and not every V90 card holds that consistently. When a buffer underrun or a card crash happens there, you end up with a file that won’t play in any player.

This article walks you through the specific repair strategy for FX3 footage — from backing up the card to a successful export. It’s based on a real case I documented in my notes (file000328 — 50p Class 480 after a DiskDrill recovery).

What the FX3 does differently

Sony XAVC isn’t “just MP4 with H.265.” Three quirks make FX3 repair tricky:

1. A uuid header with profile bytes

Every FX3 recording has a uuid box sitting right after ftyp, holding Sony-specific metadata. At byte offset 0x6e you’ll find the exact codec profile:

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

If those bytes are wrong after a card crash or a DiskDrill recovery, the repair will assume the wrong profile — and hand you garbage.

2. Multi-track audio with 24-bit iPCM

The FX3 records 4 audio tracks in parallel (XLR-1, XLR-2, internal stereo). All of them are 24-bit PCM (Sony iPCM). During the repair, all four tracks have to be resynchronized together — otherwise you end up with two tracks in sync and two out of sync.

3. A known 480 ms audio drift

Because of a Sony-specific pre-roll in the audio stream, FX3 files almost always have a 480 ms drift after a naive repair (stock untrunc). On hard cases, up to 640 ms.

The card crash: first steps

If your FX3 reports a write error mid-shoot, or the card throws a “write error” on eject:

1. Card out, FX3 off.
2. Into the reader (CFexpress Type A or an SD reader, depending on the card). With the FX3 it’s usually an SD card, but newer firmware also supports CFexpress Type A.
3. Image the whole card: sudo dd if=/dev/diskN of=~/fx3-backup.dmg bs=1m status=progress
4. From now on, work only on the image. Set the card aside, label it, and don’t reuse it until the repair is done.

File structure on the FX3

In the PRIVATE/M4ROOT/CLIP/ folder you’ll find:

• C0001.MP4 — the main recording
• C0001.XML — the sidecar with metadata (timecode, ratings, etc.)
• C0001M01.XML — the multi-track audio mapping

The XML sidecars matter: they help with the repair, because they explicitly document the recording settings. If the uuid bytes in the MP4 are destroyed, you can read the correct bitrate class and frame rate straight from the XML.

In the PRIVATE/M4ROOT/SUB/ folder there are low-res proxies alongside the clips (for quick preview in Catalyst Browse) — these are often intact even when the main file isn’t. Use them to confirm the recording actually happened.

Repair workflow

Step 1: File analysis

Load the broken C0001.MP4 into our free online diagnosis. It tells you:

• Whether ftyp + mdat are present
• How big the mdat block is
• Whether the moov atom is missing (the most common case) or damaged
• The approximate duration

If it comes back with “moov missing, mdat XX GB intact” — go.

Step 2: Choose a reference

You need an intact FX3 recording with the exact same settings: resolution, frame rate, bitrate class, picture profile.

• 25p Class 240 is not the same as 50p Class 480 — the SPS/PPS parameters differ.
• S-Log3 is not the same as Cine 2 — the color primaries and transfer-function headers differ.

If you’re not 100% sure, gather 2–3 different references and try them all.

Step 3: The untrunc attempt (optional, free)

untrunc -n -s referenz.MP4 C0001.MP4

Often successful on the container with the FX3, but the audio drift comes along for the ride. You’d then have to shift the audio manually by ~480 ms. See Fixing audio drift in video.

Step 4: Haven for a clean repair

In Haven, this runs automatically:

1. Drag both files in (the broken one + the reference)
2. Haven detects the FX3 from the ftyp XAVC and the uuid structure
3. Verifies the profile by cross-checking the uuid bytes AND the mdat frame structure — if the uuid is contradictory (DiskDrill!), Haven shows a warning and proposes the corrected profile
4. Reconstructs moov with the right SPS/PPS from the reference
5. Corrects the audio drift via cross-correlation across all 4 tracks
6. Removes the noise burst, if present
7. Preview, then export

The result: a C0001_repaired.MP4 with synchronized audio tracks and correct color metadata.

Download Haven →

A concrete example from practice

A real case: file000328.MP4 (DiskDrill-recovered from a formatted FX3 card). Size ~18 MB. ftyp + mdat intact, moov missing, and the uuid header read 7A 10 33 (25p Class 240).

First repair attempt with C2221.MP4 as the reference (also 25p Class 240) → unusable, the picture was garbage.

A cross-check of the mdat frame structure showed 24 frames per 0.48-second block → that’s 50p Class 480, not 25p. The uuid header had been mixed in from a different sector.

Second attempt with C2297.MP4 (50p Class 480) → success. 15.16 seconds of video at 50 fps, 15.20 seconds of audio after drift correction. A 0.36 s gap in the middle (a dropped frame from an SD card underrun) was unavoidable.

Lesson learned: with DiskDrill-recovered FX3 files, never trust the uuid header blindly. Always verify the profile via the frame structure.

See also: Repair DiskDrill-recovered video for the generic DiskDrill strategy.

What makes the FX3 more robust

Three workflow changes that became my standard after this incident:

1. CFexpress Type A instead of SD. Faster, more reliable cards — usable on the FX3 at no extra cost.
2. Enable proxy recording. The FX3 writes low-res proxies in parallel. After any crash, you’ll at least have those.
3. Back up after every shooting block. Not just at the end of the day — offload material to the RAID every 1–2 hours.

Related guides

• Repair Sony video — the complete overview
• DiskDrill recovered a video, but it won’t open
• Fixing audio drift in video
• Wedding video broken — first aid

Check your FX3 file locally →