Data Recovery Case File · Solid State & Flash · The Device Is Fine
A Recording Interrupted Before It Was Closed Was Never a Complete File
Her enquiry concerns one file rather than a device. A recording made on a stick that doubles as a recorder, where "when I try to copy the file to my computer it says the file or directory is corrupted or unreadable." The stick works and everything else on it copies — which points away from storage failure and towards a recording that was stopped before it was finished being written.
| Media | USB device incorporating a recording function — single audio recording reported as corrupt on copying; remaining content unaffected |
| Reported situation | Recording made using a combined recorder and storage device · attempt to copy that recording to a computer · system reporting the file or directory as corrupt or unreadable · other content on the device copying normally · recording required |
| Fault class | Incompletely finalised media file — container structures absent or partial following interrupted recording; storage device not implicated |
| Equipment used | Device health separated from file integrity by testing other content · device imaged write-blocked before any repair attempt · file structures examined for absent or partial finalisation · recording rebuilt by reconstructing container structures around the retained stream · output validated by playback in full |
The decode: why one file fails when the device does not
What the other files copying establishes: the device reads, the filesystem works, and the connection is sound. A failing stick does not fail selectively on one item while returning everything else cleanly, so the fault is very likely in the file rather than in the storage.
What that error commonly reports: the system read the file's description and found it inconsistent with what is actually there. It is a structural complaint rather than a statement that the data is absent, and the wording covers several quite different conditions.
Why a recording device produces this specific problem: media files are written in two parts. The recorded stream goes down as it is captured, and the structures describing it — length, format, index — are written at the end when recording stops properly.
Why that ordering matters so much: a recording interrupted before it was stopped never reaches the second part. The captured audio is on the device and the description of it is missing, so anything reading the file finds a header promising nothing and a body it cannot interpret.
What interrupts a recording in that way: the battery running out, the device being unplugged, a power loss, or the recording being ended by removing the device rather than by stopping it. All produce the same result, and none of them damages the stored audio.
Why the outlook is good: the substance is present. What is missing is a description that can be reconstructed, because the format of the stream is known and its actual length can be measured from what is there.
How that reconstruction works: the stream is extracted, its parameters determined from the data itself, and correct container structures built around it. The result is a playable file of the right duration, which is verified by playing it through to the end rather than by its size.
Why copying it first would be worth trying and probably will not work: the system refuses to copy a file whose structure it cannot parse. The refusal is protective in intent and unhelpful here, since the raw content is readable at a lower level even when the file will not open.
Why nothing should be attempted on the device: repair utilities offered for this error operate on the filesystem, not on the file's internal structure. They can remove an entry they regard as invalid, which would take the recording with it.
What must not happen: no further recordings on the device, no repair prompts accepted, and no consistency check run against it. The device is working, which means anything written to it now has somewhere to land.
On the bench
Device health was separated from file integrity by testing other content — a failing device not returning most items cleanly while failing one, so the fault lies in the file. Media recordings are written in two parts, the captured stream during recording and the describing structures on proper closure, so an interruption before closure leaves the substance present and its description absent. The recording was rebuilt by reconstructing container structures around the retained stream and validated by playback in full.
The outcome
Device health separated from file integrity, the device imaged before any repair attempt, and the recording rebuilt around the retained stream. Free assessment, one fixed written figure including VAT. The decode: your stick is fine, which the other files copying proves. A recording is written in two parts, and the part describing it goes down only when recording stops properly — so an interruption leaves the audio present with nothing describing it.
A single recording that will not copy or open
Don't run a repair or consistency check on the device — those work on the filesystem rather than the file's internal structure, and can remove an entry they regard as invalid, taking the recording with it. Take the fact that everything else copies as good news: a failing device doesn't fail selectively on one item. What's usually happened is that a recording was interrupted before it was stopped properly — battery, unplugging, power loss — and media files are written in two parts, with the structures describing length and format written only on proper closure. The audio is there; its description isn't.
Don't repair the device — call Manchester Data Recovery on 0161 871 0788; device health separated from file integrity, imaged before any repair attempt, container structures rebuilt around the retained stream.
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.