Data Recovery Case File · Action Cameras · Found but Unplayable
Recovered files that won't play: the fragmentation decode behind every "corrupted" action-cam rescue — and one specific day brought back whole
Her enquiry had already done the triage a lab loves to receive. The SD card in her GoPro corrupted mid-use — the camera froze, and on restart demanded a format. She refused it, correctly, and left the card alone. A computer could show only the final file from the moment of the freeze. A recovery application she ran found that "the files are still there but corrupted" — recovered, yet unplayable. And because she'd already secured most of the footage from copies on the camera, she narrowed the job with a producer's precision: concentrate on one day of filming. Possible? Yes — and the gap between "found" and "playable" is exactly the decode this genre has been waiting for in this archive.
| Device | SD card, GoPro action camera — mid-recording freeze; format demanded on restart and refused; card preserved since |
| Prior attempts | Consumer recovery scan: files located but returned corrupted/unplayable · most other footage already secured from on-camera copies · target narrowed to a single day's files |
| Fault class | Filesystem corruption from an in-camera fault mid-write — the video data fragmented across the card, the map to reassemble it damaged |
| Equipment used | Write-blocked imaging · ACE Lab PC-3000 Flash · filesystem-aware fragment reassembly with container repair · playback verification |
The decode: why "recovered but corrupted" is the action-cam signature
Her app's result — files found, files broken — is not a paradox and not the software cheating; it's the honest limit of one method meeting the way cameras actually write. An action camera lays down big video files while recording, growing them minute by minute onto whatever free space the card offers — which means a long clip almost never lives in one continuous run: it's fragmented, scattered in pieces across the card, with the filesystem's records serving as the only map of which pieces belong to which file in which order. Her freeze damaged exactly that map. A recovery scan working without it falls back on signatures: it finds where video files begin — real starts, honestly found — and then reads forward hopefully, capturing whatever bytes come next; when the next fragment actually lives elsewhere, the result is a file with a genuine head and the wrong body: present, named, sized — and unplayable. "The files are still there but corrupted" is thus the fragmentation signature verbatim, and the correct response is not a third app walking the same blind path but reconstruction that recovers the map first: the card's damaged filesystem records rebuilt from their surviving structures, each clip's true chain of fragments re-established, and — where video containers took damage at the freeze itself — the files' internal indexes repaired so players will accept what's been reassembled. Her own conduct, for the record, preserved every condition this work needs: the refused format kept the old map's remnants; the untouched card kept the fragments unoverwritten; and the single-day target turned a card-wide salvage into a focused rebuild.
The recovery — one day, reassembled and watched
The card was imaged once, write-blocked at chip level on the PC-3000 Flash, and the rebuild ran on the copy in the order the decode demands: the filesystem's surviving records reconstructed until the fragment map for the target day's clips re-emerged; each clip reassembled along its true chain rather than its hopeful one; and the recording interrupted by the freeze itself — the one genuinely wounded file — given container repair, its index rebuilt to cover the footage written before the moment everything stopped. Verification was done the only way video verification counts: the clips played — end to end, the day's filming running whole where the app's versions had stuttered and died — and delivery landed as ordinary playable files on new media, alongside the honest single-line ledger: the interrupted final clip runs to the freeze and no further, because footage never written can't be rebuilt. The card retired to the report; the app's broken versions, superseded, owed nothing.
Outcome
The day recovered and playing — and the genre's rules filed where the next freezing-camera owner will search for them. "Recovered but corrupted" video means fragmentation, not destruction: the pieces are there; the app lacked the map — stop scanning and escalate to map-first reconstruction, and never let the broken versions be written back onto the card they came from. Refuse the format, every time: her single best decision, and the one that kept the rebuild possible. And borrow her scoping habit: knowing what's already safe and naming exactly what's needed — one day, one shoot, one folder — makes the recovery faster, cheaper, and verifiable against a real target. The camera froze; the map broke; the pieces waited. That's this genre in one line — and the pieces, properly chained, played.
Action-cam cards that froze mid-recording
Refuse the format prompt and stop using the card — every new recording overwrites fragments you'll want. If a recovery app returns unplayable files, don't keep trying apps: that's the fragmentation signature, and it needs the filesystem map rebuilt, not more signature guessing. Check the camera's internal copies first (they saved most of this case), narrow the target to what's actually missing, and get the card imaged at chip level. Playback is the only verification that counts for video.
The pieces need their map — call Belfast Data Recovery on 028 9002 0144 before anything else writes to that card.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.