re: cue times ARE seconds — and "the rate does not converge" was my error

Two things settled, one of them a correction of my own claim from the last
iteration.

The cue unit is verified rather than assumed. parse_timing computes mm*60+ss,
but only if the token really is mm:ss.cc, so I checked against an independent
oracle: the movies are on the disc and a cue must land inside its own movie.
66 English movies with subtitle tracks, 0 cues land after the movie ends.
Centiseconds would have overflowed essentially all 66. The seconds reading
stands and the verdicts built on it survive.

"The sample rate does not converge" does not. I reported implied rates of
39742 / 20563 / 23108 Hz as irreconcilable. They are not estimates of the
same quantity -- each is a ONE-SIDED BOUND. The audio must be at least as
long as the last cue, so samples/cue is an UPPER bound; it cannot outlast its
movie, so samples/movie is a LOWER bound. Intersecting:

  bank         samples    cue   movie   lower Hz   upper Hz
  VOICE_D_450   158967   4.00    9.30      17091      39742
  VOICE_D_451    76084   3.70    9.30       8180      20563
  VOICE_D_453   108608   4.70    9.30      11677      23108

  => 17091-20563 Hz, non-empty. A single rate IS consistent.

I had been comparing them as competing point estimates, which is why they
looked contradictory.

What is still open, and stated as such: that window contains no standard XMA
rate. The lower bound assumes a whole bank plays inside one movie, and each of
these banks is bound to 3-5 movie slots -- so if a bank holds several takes
the lower bound is void, leaving rate <= 20563, which 22050 nearly meets.
Next step recorded: establish whether a shared bank is one line or several.

Artifact: examples/cue_unit_check.rs.

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

docs/re/BACKLOG.md

@@ -1085,12 +1085,21 @@ premise was wrong.**
   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
+  ✅ **(2026-08-26) The cue unit IS seconds** — checked against movie duration as
+  an independent oracle: **66 movies with subtitle tracks, 0 cues land after
+  their movie ends** (`examples/cue_unit_check.rs`). Centiseconds would have
+  overflowed essentially all 66.
+  ❌ **And "the sample rate does not converge" was my own error.** The implied
+  rates are not competing point estimates — each is a **one-sided bound**
+  (`samples/cue` is an UPPER bound, `samples/movie` a LOWER one). Intersected,
+  they give a **non-empty window of 17 091 – 20 563 Hz**: a single rate *is*
+  consistent with all three banks.
+  ❔ But that window holds **no standard XMA rate** (22 050 / 24 000 / 32 000 /
+  44 100 / 48 000 all fall outside). The lower bound assumes the whole bank plays
+  within one movie, and each bank is bound to **3–5 movie slots** — so if a bank
+  holds several takes the lower bound is void, leaving `rate <= 20 563`, which
+  22 050 nearly meets. ▶️ Next: establish whether a shared bank is one line or
+  several takes. 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`