diff --git a/docs/re/menu-audio-cues.md b/docs/re/menu-audio-cues.md
index c124d650..918656e8 100644
--- a/docs/re/menu-audio-cues.md
+++ b/docs/re/menu-audio-cues.md
@@ -78,7 +78,24 @@ Three routes, one answer; see
 So the per-screen BGM binding is recoverable **per screen, from the code that
 plays it** — not from any table.
 
-## ❔ And a new negative: an individual SE's audio is not extractable yet
+## ~~❔ And a new negative: an individual SE's audio is not extractable yet~~
+
+> 🔴 **SUPERSEDED by this page's own later section — read that instead.** The
+> heading's claim is **false**: the waves were located in `Static.slb` by *playing*
+> them and reading the offsets out of the running game — move **`0x1ec0`**, confirm
+> **`0x5d6c0`**, back **`0x0ec0`** — and this page states it further down: *"both
+> waves are located in `Static.slb`. The port can have the audio."*
+>
+> What survives below is the **reason the file resists static scanning**, which is
+> still correct and still worth reading: `Static.slb` carries no `RIFF`/`seek`/
+> `WAVE` delimiters at all, so a wave in it is defined only by `(offset, packet
+> count)` and those come from the oracle, not from the bytes. The negative was
+> about the *method*, and it was written as though it were about the *audio*.
+>
+> Kept rather than deleted: it is the evidence for why the extraction route had to
+> be dynamic. ⚠️ It was also still being quoted by `INDEX.md` days later
+> ([audit](data/index-vs-pages-audit.txt)).
+
 
 `Static.slb` is **8 353 472 readable bytes** (declared 8 970 240 — exactly the
 616 768 over-declaration the corpus already records), and it contains