Recovery methodsTechnicalUpdated October 17, 2026 · Data Recovery Cases Editorial Team

Recovering Fragmented Video from Memory Cards

A long recording on a memory card is not always stored in one contiguous run, and when it is not, recovering it depends on finding which card clusters belong to the file and in what order. Signature carving of one contiguous region can produce a clip that plays at the start and fails later; the container’s own index helps check a candidate but does not tell you where the pieces lie on the card.

In short

Fragmentation on the card has to be shown from evidence, not assumed from file size or camera model.
“Fragmented” can mean four different things; only scattered clusters is a card-layout problem.
Container offsets are positions in the file, not card clusters; they check an assembly but cannot replace a lost extent map.
Directory records, FAT chains and the allocation bitmap play different roles and can be cleared after deletion.
Container repair cannot recreate missing payload; report partial results as partial.

Four things “fragmented” can mean

The same word is used for several unrelated properties of a video recording. Only one of them describes how the data is laid out on the card, and the presence of another does not prove it.

Scroll horizontally to see the full table →

Four distinct senses of “fragmented” for a camera recording, and what each implies for recovery.
Sense	What it describes	What it does not prove
Filesystem fragmentation	The file’s clusters on the card form more than one noncontiguous run (extent)	Anything about the container’s internal structure; the file itself may be perfectly valid once its clusters are read in the right order
Camera split files	One continuous recording session stored as several consecutive files, each a separate filesystem object	That any one of those files is scattered on the card; each part can be contiguous or fragmented on its own
Interleaved tracks	Video and audio chunks alternating inside the file’s media data, with each track’s chunks located by the index	Card fragmentation; interleaving is the order of data inside the file, not the placement of the file on the card
Fragmented MP4 layout	A container written as a series of fragments, each carrying its own piece of the index alongside its media (for the ISO BMFF byte stream used by browsers: an initialization segment, then movie fragments each followed by their media data, per the W3C ISO BMFF Byte Stream Format, §3–4; this does not describe any particular camera)	Scattered clusters; it is a container design choice, and such a file can sit in one contiguous run on the card

Fragmentation has to be established, not assumed

On FAT/exFAT, a large recording can become fragmented across the card depending on prior deletions, the layout of the remaining free space, earlier clips and the way the device’s recording software allocates space. None of those factors makes fragmentation certain. A long recording on a well-used card may be fragmented, and a long recording on a freshly formatted card may well be contiguous, but which applies to a given file is something to establish from the filesystem evidence or from a verified assembly, not to infer from the file size or the card’s history.

Allocation behaviour is a property of a particular device and firmware. A recorder might preallocate space, grow the file as it writes, or close one file and start another at a size or time limit, but the specific behaviour of a camera or drone model should only be relied on when documentation for that model, or evidence on the card itself, supports it. Without that, no allocation scheme should be attributed to the camera as guaranteed.

File offsets are not card clusters

Two address spaces are involved, and they are easy to confuse. The container index — the sample tables in the moov atom of an MP4/MOV file — describes positions inside the file. In the QuickTime File Format, the chunk offset table gives the position of each chunk “into the containing file”, and these are file offsets rather than offsets into any atom; a separate sample-to-chunk table maps samples to those chunks. This describes the ordinary, non-fragmented layout; in a fragmented MP4 the sample information is also spread across the movie-fragment structures. In both cases the container addresses positions in the file, while the filesystem maps file offsets to clusters on the card.

So a surviving moov tells you that a chunk should begin at a given byte position of the reassembled file, but not which card cluster holds that byte. That makes the index useful as a check on a candidate assembly: if the chunk at a stated offset decodes as the expected kind of sample, that supports the checked region itself, not every earlier extent or the whole file; if it lands in unrelated data, something earlier is missing or out of order. It cannot replace a lost extent map, and it says nothing about where on the card the remaining pieces are, or whether they still exist.

What FAT and exFAT metadata can and cannot show

The pieces of filesystem metadata that matter here do different jobs. A directory record gives a file’s first cluster and its size; on its own that is the start and length of the file, not a complete map of a fragmented chain. On FAT12/16/32, the rest of the chain is recorded in the FAT, which links each cluster to the next.

exFAT separates these roles further. The FAT describes cluster chains as singly linked lists, but it does not record whether clusters are allocated — the allocation bitmap does that, one bit per cluster, and the bitmap shows only whether a cluster is in use, not which file it belongs to or in what order. A stream extension entry records the FirstCluster and DataLength of the file’s allocation, and when its NoFatChain flag is set, the allocation is one contiguous series of clusters and the corresponding FAT entries are not to be interpreted. For a file flagged that way, the first cluster and the length are enough to describe the layout; for a file that uses the FAT chain, they are not.

After deletion, this information can no longer be assumed to be intact. A directory entry marked as not in use may be overwritten by the implementation as needed, and a FAT chain may be cleared or reused by later allocations, depending on the implementation and what happened to the card afterwards. Where the records and chain do survive, they are the strongest evidence of the file’s true cluster order, and recovering them before falling back to carving is the principle covered in File-System Recovery vs. File Carving and Allocation Metadata, Orphaned Files and Lost Space. Where they are gone, the order has to be reconstructed from content, with correspondingly lower confidence.

Where signature carving runs out

Simple contiguous carving recovers the data from a matched header onward, assuming the file continues in the following clusters. For a fragmented recording, that output can have a completely valid-looking beginning and still fail partway through, because once the file stops being contiguous the carver is reading someone else’s clusters — or free space — as if they were the rest of the clip.

More specialized tools can search for further fragments and try to chain candidates together using content structure. That can recover more of a recording, but it does not guarantee that the fragments are in the right order or that all of the original bytes are present; the result is a candidate assembly that still needs to be checked. File Carving and Signature-Based Data Recovery covers carving in general.

Codec markers are corroborating evidence, with limits

Structures inside the compressed stream — NAL unit boundaries, frame headers, or similar cues — can help confirm that a candidate fragment boundary is plausible once filesystem metadata or the container index has narrowed down where to look. They are not a universal scanner. H.264 and related codecs can be packaged with start-code prefixes (the byte-stream format in Annex B of ITU-T H.264) or with length-prefixed NAL units, which is the form usually found in MP4/MOV files; other codecs use different structures; and short patterns resembling a marker can occur by chance in compressed payload. Which markers are meaningful depends on the codec and the packaging actually used in the recording, and that should be documented for the case rather than assumed.

A safer order of work, on a copy

Stop writing to the card immediately

Every additional write to the card — a new recording, the camera’s own re-indexing, or an attempted repair run directly on the card — is a chance to overwrite exactly the fragments a proper reconstruction would still need.

Preserve the card: image it read-only and keep the error map of any areas that could not be read, so that later conclusions can tell unread areas from data (see How to Image a Failing Drive Safely).
On the image, examine the filesystem evidence: directory records, FAT chain or NoFatChain flag, allocation bitmap, and how far each survives.
Build a candidate assembly of the file’s clusters — from surviving metadata where possible, from content-based reconstruction where not — and record which parts rest on which evidence.
Only if the container itself is incomplete or unfinalized, repair the container on a copy of the assembled file (see MP4 and MOV Container Repair).
Check the result with a full decode of video and audio across the whole duration and a timeline check against the expected length, not a preview of the opening seconds (see How to Validate Recovered Data).

A result with gaps, a truncated end or regions that could not be placed should be reported as partial, with the missing or uncertain ranges stated, rather than described as a repaired clip. Container repair can make the surviving media playable; it cannot recreate payload that was never recovered or has been overwritten.

A clip that plays at first and fails later

This symptom has several different causes, and they lead to different next steps.

Training scenario: a recovered clip plays for a while, then breaks

Observed

A recovered clip from a camera card opens and plays normally for the first part, then shows corrupted frames, freezes or stops, while the expected recording length was much longer.

Interpretation

Three causes should be separated. A missing extent: the index points to file offsets that land in unrelated data or beyond the end of what was recovered. Wrong ordering: the right data is present but out of sequence, so the index lands in plausible media of the wrong kind or the wrong time. Missing finalization: the payload is present, but the recording was interrupted and the index is absent or covers only part of it.

Safer next step

Work on the image: check whether directory records and the chain or NoFatChain flag survive, compare the candidate assembly against the index where one exists, and treat container repair as the step for missing finalization only.

Limit

If the missing extents were overwritten or never recovered, no reordering or container repair restores those frames; the honest result is a partial clip with the gap documented.

What a reference clip can and cannot show

A reference clip recorded with the same camera, ideally with the same settings, firmware and recording mode, can help characterize the expected container structure, codec packaging and file-splitting behaviour for later analysis. It should always be recorded onto a different card, never onto the card that still needs to be recovered.

Its value is limited to the format. It does not prove how the lost recording was laid out on the original card, since that depended on the free space and history of that card at the time, and it cannot supply frames that are missing from the lost recording.

Technical references: Microsoft exFAT file system specification — FAT chains, allocation bitmap, NoFatChain · Apple QuickTime File Format: chunk offset atom — chunk offsets are file offsets · Apple QuickTime File Format: sample-to-chunk atom — samples mapped to chunks · FFmpeg bitstream filters, h264_mp4toannexb — length-prefixed vs. start-code H.264. The FFmpeg page documents one implementation, not the H.264 standard.