re: withdraw a wrong explanation of the BGM_001 duration gap

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

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