Data Recovery Case File · Milestone · The Machine Told Him It Was Working

Everything Said It Was Recording

The thousand-and-fiftieth case in this archive is a puzzle with a shape, and the shape is the answer. Sound files from a day's filming, recorded to a card in a professional multitrack field recorder: "the files from the beginning and the end of the day are there but nothing in the middle. I still have the card and I have not formatted it. The sound recordist remembers the slate tone and watching the timecode roll for each clip, so is also confused as to how this happened. They should have recorded — all the actions to make them record were there — but there's nothing." He is right to be confused, and he is not at fault. The machine told him it was working, in four separate ways, and it was wrong every time.

The decode: the pattern, the mechanism, and why he saw nothing wrong

The pattern is the diagnosis. Beginning present, middle absent, end present. Random loss does not have a shape — it scatters. A contiguous missing block bounded by intact material on both sides describes something that stopped working and then started again. That single observation rules out most explanations before anyone touches the card, and it is why his precise description was worth more than any amount of speculation.

What actually happened: a recorder writes audio continuously into the data area as it records, but the directory entry naming each take — where it starts, how long it is, what it is called — is committed when the take stops. Those entries live in a small, concentrated region of the card. If that region develops a fault partway through the day, the entries stop committing while the audio itself continues to be written perfectly well. Later, after a power cycle, a battery change or a card reseat, the recorder remounts the card, the directory area is re-read or rewritten, and the end-of-day takes commit normally. The result is precisely what he describes — and it means the missing takes are very probably still on that card, as audio, with nothing pointing at them.

Now the part that makes this case 1050. The recordist watched the timecode roll. He heard the slate tone. The record indicator lit. The take counter advanced. Every one of those is the machine reporting what it intended to do. The clock display rolls because the recorder's clock is running. The slate tone sounds because the recorder generated it. The indicator lights because the recorder entered record state. Not one of them is confirmation that bytes reached the card and were committed to a filing structure. He did not miss a warning. There wasn't one.

The doctrine, stated plainly, because a thousand cases have been circling it. An indicator reports intent, not outcome. The same shape recurs throughout this archive in different costumes: a backup that reported "complete", a progress bar that reached the end, a sync icon showing a tick, a green light on an enclosure, a camera displaying the photograph it had just taken, a copy dialogue that closed. Every one of those is a device telling you what it set out to do. None is evidence of what actually happened at the far end.

And the practical form of it, which is the useful part: verify by reading back. Not on the device that wrote it — a recorder's own file list reads the same broken directory and would have shown the same gap, or nothing at all. On something else. On a shoot, that means spot-checking the card on a laptop at lunch, opening two or three takes and listening. On a backup, it means opening a file from the backup rather than trusting the report. On a copy, it means checking the destination rather than watching the source. It takes minutes and it is the only thing that converts a claim into a fact.

Why this one is solvable, and it is entirely down to him: he kept the card, did not format it, and did not record over it. Then he described the pattern precisely, including the detail about the slate tone — which is exactly the observation that identifies the failure rather than obscuring it. Everything that makes this recoverable was decided before it reached a bench.

The outcome — and the volume closes

The card was imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb, freezing the position his restraint had preserved. The directory region — the small area that had failed — was re-read on repeated passes, since records that fail one attempt frequently return on a later one, and every entry recovered there returns a take with its original name and timecode. Format-aware carving then swept all unindexed space for broadcast wave audio. The happy technical fact of this case is that professional audio files carry their own embedded metadata — scene, take and timecode — inside the file, so recovered takes were identified and placed against picture even where no filename survived. Every file was validated by playing it end to end. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee.

With case 1050 this volume closes and site five's first fifty are complete. The archive's milestones have each carried one argument, and this one completes a set: at 950, preserve before you decide; at 1000, ask the right question of the right trade; and here, at 1050, do not trust a machine's account of itself. Every indicator on every device reports an intention. The timecode rolling, the light going green, the bar reaching the end, the word complete — all of them describe what a device set out to do, and none of them describes what arrived. The only confirmation that exists is opening the thing at the other end and looking at it, on a different machine, before you need it.

The recordist did everything his profession asks. He slated every take, he watched his timecode, he checked his indicator. What nobody had told him — and what a day's location sound cost to learn — is that all four of those were the same machine agreeing with itself.

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.