A faulty SD card has trapped roughly "20 videos" from her GoPro in an odd limbo: each one copies across to a laptop perfectly well, yet "cannot be opened", even though "their properties are still displaying a size". A file with size but no playback is the classic signature of container damage — the footage itself sits on the card in full, but the small structural map that tells a player how to read those megabytes has gone missing or corrupt. In all likelihood the picture is still there; what the file has lost is its own table of contents.
| Media | Approximately twenty GoPro video files copied from a faulted SD card — full-size on disk, unplayable in any application; the original card's availability to be confirmed |
| Reported situation | SD card fault during or after recording · affected clips copy normally between devices · every player refuses them · file sizes intact and plausible for the footage lengths · copies currently held on a laptop |
| Fault class | Damaged or unfinalised MP4 container structure — index and metadata atoms lost to the card fault, with the encoded video and audio streams likely present in the body of each file |
| Equipment used | Original card, where still available, imaged under a hardware write-blocker in preference to working from copies · file internals examined at hex level in X-Ways Forensics to establish which structures survived · container rebuilt against a reference clip from the same camera and settings, indexes reconstructed from the stream data itself · PhotoRec sweep of the card image for footage the filesystem no longer references · every repaired clip validated by full playback |
A video file is a body of footage plus a small map, and only the map has to fail. The encoded frames sit in one large region; a compact structure elsewhere records what format they are, where each frame starts, and how audio interleaves. Players refuse a file whose map is damaged even when every frame survives — which is exactly how a clip keeps its full size while showing nothing.
A card fault produces this pattern naturally. Cameras write footage as they go and finalise the map at stop. A card failing mid-write, or corrupting the sectors that held those structures, leaves bodies without maps across however many clips were touched — twenty unplayable files is one card fault expressed twenty times, not twenty separate strokes of bad luck.
That the clips copy cleanly is quietly good evidence. Copying reads every byte; copies that complete without errors say the file bodies read back intact from wherever they now live. The damage is structural rather than a spreading corruption of the footage itself.
Repair is reconstruction, not hope. The same camera writing the same settings produces the same internal layout every time, so a healthy reference clip acts as an anatomical model: the broken files' stream data is parsed directly, frame boundaries recovered from the encoding itself, and a fresh index built to describe what is actually there. Done properly this is deterministic — the clip plays because its new map is true, and each repaired file is proven by watching it play end to end.
The original card outranks the copies, if it still exists. Copies inherit whatever the filesystem believed at copy time. The card itself may hold more — earlier fragments, clips the fault orphaned entirely, cleaner versions of damaged regions — and it costs nothing to image it write-blocked and sweep beneath the filesystem before declaring the copies the whole story. A card that faulted once is also finished as a recording medium, whatever else is true.
The honest edge case is stated up front. Where a card fault landed inside a clip's body as well as its map, that clip repairs to a version with a visible flaw at the damaged point — a glitch, a skip — rather than to perfection. Most container cases repair completely; the exceptions are reported per clip, not discovered by the customer.
The card was imaged under a hardware write-blocker and the copies gathered alongside. Each affected file was examined at hex level in X-Ways Forensics to establish surviving structure, then rebuilt against a reference clip from the same camera and settings, indexes reconstructed from the stream data. The card image was swept with PhotoRec for unreferenced footage, and every repaired clip validated by full playback before return.
Containers rebuilt from the streams themselves, the card swept for orphaned footage, and each clip proven by playback. Free assessment, one fixed written figure including VAT; where recovery is not possible, nothing is charged. The decode: your videos kept their size because the footage never left — the card fault took the map, not the territory. Rebuilt against your camera's own anatomy, they play again, and the card that caused it all retires.
Keep the copies exactly as they are and resist re-recording over the original card — it may hold orphaned footage beneath the filesystem, so set it aside write-protected. Don't run generic "video fixers" over your only copies; failed repair attempts can overwrite recoverable structure, and any legitimate repair works on duplicates against a reference clip from the same camera. Size intact plus refusal to open usually means the picture survived — it is the file's index that needs rebuilding, not the footage.
Our case files are written up from genuine enquiries our lab has handled for customers across Sheffield and South Yorkshire, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery approach our engineers apply to that fault, using the equipment listed.
Free diagnostic, fixed quote, no fix no fee — start now or call the freephone.