MP4 / MOV File Truncated — Recovery Guide

A "truncated" video file is one that's been cut short before recording reached a clean stop. The technical definition: the file is missing its index (MOOV atom), and possibly missing some final bytes from the last in-progress frame. The functional definition: it sits on your disk looking the right size, fails to open in QuickTime / Premiere / Resolve, and reports its duration as zero (or as a weird number) when probed.

Truncated files are the most-recoverable category of video corruption. The bad news: most consumer-level "MP4 repair" tools handle them poorly. The good news: this is exactly the case our engine and tools like untrunc were built for.

What truncation actually looks like

A normal MP4 / MOV ends with a finalised MOOV atom that indexes everything in mdat. A truncated file ends mid-write:

[ftyp]    ← container declaration, intact
[mdat]    ← frames + audio interleaved
                    ↓ truncation point — recording stopped here
[the next bytes — partial frame, partial atom, or just EOF]
            ← MOOV that should be here doesn't exist

Three common patterns:

1. Power loss / card-yank truncation. The most common. mdat ends mid-frame; no MOOV; file is otherwise clean.
2. Filesystem error truncation. A bad sector zeroed out a section of the file, or the filesystem failed to write the final blocks. mdat may have a hole in it but is otherwise intact.
3. Botched copy truncation. The file was partially copied off an SD card / SSD and the copy failed. The "broken" file on the destination drive is just a partial copy of an otherwise-fine source.

Cause #3 is worth checking before any recovery: try copying the file again from the original source. If the original is still on the SD card / SSD and the file there is healthy, you've solved the problem in 60 seconds.

What "duration shows as zero" really means

When QuickTime or VLC shows a recording's duration as 0:00 or as some impossibly long value (like 4:32:18:35), it almost always means the duration is being read from a missing or malformed mvhd (movie header) inside MOOV. With no valid MOOV, there's no valid duration. The frames are still there in mdat — the player just doesn't know how long the video is.

What you can try yourself

1. Re-copy from the source

Sounds obvious. Skipped often. If the original file is still on the SD card / SSD, try copying it again to a different drive. A fresh copy with cp (or rsync, or a finder copy) sometimes produces a working file when the previous copy was the broken one.

2. untrunc

untrunc — open-source — was named after this exact failure mode. Needs a healthy reference file from the same camera in the same recording mode. Quick command:

untrunc reference.mov broken.mov

Produces broken.mov_fixed.mov. Try opening it. Excellent on cause #1 (clean truncation, no holes) when a reference is available.

3. FFmpeg ignore-errors re-mux

ffmpeg -err_detect ignore_err -i broken.mp4 -c copy out.mp4

Sometimes works on cause #2 (filesystem holes) by skipping past unreadable sections.

4. Drop the partial last frame

If untrunc or our tools complain about the last frame being incomplete, there's a manual approach: trim a few hundred MB off the end of the file and try again. The trimmed file loses the last second or two but is structurally clean. Tools that automate this (including ours) do it for you.

How our recovery handles truncation

• Six-pass diagnostic identifies whether the file is cleanly truncated (cause #1), has internal holes (cause #2), or is partially copied (cause #3).
• Frame-level scan of mdat to find the last complete frame, automatic safe-trim of any partial trailing frame.
• MOOV synthesis from observed frames — no reference clip required.
• co64 for files over 4 GB to avoid offset overflow in the rebuilt index.
• Audio recovery with chunk-size dominance filtering (skip outlier chunks, keep the consistent recording).
• Hole detection for cause #2: if the file has a zero-filled section in the middle, we identify it, skip the dead range, and rebuild around it. The recovered file may have a brief gap or a stutter at the hole, but the rest plays.

What you do

1. First: try re-copying from the source if you still have it. Free, fast, often the answer.
2. If the file is genuinely truncated and re-copying doesn't help: upload it. Up to 50 GB.
3. ~1 minute later you get a free 5-second preview.
4. Pay only if the preview works.

FAQ

My file shows the correct file size but plays for less than expected. That's a different failure mode — the recording was probably finalised but played-back duration is shorter than recorded duration. Often a mvhd timescale issue, sometimes a malformed stts. Recoverable; upload it for diagnostic.

My file plays the first 10 seconds and then crashes the player. Cause #2 (mid-file hole) is most likely. The first 10 seconds are intact mdat; the player hits the hole and can't continue. Recovery rebuilds around the hole.

untrunc failed because I don't have a reference clip. Common reason to use a service like ours. We don't need a reference — we extract codec parameters from the broken file's frames directly.

My file is from a deleted-then-recovered SD card. Is it still recoverable? Card-recovery tools sometimes return files with mixed-source data (bytes from the original recording plus bytes from later recordings overwritten on top). These are messier. Diagnostic on upload tells us if it's tractable.

The file shows wrong duration but plays correctly. Just a metadata fix — ffmpeg -i input.mp4 -c copy out.mp4 usually rewrites the duration correctly during re-mux. No paid recovery needed.

Is my footage safe? Server in France, auto-deleted after 48 hours, never used to train anything or shared. Privacy policy.

Related

• MOOV atom not found (the canonical truncation cause)
• Invalid data found when processing input
• How our recovery engine works

Upload your file →