5149c7be5dbdd528de5478f61ea2d7bf99f484f0
252 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
sylph-decoder
|
e35c56a5ed |
re: refutation attempt on Q2's 'shipped twice' -- it survives, with one real caveat
The doubt was my own artefact: the entry dump printed only the first two sprite names in HashMap order, making 11 and 14 look like different studios. Full sets are identical. 7 of 8 pairs declare identical sprite sets, control included. 4/7 does not: entry 7 carries nine sprites entry 4 lacks, including ptlogo_jp and ptlogo_jpeff, so the Japanese title is a different element inventory rather than the same screen localised. That matches the JP capture work from the other side. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
ec9ab203af |
handoff: Q2 enumerated six of eight screens and mis-paired the splashes
sylpheed-port caught that a reader counting the Q2 row gets twelve entries with no slot for the boot splashes -- in a row already corrected once for an ordinal-versus-entry error. Verified off the disc: the splashes are 10/13 (palogo_sqex, publisher) and 11/14 (palogo_gamearts/seta/anima, developer). The row said 'in entry space 10/11 are the publisher and developer splashes', which names one half of each of two different pairs rather than a pair. All eight screens now enumerated, with the per-entry names committed as reference data. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
e5f1b7c2d4 |
formats: expose loop_length_units -- the port was reading +0x08 itself
sylpheed-port reports that a record's loop length is on no public ref at all (example, test and docs/re/ only), so their screen.rs parses the four bytes with its own RATC guard. That is my field to publish. One function serves both levels, since a nested .rat leaf is itself a RATC bundle with the same header shape. Returns None for a non-RATC or short slice so callers need no guard of their own. Verified against the disc, controls first: rejects a non-RATC slice, rejects one too short for the field, reads big-endian at +0x08 -- then reproduces every published value (ptbtn00f 120, ptloop01 600, ptloop02 720) over 65 GP_TITLE records with 0 violations of +0x08 >= largest keyframe time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
8d43e16c6f |
re: two fixed-code-under-unfixed-description hits in the crate the port pins
sylpheed-port named a pattern narrower than "docs go stale": a correct fix sitting directly beneath a refuted description in the same file, within twenty lines. Not drift -- editing at the point of failure without re-reading the frame around it. Applied their grep (the vocabulary the OLD rule needed) to my crate and found two. ui_layout.rs:308, in rest_plateau's fallback: `continue; // the last frame carries no time`. That is the pre-fix rule, on a branch that is now UNREACHABLE -- measured at 0 untimed of 24 811 keyframes across 965 builds. Kept as a guard because `time` is still Option<u32> and a malformed group could yield None, but relabelled: it is no longer a description of the format. ui_layout.rs:268, on the `lastall` rest override: "This is what the shifted time reading predicts ... testing it against the captures is an independent check on that reading." The shifted reading was refuted by the record-layout fix in the same file. The override survives as a plain "take the last keyframe" diagnostic alongside the documented `last` and `maxalpha`, and now says so. Both corrections quote the original sentence so the change is visible rather than silently overwritten -- the practice the port adopted from me this iteration. Verified by artifact rather than by "it compiles": a comment-only edit must leave output byte-identical, and the build-7 render's md5 is unchanged at 141771d8f1a2b3496cfd679c6cd45d1a. METHOD records the pattern with the two greps that find it: the vocabulary of the dead rule in code, and a HEDGE around something the current reader states exactly in prose -- a "~0" marks where the old reader could not see. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
22846bf30e |
re: finish the --help audit -- a stale percentage and a missing noun, both shipped
The METHOD entry I wrote an hour ago says to read your tool's own --help as if a stranger wrote it. I had done that for ONE of sixteen leaf commands, which is the "a rule written down is not a rule applied" failure this corpus already records twice. Finished it across the whole surface. One survivor, and it fails in two ways at once. `screen render --settle` said a narrow window means the bundle never settles, "(42 % of them, mostly loop* fragments)". MISSING NOUN: inside `screen render`, "them" reads as the builds you would render. The 42 % is over composable bundles -- a different and much larger set including ~1 700 two-element fragments a user of that flag never renders. ui-settle-time.md states its population precisely; the help inherited the number without it. STALE: recomputed under the corrected reader, the composable figure is 862/2211 = 39 %, not 731/1758 = 42 %. The POPULATION GREW BY 453, which is the keyframe record-layout fix's signature -- it times a group's final pose, so bundles that previously showed one timed keyframe now show two and qualify. Third consequence of that fix not being swept, after fade_quads.py and screen-transitions.md's 0.87-4.08 s fade-in. And the share a --settle user actually faces is 38 %: 185 of 491 screen builds. Corrected in the help text with all three numbers and their populations, and in ui-settle-time.md, whose three-row table is marked pre-fix and superseded rather than edited in place. Verified by artifact -- the tool's --help output is quoted, not merely recompiled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
0d1e0ae8b7 |
re: my own CLI shipped an unmeasured recommendation -- "Prefer --settle" withdrawn
sylpheed-port reported hedging a predicate in DECISIONS.md while stating the unhedged version in their tool's header, and named it as the same delivery gap they had fixed once elsewhere and not generalised. Checked this side for the same shape and found it. `sylpheed-cli screen render --at` told every user that the resting pose "is wrong twice over" and to "Prefer `--settle`". That recommendation was never measured. What the corpus actually records: scored against a live capture of the JP title, settle gives RMSE 40.210 and rest 41.690 -- a margin of 1.48 against that instrument's own noise floor of 1.2, which is not decisive -- and --settle has its own failure mode, 25.5 % of elements mid-ramp at their screen's settle instant. So neither is established as better, and the interface has been telling people otherwise while the hedge lived only in docs/re/. Corrected in the help text itself, on both flags, with the numbers rather than a softer adjective. Verified by artifact: the tool's --help output is quoted in the commit's own test, not merely recompiled. METHOD: hedging in the write-up does not protect the claim you ship in the tool. Docs are where a claim is reasoned; the tool is where it is believed. Read your own --help as if a stranger wrote it and check every confident sentence against what the corpus establishes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
82b20bc51d |
re: test the port's black-backdrop predicate disc-wide -- exact locally, rare globally
sylpheed-port proposed that a screen declaring a full-screen .prm at t=0 with fade == 0xff000000 is standalone, and one without it is composited: 12/4 across their sixteen exported screens, every exception independently known to be composited. They asked for it against archives they do not have. That is my lane. CONTROL: the predicate reproduces their split exactly. GP_TITLE's sixteen bundles give 12 with and 4 without, the four without being entries 0, 1, 2, 3 -- build_00, build_01, press_start, press_start_jp -- and the element names match (pteff00.prm, palogo_eff0.prm, pgloading_eff00.prm). Independent derivation from the disc, not a re-run of their tool. DISC-WIDE it is rare: 76 of 965 screen builds, 7.9 %. GP_STAGE_CLEAR 4/4, GP_SYSTEM 2/2 and GP_TUTORIAL 2/2 are all-yes; GP_HANGAR_ARSENAL is 0 of 390, and GP_READY_ROOM, GP_OPTIONS, GP_PAUSE_MENU and GP_GAMEOVER are all zero. So it is not a general standalone/composited test. GP_OPTIONS and GP_PAUSE_MENU are screens a player plainly sees as screens and declare no backdrop; read as "composited" the rule would make 92 % of the game's screens composited, which the archives do not support. What it appears to separate is narrower: screens that BEGIN FROM BLACK from everything else. A pause menu over gameplay, a hangar over a 3D scene and a plate over a title all lack a backdrop without being the same kind of thing -- the negative class is heterogeneous, which is what a two-way rule cannot express. For the port: exact within GP_TITLE, so --black for those twelve is justified from the file rather than assumed; do not carry it into the four archives they have yet to export, where in three of them it classifies every screen alike. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
9a80ed6bd2 |
re: (A) on a settled boot title DOES reach the menu -- the withdrawal explained
Clearing my own debt: I withdrew navigation.md's "boot title accepts a single A" counter-example as confounded by three concurrent emulators and never re-ran it, which left the claim unsupported rather than settled. Clean trial: exactly one emulator verified by count, gated on the plate pulse (glyph in [500,2500] held 12 samples) so the press lands on the BOOT title rather than the attract loop's, delivery confirmed at [file-pad] keystroke vk=5800 down/up. Glyph after the press is 0 at +2 s and +4 s -- the transition -- then 327 steady from +6 s through +39 s. 327 is a proxy and reading a proxy is the habit this corpus keeps cataloguing, so the screen was checked with which_title_screen.py instead: main_menu at RMSE 19.91 and 20.08 with margin ~10, inside the 9.9-11.7 band its control establishes on four known captures. The before frame gives the "neither" signature at margin 0.10, correctly, since the title is neither main_menu nor extras. So the count is 3 of 3, the latency is 4-6 s -- which is why a script that presses and looks 0.5 s later concludes the press was dropped -- and the two earlier failures were the confound, not the game. Refutation attempted: sylpheed-port's leaf segment rates. Derived independently from the disc and they SURVIVE exactly -- pteff03 +4.0000 then +4.0000 then a hold, pteff03a -4.0667 then -4.0625 then a hold. So their inversion stands: my linearity gate fails on the leaf whose declared track is perfectly straight. And records the third structural consequence of main being stale, which they raised: HANDOFF.md is the delivery contract and it lives on an unmerged branch, so their checkout contains none of this week's entries. Findings written into the contract reach them only through messages -- the channel the protocol says does not count as delivery. Writing it in the contract is necessary and not sufficient when the contract lives where the other party cannot see it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
dd7edd5e38 |
re: withdraw "the sweep rate matches the disc" -- two errors that cancelled
sylpheed-port corrected the disc figure I compared against: the leaf's final segment HOLDS, so a cycle length is not a motion duration. Verified from the disc rather than accepted -- pteff03 moves over t=0..540 of a 600-unit cycle (4.000 px/unit, not 3.600) and pteff03a over 0..630 of 720 (4.063, not 3.556). Checking that sent me back to my own measurement, which was worse. "6-7 px/frame" came from eyeballing deltas between consecutive APPEARANCES in a capture that skips frames, so a delta of 7 often spans two frames. A least-squares fit of x against frame over all 132/112 points gives +4.287 and -4.348 px/frame, with rms residuals of 3.6 and 3.3 px. So the confirmation I reported was a prediction 20 % too low meeting a measurement 50 % too high. Neither number was right and the agreement was an artefact of both being wrong -- which is the most dangerous form of agreement in this corpus, because nothing about it looked suspicious. The corrected numbers say something larger than the claim they replace. Measured against declared: 4.287/4.000 = 1.072 units per frame, and 4.348/4.063 = 1.070. Two independent strips with different cycle lengths and different declared rates agree to three significant figures. Q1 establishes 2 units per RENDERED frame for top-level elements. So either a nested leaf record advances at about half the top-level rate, or Q1's factor does not apply to nested records. Measured, not explained, and flagged as deserving its own iteration because Q1 is load-bearing. One untested candidate recorded: 1 unit per 1/30 s of game time against the ~28.5 fps this corpus measures for the idle title gives 1.053, close to 1.07. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
2145691586 |
re: verify the sweep leaves' full extent -- port's table confirmed, plus a new fact
Attempted to refute sylpheed-port's leaf table by measuring it against the disc. It SURVIVES to the digit: ptloop01 -> pteff03, cycle span 600, x track -639..1521, scale (100, 600); ptloop02 -> pteff03a, span 720, x -839..1721, scale (100, 800). The existing ptloop_leaf_sweep_at.rs samples only t=340..540 -- a window chosen to compare two competing fits -- so it could never have shown the extent. That gap is what let my "ptloop01/02 do not free-run" claim stand: measured over the parent's 200x90 pivot rect, which a leaf travelling -639..1521 is almost never inside. ptloop_leaf_extent.rs sweeps the whole cycle instead. New fact neither of us had: the leaves are IDENTICAL on entries 4, 5 AND 7 -- the title, the main menu and the JP title. Same leaf names, spans, x tracks, scales and parent rest position. So the menu declares exactly the same sweep as the title, and the still-open menu question is about the game's behaviour rather than a different declaration. The quad is 400 px wide at scale_x 100 % -- not widened -- and scale_y 600/800 % makes it 1080/1440 px tall, taller than the screen. A full-height strip crossing the frame and going off both sides, which is why a phase-to-phase diff covers the union of two positions and looks frame-wide. And my own "centre running x~921->1041" was a 30-unit window of a 600-unit cycle whose centre spans -439..1721. A sub-range is not an extent -- the same caution as a pivot not being a bounding box, one level up, and I made both errors within a day. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
ee5ed2cfd2 |
re: count the in-range fallbacks -- and the control that failed is the answer
sylpheed-port pointed out that classifying defaults "by inspection" is exactly
the method that cannot see an in-range fallback, and that correction applies to
my own sweep from an hour ago: I waved 64 sites through by reading them.
Counted instead, disc-wide over 965 builds and 24 811 keyframes:
ui_layout.rs:1681 untimed poses (would fabricate t=0): 0
ui_layout.rs:1010 pose_at queries 168 264, None (reads a=0): 0
Two zeroes, which is the result this corpus now distrusts most, so the detector
was made to prove it can see a hit: ask pose_at for a time no build declares.
The control FAILED -- 10 906 out-of-range queries, 0 None -- so the detector was
blind and the :1010 zero measured nothing.
The failure is the finding. pose_at is TOTAL: reading the source, its only None
path is an `if ks.is_empty() { return None }` guard, and disc-wide there are 0
elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is unreachable
BY CONSTRUCTION, which is stronger than "0 in this corpus" -- and it was
established by the control failing rather than by the count passing. Without the
control this corpus would have recorded a true conclusion resting on a
meaningless number.
:1681 stands differently: 0 of 24 811, and time really is Option<u32> with the
stale reader demonstrably producing None (its screen info prints a trailing -),
so the state is representable and a detector would see it. :973 is not a hazard
-- guarded two lines later by `if tmax == 0 { return false; }`, where reading is
sufficient because the guard is the proof.
METHOD gains both: a zero is worth nothing until the detector is shown able to
report non-zero; and the habit under several of this week's errors, which is
reading a PROXY for the thing when the thing itself is one command away -- a line
count for an era, a type name's spelling for its default, an ordinal for an
entry, a fallback's text for its firing rate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
|
||
|
sylph-decoder
|
593ce46069 |
re: sweep my own crates for fallbacks that fabricate a quantity
The mirror of sylpheed-port's sweep after their exit_ramp_units catch, where a
refuted 24.0 survived in a `get(..., 24.0)` fallback because the authored entry
had been deleted as progress and the deletion was a no-op.
112 fallback sites across sylpheed-formats and sylpheed-cli. 64 supply 0, false,
empty or Default -- sentinels asserting nothing. Of the 48 remaining most are
pass-through or an extent. Positive control: the filter found media.rs:314
unwrap_or(anchor), the voice-region start fallback landed earlier this session,
so the detector finds a known case rather than only reporting absence. The
mesh.rs cluster (1.0, 0.85, 0.5, 0.70, 0.45) is env-var tunables with defaults
documented in xbg7-mesh.md.
ui_layout.rs, the crate the port pins, has 8 sites; 6 sentinel or pass-through
and 2 that could fabricate a quantity. Both fabricate a value that is
LEGITIMATE, which is worse than the port's conspicuous 24.0:
:695 unwrap_or((DESIGN_W, DESIGN_H)) -- 1280x720, which is what every real
screen states, so no parser output can distinguish read from invented.
MEASURED: it fires 0 times in 965 builds disc-wide, so design_w/design_h
is read and the port can rely on it.
:1681 kf.time.unwrap_or(0) in the serialiser -- 0 is a real keyframe time
(pose 0's time IS 0). Unreachable today under the corrected record
layout, the same status as their exit_ramp_units branch, but a
fabricated 0 would be indistinguishable from a real one.
The measuring instrument failed its own control first: a version reading EVERY
RATC child reported all 965 builds stating a non-standard design size
(GP_TUTORIAL 12x3), where `screen list` prints 1280x720 for every one -- a T8aD
sprite header read at +0x18 is garbage that passes the range test. Filtered to
the .rat records, it reproduces screen list exactly.
METHOD: a fallback default is an authored value no reader can see, and the
dangerous ones are IN-RANGE -- the only way to know is to count how often they
fire, which no parser output reveals.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
|
||
|
sylph-decoder
|
c364cde476 |
re: sweep the disc for the ordinal foot-gun -- GP_TITLE was the mildest case
Last iteration I retracted three claims because `--build 10/11` on GP_TITLE are entries 12/15, and named the untested remainder in my own report: how much else in the corpus used a build ordinal as an entry index. This is that sweep. `screen --build N` indexes a predicate-filtered list, so every rejected entry shifts every later ordinal. Disc-wide: 21 of 24 build-bearing archives diverge, 18 of them at ordinal 0 -- `--build 0` is entry 108 in each GP_MAIN_GAME_*2D, 24/26 in GP_HANGAR_ARSENAL/GP_READY_ROOM. GP_TITLE is the ONLY archive whose first ten ordinals are the identity, which is the sole reason 207 of the corpus's 226 build citations are safe. Second foot-gun: `--all` swaps the predicate and renumbers 18 archives, so `--build N` and `--build N --all` are not the same object. The instrument failed its control first. A version using parse_build as the predicate reported GP_TITLE as 16 builds, ordinal == entry throughout -- it would have certified the exact bug it was built to find. The shipped version uses the same predicates screen_builds() uses and reproduces `screen list` on GP_TITLE exactly. Audited all 226 citations. One real defect: a five-row table in ui-keyframe-time-unit.md headed "declared element (build 11)" spans builds 10 and 11 -- palogo_sqex is in 10. All five placements re-verified and correct, so the linear-ramp measurement is untouched; only the label was wrong. Fixed with a per-row bundle column. GP_DIALOG --build 0 and GP_DEBRIEFING_PILOTLOG --build 10 re-run and reproduce. Refutation attempted: sylpheed-port's corrected mid-ramp test rests on ptlogo_all_eff holding a=127 from t=112 to t=246. Their quote is exact and it is a plateau. The refutation fails; their correction stands. METHOD already carried the rule I broke, and ui-splash-addressing already said the splashes need --all. The failure was not missing knowledge -- it was addressing a bundle by index without grepping for the index first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
3356343cad |
re: RETRACT the splash settle windows -- --build takes an ORDINAL, not an entry
The port recomputed the publisher splash's widest keyframe-free gap as 190 units against my 8 and said one reading must be wrong. Mine was, and the library was never wrong -- only my invocation. From the file: entry 10's union of times is [0,15,30,45,235,239,251,255], widest gap 190, and settle_window() returns Some((45,235)). Entry 11 gives 145. Both match the port exactly. The cause is that screen render --build N takes a BUILD ORDINAL. screen list says [10] entry 12 and [11] entry 15; the splashes are entries 10 and 11 and are not screen builds at all, so my --build 10/11 rendered the LOADING screens. This is the foot-gun HANDOFF already documents, which the port caught months ago in the mirror direction. Three retractions: 1. 'Width does not predict quality' -- withdrawn. It rested entirely on the splashes being width 8 while winning 75x. They are the widest of the five, so width and mid-ramp are perfectly confounded across every screen either of us has measured and the width hypothesis is NOT refuted. 2. 'My filter excluded the splashes' -- withdrawn; at 190 and 145 they were never near the 10-unit cutoff. The other half stands: it admitted the 10-19 bucket, the worst at 45.1 %. 3. The splash rows of settle-vs-rest-against-captures -- void. They scored loading-screen renders against splash captures. I discarded them for a railed gamma fit; the real reason is that they were the wrong screens, and the railing was that mismatch surfacing where my instrument could report it. Surviving: the title row (ordinal 4 = entry 4) and the disc-wide censuses, which iterate pak entries directly and never touch the ordinal path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
9d32852724 |
re: census the settle pose's own failure mode -- and refute the obvious explanation
The port found ptmsg, the main menu's footer, at alpha 127.5 at that screen's settle instant. Verified: build 5's window is [44,56] = 12 units and screen render --settle already prints 'narrow -- this bundle may never settle'. Disc-wide, elements caught mid-ramp at their screen's settle instant: 25.5 % overall, 40.9 % on windows under 10 units, 45.1 % on 10-19, falling to 11.7 % and 15.0 % on wide ones. The obvious reading of that table -- narrow window means the settle pose is bad -- is REFUTED by the screens that motivated the proposal, and I nearly published it. The two splashes have an 8-unit window, narrower than the main menu's 12, and the settle pose beats rest() there by 75x and 33x. Width does not predict quality. The predictor is the port's own statement: the settle pose wins decisively where rest() lands on a transient's peak, and loses slightly where rest() is already sound and an element arrives after the window closes. And my own rest_vs_settle filter was wrong in both directions: dropping bundles under 10 units admitted the 10-19 bucket, the worst at 45.1 %, and excluded both splashes at width 8 -- the strongest evidence FOR the proposal. A threshold taken from a documented rule of thumb and applied without checking which screens it admitted and which it threw away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
642341b12b |
re: rest_plateau() picks the wrong plateau -- and it is the whole residual
rest_plateau() selects the LONGEST run of identical adjacent poses, which need
not be the run covering the screen's settle instant. rest_vs_settle left a 21.9 %
disagreement that I recorded as ambiguous by construction. It is not.
CONTROL exactly one plateau, covering the settle instant:
3 072 / 3 072 agree (100.0 %)
TEST more than one plateau, at least one covering:
1 622 elements, agree on 586 (36.1 %)
of the 1 036 disagreements, rest() landed on a run NOT covering the
settle instant: 1 036 -- all of them, no exceptions
Both poses are genuinely held in these cases -- they are plateau cases, not
transients -- so this is rest() returning a pose the screen has ALREADY LEFT by
the time it settles.
This corrects my own METHOD entry of two iterations ago, which said a candidate
cannot be adjudicated against the incumbent it replaces. Too strong. The bare
comparison cannot; the comparison plus a structural property that independently
says which side is wrong in each disagreement can. What I lacked was not an
oracle but a discriminator.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
|
||
|
sylph-decoder
|
0c9224fbbc |
re: propose settle-instant posing -- and my control cannot validate it
The proposal: pose every element at the SCREEN's settle instant rather than asking each element for its own resting pose. On the 2 249 fallback elements in settling bundles the visible-pose rate falls 73.6 % -> 34.7 %. But the control fails twice. Naive, over every plateau element: 46.6 %. That one was misspecified and I caught it by asking what the number means physically -- rest() finds *a* held pose and many elements hold one during the build-in then move on, so it answers a different question and disagreement proves nothing. Restricted to elements HOLDING ACROSS the settle instant: 78.1 %, still not a pass. And the residual is ambiguous by construction: rest_plateau() picks one plateau, so an element with two whose settle instant falls in the other will disagree -- and there pose_at(settle) is RIGHT. The control cannot separate 'the candidate is wrong' from 'the incumbent is wrong'. Recorded as the general point: comparing a candidate to the incumbent cannot adjudicate when the incumbent is the thing under suspicion. It is the wrong shape of experiment, not a tuning problem. What does adjudicate is the oracle and it is the port's measurement, not mine -- publisher splash against a committed capture, settle-instant pose RMSE 2.17 / 0.01 % differing against --pose=rest 9.05 / 0.75 %. My numbers describe the proposal's effect; they do not establish it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
c89e4da723 |
re: my own 1697 audited -- and the first correction failed its control
Applying the port's physical-story rule to my own number. '1 697 fallback fires return a visible pose' was published as if it were a defect count; it is not, since an element that genuinely ends visible should rest visible. The first correction split the 1 697 by whether the element's LAST keyframe is visible: 347 correct, 1 350 transient peaks. Plausible, arithmetic fine, and WRONG -- 12 278 of 13 991 elements (87.8 %) end at alpha 0 because a screen's exit ramp drives everything to zero, so the split carries almost no information. The 1 350 is not published. What survives needs no such split: the fallback runs only when no two adjacent poses are equal, i.e. only when no pose is held, so every pose it can return is un-held by construction -- and 1 457 of the 2 305 times it returns the element's MAXIMUM alpha, the brightest un-held pose. I ran that control only because the port had just been bitten by the same exit ramp, its census calling ptmsg -- the main menu's permanent footer -- 'a 2-unit flash'. Without its message the 1 350 would have shipped. METHOD gains the sharpened form: the physical-story test catches confident FALSE claims, not just nulls. A wrong number usually still has a story, just an absurd one. Plus the tell that its fix was right -- re-keyed on the screen's span, the false positives fell out on their own, and a definition that stops needing hand-maintained exceptions is usually the correct one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
ad9cd948c6 |
re: the port's two extra elements are PLATEAU cases -- refutation succeeds, and its point gets bigger
The port listed palogo_gamearts_eff and palogo_seta_eff among GP_TITLE's four visible dwell-fallback fires; this census listed only palogo_sqex_eff and palogo_anima_eff. Checked, and the census is right: gamearts_eff and seta_eff hold a=255 at identical x, y and scale from t=15 to t=30, which is a plateau at pair index 1, so rest_plateau() handles them and t=15 is the CORRECT answer. They are not fallback cases. The distinction is not cosmetic -- a plateau is a pose the element genuinely holds, and only the dwell fallback is the unsound path. But the refutation makes the port's underlying point STRONGER. Its rest pose for those two really is the flash's peak, reached by the SOUND path. So 'a rest render is not a frame to score against a capture' does not follow from the fallback being unsound: a plateau can itself be the held peak of a transient. The rule covers both paths, and the fallback census understates the exposure rather than bounding it. Also records the port's oracle number for the rule -- publisher splash against the committed capture, timeline RMSE 2.17 / 0.01 % differing against --pose=rest 9.05 / 0.75 %, 75x the differing area. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
cae2f7596e |
re: the rest() fallback -- its example dissolved, the question got bigger
ui-resting-pose.md built its dwell-fallback section on GP_TITLE build 7's ptlogo_eff3.t32, listing keyframes [46, 61, 103, -] -- the STALE PARSER's output. Corrected they are [0, 46, 61, 103], the longest gap moves from 61->103 to 0->46, and BOTH ends of the new longest gap are a=0. The element no longer selects a visible pose under either indexing, and build 7 renders byte-identical under the corrected and legacy readings (0 px differ). MISSION lists this element as the one case a Japanese capture was needed to discriminate; it is not. But losing an example is not closing a question, so: disc-wide census. The fallback fires on 2 305 of 13 991 elements and returns a VISIBLE pose in 1 697 of them -- 74 %. GP_TITLE is 5 fires, 4 visible, and all four are on the SPLASH screens: palogo_sqex_eff and palogo_anima_eff, each [0:a0 15:a255 30:a212 45:a0], a flash peaking at 15 and dead by 45 where the fallback returns t=30 a=212. Independently converged on from the other side: the port, working from the JP capture and knowing nothing of this census, found ptlogo_back2eff1's rest.t at the peak of its own 4-unit sparkle with six staggered across the logo, so --pose=rest fires every sparkle at once -- a frame the game never shows. Consequence recorded as a rule: a render posed at rest is a legitimate common reference for comparing two DECODERS and is not a frame to score against a capture of the game. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
5f386111ad |
re: count the voice-region population properly -- 25 three-chunk, and 17 of them were broken
Pays the debt from the truncated audit. The census prints population, coverage and skips in the same output, and ends with an explicit END line, so a cut-short run cannot be read as a complete one. POPULATION 104 movies; COVERAGE 95 resolved, 9 unresolved, 0 unreadable 70 one-chunk regions, 25 three-chunk regions The port's 25 was right; my '8 of 10' was not a count. Cross-referenced against the fix's own sweep, which also ran to completion (78 + 17 + 9 = 104): all 17 changed regions are three-chunk, none is one-chunk, and 8 three-chunk regions were never affected -- which the 1.5 MB cap predicts, since a region only trips the filter if its span exceeds it. So 'the defect is specific to the multichannel regions' survives with complete populations on both sides, while 'all three-chunk regions were broken' does not. The original 8-of-10 was wrong in its denominator and coincidentally shares a digit with the 8 that are unaffected, which is the kind of resemblance that carries a dead number into a later document. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
fa832fad1e |
re: the menu BGM loops at 61.93 s, and the game never reaches the fade
240 s parked on the main menu, reached by using the XMA probe log as the screen oracle instead of video -- the route the previous iteration wrote down. Menu in 26.8 s against never-in-378 s for the video rig, guest at 0.92x, capture at 0.08 % silence against the recipe page's own best of 0.31 %. BGM_103's contexts verify the screen and no ADV context appears afterwards, so the attract loop never took over. Three results, two instruments. NO SEAM: zero runs >= 0.3 s below median-18 dB in 232 s. The port's 3.4 s near-silence is a property of its authored loop, not of the game. NOT THE WAVE LENGTH: autocorrelation r at 87.750 s is -0.009 on four independent windows; the top lag is 61.909 s with a 2x harmonic. Estimator controls recover 87.750 and 60.000 exactly. 61.93 s, INDEPENDENTLY: locating 30 s slices of the capture inside the decoded summed waves shows playback advancing exactly +5.00 s per 5 s and wrapping at 61.93, from three wraps. Control: slices cut from the wave itself at 10/45/70 s are found at 10.00/45.00/70.00. Two points mis-lock where the slice straddles a wrap and they carry the two lowest scores in the table. Offsets span 0.25..57.18 s of an 87.744 s wave, so the loop is [~0, 61.93) and the final ~25.8 s is never played -- exactly where bgm-two-stems.md found the fade-out and trailing silence. The game loops before the fade, which is why there is no seam. Also corrects my own '8 of 10 three-chunk regions start mid-stream'. The port counts 25 three-chunk regions; it is right that both numbers cannot describe the same set. My audit run was CUT SHORT -- the committed file ends mid-list with no summary line -- so that was a ratio over an unknown fraction of the population, and the claim that the defect is specific to multichannel regions is now unsupported. The ADV verification and the fix's own sweep are unaffected; that sweep ran to completion and printed its totals. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
3dbfa320ae |
formats: drop the 1.5 MB cap that truncated 17 voice regions' first stream
The cause, and the fix, with a disc-wide check. resolve_movie_voice_region picks start = the predecessor cue's trailer, then filtered it with 'end - s < 1_500_000' -- 'only within one bank'. ADV's predecessor sits 3 618 816 B before end, so the filter rejected it and start fell back to anchor, which is a TOC offset and not a stream boundary. That explains the shape of the defect exactly: it strikes regions larger than 1.5 MB, which is why the three-stream multichannel regions are hit and single-stream ones never are. 17 of 95 resolving movies took the fallback. ADV's predecessor trailer at 433 425 776 plus 17 040 B of descriptor and padding is 433 442 816 -- the -238-packet start measured against the decoder, to the byte. Dropping the cap: unchanged 78, fixed cleanly 17, changed in any other way ZERO. In all 17 the only difference is a larger first chunk with every later chunk byte-identical, which is what a corrected start looks like and what pulling in a neighbouring asset does not. Regression test pinned to the RUNNING DECODER's byte_sizes rather than to this crate's own output. That is the point of it: every internal check passed happily while a third of a stream was missing, so only an external number could have caught this class of bug. sylpheed-formats: 136 tests pass, 0 fail (the one still running at commit time is an unrelated long mesh test). Exact clips for the other 16 are not independently verified -- the sweep is strong but ADV is the only one with a decoder measurement behind it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
3e8235ddbd |
re: resolve_movie_voice_region starts INSIDE the first stream, 8 of 10 multichannel regions
Found because the port refused to apply my stream assignment and did the arithmetic instead: the running decoder's three ADV contexts sum to 3 584 000 B against a resolved region of 3 114 352 -- 15 % too small to hold them. Two spans, one wrong, and it was the disc side. The gap is 238 packets exactly (487 424 B), which is what a start offset looks like; ctx0 declares 632 packets and the resolver's leading chunk has 394. Verified against the decoder's own byte_sizes, which cannot be fitted to: at -238 packets to_xma_riffs yields [1294336, 1118208, 1171456], all three exactly. It is a real boundary and not the end of a sweep -- at -300 the previous asset's chunks appear while the three ADV sizes stay stable. Disc-wide: 24 of 24 single-chunk regions start at a boundary; 8 of 10 three-chunk regions start mid-stream. The defect is specific to the multichannel case. The audit's per-movie number is an UPPER BOUND, not the clip -- its stopping rule is the chunk count changing, and to_xma_riffs absorbs a few packets of the previous asset first (243 reported for ADV against a true 238). Only ADV has external ground truth. Consequence: in those 8 movies the leading chunk is a truncated first stream, not a spurious artefact, and anything measured on it was measured on a fragment -- including this corpus's own chunk-0 level, though the assignment survives because its ratio test was chosen to be immune to the clipping. The resolver is NOT patched. Why the predecessor cue's trailer lands 238 packets into the next asset is unanswered, and a fix guessed from one movie would be worse than a documented defect. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
8c71520ab8 |
re: which ADV stream sits where -- settled by level, not by waveform
Completes ask #4. The three chunks were dumped from the resolved voice region and decoded; the assignment is ctx0 -> FL/FR, ctx1 -> FC with LFE silent, ctx2 -> BL/BR. Two instruments failed first and both look like results, so both are recorded. Envelope correlation with a per-pair lag search returns 0.86-0.95 for EVERY chunk against EVERY channel, because all six residual channels share the dialogue's activity timing -- that is an instrument with no resolving power, not a finding. Sample-level correlation returns about zero, because the chunks do not start with the movie and the XMA decode's framing offset is unknown. Level settles it under the same 0.600 gain the bed uses: each stream lands within 0.5 dB of exactly one residual pair and misses the others by 4-6 dB. The ratio test is immune to chunk 0 being a clipped tail of ctx0 -- chunk0 - chunk2 is +5.88 dB against FL - BL at +6.18 dB, agreeing to 0.30 dB, where a swap would be wrong by 11.76 dB. Structural confirmation: chunk 1 is the only chunk with a digitally silent channel and LFE is the only output channel with an empty residual (-115.73 dBFS), one to one; and the internal L/R correlations track the residual pairs' (0.932 vs 0.918, 0.962 vs 0.929). Worth having on its own: the same 0.600 scales both the movie bed and the voice, so it is one mixer gain rather than two. Reach: levels, not waveforms; one boot, one movie; and whether 0.600 is a fixed constant or a volume setting is still unknown. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
59f3ac6846 |
re: ask #2 -- t=357.7 came from a GPU draw capture, and a sweep cannot date a frame
The port asked whether the refined sweep fit t=357.7 was measured against live-title-build4-no-plate.png, because if so one of us is 42 units out. It was not. 357.7 was solved against title-draw-capture-vertex-colours.log, a GPU per-draw capture of the submitted vertex buffer -- four observables at once, two quad centres and two vertex alphas. No framebuffer, no PNG. The gap is not a fitting error either. Posing the leaves directly, t=400 misses the captured quads by +169.0 and -172.2 px. Probe control: it reproduces the page's published t=355 centres, 981 and 478, exactly. Refutation attempted and FAILED: I expected the port's fit to be minimised by the quad leaving the screen -- 'best fit' meaning 'draws least', the same shape as the .tbm control that could not fail. At t=400 quad B is fully on screen and quad A is 319 of 400 px. Their number is fitting something present and it survives. The real reason the two must differ is better than 'different frames'. The sweeps are nested records on a free-running loop and their cycles differ -- 600 and 720, read from the record header +0x08 -- while the top-level clock stops at settle. So two captures of the same settled title share a screen time and not a sweep phase, by construction. Consequence for the port: a sweep position does not date a frame; it gives a phase on a 600- or 720-unit loop. And 357.7 is a joint fit over both leaves while the port's ~400 poses one, so the two are not comparable in kind -- the phases coincide only every LCM 3 600 units. Discriminator handed to the port rather than taken: if its ~400 is pteff03 and the frame is in the first cycle, pteff03a must be at centre 295 in that same frame. The fit is against its renderer, so it owns the check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
bec7f02c0a |
re: not ONE of the 80 forced instances has a file-read key
The port agent pointed out that forced_backdrop_necessity.rs collapsed
sprite_layer_key (a u16 read from the T8aD header, decoded) with
implied_layer_key (this crate's table of positions MEASURED in the running
game), and that 'has its own key' therefore reads as file-backed when it is
not. Splitting them is stronger than either of us stated:
read from the T8aD header: 0
implied (measured): 14 10x pfbase.tbm, 4x palogo_eff0.prm
nothing at all: 66 62 decided, 4 inert
Zero. There is no instance on the disc where a forced element also carries a
file-read layer key, so this rule has never been checked against a decoded
field -- there is no case where both can speak. That is what a keyless-element
fallback necessarily looks like, but it removes a check a reader would assume
exists.
Also corrects something I said to the port and had wrong. 'None of the 18 is
evidence for the rule in any direction' conflated two questions. Whether the
rule changes the composite: no, the sort already had the key. Whether the rule
gets the RIGHT answer: yes, and the 14 implied keys are measured positions, so
this is the rule agreeing with the oracle -- its only external corroboration,
and there are 14 instances of it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
|
||
|
sylph-decoder
|
f8abb56bc4 |
re: reconcile the two ink counts -- we agree at >1 and not at >0
The port agent produced a genuine second witness for the pixel-cost claim: it
re-checked GP_TITLE entry 12 in Godot, which shares no code with compose,
swapping only paint_order. 59 530 px ink with the rule, exactly 0 without it.
The strong form -- the screen ceasing to exist, not merely changing a lot --
now has two real renderers behind it on that entry.
Its figures did not match ours, so I counted the same composite every way:
RGB > 0 ours 49 771 Godot 59 530 16 % apart
RGB > 1 ours 48 043 Godot 48 368 0.68 % apart
The entire disagreement lives in pixels whose value is exactly 1. That is a
1-LSB sampling artefact between two samplers, not a different set of inked
pixels. So '>0' is not a portable ink convention between renderers on a
mostly-dark frame and '>1' is; any future cross-renderer ink figure should say
which it used.
Also worth recording: our 49 771 was never a threshold figure. It is exact RGBA
inequality between the two paint orders, which over a black backdrop coincides
with ink>0 -- so it belongs against the port's 59 530, not its 48 368. Matching
it to the 48 368 would have made the two renderers look like they agreed for
the wrong reason.
The without-the-rule column is 0 at every threshold here too, matching Godot:
the strong form is not threshold-sensitive in either renderer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
|
||
|
sylph-decoder
|
aa9b7ef340 |
re: the forced-backdrop rule's pixel cost -- 38 screens go black without it
Follows the necessity census. 'The order moves' is a property of the sort; the
tie-break work already found reorders costing zero pixels, so the picture
moving is a separate claim. Rendered each of the 62 deciding builds twice and
diffed.
38 .prm deciders: changed_px == ink_px in ALL 38. Without the rule the
primitive sorts last, paints over everything, and the
screen composites to pure black. The port's original
contradiction argument, measured on 38 builds across seven
archives instead of argued on two.
24 .tbm deciders: zero -- and that is MY INSTRUMENT, not a finding.
The control asked whether the composite had ink; it always does. The question
was whether the reordered ELEMENT has ink, and compose draws no pixels at all
for a .tbm. So those 24 zeros measure our renderer's blindness by construction.
tie_break_pixel_cost.rs already had the per-element ink_mask this needed.
Reported rather than quietly patched: a control that cannot fail is the shape
this corpus keeps paying for.
Also corrects two things the port agent caught:
- 'Two renderers, same answer' was true of the six GP_TITLE instances and not
of the other 74. The port's re-run of my probe is my code executed twice;
its independent leg was removing its own exporter post-pass, which covers
GP_TITLE only. The disc-wide 62 has one witness and the page now says so.
- forced_backdrop_necessity.rs defaulted to GP_TITLE with no argument, so a
bare run printed 6 instances in the same format as 80. It now walks every
dat/*.pak and reports the archive count.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
|
||
|
sylph-decoder
|
304ce9efaa |
re: forced_backdrop DECIDES 62 of its 80 instances, not 6
The port agent raised that every check this corpus ran on the rule measured its STABILITY -- that no verdict moved -- and never its NECESSITY. It is right, and the distinction is load-bearing. New probe: recompute derived_paint_order with the forced_backdrop fallback removed and diff the orders, over every dat/*.pak. 80 forced instances = 62 the rule DECIDES + 18 it merely AGREES with. The 80 reproduces the page's own census exactly, which is the check that the probe sees the same set. Every one of the 62 deciders is keyless; no keyed element is ever moved. Of the 18 that agree, 14 have their own key -- and that includes the palogo_eff0.prm 'control', whose implied key is 0x00000000 and would sort it first regardless. So that agreement is the rule reproducing our crate, not the game confirming the rule. The port saw this before I did. The remaining 4 are keyless but inert: every element on those two builds is forced, so the tie-break gives the same order either way. Confirms the port's GP_TITLE finding from the other side: entries 10/11/13/14 unchanged without the rule, entries 12/15 decided by it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
159778faf1 |
formats: test backdrop coverage per instant, and record where the .tbm hunt reached
Two things, neither of which moves a verdict. The port pointed out that rejecting on DECLARED size replaces one error with its mirror: an element scaled ABOVE 100% could cover the screen from a smaller declared size, and my guard would silently exclude it. Checked against the disc first: across 921 keyless elements, ZERO cover the screen only via scale, so the mirror case does not occur here. Adopted anyway, because the construction does not need that to stay true -- coverage is now tested per instant against the scaled size, alongside the opacity test, since both animate on the same ramp. 80 forced instances before and after, split 42 .prm / 38 .tbm, unchanged. Second: an attempt to upgrade the 38 .tbm verdicts from inferred to decoded by finding the texture and measuring its alpha coverage. It cannot be located. Not in its bundle (no RATC record, no sprite-table entry, for any of the 13 names); not a file (no .tbm anywhere on the disc); not a pak entry (its archive's hashed TOC contains none of the name, its uppercase form, its stem, .t32/.tga/.xpr variants, or ui\\ and tex\\ prefixes, across four archives); and not visible in our composite, since compose skips an element with no resolvable sprite, so we draw no pixels for a .tbm at all -- and no committed capture covers a screen that has one. So a second reading survives and is recorded rather than excluded: a .tbm may contribute no pixels, in which case its paint position is INERT rather than correct. That leaves the 38 harmless instead of right -- a different claim with the same consequence. Distinguishing them needs a capture of GP_SAVE_LOAD, GP_BUNK or GP_DEBRIEFING_PILOTLOG, all behind the A fault. One upgrade: pfbase.tbm's first position is MEASURED, not inferred -- it is element 0 of the save/load frame and the order read off the running game starts [0, 1, 2, ...]. Twelve of the thirteen .tbm names still rest on the rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
29c99e1b3e |
re: primitive blend mode -- undecodable with reach, and no longer a risk
Looked in four places. The bundle has no field: a primitive has no RATC child at all and the declaration words are constant across every element of three measured screens -- the two grounds ui-prm-primitives.md already used to refute a bundle-side LAYER key, and they apply identically to blend. The colour census: every full-screen *eff00* primitive on the disc carries pure black at its various alphas, and the only non-black primitive anywhere is pbafc.prm, RGB 00e8e0 cyan. The occlusion constraint cannot reach that one. pbafc.prm looked alarming at a declared 844x600 and alpha ff; it is a small moving glint. It strobes between alpha 255 and 124 every 2 units, travels from x=178 to x=291, and is scaled 2%x3%, so it draws about 17x18 pixels. At that size it occludes essentially nothing. The oracle is unavailable: GP_READY_ROOM is a recorded no-go and gameplay needs the A press that faults the guest in this container. But the consequence closes even though the question does not. For a BLACK quad -- which is every primitive forced_backdrop touches -- the hypotheses differ only in whether it hides what is beneath. Drawn first it is correct under both; drawn last it is correct only under additive. So the rule's verdict is robust to the open question, and the port's original "layerless sorts last" was wrong under alpha-over and merely pointless under additive. This is explicitly NOT evidence for alpha-over. The investigation also found forced_backdrop judging coverage from the pivot alone, ignoring scale -- pbafc.prm is the disc's own proof that a nominally 844x600 element can draw at 2%. Checked before changing anything: all 80 forced instances are at scale 100% on every opaque instant, so no verdict moved. The guard now requires scale >= 100 at the instants it counts as opaque. Defensive, not a fix. 4 + 13 disc tests green either side. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
1f6e07598e |
re: the primitive colour census -- and it refutes 38 of my own 80 forced verdicts
A disc-wide census of the ARGB that keyless elements carry. Every full-screen *eff00* PRIMITIVE is pure black at its various alphas (ff000000, 7f000000, 40000000, b2000000, cc000000, d4000000, 00000000). Black at alpha a over content is exactly an alpha-over dim or fade, and an additive black quad would be a no-op nobody would author -- so this narrows the open blend question a long way. The only non-black primitive on the disc is pbafc.prm, RGB 00e8e0 cyan at alphas up to ff, and it is 844x600, NOT full-screen, so it sits outside forced_backdrop's geometry guard. It is now the sole additive candidate. The census also refutes my own argument for nearly half its verdicts. Of the 80 forced-first instances only 42 are .prm; 38 are .tbm carrying fade ffffffff. A SOLID white quad at alpha 255 painted first would make the screen white, and no screen is white -- so a .tbm is a white modulation on a texture, and element alpha does not establish its coverage. That is the .t32 error one file extension further out. I guarded that with el.sprite.is_some(), which fixed the symptom and not the cause: an element's alpha is not its texture's opacity, and only an untextured primitive makes the two the same fact. So 42 verdicts stay decoded and 38 drop to inferred -- still almost certainly right, since all are named *base*, all are full-screen, and pfbase.tbm's first position is measured in the running game, but that is a name-and-role argument which this page elsewhere calls the weaker kind. The code is deliberately unchanged. Restricting forced_backdrop to .prm would send eleven screens' backgrounds back to u32::MAX -- last -- which is the blank-screen bug the rule was written to fix. Downgrading the status is honest; reverting the position would be wrong. The 42/38 split is pinned by a test so anyone tightening the rule sees what it costs. Separately, on the port's black_hold_units ask: four more no-input boots yielded one usable log, which armed late and missed the publisher splash, so the sample is still two runs spanning 3 and 4 frames. Their 6.5-9.2 range stands. And a reason it may not be resolvable this way: the draw log DROPS frame numbers -- in the 3-frame run, frames 121 and 124 are absent entirely, so "frames with no sprite" and "span of frame numbers" are different quantities. Their statistical correction is taken: at n=3 the sample SD (3.893) is the estimator, not the population SD (3.179), making my run 1.88 sigma from the corpus mean rather than 2.31. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
cf91ad1dcc |
re: the forced-backdrop span -- 256 vs 211 is a bundle mismatch, and the hold
decides 55% of verdicts The port implemented the forced-backdrop rule and reported a discrepancy: palogo_eff0.prm at 256 opaque instants against this corpus's 211. There is no discrepancy. palogo_eff0.prm appears on BOTH splashes -- the publisher (entries 10, 13) runs to t=255, giving 256 instants; the developer (11, 14) runs to t=210, giving 211. Same definition, different bundle. The page now names the entries so it cannot recur. The definition, stated: the span is 0..=max keyframe time over every element in the build, and an element HOLDS its final pose past its own last keyframe -- which is what pose_at does, and which is decoded rather than assumed (a group holds at its last keyframe rather than looping; the declared +0x08 never falls short of the last keyframe, the slack being that hold). The port's instinct that the hold was load-bearing was right. Over the 130 keyless full-screen primitives with an opaque interval: * span = the header's declared +0x08 -> 0 verdicts change * span = the primitive's own last keyframe -> 72 change * elements GONE after their last keyframe -> 72 change So the hold decides 55% of verdicts -- and dropping it is REFUTED by a measured order. palogo_eff0.prm is a single keyframe at t=0: without the hold it is opaque for one instant, no other element is up yet, and the rule calls it free, against a game measured painting it first. Pinned by a new test that spells out the counterfactual rather than importing it. The verdicts that matter are convention-independent: pgloading_eff00.prm is FIRST under all four conventions and pteff00.prm FREE under all four. And the header length is interchangeable with the elements' maximum -- zero disagreements disc-wide. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
cfcda5501c |
formats: a keyless primitive that would hide the screen is forced to paint first
Partly closes ui-prm-primitives.md's standing blocker, "where an UNMEASURED
primitive paints". Raised by the port: build_12/build_15 composite to solid
black at every instant of their declared life, because pgloading_eff00.prm -- a
full-screen opaque quad -- sorts last.
The rule is a constraint read off the file, not a preference: an element that
covers the screen and is fully opaque at some instant cannot paint above
anything visible at that instant. Where the elements visible during its opaque
span are ALL of them, its position is forced to first.
pgloading_eff00.prm is opaque for 39 instants and all 9 other elements are
visible inside that span -> forced first, 4/4 instances.
Two controls, both measured orders from the running game, and the rule has to
survive both:
* palogo_eff0.prm is measured painting FIRST -- opaque 211 instants, forced
below 6 of 6. It is NAMED like an overlay, so a name-based rule sorts it
wrong against a measured order. Occlusion gets it right.
* pteff00.prm is measured painting LAST -- opaque for 2 instants at its
screen's entry and exit, forced below only 3 of 23, so the constraint
permits it on top where it belongs.
Disc-wide: 80 instances forced first, 50 constrained but not forced, 0
unconstrained. The split runs almost exactly along the names -- every *base* is
forced, every *eff00* is not -- with three families crossing it, which is
exactly why the name is not the rule.
It also explains 36 builds the corpus had recorded as "coming out one colour"
with no cause: pzeff00.prm is forced first in 32 of 32 instances, so they were
wiped by our own sort rather than by the game.
The rule's real limit was found by its own disc-wide test failing. Applied to
any element it claimed 22 .t32 SPRITES must sort first against their own layer
keys -- pneff01.t32 (key 0xd850, #8 of 13) and pbfriendly.t32 (0x9230, #17 of
49). A sprite's ELEMENT alpha says nothing about whether its TEXTURE covers the
screen, so forced_backdrop is now restricted to untextured primitives, which is
also the only case derived_paint_order consults it for.
Reach stated: assumes straight alpha-over (blend mode is still open, and an
additive quad at alpha 255 would not occlude); it is a lower bound, not an
ordering; and there is no new oracle measurement -- both controls are prior
ones, and a loading screen is not reachable from the title path.
3 new disc tests; the 13 paint-order tests are green, including
the_derived_order_matches_the_measured_ones_up_to_ties.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
d98c8214cc |
re: the title's build-in measured in the guest's draw stream -- the flashes are real
The settle-time decode was confirmed only against a SETTLED frame, which shows the end state is right and says nothing about whether the five flashes ever happen. This runs the oracle: a draw capture armed before the title exists, so the window contains the frames in which the screen is built. The flashes fire in a six-frame window and are absent from all 155 other sampled frames. `ptlogo_back2eff1` is drawn in exactly two frames at t = 54.0 against a decoded peak of t54-56; `ptlogo1` first appears at t = 42.2 against a decoded t42. Units-per-frame was taken from the GLOW's period alone, a different element, so the timings are not circular. The two holders are continuous from frame 134. The plate glow's quad carries a per-vertex colour whose alpha IS the element's fade alpha, so the ramp is read straight out of the guest: observed range 0..80 against a decoded peak of 80, exact and unfitted; period 51.158 presented frames over 20 cycle starts. Fitting the decoded ramp gives RMS 13.16 alpha levels against 38.18 for the same ramp REVERSED -- if the shape carried no information those would be equal, so the asymmetry is real and correctly directed. Further controls: symmetric triangle 15.73, flat 31.13. `ptlogo_back2eff3` was never drawn, and that is expected rather than a miss: a 2-unit flash peak is 0.85 of a presented frame, so catching one is a matter of phase. A port drawing all five every time shows more sweep than the console. METHOD.md gains the trap this cost: a 2D draw's identity is its vertex geometry, not its bound texture. These sprites sample shared pages, and matching texture dimensions produced a false negative (no flash is ever drawn) and a false positive (the intro movie's 640x360 YUV planes read as `ptbase2`) in the same pass. Also records the top-level restriction on the settle window, which the port raised and which is verified here: top-level [160,236] width 76, including the `ptloop` leaves [269,540] width 271 -- an instant past the end of every top-level element's timeline. Evidence committed as a derived per-frame series, not the 7 MB raw log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
4c74e579a0 |
re: 210 focus records pulse, not 2 -- and 8 of them fail in a way that looks right
The port censused focus-record alpha over its own export -- 34 elements, 2 varying, both `ptbtn00f` -- and concluded there is nothing to fix. That is correct and correctly scoped. This asks the same question of the whole disc. 1 130 focus records, 2 664 timed elements, 210 with a varying alpha. 202 have `rest()` returning the PEAK, the `ui-settle-time` pathology. By pak: PILOTLOG 116, MOVIE_THEATER 54, HANGAR_ARSENAL 30, LEADERBOARD 8, GP_TITLE 2. So the port's 2 is right because GP_TITLE has 2. The scope was load-bearing and was not stated as a limit -- "only 2 have a varying alpha" reads as a fact about the format and is a fact about one pak. The pathology is concentrated in exactly the screens a wider port reaches next. The 8 LEADERBOARD ones are the worse mode. `py_ranking_btn01f` swings 255->127->255 with no two adjacent keyframes equal, so `rest()` falls through to its longest-dwell rule and returns 244 -- neither the peak nor the trough. A glow stuck at its peak is visibly wrong; one stuck at 244 of a 127..255 range looks entirely plausible and nothing reports it. Verified rather than asserted: two hits dumped keyframe by keyframe, and a control on `ptbtn01f`, which is genuinely constant across its cycle and is correctly NOT flagged. `py_ranking_btn01f` also confirms the loop-length decode independently -- its ramp ends at t=90 inside a declared 120-unit cycle, holding bright for 30 units. Reach stated: 210 is a floor. Focus records are matched by the `Xf.rat` name rule, and elements with constant alpha but varying scale, rotation or position have the same problem and are not counted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
d4a08ad194 |
re: a nested record's +0x08 is its loop length -- the plate's period is 120, not 105
Answers the question the port agent asked: does the `PRESS A` plate's pulse group loop from its start, or hold at alpha 0 between cycles? It holds. A nested record is itself a RATC bundle with its own header, and that header's `+0x08` is the loop length -- the same field ui_header_time_disc already tests as an animation length at the top level. Its keyframes need not fill it, and the slack is a hold at the final pose. `ptbtn00f` is 105 units of ramp inside a 120-unit cycle, so the glow rests dark for 15 units between pulses. The five main-menu focus records fill their 120 exactly, which is what shows the slack belongs to this record rather than to the format. Disc-wide over 1 781 timed nested records: 92.3% declare exactly their last keyframe time, 7.7% declare more, and 0 declare less. That last row is the falsifier -- a cycle cannot restart before its own last pose -- and it never fires; the 7.7% is what keeps the reading from being an unfalsifiable relabelling of the keyframes. Falsification against the running game, using a pacing factor measured INDEPENDENTLY on the main menu's focus ring (declared 120 units, measured 2.177 s, factor 1.0885): to reach the corpus's four measurements of the plate pulse (2.12/2.19/2.34/2.31 s), a 105-unit period needs a factor of 1.211-1.337, which EXCLUDES the ring's; a 120-unit period needs 1.060-1.170, which CONTAINS it. Predicted 2.177 s against a measured 2.12-2.34. The two elements are in different bundles and were measured in separate runs; the only thing tying them together is that both declare 120. So the port should stop shipping 105. Its 123-vs-129 ambiguity straddled the right answer without containing it, and 129 only fitted because it was 105 + the exit_ramp_units constant it has since correctly deleted. Reach is stated: this says where a cycle ends, not which records cycle, and the TOP-level +0x08 is a different field left untouched -- every GP_TITLE entry declares 300 while its elements end at 244-269. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
7b5a4aa041 |
re: the paint-order tie-break costs one pixel, on one screen we do not ship
Closes the open half of Q3. `ui-paint-order-derived-check.md` bounded WHERE a wrong tie-break could show -- overlapping same-key pairs -- and said outright that nobody had measured how many change a pixel. At the instant the player sees, the answer is: at most 1 px at max channel difference 1, on the JAPANESE title only (`ptlogo2` x `ptlogo_tm`, 5 px of shared ink). Exactly 0 px on all five port screens. The earlier 24-pair bound was counted at `rest()`, and 10 of the title's 11 overlapping tied pairs are between `ptlogo_back2eff1`..`eff5` -- the five transient flashes from the settle-time finding, transparent on the settled screen. A tie between two invisible elements cannot cost a pixel. Not a knife-edge. Sweeping every keyframe time and every midpoint between keyframe times, the live-pair count is flat across the ENTIRE settle window: 1 on the EN title, 2 on the JP title, 0 on all four loading bundles -- whose tie is live only at t17..t33, during the build-in, which matters because their settle windows are narrow enough to deserve little trust otherwise. Controls: every entry reporting zero also swaps an overlapping DIFFERENT-key pair, which must and does move pixels (25 310 / 268 698 / ~765 000 px). Zeros are explained by shared-ink counts rather than asserted -- the `ptframe` pairs overlap by bounding box and share 0 px of ink. Entries 0/1/12/15 have NO live control and their zeros rest on keyframe data rather than a render; recorded as the weaker claim it is. Refutation attempt on the corpus's "24 overlapping pairs": it SURVIVES as a rest-pose count -- an independent recount reproduces entry 7's 16 exactly. What is overturned is its interpretation as the risk surface. `tie_break_pixel_cost` gains a settle-time case and an alpha/scale filter on its rect test; `tie_cost_over_time` is new. Also strips 611 bytes of captured cargo warnings from the head of the committed tie census. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
d0735d2c25 |
formats: a settled screen is one instant, not one hold per element
`Element::rest()` picks each element's last hold keyframe independently of every other element, so a composite built from it is not the screen at any moment in time -- it is a per-element maximum. For a transient that is exactly wrong: a two-frame flash's last hold IS the flash peak, so it burns forever. GP_TITLE build 4 is the case. `ptlogo_back2eff1`..`eff5` are five staggered two-frame flashes -- one light sweep drawn as five frames, all extinguished by t110 -- that `rest()` draws simultaneously and permanently. Five stacked white glows saturate the light arc behind the logo. The disc names the right instant: the midpoint of the longest interval containing no keyframe of any element. `UiBuild::settle_time()` and `settle_window()`; `screen render --settle` applies it and prints the window, whose width is how much the midpoint is worth. Predicted t=198 from [160,236] BEFORE scoring. Against the console capture, the arc band goes 33.22 -> 11.79 and pixels at the clipping level 8581 -> 1452, where the console has 1459 -- an unfitted statistic. Whole frame 14.07 -> 12.06. Controls at t=100 and t=358 are far worse, and a hand-picked visibility list reaches the identical numbers. `ComposeOptions::at` now poses every element rather than leaves only, which is why the earlier rotation pose scan was flat: it moved the sweeps and never touched the top-level flashes. `at = None` is byte-identical (cmp), the pre-rotation tag renders identically at rest, and the 13 paint-order tests plus the keyframe/focus/opt-link disc tests are green. Also fixes the diagnostic that caused a wrong finding to be sent to the port agent: `not drawn` listed bare names, and a kind-0x4 ghost carries its template's name, so four ghosts printed as `ptlogo1.t32`/`ptlogo2.t32` and read as "the logo is missing". It now prints index, name and reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
37af2055e3 |
formats: a scale-0 leaf must not claim the draw and blank its parent
Found by inspection while the disc tests ran. The leaf branch set its something-was-drawn flag unconditionally after calling blit, but blit returns early on a zero scale -- collapsed to nothing, not unset. So a scale-0 leaf would have been counted as drawn, its parent skipped, and the element blanked outright. pgloading_loop5 s leaf is scale (0,0), so this was live on all four loading screens, and scale-0 is one of the failures this corpus is already named for. Fixed by skipping a zero-scale leaf pose before it can claim the draw; the loading builds render afterwards at 4.0 percent non-black. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
81f42f9041 |
formats: teach the renderer to rotate (Option A) -- and report that it does not close the title
The human chose Option A: teach sylpheed-formats own renderer to draw rotation_deg so it and the port stay comparable and verify-screen keeps meaning someone is wrong. Three pieces, because rotation alone does nothing on the title. blit gains a rotated path that draws by inverse mapping over the rotated bounding box, turning about the pivot, whose absolute position is invariant under scale; zero rotation keeps the original forward-mapped path byte for byte so non-rotating screens cannot regress. compose draws a nested .rat leaf when the leaf carries geometry the parent does not, which is the sweeps case, but not as a blanket rule since a button s leaf duplicates its parent. And --at poses leaves at a keyframe time, because the sweeps hold off-screen at x=1521 so a resting composite omits them. A trap found the hard way: posing EVERYTHING at one global time is wrong, because a top-level group s final keyframes are its exit ramp and rest() deliberately stops before them. Posing the title at t=358 walked every parent into its exit and drove the disagreement from 10.92 to 61.74. So at poses leaves only. Controls: 0 and 360 degrees byte-identical to the unrotated path, 90 degrees swaps a 10x4 to 4x10, area conserved within 15 percent, centroid stays on the pivot. 116 lib tests pass, main_menu unchanged at 9.26. And the verification did not show what it was meant to, which is reported rather than buried: scanning the pose time against the title capture gives 10.73 to 11.17 against a 10.92 baseline -- flat, no minimum, best 1.7 percent. The whole-frame mean is dominated by the tone curve, and the renderer still does not draw ptlogo1/ptlogo2 at all, which is a far larger spatial gap than two translucent sweeps. So rotation is correct in isolation and no screen regressed, but whether it closes the port s 1.81 percent is not established here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
1f9609c37f |
re: the keyframe block s +4 and +8 are angles used almost always as a 180 flip
Narrows a standing unexplained pair without claiming to decode it, and states precisely why it cannot be closed in this container. Census over every UI pak on the disc -- 2859 builds, 90347 keyframes, parents and nested leaves. +4 has 12 distinct values and +8 has 11, against 157 for the decoded rotation at +12. Per sprite-instance across 14241 of them, with +12 as a control because it is known to hold a real angle: +4 takes more than two distinct values on 7 instances, +8 on 99, and +12 on 396. So +4 is in practice a two-state field whose state is 180 -- and for a screen-plane sprite a 180 degree rotation about an in-plane axis is a mirror. But they are not booleans. GP_TITLE entry 7 s ptlogo3a runs +4 = -72, -18, -4, -1 against +12 = -14, -4, -1, 0: the two decay to zero together with +4 roughly four to five times +12 at each keyframe. That is a coupled two-axis settle and the strongest support the disc offers for the three-axis reading. So the readings reconcile -- the field is an angle whose overwhelmingly common use is the 180 degree special case. The reach is the important half. All six non-zero +4/+8 keyframes in GP_TITLE are in entry 7, the Japanese title, which has no oracle capture and which MISSION scopes out as localisation beyond English. The five English screens that do have captures carry +4 = +8 = 0 on every keyframe, so they never exercise the fields. The paks that use them heavily, GP_READY_ROOM at 4686 and GP_DIALOG at 1058, are also out of scope and GP_READY_ROOM is a recorded no-go. So this is untestable against every oracle the project holds rather than merely unfinished. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
a1adb17d35 |
re: 125 percent is not the only odd scale, and ptlogo_eff2 is a pop not a steady state
Refutes a DECISIONS claim and decodes the element the port withheld on my say-so. The claim that title_jp s ptlogo_eff2 at 125 percent is the single drawn element in the whole export at a scale that is not a whole multiple of 100 percent rested on a census of PARENTS only. Opening the 45 leaves as well finds thirteen distinct non-whole-multiple scales -- 75, 96, 99, 101, 103, 112, 125, 150, 204x208, 210x220, 250, and the 75x100 / 96x100 / 99x100 pairs -- with 125 among the rarest at two occurrences. ptlogo1 and ptlogo2 carry 101/103/112 on the ENGLISH title too, so it is not a Japanese-build peculiarity. The claim s real content was "the only one the port draws", which is about the export s element set rather than the disc. And ptlogo_eff2 is decoded. The 125 percent lasts 57 units, about 0.95 s -- a scale-0 to 125 to scale-0 flash between t=50 and t=107, a transient rather than a steady state, which is why it looked anomalous in a census of resting poses. The leaf draws at 100 percent as two superimposed copies of the same sprite at alpha 160 and 80, each rotating a full 360 degrees over 960 units: a slow double-layered spin, 16 s per revolution. This is exactly the case the ptloop rule could not separate. There the parent had expired so leaf-wins and parent-ignored were indistinguishable; here the parent carries real geometry including a scale that reaches zero twice. If parent scale gates the leaf the spin is a 0.95 s flash; if the leaf runs on its own timeline it spins for 16 s. Nothing on the disc chooses between them, and title_jp has no oracle capture, so it is undecodable in this container -- the port is right to withhold it, and the Japanese-locale capture MISSION has parked would settle it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
2f1c561d76 |
re: a nested .rat leaf animates on its own timeline; parent alpha does not multiply
Answers the port s question, which they refused to guess at: they emit both a parent record and its nested leaf, each with an alpha ramp over a different span, and would not draw the leaf without the composition rule. The per-draw capture records vertex colours, and on the title s ptloop draw they are C3FFFFFF and B6FFFFFF -- alpha 195 and 182, not 255 -- so the composed alpha is observable. Fitting ONLY the two alphas against the two leaf ramps gives one consistent time, t = 355, where leaf A is 194.8 against an observed 195 and leaf B is 182.2 against 182. The parent has expired there: it returns to 0 at t=250 and a group holds at its last keyframe. So leaf times parent over 255 predicts zero for both quads and the sweeps would be invisible. They are drawn. The position check was predicted rather than fitted: nothing about x entered the fit, and the same t=355 places the quad centres at 981 and 478 against 992.0 and 467.2 measured off the capture -- within about 11 px on 400-px quads travelling 1560 and 1950 px. Four quantities from two differently-shaped ramps agree on one time. The rule: a leaf carrying geometry animates on its own timeline and the parent s alpha does not gate it. For these records the parent is a container with no sprite. Reach stated: one draw, one capture, one element pair, and specifically the case where the parent carries no geometry. The opposite case is already recorded -- for a button a base record s leaf duplicates the parent and the parent wins -- so the discriminator is which record carries the geometry, not a fixed precedence. And because every observation here has parent alpha 0, "the leaf wins" is not separated from "the parent is ignored because it draws nothing"; a capture during t=100 to 238 would separate them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
05d278173d |
re: the two unexplained XMA streams are BGM_102, and BGM_103 s sizes survive
Closes the open question left by the take-2 audio capture, where the probe logged five streams on one boot when only ADV s three were accounted for. Both unexplained sizes are whole packet counts, 562 and 620. Searching every inter-descriptor span of the voice stream and every sound.pak entry large enough finds zero hits in the voice stream and ONE entry carrying both -- hash 9799c546, which candidate enumeration recovers as BGM_102.slb, two streams of 1150976 and 1269760 B. One entry holding both sizes is the two-stem shape rather than two coincidental matches. So the boot s five streams were ADV s three voice streams plus one music bank s two stems, and nothing is unaccounted for. What it does not establish is which screen it belongs to. The window ran from launch to t=253 s with the title arriving at 262, so BGM_102 was decoded somewhere inside a launch-to-just-before-title window -- but the probe fires on first decode and its lines carry a thread id rather than a timestamp, so a title BGM decoded moments before the title appears is equally consistent with the evidence. Cue 1103 is already the main menu, which makes 1102 as the title at least suggestive. The settling experiment is written down and not done. Refutation attempt on HANDOFF s BGM_103 wave sizes: exact match on both (3876864 / 3930112). The claim survives unchanged. Also a third route to two-stems-of-identical-duration, from the XMA1 header alone now that PsuedoBytesPerSec is read correctly: BGM_102 37.487/37.487, BGM_103 87.750/87.749, BGM_001 173.821/173.821. The one apparent disagreement resolves in the corpus s favour -- BGM_001 reads 173.821 here against the port s decoded 167.663, a gap of 6.158 s, and HANDOFF already records 6.15 s of trailing silence after its fade-out. Declared duration covers the encoded stream including that silence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
a98a66190e |
formats: XMA1 is not a WAVEFORMATEX -- audio info was reading three wrong fields
parse_riff_wave read every fmt chunk as a WAVEFORMATEX. XMA1 (tag 0x0165) is not one, so audio info reported the disc s movie voices as 16 channels, 4310 Hz, 2-bit: 16 is wBitsPerSample read as a channel count and 4310 is wEncodeOptions (0x10d6) read as a sample rate. This misled me earlier in the session and I recorded it as a limitation before finding the cause. XMA1 carries XMAWAVEFORMAT followed by one XMASTREAMFORMAT per stream. The reader now branches on the tag and reads bits at +2, PsuedoBytesPerSec at +12, SampleRate at +16 and Channels at +29. The same three files now report 2 channels, 48000 Hz, 16-bit. The consequence worth having: this crate has no XMA decoder, and data_bytes / PsuedoBytesPerSec is the only route to a duration. Checked against durations decoded independently by the port: ADV presentation 1 137.34 s declared 137.324 s decoded +0.012 percent ADV presentation 2 137.33 s declared 137.324 s decoded +0.004 percent S00A presentation 1 93.71 s declared 93.694 s decoded +0.017 percent So the corpus can now get XMA1 durations off the disc without a decoder, which is a capability I had written down as absent. It is a declared rate rather than a measurement of the samples, and the CLI labels it as such. Regression test pins the real on-disc header bytes and asserts the duration against the independently decoded 137.324 s. 115 lib tests and 3 media disc tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
b82f75979e |
re: the dual-mono explanation for the extra stream bytes does not generalise
The port chose a voice presentation on the argument that ADV chunk 1 is mono-in-stereo and chunk 2 is dual-mono, so chunk 2 s extra bytes encode a duplicated channel rather than fidelity -- which would explain its higher declared PsuedoBytesPerSec without appealing to encode quality. Their ADV channel measurement stands. The generalisation does not. If stream 3 were systematically the same take with its channel duplicated, its size ratio to stream 2 would be tight across the 28 three-stream cues. Measured: min 0.0778 (S00A, the silent one) median 1.2565 max 2.9163 (S06A) sd 0.5057 within 15 percent of 1.0: 12 of 28 A 37x spread is not a duplicated channel, and the declared rates scatter with them -- S06A is 5661 against 16513 B/s. Whatever distinguishes the three streams varies per cue rather than being a fixed channel-configuration triple. This does not touch the port s decision, which is to take the loudest presentation: that is a per-asset content measurement, not a structural rule, so a scattering ratio cannot undermine it. It touches the explanation, which should not harden into a fact about the format. Two curiosities recorded: S12B s three streams are byte-size identical at 14396 each, and BIRD_224 is 3-stream while being a non-movie cue, so the shape is not exclusive to cutscenes. Also narrows the settle-time page s own generalisation. The port measured its boot the way this corpus measured the game and found the sequencer NOT late -- its 0.6 s discrepancy was arrival-to-arrival timestamps compared against visible spans, the plate-delay trap in a second place. So what is supported is that rest.t is the wrong landmark for the TITLE, not that everything paced off it is late. And the offered re-take of the one-run menu figures is recorded as declined, with the reason, rather than left looking unfinished. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
3f945808d6 |
re: a long voice cue is three presentations of one take, and our guard clips the first
Closes the last open question on the voice regions: why one cue s byte span decodes to ~2.6x the movie s length. The port measured, with controls including a cross-movie negative, that a region s leading chunk is the TAIL of the full-length chunk that follows it -- r = 0.998 at a lag that puts it flush against that chunk s end, residual 16.7 dB down over 84.5 s. They withdrew their own earlier 0.768, which came from a search that scored best on the boundary of its own lag range. Checked it here by an independent route that needs no decoder. If the leading chunk is the tail of a full-length first stream, the whole leading stream should be one complete take of chunk 1 s duration. For ADV: 504464 + 808304 = 1312768 B at chunk 0 s byte rate of 9559.7 B/s is 137.323 s, against chunk 1 s measured 137.324 s. One millisecond over 137 seconds, from byte rates rather than from envelope correlation. And the byte structure settles the shape disc-wide. Counting stream starts inside every inter-descriptor span: 258 hold exactly 1 stream, 28 hold exactly 3, and nothing holds 2 or any other number. All 20 spans over 1.5 MB are 3-stream. The 95 movie regions decompose 70 + 8 + 17, and the 8 are independently the same 8 the first census found as bank-header-with-3-chunks. So 359 s = 84.55 + 137.32 + 137.32: three presentations of one take, the first clipped by resolve_movie_voice_region s own 1.5 MB guard. Consequences recorded for the port: dropping the leading chunk is removing a duplicate rather than truncating, so the hedge is lifted; but summing chunk 1 and chunk 2 is wrong, because they are the same take at different gain, not two stems. Take one stream. Also flags a coincidence I nearly built on: the 504464 B constant is structural, not proportional -- ADV s proportional prediction lands within 8 bytes of it and S00A s is 4305 B out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
432fb7450b |
re: the voice region s leading chunk is the movie s OWN dialogue, and a guard puts it there
My own leading hypothesis -- that the leading chunk is an in-mission VOICE_D_* line -- is refuted, on the route the port suggested: widen the enumeration past the 95 manifest-bound movies and the byte-span test settles it without anyone listening. Scanning the stream for every trailer descriptor (the (id, 0x11) pair whose id repeats at +0x800) gives the complete cue partition, mission lines included: 287 descriptors in a 116.2 MB window, all 287 carrying an id the 4280-name registry names. Every one of the 17 leading spans is bracketed by desc(N-1)..desc(N) where desc(N) is that movie s OWN cue id. Zero mission lines. The mechanism is a guard in our own resolver. resolve_movie_voice_region takes the predecessor trailer as the region start, guards it with end - start < 1_500_000, and falls back to the .slb TOC anchor when that fails. Cues with a true span over the guard: 17, of which 17 are stream-opening. Cues under it: 78, of which 0. Perfect discrimination both ways. The anchor sits a constant 504464 B after the true predecessor trailer on all 17, which is unexplained. Not established, and stated as such: this does NOT mean the export truncates N seconds. The port s decode already has ADV s region at 359 s against a 137 s movie, so it over-covers and the byte-to-time mapping is not linear. No XMA1 decoder in this container to check. Also withdraws a claim this page had adopted from the port -- that chunks 1 and 2 are two stems of one performance. The port refuted its own claim by decoding: S00A chunk 2 is digital silence, ADV chunk 2 is 0.60x chunk 1 with the residual 26.8 dB down. Equal duration was a shape match and Q10 s music census should not have been carried across to voice on it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |