Case Study
Recovering a Voice Memo That Was Unplayable for 14 Years
A 45 MB voice memo recorded on an iPhone 3G on November 14, 2011 arrived at our lab. The file hadn't played since the day it was recorded. Over five commercial repair tools had failed. Every one assumed the wrong codec. We identified the real codec, wrote custom scanning tools, rebuilt the file's metadata from scratch, & recovered all 19 minutes and 32 seconds of audio.
Can corrupted voice memos be recovered?
Yes. A corrupted voice memo usually contains intact audio data trapped inside a broken file container. The metadata index (called a moov atom) that tells players how to read the audio is missing or damaged. Recovery means identifying the codec, scanning for every frame boundary in the raw data, & rebuilding that index from scratch. iPhone data recovery at Rossmann Repair Group costs $300–$650. If we can't recover your data, you don't pay.
The File: 45 MB of Audio Nobody Could Play
The file was 2_22 AM 11_14_2011.m4a, recorded using Apple's built-in Voice Memos app on an iPhone 3G running iOS 3.x or 4.x. The recording was 45,251,298 bytes (45 MB), with SHA-256 hash eb712368ea10ffc3bc6de73d78aed95c7ab8bf1a56218043a600b4a9b0f72783. Two copies of the file existed; the second had a timestamp suffix appended to the filename. SHA-256 confirmed they were byte-identical, so only one needed recovery work.
The iPhone 3G was released in 2008 & discontinued in 2010. Voice Memos was introduced with iPhone OS 3.0 in June 2009. This recording had sentimental value. It had been sitting in backups for over 14 years, written off as permanently lost.
Hex inspection confirmed the file contained only three atoms: a 28-byte ftyp (file type identifier, intact), an 8-byte wide placeholder, and a mdat (media data) containing all 45 MB of raw audio. The moov atom was completely missing.
An additional complication: the mdat atom's size field was set to zero. Under the MPEG-4 specification, a zero-length size field means "this atom extends to the end of the file." This is valid encoding, but some repair tools interpret a zero-length mdat header as an empty atom rather than a file-spanning one.
What Is a Moov Atom & Why Was It Missing?
An M4A file (MPEG-4 audio container) stores audio data in a hierarchy of structures called atoms. A valid M4A needs three: the ftyp identifies the container format, the mdat holds the raw encoded audio, and the moov contains the codec configuration, sample rate, channel count, frame size table, & byte offset index that maps every frame inside the mdat.
Without the moov, no software knows what codec was used, what the sample rate or bit depth is, where each frame starts & ends, or how long the recording is. The file is a 45 MB blob of compressed audio with no instructions.
How the Moov Gets Lost: Interrupted Recording
When Voice Memos records, it writes raw audio frames into the mdat in real-time. The indexing metadata (frame sizes, byte offsets, codec configuration) stays in the phone's volatile RAM. The iPhone 3G had 128 MB of eDRAM shared between the OS & all apps.
When recording stops normally, the app takes that RAM-based index, constructs the moov atom, & appends it to the file. When recording is interrupted abnormally, the RAM buffer is wiped before it can be written to flash storage. The audio data survives in the mdat. The moov is never written.
Given the circumstances (a nearly 20-minute recording at 2:22 AM on an aging iPhone 3G in late 2011), the most probable cause was battery death, an out-of-memory crash from iOS's aggressive OOM killer, an app crash in early Voice Memos, or storage exhaustion on the phone's flash. Any of these produces the same result: valid ftyp, valid mdat full of audio, no moov.
Every Approach That Failed
The recovery went through multiple phases of investigation before arriving at a solution. The failures are as instructive as the fix.
Phase 1: Standard Diagnosis
ffprobe reported zero playable streams. It could see the ftyp & mdat atoms but couldn't find a moov, so it had no idea what codec was inside. Shannon entropy analysis of the mdat payload yielded 7.98 bits per byte (near the theoretical maximum of 8.0), confirming the data was compressed audio, not raw PCM or random noise.
Phase 2: The AAC Assumption
Based on the .m4a extension & general knowledge that iPhones record in AAC, every initial attempt assumed the audio was AAC-LC. This was wrong.
- The mdat was scanned for ADTS sync words (the 0xFFF bit pattern that marks AAC frame headers). None were found.
- Raw mdat extraction with ADTS header wrapping at various sample rates (8000, 16000, 22050, 44100, 48000 Hz) produced static or silence.
- Synthetic moov atoms were built with AAC-LC codec configurations at various sample rates and channel configurations (8000, 16000, 22050, 44100, 48000 Hz; mono and stereo; with and without SBR) & appended to the file. ffmpeg's AAC decoder returned zero decoded samples in every case.
Before abandoning the AAC hypothesis, we analyzed the first bytes of the mdat (00 00 00 00 00 13 08 09) bit-by-bit as if they were AAC syntax elements. The byte 0x13 was parsed as an AAC Single Channel Element (SCE) tag with specific element_instance_tag and global_gain values. The analysis appeared plausible on the surface; it produced a coherent AAC parse. But it was wrong. This is how deeply the wrong assumption was investigated, and why surface-level bitstream analysis can mislead when the fundamental codec assumption is incorrect.
The data was not AAC. Every tool that tried to treat it as AAC returned nothing.
Phase 3: untrunc (Multiple Attempts)
untrunc is an open-source tool designed to repair MP4/M4A files with missing moov atoms by using a healthy "reference file" recorded with the same device & codec. Multiple AAC reference files were generated at various sample rates. Every attempt failed because ffmpeg's AAC decoder returned zero samples from the mdat.
The untrunc source code was examined & two bugs were found in its codec matching logic. Both were patched to be more permissive. After patching, untrunc's matcher accepted the data as "mp4a" audio, but ffmpeg's AAC decoder still returned zero samples. The matcher could be fooled. The decoder could not.
Even after we identified the correct codec, untrunc couldn't help. An ALAC reference file was generated & fed to untrunc. This time it correctly identified the track as "alac" but reported Bad track: 'alac' with a warning that it lacked logic for ALAC frame detection. untrunc was designed for H.264 video & AAC audio recovery; its ALAC support didn't include frame boundary detection. The file also showed mdat->file_end: 48, suggesting it interpreted the zero-length mdat header as an empty atom rather than a file-spanning one.
Why Over Five Commercial Tools Failed
Every commercial M4A repair tool assumes the audio codec is AAC because every iPhone from the 3GS onward (2009 to present) records voice memos in AAC. Every iTunes Store purchase is AAC. AAC in M4A is the near-universal standard across Apple's entire product line.
The iPhone 3G's use of ALAC for voice memos was a brief historical anomaly limited to a single device generation, discontinued over 15 years ago. No commercial tool's codec detection matrix includes ALAC for this use case. When their AAC heuristics find nothing recognizable, they report the file as "severely corrupted" or "unrecoverable."
Identifying the Real Codec
After exhausting every AAC-based approach, we shifted to researching the iPhone 3G's hardware capabilities & the behavior of iOS 3.x's audio subsystem. The question wasn't "how do we fix this AAC file?" It was "what if this isn't AAC at all?"
Our research identified the answer: the iPhone 3G Voice Memos app recorded in Apple Lossless (ALAC), not AAC. The iPhone 3G lacked the dedicated hardware encoding silicon or sufficient CPU overhead to encode compressed AAC in real-time. Apple's solution was ALAC, a lossless codec that's computationally simpler to encode. The iPhone 3GS, released in June 2009 with a faster processor, was the first to switch Voice Memos to AAC-LC.
This explained everything. AAC decoders returned zero samples because the data isn't AAC. No ADTS sync words were found because ALAC doesn't use ADTS framing. The hex signature 00 00 00 00 00 13 08 09 didn't match any AAC syntax pattern because it's a documented ALAC frame header. The entropy was near-maximum because ALAC uses Rice coding & linear prediction, producing high-entropy compressed output despite being lossless.
Proving the Codec Before Building the Scanner
Before committing to a full frame scanner, we built a test moov atom using a constant estimated frame size of 3,780 bytes. ffprobe immediately recognized the file as ALAC, 44,100 Hz, approximately 1,112 seconds, at roughly 326 kbps. ffmpeg decoded frame 0 successfully: 4,096 samples of real, audible audio came out.
Subsequent frames failed with "Syntax element 5 is not implemented" errors because the constant frame boundaries didn't align with the actual variable-length ALAC frames. But that first frame was enough. One frame of real audio proved the codec identification was correct. The remaining problem was finding where each of the other 12,618 frames started and ended.
How the File Was Reconstructed
With the codec identified, the recovery required three custom steps that no commercial tool provides.
ALAC Configuration: The 36-Byte Magic Cookie
ALAC's decoder requires a 36-byte initialization structure called a Magic Cookie (the equivalent of AAC's AudioSpecificConfig). A reference ALAC file was generated using ffmpeg, & the Cookie was extracted & verified:
00 00 00 24 61 6C 61 63 00 00 00 00 00 00 10 00 00 10 28 0A 0E 01 00 FF 00 00 00 00 00 00 00 00 00 00 AC 44
This 36-byte structure encodes the frame length (4,096 samples), bit depth (16), Rice coding parameters (pb=40, mb=10, kb=14), channel count (1, mono), & sample rate (44,100 Hz).
Custom Frame Scanner: Binary Search on 45 MB
A Python script using PyAV (Python bindings for ffmpeg) scanned the entire mdat for ALAC frame boundaries. The algorithm initialized an ALAC decoder with the 36-byte Magic Cookie, then for each frame position, attempted to decode with a large packet & used binary search to find the minimum byte count that still produced a valid decode. That minimum is the exact frame size.
| Metric | Value |
|---|---|
| Frames found | 12,619 |
| Decode errors | 0 |
| Minimum frame size | 2,918 bytes |
| Maximum frame size | 5,975 bytes |
| Average frame size | 3,586 bytes |
| Total samples decoded | 51,687,424 |
| Duration | 19 minutes 32 seconds |
The scanner processed all 45 MB in 10.3 seconds at roughly 1 ms per frame. The full decode of all 12,619 frames took 0.9 seconds. Total wall time from start to a complete frame map: 11.2 seconds.
Every byte of the mdat was accounted for as part of a valid ALAC frame. Zero bytes left over. Zero decode errors.
Moov Atom Reconstruction
A second Python script constructed a complete, standards-compliant moov atom from scratch. This isn't a repair or a patch; it's a ground-up build of the entire metadata container.
- stsd (Sample Description)
- ALAC codec entry with the 36-byte Magic Cookie containing sample rate, bit depth, channel count, & Rice coding parameters.
- stsz (Sample Size Table)
- 12,619 exact frame sizes from the scan, one entry per frame.
- stco (Chunk Offset Table)
- 12,619 absolute file offsets mapping each frame's position in the mdat.
- stts (Time-to-Sample)
- A single run-length entry mapping all 12,619 frames, each containing 4,096 samples at 44,100 Hz.
The reconstructed moov was combined with the original mdat. The resulting M4A plays in Apple Music, VLC, ffmpeg, foobar2000, & any other player that supports ALAC.
Recovered Output Formats
We delivered four copies of the recovered audio in different formats.
| Format | Size | Specs | Purpose |
|---|---|---|---|
| ALAC .m4a | 44 MB | 44,100 Hz / 16-bit / mono / ~309 kbps | Lossless, identical to original audio |
| FLAC | 43 MB | 44,100 Hz / 16-bit / mono | Lossless, wide compatibility |
| WAV (PCM) | 99 MB | 44,100 Hz / 16-bit / mono / 705.6 kbps | Uncompressed, universal |
| AAC 128k .m4a | 19 MB | 44,100 Hz / mono / 128 kbps | Compressed, portable |
Professional Mastering of the Recovered Audio
The raw recovered audio was complete & technically accurate, but it had the characteristics of a voice memo recorded on 2011-era smartphone hardware in an uncontrolled environment: audible electrical hum, background hiss from the iPhone 3G's microphone & analog-to-digital converter, and inconsistent levels.
Louis Rossmann performed professional mastering on the recovered file. Rossmann worked as a technician at Avatar Studios (now Power Station at BerkleeNYC) in New York City during 2007-2008. Avatar was one of the most respected recording studios in the world, known for recording artists including The Foo Fighters, Aerosmith, & Tony Bennett. That environment provided hands-on experience with world-class signal processing chains & mastering workflows.
What the Mastering Involved
- Spectral noise reduction: Removed electrical hum & background hiss, calibrated to eliminate the noise floor without introducing artifacts or damaging the voice signal.
- Gain staging & loudness normalization: Brought the voice memo to a consistent listening level without clipping or distortion, following broadcast & streaming loudness standards.
- Targeted EQ & dynamic processing: Improved voice clarity & intelligibility, compensating for the iPhone 3G's limited microphone frequency response.
Why This Recovery Required a Custom Approach
Three things separated this recovery from what any off-the-shelf tool can do.
- Correct codec identification through historical research. Determining that the iPhone 3G used ALAC required research into Apple's hardware capabilities circa 2009 & the behavior of iOS 3.x's Voice Memos app. This is obscure historical knowledge not encoded into any commercial repair tool.
- A custom ALAC frame boundary scanner. A purpose-built Python script used ffmpeg's ALAC decoder via PyAV with the correct configuration (44,100 Hz, 16-bit, mono, 4,096 samples per frame) to decode each frame individually. Binary search found the exact size of all 12,619 frames with zero errors.
- Manual M4A container reconstruction. With exact frame sizes known, a second script built a complete moov atom from scratch: the ALAC-specific Magic Cookie, a per-frame sample size table (stsz), chunk offset table (stco), time-to-sample mapping (stts), & the full container hierarchy (mvhd, tkhd, mdhd, hdlr, minf, dinf, stbl).
No commercial tool performs this sequence. They're built for common cases (AAC audio, H.264/H.265 video) & rely on pattern-matching heuristics that don't extend to ALAC bitstreams from a device that's been obsolete for over 15 years.
The investigation spanned extended analysis and multiple failed approaches before the codec breakthrough. The AAC assumption alone consumed rounds of ADTS scanning, bitstream parsing, synthetic moov construction, and untrunc source code patching. After the ALAC identification, we still had to prove the codec with a test moov, build the binary-search frame scanner, write the moov atom constructor, and master the final audio. The 11.2-second scan at the end was the payoff for the research that preceded it.
Frequently Asked Questions
Can corrupted voice memos be recovered?
Why is my iPhone voice memo not playing?
What is a moov atom?
What codec did iPhone 3G use for voice memos?
Can you recover a voice memo from an old iPhone?
Are voice memos from newer iPhones easier to recover?
What happens when an M4A file is missing its moov atom?
Have a corrupted voice memo or audio file?
We recover data from iPhones, corrupted files, & damaged storage. $300–$650 for iPhone recovery. Free evaluation, no data no fee.