re: FFmpeg stops on the LAST frame — my "partial decode" claim was wrong

I had been discarding FFmpeg's stderr with Stdio::null(). It says exactly
what happens: an unimplemented "Reserved bit", then a negative bit-skip --
and the failing frame index is always the last one.

  bank         packets  frames  fr/packet  fails at
  VOICE_D_450        8    45.7       5.71        44
  VOICE_D_452        7    29.4       4.21        28
  VOICE_D_453       22   198.9       9.04       198
  VOICE_D_454       29   287.5       9.92       287

So the previous entry's "the decodes are visibly partial" is wrong, and it
was mine. I read "samples per input byte ranges 2.10-4.96" as truncation; it
is ordinary XMA1 variable bitrate. Only the final frame of each stream is
lost. The decode is essentially complete.

The sample rate still does not converge. I tried the obvious repair --
counting the whole bank, leading region plus RIFF sub-waves, since the two
split the audio very differently per bank. Two banks then agreed at a tidy
~2.1x ratio pointing near 22 kHz, and the third refuted it: implied rates are
39742, 20563 and 23108 Hz.

So the container is identified, the decode is essentially complete, and the
duration still does not reconcile -- which moves suspicion to the other side
of the comparison. movie_subtitle::track_voice_cues returns (u32, f32) and I
have been reading that f32 as SECONDS on the strength of the format notes
describing mm:ss.cc cue text. If it is centiseconds, a frame index or a
per-page offset, every "audio missing" verdict inherits the error. Recorded
as the next thing to check, and to be checked BEFORE any more audio work.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/BACKLOG.md

@@ -1075,9 +1075,22 @@ premise was wrong.**
   converge** — 21 665 Hz for `D_453` (temptingly near 22 050, and I nearly wrote
   it down) but **5 844 Hz** for `D_450`. The decodes are partial: samples per
   input byte ranges 2.10–4.96 where a clean decode would be near-constant.
-  ▶️ Next: find why FFmpeg stops early — likely the packet/subframe fields in the
-  synthesised `fmt`, which are hardcoded (`SubframeData = 4`, `NumStreams = 1`).
-  See
+  ✅ **(same day) Why FFmpeg stops is captured** — I had been discarding its
+  stderr. It reports an unimplemented "Reserved bit" and a negative bit-skip, and
+  the failing frame is always the **last** one (44 of 45.7, 28 of 29.4, 198 of
+  198.9, 287 of 287.5). ❌ **That corrects my own previous claim**: "the decodes
+  are visibly partial" was wrong — the 2.10–4.96 samples-per-byte spread is
+  ordinary XMA1 variable bitrate (4.21–9.92 frames per packet), and only the
+  final frame is lost. ❌ The sample rate still does not converge, including
+  after counting leading region + RIFF together: 39 742 / 20 563 / 23 108 Hz for
+  the three banks with a usable cue. Two of them agreed at a tidy ~2.1× ratio and
+  the third refuted it.
+  🟡 **▶️ Check the OTHER side of the comparison first.**
+  `movie_subtitle::track_voice_cues` returns `(u32, f32)` and I have been reading
+  that `f32` as seconds. If it is centiseconds, a frame index, or a per-page
+  offset, every "audio missing" verdict inherits the error. Cheap to settle
+  against a movie of independently known length, and it should be settled before
+  any further audio work. See
   [`voice-bank-leading-region.md`](voice-bank-leading-region.md).
 * ❌ **(2026-08-25) My own boot-nav diagnosis, MEASURED AND WITHDRAWN.** I said
   the run died because `skip_intro.sh` gates the title test at `rmse <= 1500`