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

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.

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.

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, & 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

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, compensating for the iPhone 3G's limited microphone frequency response.

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 isn't gone. The board just can't present it.

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

Voice memos live on a BGA-soldered NAND chip as ciphertext under iOS Data Protection, keyed by the Secure Enclave inside the processor. On any A7-and-later iPhone (the 5s & everything after), desoldering that NAND & reading it on a programmer returns only 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 path is to microsolder-repair the original board until it boots, or transplant the whole paired set of SoC, NAND, & EEPROM together to a donor board when the original is destroyed, then power it on & let the owner enter the passcode so the phone decrypts its own data & the files copy out over USB.

The Board Faults That Trap a Recording

The USB data controller IC is the usual suspect when charging works but nothing appears in Finder. That IC is Tristar on phones before the iPhone 8, & Hydra on the iPhone 8 through 14 (the U6300 designator; on newer generations we name the family without a U-number). A failed data IC 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 the data IC, & 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 instead fracture the microscopic BGA joints under the SoC or NAND; reflowing or reballing those joints restores the electrical path the data was always waiting behind.

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.