diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index 4608dacc..6c9e0092 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -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.
diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index de71436b..1821640a 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -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
 
diff --git a/docs/re/bgm-102-decoded-during-boot.md b/docs/re/bgm-102-decoded-during-boot.md
index a9186642..24e041c8 100644
--- a/docs/re/bgm-102-decoded-during-boot.md
+++ b/docs/re/bgm-102-decoded-during-boot.md
@@ -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.