Recovering a Voice Memo That Was Unplayable for 14 Years

45 MB M4A File with a Missing Moov Atom

The file was 2_22 AM 11_14_2011.m4a, recorded using Apple's built-in Voice Memos app on an iPhone 3G. 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. Voice Memos was introduced with iPhone OS 3.0 in June 2009. The file had been sitting in backups for over 14 years. No one could play it.

Hex inspection confirmed the file contained only three atoms. The moov atom was completely missing.

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." Valid encoding, but some repair tools interpret a zero-length mdat header as an empty atom rather than a file-spanning one.

Every Approach That Failed

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. We ran Shannon entropy analysis on the mdat payload & got 7.98 bits per byte, near the theoretical maximum of 8.0, so it wasn't raw PCM.

Phase 2: AAC Codec Testing (All Failed)

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 & channel configurations (8000, 16000, 22050, 44100, 48000 Hz; mono & stereo; with & 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 & global_gain values. The analysis appeared plausible on the surface; it produced a coherent AAC parse. But it was wrong.

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. 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

The commercial M4A repair tools we tried assume the audio codec is AAC.

None of them checked for ALAC when they tried to detect the codec on this file. When their AAC heuristics found nothing recognizable, they reported the file as "severely corrupted" or "unrecoverable."

How the File Was Reconstructed

Once we knew the codec, the recovery took three custom steps, & none of the commercial tools we tried could do them.

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.

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.

Professional Mastering of the Recovered Audio

The raw recovered audio was complete & technically accurate. It still sounded like a voice memo recorded on 2011-era smartphone hardware in an uncontrolled environment, with audible electrical hum, background hiss, & inconsistent levels.

Louis Rossmann performed professional mastering on the recovered file. He worked at Avatar Studios in New York City back in 2007.

What the Mastering Involved

1. Spectral noise reduction: Removed electrical hum & background hiss, calibrated to eliminate the noise floor without introducing artifacts or damaging the voice signal.
2. Gain staging & loudness normalization: Brought the voice memo to a consistent listening level without clipping or distortion, following broadcast & streaming loudness standards.
3. Targeted EQ & dynamic processing: Improved voice clarity & intelligibility.

When the Voice Memo Is Trapped on a Phone That Won't Boot

The recovery above solved a container problem: a valid audio file with a missing index, already sitting in a backup. A different situation looks identical to the owner but is entirely a hardware problem. If the recording exists only on an iPhone that won't power on, or that powers on but never mounts to Finder or iTunes, the memo usually isn't gone. The board just can't get it to the computer.

Two Different Problems That Look the Same

A corrupt file that already copied off the phone is a software job: identify the codec, rebuild the moov atom, done. Audio trapped on a phone that won't boot is a board-level microsoldering job. No file tool can reach a recording the board won't hand over, because the phone never presents its storage to a computer in the first place.

Signs the recording is trapped by a board fault, not a file fault:

• The phone shows no display, no Apple logo, & no response when plugged in to charge.
• The phone charges but never appears in Finder or iTunes when connected to a computer.
• The screen lights but the device sticks in a boot loop & never reaches the lock screen.
• The phone got wet, or took a hard drop, before the recording was ever backed up.

Why There's No Chip-Off Shortcut

On any A7-and-later iPhone, meaning the 5s & everything after it, voice memos sit on a BGA-soldered NAND chip as ciphertext. iOS Data Protection encrypts them, keyed by the Secure Enclave inside the processor. If you desolder that NAND & read it on a programmer, all you get is ciphertext. There's nothing to decrypt it with, because the key material is fused into the original SoC & never leaves it. Chip-off yields a raw dump with no filesystem & no audio, so it isn't a path to the recording.

In-place decryption needs three originals together: the original SoC (Secure Enclave), the paired NAND, & the owner's passcode. A donor NAND, or a blank or foreign chip swapped in, yields nothing. The way in is to microsolder-repair the original board until it boots. Then the owner enters the passcode, the phone decrypts its own data, & the files copy out over USB. We don't do donor-board transplants, so a board that can't be repaired isn't a job we take.

Board Faults That Trap a Recording

Tristar or Hydra is the usual suspect when charging works but nothing appears in Finder. On the iPhone 5 through the iPhone 7, that chip is Tristar. Hydra first shows up on the iPhone 8, where it sits at U6300. A failed Tristar or Hydra can leave charging fully functional while the USB data line stays dead, so the board never handshakes with a computer or the lab's tools until the IC is microsolder-replaced. Tigris is a charging IC, not Tristar or Hydra, & the two aren't interchangeable.

A power fault stops boot earlier. A short-to-ground on a main rail such as PP_VCC_MAIN, common after liquid corrosion creeps under the BGA pads, halts the boot sequence, & a board that won't boot can't decrypt anything. Diagnosis is diode-mode measurement, probing voltage drop pin by pin: a normal reading is 0.3 to 0.7V, & a reading near 0.0V is a short to ground pointing at the dead rail. A hard drop can crack the microscopic BGA joints under the SoC or NAND instead. We reball those joints, & that puts back the electrical path the data was sitting behind the whole time.

These are the same constraints that govern photo recovery, message recovery, & general iPhone recovery. When the board won't boot there's no special software path for audio, & no way around the passcode: the recording comes back only by restoring the original hardware so the owner can unlock it. iPhone board repair here runs $500–$750. No data, no fee. Free evaluation. No diagnostic charges.

Board-level video: a dead logic board with the short on its main rail traced down until the phone boots, & a diode-mode pin-by-pin comparison on an iPhone 6s display connector, a different circuit checked with the same meter setting.