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 exception is stated up front. Where a card fault landed inside a clip's body as well as its map, the repair gives a version of the clip with a visible flaw (a glitch or a skip) at the point of damage, rather than a perfect result. Most containers are fully restored; exceptions are reported clip by clip, not left for the customer to discover.
The card was imaged under a hardware write-blocker and the copies were gathered alongside. Every affected file was analysed at hex level in X-Ways Forensics to establish what structure remained, then rebuilt against a reference clip from the same camera and settings, with indexes recreated from data within the video stream. The card image was swept with PhotoRec for unreferenced footage, and every repaired clip was verified through full playback before being returned.
Containers rebuilt from the streams themselves, the card swept for orphaned footage, and every clip proven through full playback. Free assessment, one fixed written figure, plus VAT; where recovery is not possible, nothing is charged. The decode: your videos kept their original size because the footage itself never left the card. What the card fault took was the map, not the territory. Rebuilt to match your camera's own anatomy, they play again, and the card that caused it all is retired.
Keep the copies in their current state and don't record over the original card, because it may still hold orphaned footage underneath the filesystem; put it away write-protected. Do not run generic "video fixers" on your only copies, since a failed repair attempt can overwrite recoverable structure, and any legitimate repair works on duplicates using a reference clip from the same camera. If the file size is intact but it won't open, the picture has usually survived: it is the file's index that needs rebuilding, not the footage itself.
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.
Alongside a free diagnostic and a fixed price quote, in most cases you only pay if we recover your data. Start now or call our freephone number today.