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

re: withdraw a wrong explanation of the BGM_001 duration gap

Browse Source 
I wrote that BGM_001 s declared 173.821 s disagreed with a decoded 167.663 s,
and explained the gap as declared covering the encoded stream including trailing
silence while decoded is where the audio stops. The port decoded it fully: the
bank yields 173.809 s of PCM. There is no disagreement -- 167.663 s is where the
music fades out, measured from the audio, and the stream continues silent to its
declared end inside that same decode.

So the declared-rate method is better than this page claimed, and is now
cross-checked on three banks against independent decodes: BGM_103 87.750 vs
87.744, BGM_102 37.487 vs 37.482, BGM_001 173.821 vs 173.809 -- agreement 5 to
12 ms.

The conclusion survives unchanged and is the useful half: trust it for lengths,
not for musical boundaries. A declared length includes whatever silence the
encode carries, so it is not a loop point.

Also records in METHOD a defect shape the port hit three times in one pipeline,
each invisible to every check except a level: normalising by how many inputs
there are rather than how many carry signal. A silent chunk in a voice sum, a
silent channel in a mono fold, and a silent sub-wave -- the 10240-byte bank
header wrapped to 10300 B -- counted as a third stem in a music sum, which put
every real stem at 1/3 instead of 1/2 and cost 3.52 dB on all menu music for two
iterations. This corpus s census said two waves and the exporter s divisor said
three; the count that disagrees with a census is the one that is wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 16:20:49 +00:00
parent c05c8e1719
commit 3a5f215179
3 changed files with 45 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/port/HANDOFF.md
View File

@@ -603,11 +603,18 @@ decoder**, via the corrected XMA1 `PsuedoBytesPerSec`. Both stems of a bank agre
| `BGM_103` (your menu track) | **87.750 s** | 87.749 s |
| `BGM_001` | 173.821 s | 173.821 s |
⚠️ **These are declared durations and they INCLUDE trailing silence.** `BGM_001`
reads 173.821 s here against your decoded **167.663 s** — a gap of **6.158 s**,
and this page already records 6.15 s of silence after its fade-out. So the two
figures are consistent: declared = encoded stream, decoded = where the audio
stops. **For a menu loop point, use the decoded figure, not this one.**
🔴 **My explanation of the `BGM_001` gap was wrong and you corrected it.** I said
declared 173.821 s vs decoded 167.663 s meant "declared includes trailing
silence, decoded is where the audio stops". A full decode yields **173.809 s of
PCM** — so declared and decoded **agree to 12 ms**, and 167.663 s is the
*fade-out*, sitting inside the decode. Cross-checked on three banks now:
`BGM_103` 87.750 declared / 87.744 decoded, `BGM_102` 37.487 / 37.482,
`BGM_001` 173.821 / 173.809 — **5–12 ms**.
⚠️ **The conclusion is unchanged and is the useful part: trust it for lengths,
not for musical boundaries.** A declared length includes whatever silence the
encode carries, so it is not a loop point. For `BGM_001` the music stops at
167.663 s, 6.1 s before the stream ends — **measure a loop point from the audio.**
🟢 **Refutation attempt on this page's own `BGM_103` claim: it survived.** The two
declared waves read 3 876 864 / 3 930 112 B off the disc — exact.

11
docs/re/METHOD.md
View File

@@ -58,6 +58,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
* **My own last-turn result is a hypothesis too.**
* **A global partition can understate a per-owner one.**
* **A residual is measured against a population — name it.**
* ⚠️ **Normalising? Divide by how many inputs CARRY SIGNAL, not how many there
are.** The port hit this three times in one pipeline, each invisible to every
check except a level measurement, and each the same mistake:
a digitally silent *chunk* counted in a voice sum; a digitally silent
*channel* counted in a mono fold (−5.94 dB); a digitally silent *sub-wave* —
the 10 240-byte bank header, wrapped to 10 300 B — counted as a third stem in
a music sum, putting every real stem at 1/3 instead of 1/2 (**−3.52 dB on all
menu music, shipping for two iterations**). This corpus's own census said
those banks hold **two** waves; the exporter's divisor said three. **A count
that disagrees with a census is the count that is wrong**, and the symptom is
never a crash — it is everything being quietly a few dB down.
## Searching and tooling

30
docs/re/bgm-102-decoded-during-boot.md
View File

@@ -79,12 +79,26 @@ gives the same answer from the header alone, on three banks:
| `BGM_103` | 87.750 s | 87.749 s |
| `BGM_001` | 173.821 s | 173.821 s |
⚠️ **And the one apparent disagreement resolves in the corpus's favour.**
`BGM_001` reads **173.821 s** here, against the **167.663 s** the port measured by
decoding. The gap is **6.158 s** — and HANDOFF already records that `BGM_001`
"fades out at 167.663 s and is followed by **6.15 s of silence**". The declared
duration covers the encoded stream *including* its trailing silence; the decoded
figure is where the audio stops. The two are consistent, and neither is wrong.
🔴 **An explanation I gave here was wrong and is withdrawn (2026-08-29).** It
said `BGM_001`'s declared **173.821 s** disagreed with a decoded **167.663 s**,
and that "declared covers the encoded stream including its trailing silence; the
decoded figure is where the audio stops". **There is no disagreement to explain.**
A full decode of `BGM_001` yields **173.809 s of PCM** — the 167.663 s is where
the music *fades out*, measured from the audio, and the stream continues silent
to its declared end **inside** that decode. Declared and decoded agree.
That is a genuine cross-check of the declared-rate method against an independent
decode, and it is the second one (the first was `ADV`, agreeing to 0.02 %).
✅ **The declared-rate method is now cross-checked on three banks against
independent decodes**, and it is better than the first version of this page
claimed:
| bank | declared | decoded | agreement |
|---|---|---|---|
| `BGM_103` | 87.750 / 87.749 s | **87.744 s** | 5–6 ms |
| `BGM_102` | 37.487 s | **37.482 s** | 5 ms |
| `BGM_001` | 173.821 s | **173.809 s** | 12 ms |
⚠️ The conclusion that survives unchanged is the useful one: **trust it for
lengths, not for musical boundaries.** A bank's declared length includes whatever
silence the encode carries, so it is not a loop point — that has to be measured
from the audio, and for `BGM_001` that is 167.663 s, 6.1 s before the stream
ends.