How a 1.6 GB unplayable 20251025075725.mp4 (SplitCam screen recording, Windows) was diagnosed as unrecoverable — and the checks that prove an mdat is garbage before you sink hours into untrunc.
Bottom line
moov atom not found usually means “interrupted recording, repairable with untrunc”. But if the recorder crashed before flushing any frames, the mdat is just preallocated NTFS clusters holding stale deleted-file data. That is unrecoverable by any tool. Verify the payload first.
Symptom
ffprobe 20251025075725.mp4
[mov,mp4,m4a,3gp,3g2,mj2] moov atom not found
Top-level atom walk showed the classic interrupted-recording signature:
Atom
Size
ftyp
32 B
free
8 B
mdat
size field = 0 → “extends to EOF”
No moov. Writers stream mdat first and append moov (with avcC, SPS/PPS, and the sample table) at clean shutdown — so a crash loses the index.
The usual fix (and why it didn’t apply)
untrunc (anthwlock fork) rebuilds a missing moov by re-parsing the mdat, using a known-good reference recording from the same encoder/app to learn codec params and frame layout.
macOS packaging
As of 2026-07 Homebrew has no untrunc / untrunc-anthwlock formula. You must build from source. Don’t plan around a brew install.
Not worth it here, because the mdat had nothing to parse.
Proving the mdat is garbage — the 5 checks
1. Walk AVCC NAL units from the start of mdat
H.264 in MP4 is length-prefixed (4-byte big-endian length + NAL). Walking from mdat’s first byte:
NAL 1 — SEI, 686 B, containing the x264 version string ✔
Zero hits. Repeated with a loose test (chain of 3, type set only, no ref check) over a 120 MB window — also zero hits.
3. Shannon entropy sampling
Sampled at 7 offsets: uniformly 7.997 bits/byte, 256 distinct byte values everywhere. Real H.264 is high-entropy but not that flat — this is the signature of unrelated compressed/encrypted residue, not a video bitstream.
4. Box-tag search
Searched for moov / moof / mdat / avcC / stbl across the file. Hit count matched random chance (≈ 1.7e9 / 2^32 per 4-byte tag). No fMP4 fragments to salvage.
5. Tail check
The last 10 747 952 bytes were all zeros — freshly-zeroed, never-written clusters.
Root cause
SplitCam crashed mid-recording on Windows. NTFS preallocated ~1.6 GB of clusters; the video data was never flushed. The clusters still hold stale content from previously deleted files — hence max entropy, no structure, no NAL chains.
Only the first ~69 KB of genuine H.264 ever hit disk, and even that is undecodable: SPS/PPS live in avcC inside the missing moov.