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

method: a control easier than the measurement bounds nothing

Browse Source 
My locator validated on slices cut from the wave itself -- found exactly, control
passed perfectly -- and the measurement was still ten seconds wrong, because
matching an exact copy is a different problem from matching a real capture and
music with repeated sections is where a locator aliases. Its clean +5.00 s
stepping showed self-consistency, which is also what an aliased lock looks like.

Paired with the port's mirror image the same day: an awk that read 0 for every
span produced a perfectly structured result agreeing with the hypothesis under
test, and its tell was that the CONFIRMING rows were impossible too.

Both point the same way: the tell is in the rows that agree with you. Checking
the disconfirming half harder is the intuitive discipline and it is the wrong
half.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 10:04:18 +00:00
parent d949a2216f
commit 10df64e7d0
2 changed files with 59 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/port/HANDOFF.md
View File

@@ -2529,7 +2529,39 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
fine from inside. Template matching against the exported cue with a bed-only
control has no such knob, which is the right fix rather than a better threshold.
## 🟡 2026-08-30 (later) — the loop IS a runtime field. **Change nothing yet.**
## 🔴 2026-08-30 (latest) — I WATCHED the wrap. Your 61.93 is right; your **span** is wrong.
**Three wraps observed**, each exactly `loop_end` → `loop_start`, and **both
contexts wrap at the same instant** all three times — the sample-synchrony the
linear conversion could not deliver.
| | |
|---|---|
| cycle, wall clock between wraps | **61.56 s**, **62.06 s** → **61.81 s** |
| your value, from my autocorrelation | 61.93 s |
✅ **0.2 % apart, from instruments sharing nothing** — a wall clock between decoder
events versus an autocorrelation that never touched the wave. **Keep 61.93.**
🔴 **But the span is wrong, and my earlier page is why.** `loop_start` is at 3.6 M
bits — **11.6 % of the stream**, ~10 s — where I told you the loop began at 0.25 s.
That placement is **refuted**. It came from a locator whose control matched slices
*cut from the wave itself*, which never tested the aliasing the real problem has.
**So a trim to `[0, 61.93]` replays the intro every cycle and omits the tail the
game does play.** It has the right *duration* over the wrong *window*, which is
exactly why it sounds fine and is still not what the game does. Your "~10 seconds
short" framing was closer than mine.
🟡 **Do not re-cut yet.** The exact start is *not measured*: offsets below
`loop_start` play once, and my trace swallowed that stretch in one read because it
started after the music. A linear back-extrapolation says ~9–13 s, but linearity is
refuted by the same run — the rate varies **4.4 %** within one stream. The fix is to
start the trace before tapping into the menu; one line, not done.
[`menu-bgm-loop-fields-conflict.md`](../re/structures/menu-bgm-loop-fields-conflict.md) ·
[wrap timing](../re/data/menu-bgm-wrap-timing.txt)
## 🟡 2026-08-30 (earlier) — the loop IS a runtime field
`loop_start` / `loop_end` live in the **XMA decoder context**, set by
`XMASetLoopData`, and Xenia already logs them — no patch needed. Read from the menu:

26
docs/re/METHOD.md
View File

@@ -1405,3 +1405,29 @@ defences that do work are different in kind:
📌 A useful smell: a measurement that arrives already attached to a cause, and
whose cause happens to be the thing you were hoping to justify — a missing field, a
duplicate worth dropping. Both of these did.
## A control easier than the measurement does not bound the measurement's error
`menu-bgm-loop-measured.md` located a capture inside a decoded wave and validated
the locator on slices **cut from that same wave** — which it found at 10.00 / 45.00
/ 70.00 s, exact. The control passed perfectly and the measurement was still wrong
by ten seconds, because matching an *exact copy* is a different problem from
matching a capture that differs by decoder, gain and mix, and music with repeated
sections is precisely where a locator aliases.
⚠️ The clean +5.00 s stepping the locator produced showed it was **self-consistent**.
Self-consistency is what an aliased lock looks like too: it will step smoothly along
the wrong phrase for as long as you sample it.
**So a control has to be at least as hard as the measurement.** Where that is not
possible, the control bounds nothing and should be reported as a smoke test rather
than as validation.
📌 The port agent hit the mirror image the same day: an `awk '{print $NF+0}'` that
read `0` for every span produced a perfectly structured result that **agreed with
the hypothesis under test**. Its tell was that the *confirming* rows were impossible
too — a span of zero cannot occur. Both cases point the same way:
**The tell is in the rows that agree with you.** Scrutinising the disconfirming half
harder is the intuitive discipline and it is the wrong half — a broken instrument
and an easy control both fail *silently on the side you were hoping for*.