re: the +0x08 falsifier does not identify +0x08 -- the value is right, my argument was wrong

sylpheed-port aimed my own boundary finding at my loop-length control. Reproduced
from my reader over every pak: +0x04 has 0 violations too, so the falsifier rejects
+0x0c and accepts +0x04 and never discriminated. What identifies +0x08 is the
exactness statistic the page presents as secondary -- exact match in half the
records against 0 % for +0x04.

Population differs from theirs, 3311 records against 1781, because this scan takes
every pak and requires a timed keyframe, so the percentage moves but the
discrimination does not.

Second time this week with the weight on the wrong leg: a count taking credit for an
exclusion argument, now a falsifier taking credit for an exactness statistic, and
both times the real discriminator sat beside it described as a formality.

Their general form is sharper than my boundary rule: an interior consistency check
is satisfied by any internally consistent reading, and that is what a wrong offset
into a regular structure usually is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

crates/sylpheed-formats/examples/loop_length_offset_discriminates.rs

@@ -0,0 +1,64 @@
+//! Does the `+0x08` falsifier actually identify `+0x08`?
+//!
+//! `ui-record-loop-length.md` (mine) rests on: an animation cannot restart before
+//! its own last pose, so a wrong reading should produce violations, and none exist
+//! in 1 781 records. `sylpheed-port` re-ran it at the neighbouring offsets and
+//! reports the falsifier ACCEPTS `+0x04` too — meaning it does not discriminate,
+//! and the real evidence is the exactness statistic I called a formality.
+//!
+//! This checks that from my own reader before I correct the page.
+//!
+//!     cargo run -p sylpheed-formats --example loop_length_offset_discriminates
+use sylpheed_formats::{pak::PakArchive, ui_layout};
+use std::path::PathBuf;
+
+fn be32(b: &[u8], o: usize) -> Option<u32> {
+    (b.len() >= o + 4).then(|| u32::from_be_bytes([b[o], b[o + 1], b[o + 2], b[o + 3]]))
+}
+
+fn main() {
+    let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
+    let dat = root.join("dat");
+    let mut paks: Vec<_> = std::fs::read_dir(&dat)
+        .expect("dat")
+        .filter_map(|e| e.ok().map(|e| e.path()))
+        .filter(|p| p.extension().map(|x| x == "pak").unwrap_or(false))
+        .collect();
+    paks.sort();
+    // offset -> (records, violations where word < max_t, exact matches)
+    let mut stat = [(0usize, 0usize, 0usize); 3];
+    let offsets = [0x04usize, 0x08, 0x0c];
+    for p in &paks {
+        let Ok(ar) = PakArchive::open(p) else { continue };
+        for e in ar.entries() {
+            let Ok(by) = ar.read(e) else { continue };
+            let Some(b) = ui_layout::parse_build(&by) else { continue };
+            for (_, (off, size)) in &b.records {
+                let rec = &by[*off..(*off + *size).min(by.len())];
+                if rec.len() < 0x10 || &rec[0..4] != b"RATC" {
+                    continue;
+                }
+                let Some(leaf) = ui_layout::parse_build(rec) else { continue };
+                let max_t = leaf
+                    .elements
+                    .iter()
+                    .flat_map(|el| el.keyframes.iter().filter_map(|k| k.time))
+                    .max();
+                let Some(max_t) = max_t else { continue };
+                for (i, o) in offsets.iter().enumerate() {
+                    if let Some(w) = be32(rec, *o) {
+                        stat[i].0 += 1;
+                        if w < max_t { stat[i].1 += 1 }
+                        if w == max_t { stat[i].2 += 1 }
+                    }
+                }
+            }
+        }
+    }
+    println!("{:>8} {:>9} {:>12} {:>14}", "offset", "records", "violations", "exact == max_t");
+    for (i, o) in offsets.iter().enumerate() {
+        let (n, v, x) = stat[i];
+        println!("  +0x{o:02X}   {n:>9} {v:>12} ({:>5.1}%) {x:>8} ({:>5.1}%)",
+                 100.0 * v as f64 / n.max(1) as f64, 100.0 * x as f64 / n.max(1) as f64);
+    }
+}

docs/re/METHOD.md

@@ -3206,3 +3206,32 @@ published alignment survives at both edges, both shifts fail.
 📌 **The general rule: for any repeated structure, the evidence for the field order
 lives at the first and last record.** Everything in between is compatible with every
 phase, and checking it is the reassurance that feels like verification.
+
+## An interior consistency check is satisfied by any internally consistent reading
+
+`sylpheed-port` aimed my boundary finding at a control of mine and it landed. My
+`+0x08` loop-length page rests on a falsifier: *an animation cannot restart before
+its own last pose, so a wrong reading should produce violations, and none exist*.
+
+🔴 **It does not identify `+0x08`.** Reproduced from my own reader over every pak:
+
+| offset | violations | exact `== max t` |
+|---|---|---|
+| `+0x04` | **0 — passes** | **0.0 %** |
+| `+0x08` | 0 | 49.6 % |
+| `+0x0c` | 1 287 | 11.8 % |
+
+A wrong reading one word left produces no violations either. **The discriminator is
+the exactness statistic the page presents as secondary** — `+0x08` matches exactly
+in half the records, `+0x04` in none.
+
+📌 **Second time this week with the weight on the wrong leg**, and both have the
+same shape: a *count* taking credit for an exclusion argument, then a *falsifier*
+taking credit for an exactness statistic. **In both, the real discriminator was
+sitting beside it, described as a formality.**
+
+⚠️ Their statement of the general rule is sharper than my boundary version, which
+does not transfer to a per-record header: **an interior consistency check is
+satisfied by any reading that is internally consistent — and "internally
+consistent" is what a wrong offset into a regular structure usually is.** The
+boundary rule is the special case where the structure's edges break that regularity.

docs/re/structures/ui-record-loop-length.md

@@ -1,7 +1,31 @@
 # A nested record's `+0x08` is its loop length — and the plate holds dark for 15 units
 
 **Classification: decoded.** The field is read from the disc and checked
-disc-wide (1 781 records, 0 violations). The consequence for the `PRESS Ⓐ` plate
+disc-wide (1 781 records, 0 violations).
+
+> 🔴 **CORRECTED 2026-08-31 — the value is right and this argument for it was
+> wrong.** "0 violations" was published as the load-bearing evidence: an animation
+> cannot restart before its own last pose, so a wrong reading should produce
+> violations. `sylpheed-port` re-ran it at the neighbouring offsets and **it does
+> not discriminate.** Reproduced from my own reader over every pak:
+>
+> | offset | violations (word < max t) | exact (word == max t) |
+> |---|---|---|
+> | `+0x04` | **0 — passes the falsifier** | **0.0 %** |
+> | `+0x08` | 0 | **49.6 %** |
+> | `+0x0c` | 1 287 (38.9 %) | 11.8 % |
+>
+> **A wrong reading one word left produces no violations either.** The falsifier
+> rejects `+0x0c` and accepts `+0x04`, so it never identified `+0x08`.
+>
+> ✅ **What does identify it is the exactness row below, which this page presents as
+> a secondary statistic**: `+0x08` equals the largest keyframe time *exactly* in
+> half the records and `+0x04` in **none**. No unrelated word reproduces that.
+>
+> ⚠️ My population differs from theirs — 3 311 records against 1 781, because this
+> scan takes every pak and requires a timed keyframe — so the exact percentage
+> moves (49.6 % vs 92.3 %). **The discrimination does not**: 0 % for `+0x04` under
+> both counts. The consequence for the `PRESS Ⓐ` plate
 is then tested against the corpus's existing measurements of the running game,
 which it passes and the previous reading fails.