Case notes · Memory cards · MHD-2025-6907
The Wedding Footage Would Not Open.
A videographer from Bracknell, home from a marquee wedding at a farm out towards Warfield, arrived with a card that had turned strange overnight: the last three files of the night will not import at all
. What he said next gave us a starting point — the card says they are full size, so the footage must be sitting in them
— and the couple were flying out inside a fortnight.
Much the same fault? Call us.
0800 6890668
In everyday terms.
He had reasoned it correctly, and the mechanism is worth setting out. While a camera records, it writes picture data to the card continuously; the index — the table saying where each frame begins — is only committed when the file is closed. Take the card out while the access lamp is still going and you keep the frames but lose that table; a flat battery or a card that fills up ends the same way. Players and edit suites find their way around a clip by the index and nothing else, so a file packed with frames but carrying no map opens as though it were empty.
What the bench used here.
How a job is handled →| Tool | Why we used it | What it brings |
|---|---|---|
| Klennet Carver | Wrapped the surviving frames in fresh containers the edit suite would accept | It knows how a video file is assembled; blunter tools return fragments nothing will play |
| PC-3000 Flash | Made the sector-by-sector copy of the card before any repair began | Reads the NAND chips directly, matched against a maker-ID library that is kept up to date |
| UFS Explorer Professional Recovery | Lifted the sound clips and the card's directory structure from that image | Reads the awkward filesystems others stumble over: APFS, ReFS, XFS, ZFS, Btrfs |
The lab work.
Nothing happens before the copy exists
Not a word of diagnosis was offered until the card had been imaged. A date already promised to a client will change how quickly a job moves; it does not entitle anyone to experiment on the only original that exists. Everything afterwards ran against the copy, while the card went into a sleeve and stayed in it, held back in case a second read was ever wanted.
Separate the clips that play from the ones that do not
The bulk of the wedding came off the image without complaint and went straight into safe storage. Only then were the three problem files opened up properly, and his theory survived the test: frame data present in quantity, the closing index cut short on two of them and missing altogether on the third. Everything that followed was decided by that.
Use the healthy clips as the template for the broken ones
Footage from a camera does not sit in one continuous run, and fragmentation is precisely where one-click utilities give up; whatever they produce opens in nothing. Intact clips from half an hour earlier, same body, same codec, same settings, supplied the pattern. Each broken file was assembled around whatever frames had survived, then tested in the one way that means anything: watched from start to finish.
How the job closed.
Two of the three returned complete and were watched all the way through before they left. The third plays cleanly until the final seconds, which were still in the camera's buffer at the moment the card was pulled. The couple had the film before their flight.
More of the jobs we've closed.
Filed on the Memory cards shelf.
Does any of that match your case?
Nothing needs deciding until the diagnosis is back: switch the device off, send it in, and let the findings settle it.