From d660705c47098c9de58b4a3abd44d2b7ab57b3d2 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Wed, 12 Aug 2026 00:16:22 +0000 Subject: [PATCH] re: the correct anchor is already a candidate -- locality selects it, monotonicity does not Enumerating every validating candidate for e303_wep_01 in Stage_S02 gives exactly two: vb = 18403456 span 1600 x 2100 x 4800 <- taken, only because it is first vb = 52257440 span 49 x 23 x 42 <- correct, the size all 11 good containers give So the scan is not missing anything; the wrong block merely appears earlier in file order. Monotonic anchoring is REFUTED as the constraint: recording each resource's accepted anchor in descriptor order gives 25/47 increasing steps in Stage_S01 and 130/248 in Stage_S02, no better than chance. Locality holds instead -- in Stage_S02 the descriptor neighbours anchor at 51974668 and 52218424, the correct candidate is 52257440, and the wrongly-taken block sits at 18403456, two thirds of the file from its own family. Proposed rule, needing no new format knowledge: among validating candidates prefer the one nearest the neighbouring resources' anchors, falling back to first-match when there is no neighbour yet. It selects 52257440 here. Not implemented: it moves the anchor for all 6294 resources, so it needs the before/after measurement (decoded must not fall from 5480, inconsistent should fall from 125) and then un-ignoring mesh_consistency_disc. Instrumentation reverted; only docs land here. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/structures/xbg7-mesh.md | 41 +++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/docs/re/structures/xbg7-mesh.md b/docs/re/structures/xbg7-mesh.md index 9e5cd60..de74547 100644 --- a/docs/re/structures/xbg7-mesh.md +++ b/docs/re/structures/xbg7-mesh.md @@ -365,16 +365,39 @@ family of fixes: no threshold, no scoring, no "pick the best candidate" changes this, and the earlier attempt to add best-of-N selection in the grouped-pool anchor duly changed nothing. -**The search space has to be constrained instead.** Two candidates, in order of -how much new format knowledge they need: +**The search space has to be constrained instead — and the fix is now pinned +down.** -1. **Per-resource data extents.** The XPR2 resource table gives each resource a - descriptor; if the geometry extent can be derived from it, restrict `starts` - to that range and the theft becomes impossible. -2. **Monotonic anchoring.** If resources' data blocks follow descriptor order, - then resource *k*'s `vb` must lie after resource *k−1*'s — a cheap constraint - needing no new format knowledge. Testable against the 556 resources that - already decode consistently across containers. +**The correct block is already in the candidate list.** Enumerating *every* +validating candidate for `e303_wep_01` in `Stage_S02` gives exactly two: + +``` +vb = 18 403 456 span 1600 × 2100 × 4800 ← what the decoder takes, only because it is first +vb = 52 257 440 span 49 × 23 × 42 ← correct: the same size all 11 good containers give +``` + +So nothing needs to be found that the scan is missing; the wrong one merely +appears earlier in file order. + +**Locality picks the right one.** Recording each resource's accepted anchor in +descriptor order shows that global **monotonicity is refuted** — only 25 of 47 +steps increase in `Stage_S01` and 130 of 248 in `Stage_S02`, i.e. no better than +chance. But *neighbourhood* holds strongly: in `Stage_S02` this resource's +descriptor neighbours anchor at **51 974 668** and **52 218 424**, its correct +candidate is **52 257 440**, and the block it wrongly takes is at **18 403 456** — +two thirds of the file away from its own family. + +**Proposed rule:** among candidates that validate, prefer the one **nearest the +anchors of the neighbouring resources** (equivalently: decode in descriptor order +and prefer candidates close to the previous resource's anchor), falling back to +first-match when there is no neighbour yet. That needs no new format knowledge, +and it selects `52 257 440` here. + +**Not implemented.** It changes the anchor for every one of the 6 294 resources, +so it needs the before/after measurement — decoded count must not fall from +5 480, and the inconsistency count should fall from 125 — plus the ignored test +[`mesh_consistency_disc.rs`](../../crates/sylpheed-formats/tests/mesh_consistency_disc.rs) +un-ignored once it passes. ### Where the mis-decode is *not*: the grouped-pool anchor