Interrupted recording recovery comes down to one question that determines almost everything: did the camera finish writing the file, or did it stop before the index was written? Video files carry their index at the end, so a clip whose recording ended abruptly is usually complete footage with a missing table of contents. It will not play, no player will open it, and yet the frames are sitting on the card. The failure is in the last few kilobytes of the file rather than in the tens of gigabytes before it.
The exception is when the damage lands in the wrong place. If the interrupted write destroyed the leading index of a chaptered sequence, the file may need its predecessor to be rebuilt, and the problem changes from “repair one file” to “reconstruct a series.”
Why an unplayable clip is not a damaged clip
Container formats such as MP4 and MOV are organized in boxes, and the box that matters here is the movie box — the moov atom — which holds the index of every track and the timing tables that map file offsets to playback time. That index is written when the recording closes, not when it starts.
This design exists because the index cannot be written before the recording ends: the camera does not know the duration, the sample count, or where the last sample will land until it stops. The consequence is that every recording is one interrupted moment away from producing a file with valid media and no map. The camera writes media data first and metadata last, so a power loss, a battery pull, a card removal, or a firmware hang all produce the same artifact: a large, structurally orphaned file.
The first counterintuitive fact in this topic follows from that. The clip you cannot open is not corrupted in the sense of containing damaged frames; it contains frames the player has no way to locate.
Case one: the trailing index never arrived
This is the common case and the better one. The file exists with a plausible size, the directory entry describes it, and every byte written before the interruption is intact. Only the closing metadata is absent.
Salvageability is high. A repair tool reads the media stream, measures the samples that are actually present, and writes a new index at the end of the file. The result is a clip that plays to the exact moment the recording stopped, which is normally everything you wanted. Nothing is recovered beyond that point because nothing was ever written.
Two honest limits apply. The last fraction of a second is frequently lost, because the camera’s write buffer had not been flushed. And if the file was shot with a codec that depends on periodic intra-frame references, a repair that ends mid-GOP will trim back to the previous keyframe rather than present partial frames.
Case two: the leading index is damaged, and the chapter matters
The harder case involves chaptered recording, which splits a long take into a numbered sequence of files — a behavior common to action cameras and drones.
In a chaptered sequence, the first file carries initialization data the later files do not repeat, and later files reference the frames that preceded them. That means an interruption that damages the first file of a sequence is qualitatively different from one that damages the last. Damage to the last file is a local problem: the earlier chapters are complete and playable on their own. Damage to the first file can affect every chapter after it, because the reference frames the rest of the sequence needs live there.
The practical rule is to examine the sequence in order and note which file is anomalous. A broken final chapter is usually a repair. A broken first chapter with the rest intact is the case where a tool has to rebuild the missing references, and the outcome may be visibly imperfect at the start of the rebuilt section. How chapters are structured and why they exist is explained in the chapter system used by action cameras; the corruption patterns that follow are catalogued under corrupted chapter sequences; and the reassembly workflow, once the files are repaired, is documented in the guide to reassembling chaptered video.
Three checks before you touch anything
Run these in order. They take five minutes and they determine whether the recovery is routine or delicate.
Check the file’s presence and size. In the camera’s folder, find the file with the last recorded timestamp. If it exists at close to the expected size — a 4K clip runs tens of megabytes per second, so a 4 GB file is a normal chapter — the media was written and only the index is missing. If the size is zero, the header was never committed and the media may have to be carved out of free space. If the file is absent from the directory, the entry was never written and a signature scan of the whole card is the route.
Check whether the file is the last of a sequence. Sort the folder by name. A run of consecutively numbered clips with one final clip that fails to open tells you the damage is at the tail. A gap in the numbering, or a first clip that will not open while the rest do, tells you the damage is at the head and the repair is more involved.
Check what the file actually contains by opening it in a hex viewer. Look at the first bytes. A valid MP4 begins with a file-type box in the first few bytes, and a valid MOV does the same in a different form. If the header is missing or unrecognizable while the file has real size, the media stream is present but unindexed. If the header is present and the file still will not play, the failure is almost certainly the missing trailing index.
| What you find | What it means | Salvageability | Approach |
|---|---|---|---|
| Large file, valid header, will not open | Trailing index never written | High, up to the interruption point | Rebuild the index from the media stream |
| Large file, unreadable header | Header region damaged | Medium; media present, structure unclear | Scan for the media stream and reconstruct the header |
| Zero-byte file | Recording never committed anything | Low from the file itself | Carve the media from the card’s free space |
| File missing from the folder | Directory entry never written | Medium | Signature scan of the entire card |
| Plays briefly, then stops | Index written partially | High for the visible duration | Rebuild and extend the index from the remaining samples |
| Earlier chapters fine, last one broken | Tail-of-sequence damage | High for the earlier chapters | Repair the last file; earlier ones need no work |
| First chapter broken, later ones intact | Head-of-sequence damage | Medium | Rebuild using cross-file references from the sequence |
Copy before you try, and here is the reason
The rule that governs every step after the checks is simple, and it is not merely cautious advice: copy the entire card to a disk image or a folder before running any repair or scan.
The reasoning has three parts, and the third is the one that catches people out. First, a card that has just been interrupted may be failing hardware rather than merely busy, and each additional operation is an opportunity for it to stop responding entirely. Second, most repair operations write to the file they are fixing, so a failed attempt can leave it worse than it started. Third, and least obvious: a camera that powers back on frequently performs its own repair pass over the file system, and truncated files are exactly what such a pass is designed to clean up. Some cameras will truncate, rename, or remove a damaged clip during that pass.
That is why “copy first” is not a preference here. It is the difference between a file with recoverable content and a file that no longer exists.
If the interruption was caused by power rather than by the card, the same sequence applies and the mechanics of the failure are explained in the analysis of losing power during recording. If the card itself was removed or the camera shut down without warning, the situation is the general one described in the camera video recovery workflow.
Working the repair
Once the copy exists, work on the copy. For a file with a valid header and a missing index, an index rebuild is a single operation and is the highest-value repair available. For a file whose header is damaged, the repair must locate the media stream by signature and synthesize a header, a more fragile operation that often yields a clip with visible artifacts at the start.
If the media stream is intact but the container cannot be rebuilt, the alternative is to extract the elementary stream and remux it into a fresh container. This produces a playable file with correct video but typically loses chapter markers, embedded telemetry, and the original timecode. In footage where the gyro or telemetry data matters for stabilization or mapping, that loss is significant, and the note on recovering low-resolution proxy files explains why a proxy copy can sometimes stand in when the primary will not.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive. If a file is recovered but will not play, the frames are usually complete and a repair pass over the recovered file will index them. The habit of checking files before you delete the source, rather than after, is the subject of the workflow for verifying recovered files.
Frequently Asked Questions
Is the last clip from an interrupted recording recoverable?
Usually yes, if the file exists with a plausible size. That pattern means the media was written and only the trailing index is missing, and rebuilding the index normally recovers everything up to the moment the recording stopped.
Why does a video that was recording fine refuse to open at all?
Container formats store their index at the end of the file, so a recording that never closed has media but no map. Players rely on that index and decline to open the file rather than searching for the frames themselves.
Should I let the camera repair the file when it powers back on?
No. Cameras frequently run a repair pass at startup that truncates or removes damaged clips, which can destroy the only copy. Copy the card to a computer first, then work on the copy.
The last chapter is broken but earlier ones are fine. Do I need to repair all of them?
No. In a chaptered sequence the earlier files are self-contained, and only the damaged chapter needs work. If it is the first chapter that is damaged, the repair is harder, because the later chapters depend on references it holds.