fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Sylpheed RE agent
2026-08-26 00:14:31 +00:00
parent cfe9bd863f
commit 44dae8d387
3 changed files with 123 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/re/BACKLOG.md
View File

@@ -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`

59
docs/re/voice-bank-leading-region.md
View File

@@ -225,18 +225,57 @@ refutes that too:
So: the container is identified, the decode is essentially complete, and the
duration still does not reconcile.
## ✅ The cue unit is seconds — checked, not assumed
`parse_timing` computes `mm*60 + ss`, but only if the token really is `mm:ss.cc`.
The movies are on the disc, so their duration is an independent oracle: a cue
must land **inside its own movie**. Over every English movie with a subtitle
track — **66 movies, 0 cues land after the movie ends**
(`examples/cue_unit_check.rs`). Centiseconds would have overflowed essentially
all 66. So the seconds reading stands and the verdicts built on it survive.
## ❌ "The sample rate does not converge" — that was MY error, twice over
I reported implied rates of 39 742 / 20 563 / 23 108 Hz and called them
irreconcilable. They are not, because 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 → `samples / cue` is an
**upper** bound on the rate;
* the audio cannot outlast its movie → `samples / movie` is a **lower** bound.
| bank | samples | cue | movie | lower (Hz) | upper (Hz) |
|---|---|---|---|---|---|
| `VOICE_D_450` | 158 967 | 4.00 s | 9.30 s | 17 091 | 39 742 |
| `VOICE_D_451` | 76 084 | 3.70 s | 9.30 s | 8 180 | 20 563 |
| `VOICE_D_453` | 108 608 | 4.70 s | 9.30 s | 11 677 | 23 108 |
Intersecting them gives **17 091 – 20 563 Hz**, a non-empty window. A single
sample rate *is* consistent with all three banks. I had been comparing the
numbers as if they were competing point estimates.
## ❔ But the window contains no standard rate
Nothing in 17 091 – 20 563 Hz is a normal XMA sample rate (22 050, 24 000,
32 000, 44 100, 48 000 all sit outside). Two things could move it, and neither
is settled:
* **The lower bound assumes the whole bank plays inside one movie.** Each of
these banks is bound to **3–5 different movie slots**, so if it holds several
takes rather than one line, its total length has no reason to fit one movie and
the lower bound is void — leaving only `rate ≤ 20 563`, which 22 050 nearly
satisfies.
* The final frame of each stream is lost to the decoder, but that is ~512
samples and cannot move a bound by 10 %.
So the honest state is: container identified, decode essentially complete, cue
unit verified, and the rate constrained but **not** determined.
## 🟡 Where the tension probably is now
The audio side has stopped looking suspect: mono XMA1, decoded to the last
frame. The link I have *not* checked is the other one — `movie_subtitle::
track_voice_cues` returns `(u32, f32)`, and I have been reading that `f32` as
seconds because the format notes describe `<mm:ss.cc>` cue text. If it is
anything else — centiseconds, a frame index, a per-page offset — every "audio
missing" verdict above inherits the error.
**That is the next thing to check, and it should be checked before any more work
on the audio.** It is cheap: a cue on a movie whose length is known independently
would settle the unit.
Checked and cleared: the cue unit is seconds (above). What is left is whether a
**shared** bank holds one line or several takes — that decides whether the
lower bound above is real, and it is the thing to establish next.
## ❔ The first attempt at this — inconclusive, and for a boring reason