Data Recovery Case File · Formatted & Logical Faults · The Index Is Written Last
Interrupted Recording: the Size Is Right and It Will Not Play
Her enquiry described a single file rather than a device, and it is one of the most repairable situations in this archive. A voice memo "likely corrupt due to power shutdown mid-recording. Size of file seems right — around 30MB — but cannot be played. File length around 35 to 40 minutes. Can the file be repaired, and at what price?" Her reasoning is exactly right and her observation about the size is the key to it. The audio is all there. What is missing is the small piece of structure that tells a player where everything is — and on recordings, that piece is written last, when the recording stops cleanly. Hers never got the chance.
| Media | Single audio recording of approximately 30MB and 35–40 minutes' duration — recording interrupted by a power loss; file present at plausible size and unplayable in any application |
| Reported situation | Recording terminated by an unexpected shutdown · resulting file of expected size · playback failing in all applications · no device fault reported · repair sought rather than recovery |
| Fault class | Unfinalised media container — audio stream present with the index and terminating structures never written; repairable by structural reconstruction |
| Equipment used | File examined structurally before any modification · reference recording from the same device and settings obtained · container structure rebuilt and the audio stream remuxed · result validated by playing in full |
The decode: why the index comes last, and how the repair works
How a recording is actually written: media files of this kind are containers. The audio data streams into the file continuously while recording, but the index — the map describing the stream's format, its timing, where each chunk sits and how long the whole thing is — cannot be completed until recording ends, because none of those facts are known until then. So the index and the terminating structures are written at the very end, as the final act of stopping cleanly. A recording that is interrupted has all of its audio and none of its map.
Why that explains her observation exactly: the file is the right size because the audio really is in it — thirty megabytes of a thirty-five-minute recording is entirely consistent. A player opening it looks for the index first, finds nothing usable, cannot establish what the stream is or where it begins, and declines. It is not that the audio is damaged; it is that nothing has told the player how to read it. That distinction is why this is repairable and why the odds are good.
How the repair is done: by supplying the missing structure. A reference recording is made or obtained from the same device with the same settings — even a few seconds is enough — and its container structure is used as the template: the stream format, sample rate, channel configuration and encoding parameters are identical, because the same device produced both. The damaged file's audio stream is then remuxed into a correctly-formed container with a rebuilt index. The result plays normally. Some material at the very end, where the recording was cut off, may be lost or produce a fragment; the body of the recording generally comes back intact.
The practical instruction, and it is unusually actionable: if she still has the device that made the recording, she should record a short test clip on it now, using the same app and the same settings, and keep it. That reference is the single most useful thing she can supply, and it costs a minute. Where no reference exists, the parameters can often be derived from the stream itself, but a reference makes it faster and more reliable.
What not to do: not let any application "fix" or convert it, and not overwrite the original — work on a copy. Conversion tools that fail on the file may write a truncated result over it.
On the bench
The file was examined structurally before anything was modified, and all work was done on a copy — confirming that the audio stream was present and continuous and that the index and terminating structures were simply absent, rather than the data being damaged. A reference recording from the same device and settings was obtained and its container used as the template, since a file produced by the same encoder carries exactly the parameters the damaged one is missing. The stream was remuxed into a correctly-formed container with a rebuilt index, and the result was validated by playing it in full rather than by confirming it opened.
The outcome
The container rebuilt from a same-device reference and the recording restored and validated by playing it end to end. Free assessment, one fixed written figure including VAT before any work. The decode, for anyone with a recording that will not play: media containers write their index last, when recording stops cleanly, because the duration and layout are not known until then — so an interrupted recording has all its audio and no map, which is exactly why the file is the right size and refuses to open; the audio is not damaged, nothing has told the player how to read it, and that is repairable; the repair works by taking a reference recording made on the same device with the same settings and using its structure as a template; so record a short test clip on that device now and keep it, because it is the most useful thing you can supply.
Recording that will not play but seems the right size
Take the size as good news — your audio is almost certainly all there. Media files write their index last, when recording stops properly, because the duration and layout aren't known until then. So a recording cut short by a crash, a flat battery or a power cut ends up with the whole stream and no map, and every player opens it, finds nothing telling it how to read the contents, and refuses. The data isn't damaged; the instructions are missing, and that's repairable. Do one thing straight away if you still have the device: record a short test clip using the same app and the same settings, and keep it. That reference file carries exactly the structure yours is missing and makes the repair faster and more reliable. Meanwhile work on a copy, and don't let conversion or repair tools write over the original.
Record a short reference clip on the same device — then call Glasgow Data Recovery on 0141 404 0294; container rebuilt from that template, stream remuxed, and the result validated by playing it in full.
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.