The port's authored/flow.json stamped title/on_cancel_why = 'MEASURED, HANDOFF
Q5' for a clause whose evidence cell in the source table reads 'none'. It did not
invent that: HANDOFF's Q5 row opened with one **measured** covering six clauses of
different strength, and HANDOFF is the document it authors against.
Split per clause. Measured: initial focus varies; up/down move one item per press
and wrap both ends; left/right do nothing; B on a submenu restores focus 4/4; B on
the main menu goes to the title in <= 0.4 s with no loading screen. NOT measured,
evidence cell empty: 'no auto-repeat at the durations tried', and 'B on the title
-> nothing'. Both marked do-not-stamp.
Also splits the source table's own up/down row, which bundled 'one item per press'
(indirectly but soundly evidenced by the 4-press wrap count) with 'no auto-repeat'
(nothing behind it, and the hedge was carrying the claim).
METHOD entry: the failure is in summarising, not at either endpoint. The source
table was honest and the consumer cited its source; flattening six claims into one
adjective created a provenance nothing supports. A strength label is not
distributive.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Closes the open second reading in ui-forced-backdrop.md: that a .tbm contributes
no pixels, leaving 24 of its 62 deciding verdicts harmless rather than correct.
The TUTORIAL screen was reached and captured. It carries a full-screen blue
circuit/hex background. GP_TUTORIAL build 0's element 0 is pubase.tbm with pivot
(640,360) -- 1280x720, the only full-screen TEXTURED element in the bundle; the
one other full-screen element is pueff00.prm, an untextured primitive the colour
census puts at pure black. Our render of the same build is the identical layout
on pure black, 6.0-6.4 % inked against the game's 99.7 %. The only difference is
the background and the only thing it can be is the .tbm.
So the 24 .tbm verdicts are correct rather than harmless, and they are
load-bearing in the full sense. Reach: one .tbm observed; the class question is
settled, the ten other families are not individually seen.
Also: screen render is wrong on every screen carrying a .tbm -- it drops the
background silently, with no diagnostic.
And the identification is worth its own METHOD entry. Two statistical identifiers
were built. Masked correlation FAILED its control, picking EXTRAS over the known
main menu by 0.004 because the shared background dominates. A high-passed variant
PASSED by 1.28x, which is not a margin that licenses identifying an unknown, so it
was not used. The screen says TUTORIAL across the top. Ask whether the artefact
already states the answer before building a matcher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Applying my own METHOD entry one iteration after writing it found four refuted
statements still asserted unmarked where a reader lands:
* envelope correlation 'has no resolving power' -- in three places including
HANDOFF. The port controlled the same estimator on a single track and got
r=1.0000 at zero offset; the saturation needs CONCURRENT streams sharing
timing. I agreed to this in a message and never landed it.
* '8 of 10 three-chunk regions' -- still asserted in HANDOFF in a different
section from its own correction.
* 'r9 is a wild pointer, never a guest address' -- still asserted inside the
kept-for-the-record section.
* the ALSA channel permutation, stated without scope, when a later capture
measured the identity and labelling from it put the silent channel on the
wrong name.
All four marked in place, striking the sentence and pointing forward.
Two lessons added: a 'kept for the record' section still asserts, so labelling
the heading is not enough; and naming a refuted claim keeps it greppable, so the
audit returns its own corrections as hits and every hit needs reading.
The first item is the one worth admitting: I acknowledged that correction in a
message, wrote the entry about corrections that never land, and then did not land
my own for a full iteration.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
An A press produced no screen change; the obvious reading was that the button did
nothing. The log said the press was never delivered -- two file-pad vk=5800 lines
across the whole run is ONE press -- because it was issued 0.8 s after a screen
appeared, while the guest was loading and not polling.
The pad driver reports what it emitted, so a script checking its own output sees
success either way. Confirm the receiving side.
Generalised: when an action produces no observable effect, the first hypothesis
is that the action did not occur, not that it had no effect. The corpus has paid
for this twice -- here, and in the sign-in swallow where thousands of delivered
keystrokes were discarded inside the emulator and looked exactly like a dead pad.
Companion to the control entries: a control proves the instrument reads
correctly; a delivery check proves the experiment happened at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port found its exporter still shipping 'no loop-point field has been
identified anywhere' in the field manifest.json concatenates, days after the
correction existed in other fields. Auditing this corpus the same way found the
same failure here: the refuted sentence was still standing untouched in
bgm-two-stems.md -- where anyone looking up BGM behaviour arrives -- and in
HANDOFF.md, the one page the port is told to read. My correction had gone into a
NEW page only.
Both fixed in place, each naming the refutation rather than quietly deleting the
old claim, and each carrying the measured window [9.44, 71.31] s at 61.87 s.
METHOD entry: writing a correction down is not landing it. Grep the corpus for
the CLAIM, not for the file you were working in. Plus the port's trap in doing
that audit -- a replacement that quotes the refuted sentence in order to name it
will match a substring search from inside the paragraph saying it is false.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
My locator validated on slices cut from the wave itself -- found exactly, control
passed perfectly -- and the measurement was still ten seconds wrong, because
matching an exact copy is a different problem from matching a real capture and
music with repeated sections is where a locator aliases. Its clean +5.00 s
stepping showed self-consistency, which is also what an aliased lock looks like.
Paired with the port's mirror image the same day: an awk that read 0 for every
span produced a perfectly structured result agreeing with the hypothesis under
test, and its tell was that the CONFIRMING rows were impossible too.
Both point the same way: the tell is in the rows that agree with you. Checking
the disconfirming half harder is the intuitive discipline and it is the wrong
half.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Named by the port after hitting it twice in a fortnight -- a real 3.4 s seam
written up as the cost of a missing loop point when our own loop produced it, and
a real r=0.998 correlation written up as a duplicate when it was a
start-truncated simultaneous stream.
Distinct from everything else in this file, which is about broken or misspecified
instruments. Controls test whether a measurement is faithful and say nothing
about the clause that follows it. The defences that work are naming the
alternative explanation so it can be rejected, and noticing when a measurement
taken in OUR output is being used to make a claim about THE GAME.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
From the port, after two rounds of its 'known incomplete' banner firing wrongly
-- once with a message true only for ADV, once claiming a gap over 93.694 s of
exact zeroes. Both errors were in the cautious direction, which feels like the
safe mistake and therefore goes unexamined longer than a false all-clear would;
the cost is deferred onto the one occasion the warning is true. A warning needs
the same scrutiny as an assertion, starting with what it keys on.
Also records S00A's kept count moving 1 -> 2 after the voice-region fix, on an
asset the fix was not derived from and with the prediction preceding the
observation -- at the strength it actually has. A different ASSET is evidence
about generality; a different IMPLEMENTATION is what would make it independent,
and only one of those was present.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The voice-region truncation survived every test because there was nothing to
catch: the region parsed, the chunks decoded, the durations were self-consistent.
A missing third of a stream is smaller VALID output, and no check written against
our own output distinguishes that from correct output. What caught it was a
number from outside -- the running decoder's byte_sizes not fitting the region.
So: prefer at least one test per decoder pinned to something we did not produce,
and say so in the test, because the obvious maintenance of such a test is to
re-baseline it against current output, which deletes the only thing it was for.
Plus the port's corollary: it was checkable only because the identifier happened
to be a byte count. Index a handed-over result by a quantity the recipient can
test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
From the port agent. This file already carries two divisor bugs of the same
shape -- a silent input in a divisor attenuating real signal -- and the lesson
taken from them was 'be suspicious of dividing by N'. Applied to the intro's
three streams it produced a unity sum that the port's own checker rejected at
+2.62 dBFS.
The precedent did not transfer because a BGM bank's two waves are stems of one
signal while the intro's three streams are positions in a field, whose downmix
weights sum to one whatever the assignment. Nothing in 'several streams, one
output' distinguishes those.
The general point: a rule extracted from a burn is indexed by what the burn
looked like rather than by why it happened, so it fires on the next thing with
the same silhouette while feeling well-earned. State the mechanism a past lesson
turned on and check that mechanism is present.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port reproduced the floor exactly (159) once the predicate was named, and
counted an independent capture from a different session: 753 against this run's
714, a ratio of 4.7x against 4.6x. 'Never goes off' is no longer single-run.
Two METHOD entries.
A detector that can fire on a single frame will fire on the wrong one. The A/B's
first pair was void because the title detector tested one frame against a glyph
threshold and the intro movie throws sub-second green flashes of 1298..5433. The
presses were real and skipped the movie, so both legs returned a clean,
symmetric, meaningless result -- a void test that looks like it ran is worse than
one that errors. Same shape the corpus already recorded for screen_id.py calling
the SQUARE ENIX logo 'title'. Twice paid for. The rule is that a screen detector
matches a signature over time, and a broken run's own series is the cheapest
control for its replacement.
A demand for reproducibility can surface a defect that is not the one demanded.
The literal answer to 'your figures are unverifiable' was 'here is the
predicate', after which they verified exactly -- but writing the method down is
what exposed the cross-geometry floor comparison, which nobody was looking for.
And both sides were wrong at once: the challenger's counts were the wrong
measurement AND the published figure had a real flaw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port agent could not reproduce this page's 159/714/1520 from the capture it
holds: counting green>150..200 over a plate box it got 3-5x at every threshold.
The page named neither the region nor the predicate.
Stated now: the whole 1280x720 frame, and is_title.py's three-channel predicate
(g>130 & g-r>45 & g-b>45), which is why it counts far fewer pixels than a bare
green>N. That reproduces 1520/714/159 exactly.
Writing the method down exposed a defect the prose had hidden. The 159 floor
came from live-title-build4-no-plate.png at 1279x675 -- the game surface --
while the pulse frames are 1280x720, the whole display. Different crops,
silently compared.
Replaced with a same-run, same-geometry floor that was in the series all along:
154, flat for ~2 s immediately before the plate ramps in. So 'it never goes off'
now rests on one run in one geometry, at 714 against 154, which is where it
should have rested from the start. The port's independent ratio of 1:10.4-10.9
brackets this page's 1:9.6 and is the part robust to how anyone counts.
Two METHOD entries: a pixel figure needs its region and its predicate, and a
comparison between two counts needs them to share a geometry; and the port's
observation that a fix which overshoots leaves no symptom until a third change
needs the part it disabled.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two corrections from the port agent, both of which make earlier claims smaller.
1. Its 'reproduces your published centres to half a pixel' was model against
model. This corpus's 981/478 are the model's output at t=355, not the
capture's; the capture measured 992.0/467.2, the 11.5 px residual the page
declines to fit. So that control shows two implementations of one model
agreeing, not the model matching the oracle. Neither of us applied the
correlated-instrument test to that sentence at the time.
The discriminator survives: it asks whether two captures are the same frame,
and the model is monotone in t at ~4 px/unit, so a 42-unit gap cannot come
out of one frame however wrong the absolute times are. Recorded as such.
2. Running my 'grep for the symptom' audit against its own tree, the port found
the opposite failure: a control recorded in BOTH a tool table and a document,
drifted to 53.3 % and 53.2 %, with the evidence file gone so neither can be
re-measured. One hard-to-find record announces itself as missing; two
disagreeing records announce nothing, which is worse.
So the rule is not 'write it down twice' -- one record in docs/re/,
everything else cites it, and any number that must appear twice is generated
rather than typed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Answers the open half of the A-press diagnosis, and most of the answer was
already in the tree.
The faulting runs booted with logged_profile_slot_0_xuid = "" -- their own
config dump -- while a profile existed (Found 1 Profiles). With nobody signed
in, A takes the state-0 branch of sub_821D03A0 and calls XamShowSigninUI(1,1);
Canary raises its Sign In dialog with a no-op close handler and nothing in an
unattended run dismisses it. 85 instructions verified against the image, 0
mismatches; the state-3 branch is XamShowDeviceSelectorUI, already ruled out by
storage_selection_dialog = false.
The correlation runs through the tooling: boot_menu.sh passes the profile flag
and Q4/Q5 pressed all five buttons; frame_clock.sh, which produced the faulting
run, does not.
So there is no blocker -- boot with boot_menu.sh. Flagged as retrodicted rather
than A/B tested, since I have not myself booted both ways and pressed A.
The uncomfortable half: canary-scripted-input-traps.md section 3 already named
the sign-in dialog WITH a committed capture, and boot_menu.sh's header already
carried the mechanism and the 8.4 million figure. The fault page searched for
the cause it had hypothesised and never searched for its own symptom. Added to
METHOD.md, along with the more expensive lesson -- a measurement whose only
record is a script comment is invisible to the document that needs it.
What this session did add is the join: that the known blackout is what drives an
unbounded guest queue into a failed 128 MB allocation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port refuted the boundaries in boot-splash-dwells-are-declared.md by
arithmetic: the two splash spans gave 2.237 and 2.414 units/frame, 7.9% apart on
one boot of one guest, which must be one number. They proposed the spans were
anchored on different elements.
The log says the cause is worse. The developer splash batches SIX quads into one
draw (indices=24) and the log dumps only the first two. While the three glows are
alive they occupy that prefix, so the three wordmarks are invisible to the log
until the glows stop being submitted at t=45. "Developer wordmarks first drawn at
frame 140" was the logging prefix shifting, not the game -- and the same defect
explains why palogo_anima never appeared at all.
The fix costs nothing: indices/4 is how many quads the draw actually holds, and
the 8-vertex cap cannot touch it. Its transitions land exactly where the declared
count of elements with alpha>0 changes, giving free calibration points:
publisher 1->2 quads at frame 5.5 (t=15), 2->1 at 22.5 (t=45), ends 119.5 (t=255)
developer 3->6 quads at frame 126.5 (t=15), 6->3 at 139.5 (t=45), ends 209.5 (t=210)
That yields 1.765 and 2.165 units/frame on the publisher, 2.308 and 2.357 on the
developer -- the developer's two independent segments agreeing to 2%, and the rate
rising 33% across the run. One cause for both the port's 7.9% inconsistency and
this page's open 4.1% publisher error, exactly as they predicted: the publisher
splash runs during the first seconds, where the rate is furthest from its later
value. It also means no single units-per-frame figure describes a run here, which
is the dwell-is-emulator-paced conclusion from a third direction.
The declared dwells (255 and 210 units) and the corpus's three-cold-boot
confirmation are untouched -- neither uses this draw log.
METHOD.md gains the general form: when an instrument truncates, the surviving
sample is not random, it is the first N, and what falls in the first N is itself a
moving function of the thing being measured. A truncated view looks like a
complete view of a smaller set.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
The console draws all five title flashes. My claim that ptlogo_back2eff3 is
never drawn was an instrument artefact, and I had reported it to the port with
three alternative explanations "ruled out".
A GPU draw can batch several quads -- indices=4 is one, indices=8 two,
indices=24 six -- and the UI draw log dumps only the first 8 vertices. Taking
min/max over a line's whole vertex list merges quads into one box.
eff3 is batched with eff4, and because the wipe family is right-aligned, eff3
(788..1196) lies ENTIRELY INSIDE eff4 (447..1196). The union is exactly eff4's
own extent, so the merged box matched eff4 to 1 px, eff3 vanished, and nothing
looked wrong.
Parsed per quad, all five fire in both title entries in the declared stagger:
eff1 130-131, eff2 133, eff3 133-134, eff4 133-135, eff/eff5 134+, back2 136+;
and 5953-5955 / 5955-5957 / 5957-5958 / 5957-5959 / 5958+ / 5962+ in entry 2.
Frames 133 and 134 are t=60.1 and 62.3, inside eff3's declared t in (58,64).
Also retracts "the developer splash is one composited quad" -- the same bug,
which the port refuted by arithmetic first (a 259-tall box cannot contain three
logos spanning y 164..585). It draws three logos and three glows as separate
quads in one indices=24 call; the 525x259 was gamearts_eff merged with
seta_eff. The 9-unit black hold is unaffected: those glows are the developer
splash's first draw.
The three "ruled out" explanations were all aimed at the wrong failure. In
particular the invisible-draw check counted draws with NO geometry line, when
the hiding place was draws with PARTIAL geometry. Refuting three wrong
hypotheses is not evidence for a fourth, and a list of failure modes written by
whoever built the instrument is the least likely to contain its blind spot.
Recorded in METHOD.md, along with the tell that was present and explained away:
a merged box carries the first quad's colour, which made one element's alpha
read 255/127/254 on consecutive frames.
New tool: tools/re-capture/quads_per_frame.py parses vertices in groups of four
and warns when the logged quad count falls short of indices/4.
Also guards a double-A-tap in ui_draw_capture.sh: the movie branch ignored that
TARGET=menu had already tapped, so a run tapped A on the title at t=23s and
again at t=27s on the transition; the guest faulted and Xenia dumped registers
to stdout until the file reached 519 MB.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
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
Records the settle-time decode, and corrects two claims it overturns.
docs/re/structures/ui-settle-time.md is the finding: a settled screen is one
instant every element is posed at, the disc names it (the midpoint of the
longest keyframe-free interval), and the title's arc closes from 33.22 to
11.79 with the clipped-pixel count landing on the console's 1459 within 0.5%.
Includes the disc-wide reach -- only 30% of bundles have a window wide enough
to trust -- and a three-way figure.
Withdrawn in ui-rotation-implemented.md:
* "Flat. No minimum." was not a property of rotation. `at` posed LEAVES ONLY,
so the scan moved the light sweeps and never touched the top-level flashes.
* "our renderer does not draw ptlogo1/ptlogo2 at all" is wrong. Both are
drawn; the four elements the diagnostic named are kind-0x4 ghosts sharing
their template's name. Hiding the real ones makes the error WORSE by
+5.20 and +7.47.
* Its 10.92 baseline is not reproducible -- 14.07 at its own pre-change tag
and 14.07 today -- so the "1.7% better" verdict rests on an unrecorded
recipe. Flagged in title-residual-tone-vs-geometry.md too.
METHOD.md gains two traps: a shared CARGO_TARGET_DIR makes a `git worktree`
build silently replace the binary you run next (it cost three renders here,
caught only because a missing flag was a hard error rather than a wrong
number); and an aggregate computed per-element is not a state of the system.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
The port checked my pivot claim rather than taking it and found the nuance: the
sprite is odd-width, 399, so its true centre is 199.5 against a declared pivot of
200. Half a pixel, far inside the 0.70 and 0.48 px agreement, so it changes
nothing -- but "the pivot IS the centre" is the kind of sentence somebody leans on
for a sub-pixel claim later, so the page now says it is the centre rounded up.
And records the general form of the two bugs this exchange produced, which share
one cause. First, a leaf-composition rule was checked against alpha, which moves
about 0.3 levels per keyframe unit, so a one-keyframe association error barely
shifted it and the rule looked confirmed -- while the same span moved x by
1560 px. Second, fitting t from that same alpha manufactured an 11.5 px position
residual that did not exist and sent the consumer hunting a pivot rule to explain
it, because one byte of alpha quantisation is worth 1.5 to 1.9 keyframe units.
Solve on the fastest-moving field and check the slow one, never the reverse. The
second failure is the more expensive: failing to falsify leaves you falsely
reassured, but inventing a residual sends you looking for a mechanism.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Two more data points for the Q5 instability, from today s drives. A run that
pressed A with no d-pad movement ended in a tutorial mission, correlating +0.960
with the committed capture, so that boot opened on TUTORIAL. A later boot read
NEW GAME from a focus detector on the first menu frame.
Six boots on the same harness now: TUTORIAL three times, NEW GAME three times,
and no other item ever observed. The distribution is not uniform over the five
buttons -- only these two occur -- which is a real constraint on whatever selects
initial focus and something an explanation will have to account for.
Also records in METHOD a bug that cost a seven-minute driven boot: a value was
clamped for readability BEFORE the comparison that used it. A focus detector
printed a degenerate margin, so it was capped at 999; the cap ran before the
vote-sorting step, two different votes compared equal, the stable sort kept the
wrong one, and a correct NEW GAME became an out-of-range index and a refusal. The
measurement was right throughout -- a cosmetic fix changed a decision. Clamp at
the point of display, never upstream of a comparison.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Raised by the port and independently reproduced here before being adopted, since
adopting their claims unchecked has misfired twice this session.
Binning matched pixels by render level rather than fitting a scalar, the implied
exponent falls monotonically and crosses 1.0:
render 16 23 31 39 47 64
port (all) 1.26 1.18 1.10 1.03 0.93 0.85
mine (flat) 1.303 1.347 1.128 0.912 0.935 1.003
Below the crossing the capture is darker than the render, which is what the page
measured; above it the capture is brighter. A single exponent cannot express a
curve that crosses unity, so the model is valid only in the darks -- which is
exactly the reach the page already stated. The reach line was not a hedge, it was
the finding.
Where the two disagree is recorded and not resolved: the crossing is about 44 by
their binning and 35 to 40 by mine, and the darks read 1.18-1.26 theirs,
1.30-1.35 mine, 1.49 for the page s original patch fit. Three estimators on three
populations, all agreeing on direction and on gamma above 1 in the darks.
A confound in my own reproduction is stated rather than left implicit: whole-image
correlation is only 0.594 because the committed capture and the default render
differ in focus state, which the port measured as 74.1 percent of differing
pixels. My bins include that mismatch, so they are not a clean second opinion.
And a 1280x720 render against a 1279x675 capture needs a resample, which is why
the fit is restricted to flat-neighbourhood pixels.
METHOD gains the general form: a stated reach is a boundary rather than a hedge,
and the fix was printing the curve instead of a scalar, because a scalar hides
its own domain.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Both reproduce on committed reference frames, so this is a defect in a shared
harness tool rather than a one-run anomaly:
live-title-build4-no-plate.png -> other (should be title)
live-title-press-a.png -> title
difficulty-screen.png -> menu (is not the main menu)
It thresholds on green -- 0.0009 with the PRESS A plate against 0.0002 without --
so it only recognises a title once the plate has faded in. This corpus s own
finding is that the boot title shows build 4 FIRST, plate-less, for about 2.25 s,
which means any harness waiting for `title` from it can sit through a visible
title and report nothing. That is what happened on an S00A drive here: 396 s of
`other` with two spurious `menu` hits, on a run whose audio proved the guest was
healthy throughout. newgame_path.sh, nav_probe.sh and boot_menu.sh all gate on
it.
The zncc-against-committed-frames classifier used for the settle-time screen log
has neither defect, controlling 6/6 with both movie frames and difficulty-screen
as negatives -- but only at a 0.85 threshold. At 0.60 it also called
difficulty-screen a menu at 0.632, so the threshold is doing real work and has to
be controlled rather than chosen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
I wrote that BGM_001 s declared 173.821 s disagreed with a decoded 167.663 s,
and explained the gap as declared covering the encoded stream including trailing
silence while decoded is where the audio stops. The port decoded it fully: the
bank yields 173.809 s of PCM. There is no disagreement -- 167.663 s is where the
music fades out, measured from the audio, and the stream continues silent to its
declared end inside that same decode.
So the declared-rate method is better than this page claimed, and is now
cross-checked on three banks against independent decodes: BGM_103 87.750 vs
87.744, BGM_102 37.487 vs 37.482, BGM_001 173.821 vs 173.809 -- agreement 5 to
12 ms.
The conclusion survives unchanged and is the useful half: trust it for lengths,
not for musical boundaries. A declared length includes whatever silence the
encode carries, so it is not a loop point.
Also records in METHOD a defect shape the port hit three times in one pipeline,
each invisible to every check except a level: normalising by how many inputs
there are rather than how many carry signal. A silent chunk in a voice sum, a
silent channel in a mono fold, and a silent sub-wave -- the 10240-byte bank
header wrapped to 10300 B -- counted as a third stem in a music sum, which put
every real stem at 1/3 instead of 1/2 and cost 3.52 dB on all menu music for two
iterations. This corpus s census said two waves and the exporter s divisor said
three; the count that disagrees with a census is the one that is wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Both of these cost time in one session and both are the kind that look like
success.
run-canary line 82 is SDL_AUDIODRIVER=${SDL_AUDIODRIVER:-dummy}, and its own
header explains why: --apu=nop stalls the guest in the intro movie, so the SDL
driver against a dummy device is what lets the title advance. But the comment s
premise -- "there is no PulseAudio here" -- stopped being true when
tools/audio-capture landed, since that starts a daemon on demand. So a capture
through the null sink records pure silence, of the right length, behind a run
that looks perfectly healthy. The override is
PULSE_SINK=cap SDL_AUDIODRIVER=pulseaudio run-canary, and the live check is
pactl list sink-inputs: empty means Canary never attached and the sink sits at
IDLE. audio-capture s own -inf peak warning is the backstop, but it only fires
after the whole run.
Separately, pkill -f and pgrep -f match the caller s OWN command line. Hit twice
here: pkill -9 -f adv_audio_cap.sh killed the shell running it, and an
until ! pgrep -f "probe.py --run" loop never exited because the loop s own
command line contained the pattern -- which looks exactly like the job hanging.
Kill by process name with ps -o pid= -C instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Five corrections across two agents in two days share one shape, and it is worth
naming as a family rather than fixing one at a time. None was carelessness about
the measurement -- every underlying observation was true of the asset actually
looked at. The failure is reaching for the general form in the same breath as the
specific one, where the two are indistinguishable on the page and the general one
is what the next reader uses.
Three were the port s and two were mine, and the entry names both sides:
the two chunks are two stems of one performance -- true of a music bank,
written as a fact about voice, where one of the two is digital silence
the extra bytes are a duplicated channel, not fidelity -- true of ADV, and the
size ratio it implies runs 0.0778 to 2.9163 across the disc
everything the sequencer paces off rest.t is late -- true of the title, and
false of the screens actually checked
a three-stream cue is a movie cue -- mine, and BIRD_224 is neither
take the highest-rate, highest-gain stream -- mine, and on ADV those two
criteria select different streams
The counter is the same every time: run the census before writing the rule.
Where the census cannot be run, write the specific sentence and say it is
specific.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Found while controlling the timing probe before a settle_time run, not by
reasoning about it.
title_timing_probe.py s plate detector thresholds a green-glyph pixel count at
400, and its control checks two committed movie frames that both score 0. A real
boot disagrees: in one 100 s attract window, 17 frames scored at or above 400
and the peak was 5393. The attract movie has green content in the plate region.
The probe is not wrong -- its state machine refuses to look at the glyph until
the content classifier has already labelled the frame title_noplate or
title_plate, so the false positives never reach the drive. But it is safe
because of that gate, not because the threshold discriminates, and the
distinction matters for anyone reusing glyph() on its own.
Recorded with the general form: a two-frame control over a three-and-a-half
minute movie is not a control over that movie.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
The port challenged HANDOFF's loading-screen row and was right. The Q2 row said
"0/1 and 10/11 are the LOADING screen"; the dated section above it says
"entries 0, 1, 12, 15". Both are true, in different index spaces, and the page
did not say which.
Verified against the bytes rather than the table:
screen list GP_TITLE.pak -> 12 builds, ordinals 0..11
screen list --all GP_TITLE.pak -> 16 builds, ordinals 0..15
Only under --all does the ordinal equal the pak entry. Without it ordinal 10 is
entry 12 and ordinal 11 is entry 15. `screen info --all --build 10` shows
palogo_sqex; --build 11 shows palogo_gamearts / seta / anima; 12 and 15 show
pgloading_*. So in ENTRY space 10/11 are the publisher and developer splashes,
which is exactly the screen the wrong reading would have renamed.
It would have validated silently: the port's screen_names.json is keyed by
entry. Q2 row corrected to entry space and marked; the trap is in METHOD under
"Mechanics that have bitten", with the rule that a number leaving this
repository says "entry N", never "build N".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
The port flagged docs/re/data/boot-timeline-2026-08-29.tsv, whose label column
runs splash_dev before splash_pub, as a possible boot-order bug in its tree.
Three cold boots, t=0 at launch, no pad input, and the frames looked at rather
than only correlated: SQUARE ENIX 3.05-7.34 / 1.18-5.78 / 1.19-5.56 s, then a
~0.25 s black hold, then GAME ARTS/SETA/studio anima. Publisher first, 3/3.
The TSV is not wrong about any frame; its t=0 is ~7.7 s into the guest's boot,
so the publisher splash had been and gone before the stream opened. The tell is
in the file: its first twelve rows are byte-identical to four decimals -- one
held frame sampled twelve times -- and those exact numbers reappear in my run 1
at 8.42-10.94 s.
Second trap, new: ADV.wmv opens with its own SQUARE ENIX card, bloomed and below
centre, scoring 0.59-0.75 against live-splash-publisher.png. The classifier
fires splash_pub twice per boot and the second one is a movie frame. The real
splash holds perfectly still and scores 0.93-0.94.
And the dwells are DECODED, not measured: the publisher declares 240 units
(4.000 s) and the developer 195 (3.250 s), against measured 4.30/4.60/4.37 and
3.51/3.50/3.37. Measured over declared is 1.085 on average across six spans --
a 30 Hz timeline at 27.6 fps, which is the presentation rate this corpus has
measured independently three times. The port authors nothing here.
Instrument control run first: 11/11 content, 4/4 plate, the two splash
references rejecting each other at 0.035.
docs/re/boot-order-and-splash-dwell.md
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzY
Probed all 97 movies. 28 are wmapro 48 kHz 6-channel 5.1 -- ADV.wmv and every
S*.wmv story cutscene; the other 69 are wmav2 48 kHz stereo, every RT*.wmv and
hokyu_*.wmv. The split is cinematics vs in-mission radio chatter.
Both movies the menu milestone needs, ADV.wmv (the boot/attract intro) and
S00A.wmv (the new-game intro), are in the SURROUND group.
Why it matters: one ffmpeg command over dat/movie/ produces two different kinds
of result and records neither. The 69 stereo files pass through unchanged; the 28
surround files get downmixed 5.1 -> stereo by ffmpeg's DEFAULT matrix, folding
centre-channel dialogue into L/R at a weighting nobody chose and which is not
stable across ffmpeg versions. That is a content decision inherited by accident,
so it should be stated explicitly and recorded beside the command.
Credit where due: found by the human while checking a transcode, verified
independently here and widened from one file to the whole disc.
Two METHOD entries from the same episode, both about measurement rather than
format: don't probe a file another process is still writing (a half-written
transcode reported 33 s against a 137 s source, no error, nearly a filed bug),
and a difference-signal RMS is meaningless before cross-correlation alignment
(-34.2 dB against a -25.3 dB source looks like failure and is inconclusive).
Two runs were killed this session for looking stuck. Measured: 1 318 s serial,
no output while it runs. Also records that `build-reborn test` forces
--workspace and silently ignores a `-p`, so scoping needs the cargo
passthrough (`build-reborn t -p <crate>`).
Closes the reach caveat the `opt ` name fix left behind: 60 of 18 002 RATC
children carry no `opt ` block, and it was not established whether they lack one
or sit past our 128-byte window.
Neither. They are not children. `examples/ratc_optless_children.rs` re-runs
`ratc::parse`'s own guards over the disc and reports which one fired: all 60 are
"tag beyond the window", none is rejected by length, gap or charset, none is
child #0, and all 60 live in six bundles of one archive. Within a bundle the
distances back to the nearest tag are an exact arithmetic progression, step
60 600 -- ten different records finding the SAME tag, because there is only one.
Reading a bundle directly: children 1..10 are equal-size T8aD blocks under a
single `opt ` name, `pb_f15_eg_anm.tan`. `.tan` is a FRAME SEQUENCE. One block
declares the resource; its payload is a run of T8aD frames.
Disc-wide, over all 18 718 `opt ` names in all 33 paks: a RATC bundle names
exactly six kinds of resource -- `.t32` 14 756, `.rat` 3 311, `.prm` 367,
`.tbm` 224, `.sbo` 54, `.tan` 6. Six `.tan`, ten frames each = 60, the entire
population with nothing left over. The negative is closed, not narrowed.
Consequence recorded but deliberately not fixed: `ratc::parse` over-reports
there, listing a `.tan`'s frames as anonymous children. Nothing in the menu
milestone reads a `.tan` -- it occurs only in GP_READY_ROOM, which S1 ruled
out -- so no screen the port draws changes.
Also a METHOD entry for this container OOM-killing `slb_leading_segment_disc`
under default test parallelism (SIGKILL, no assertion; 8/8 pass with
--test-threads=1).
`ratc::parse` named each child by scanning backwards for the last printable run
of bytes before its magic. The format states the name explicitly instead, in an
`opt ` block: `"opt " | BE32 len | name | NUL | 3 bytes | magic` -- the same
block `ui_layout::opt_link` already read for a button's focus link.
The scan agrees with it 17 918 times out of 17 942 and is wrong 24 times, every
one the same failure: the 3 trailing payload bytes are themselves printable and
beat the real name. For `pteff05.t32` those bytes are `38 41 58` = `8AX`, so the
full-resolution background of all five menu screens registered under a name no
element declares, resolved to no sprite, and `compose` dropped it through an
early `continue` that -- unlike the two arms above it -- records nothing. The
screen lost its background and `screen render` still reported "all resolved".
`8AX` was never a name. Docs that treated it as one are corrected here.
Disc-wide, and the control is the 17 918 the scan already got right: the `opt `
reading reproduces every one of them. Effect on the five screens is the
signature of the same art at twice the resolution -- mean brightness unmoved,
high-frequency detail x1.15..x1.30 -- which is what the separately-measured
`ui-8ax-fullres-background` result said the game draws.
Also closes a long-standing dangling reference: `pmbase.t32`, recorded as "on
the disc nowhere", is the `GP_STAGE_CLEAR` child the scan called `8AX`. RATC
sibling references now resolve 10 148 of 10 148.
Verified: 114/114 sylpheed-formats unit tests (including two new ones pinning
the `8AX` case byte for byte and the no-block fallback), and every disc-gated
integration suite in sylpheed-formats/sylpheed-cli.
Last iteration I claimed the splash's measured_paint_order [0,2,4,6,1,3,5]
records, between its glow and logo halves, the temporal order they were
seen in rather than depth -- because the halves never share a frame.
The no-overlap measurement is right (glows f94-115, logos f116-211). The
inference is wrong, on two independent grounds:
* Wrong source. That vector is not a read of the draw capture. It is a
read of the live screen object's CHILD ARRAY -- ui-screen-runtime.md
records it literally as "paint order (child slots)". A child list has
a definite order whether or not its children are ever drawn together,
so co-occurrence does not bear on it. The capture was the CHECK.
* The order is in the file anyway. paint_order_audit on GP_TITLE entry
11: derived == measured, 0 inverted pairs, 0 same-layer-key ties. The
glows and logos carry distinct T8aD keys (0xa100 < 0xa110), so the
file orders the halves statically, no capture involved.
I asked the question that started this iteration -- do the title and menu
orders have the same problem -- and the answer is that none of the three
does, for the same reason.
What survives is narrower and now recorded with numbers: how much of each
order its capture actually cross-checks. The title capture is stable (8
draws / 12 quads / 5 textures, identical in all five captured frames
across two logs) and confirms 7 of 24 positions; the menu capture is not
(texture 0x11C30000 present in frame 0, gone by frame 3); the splash
capture cannot cross-check its middle at all.
A counting trap worth the tool: count QUADS, not draws. The menu's draw 9
is indices=24 -- six quads batched from one texture. Counting draws reads
9 where 16 are on screen, and an earlier pass of this analysis briefly
"found" three quads for six declarations that way and concluded elements
were missing. They were batched.
METHOD: check what a "measured" value was measured FROM before reasoning
about its limits. The co-occurrence rule is real, and it is specific to
orders read from draw captures.
ui-prm-primitives recorded that where a .prm paints on a screen without a
measured order is unsolved. For the developer splash it is now measured.
Every frame opens with two full-screen draws before any sprite. The
second is untextured in all 212 frames with a constant vertex colour of
FF000000 -- opaque black -- matching palogo_eff0.prm's declaration
exactly: kind 0x10, pivot (640,360) -> 1280x720, one keyframe, a = 255.
So the splash backdrop is an opaque black full-screen quad from the
bundle itself, painted behind every sprite, which is why a splash render
needs --black rather than the default backdrop.
Not a general rule, and said so: the measured main-menu order puts
pteff02.prm at position 4 and pteff00.prm LAST, the latter being the
screen-transition fade.
And a correction to an existing row. measured_paint_order returns
[0, 2, 4, 6, 1, 3, 5] for the splash, described as "the .prm, then all
three glows, then the three logos". But the glows and the logos never
appear in the same frame -- 0 overlapping frames in 235 -- and two
elements that never co-occur have no observable relative depth. Between
those halves the vector records the order they were SEEN IN, not a
front-to-back relationship.
That does not make the render wrong, and element 0 is a real depth
observation since the .prm co-occurs with everything. But the type of the
claim matters: reading the vector as depth invites compositing all seven
elements at once, which is exactly what does not reproduce the screen.
METHOD: two things that never co-occur have no observable relative order;
when recording an order, note which pairs actually appeared together.
Last iteration I withdrew "a bundle is a palette" because the evidence
did not choose between selective activation within one bundle and two
compositions shown in sequence. The alternative can be killed from the
disc, which I had not tried.
Hypothesis 2 needs a bundle declaring the GLOWS WITHOUT THE LOGOS. There
is none. Every GP_TITLE entry carrying palogo elements:
10, 13 (publisher twins) palogo_eff0.prm, palogo_sqex, palogo_sqex_eff
11, 14 (developer twins) palogo_eff0.prm + all three logos + all three glows
Four entries, and each developer entry declares the complete set of six.
So whichever bundle was active across frames 94-211 -- entry 11, entry
14, or both in turn -- it declared the logos and the glows, while the
game drew two sprites at a time in disjoint phases.
Therefore only a subset of a bundle's elements is drawn at any moment,
whatever the bundle-loading story is. The conclusion no longer depends on
resolving how many bundles are involved, which is why the texture-base
test's failure stopped mattering.
So the claim is reinstated -- this time by eliminating the alternative
rather than by assuming it away. What worked was not a better capture but
asking what the competing hypothesis would REQUIRE on the disc and
finding it absent.
METHOD: a hypothesis that predicts an artefact can be killed by looking
for the artefact, which is often far cheaper than measuring the behaviour.
Last iteration I wrote that a bundle is a palette whose elements are
selectively activated. The disjoint glow/logo phases have two
explanations and I asserted one:
1. one bundle, some elements run then others;
2. two bundle-loads shown in sequence (entries 11 and 14 are twins
declaring identical sprites).
The draw log's tex[base=...] looked like it would separate them. It does
not, and the control is in the same table:
publisher splash f1-90 0x11C30000, 0x10000000
glows f94-115 0x11C30000, 0x10000000
logos f116-211 0x11C30000, 0x10000000
The publisher splash is certainly a DIFFERENT bundle from the developer
splash, and it uses the same base. So 0x11C30000 is a reused upload slot,
not a bundle identity, and the test cannot choose between the two
hypotheses.
Survives: a bundle's declared elements are not what gets drawn.
palogo_anima and palogo_gamearts carry byte-identical keyframe times and
in the same run one is drawn 95 frames and the other none -- and
whichever twin was active declares both. The phases are strictly disjoint
(0 overlapping frames in 235).
Withdrawn: the mechanism. The practical consequence is unchanged --
compositing every element of a bundle does not reproduce what the game
shows over time -- but the why is not established and I stated it as
though it were.
What would separate them: a per-draw capture recording the bundle each
draw came from, or a file-IO log showing whether a second RATC entry is
read between frames 115 and 116.
METHOD: a shared resource address does not identify the resource's owner;
and state the mechanism as a separate claim from the observation, or the
weaker one inherits the stronger one's evidence.
Two checks on last iteration's "sequential, not simultaneous" reading.
First, the phases really are disjoint. If glows and logos ever shared a
frame the claim would be wrong. Across all 235 captured frames the count
of frames containing both is ZERO, and the switch is a single clean
boundary -- f110-115 draw 1280x720 + 262x108 + 525x90, f116 onward
1280x720 + 243x86 + 499x72. Two sprites either side, no transition frame.
Second, and larger: a third of the bundle is never drawn. Entry 11
declares three logo/glow pairs and only two appear.
palogo_gamearts / _eff 95 / 22 frames
palogo_seta / _eff 95 / 22 frames
palogo_anima / _eff never
palogo_anima declares the SAME keyframe times as palogo_gamearts. Two
elements with byte-identical data, 95 frames and 0 frames in one run.
Reach: the capture covers frames 1-214, so this is "never in the window".
So a bundle is a palette, not a script. Its elements say what to draw and
for how long; which of them run, and when each starts, is decided outside
the placement data. That is the same conclusion the boot-order work
reached from the other end -- the driver is code, not data -- now with a
per-element measurement behind it.
For the port, concretely: compositing every element of a bundle does not
reproduce what the game shows over time. It is the right thing for a
static screen that settles, and it is not a timeline.
METHOD: two elements with identical data and different outcomes is the
strongest possible evidence that the decision is elsewhere.
Tested whether the splash timeline, played, reproduces the capture --
the last gap in the animation model. Half of it does.
Durations match. At 2 units/frame under the shifted reading, from the
235-frame draw capture of the developer splash:
glows drawn f94-115 (22 frames = 44 units) declared ~0..45 = 45 97.8%
logos drawn f116-211 (96 frames = 192 units) declared 15..210 = 195 98.5%
Each element is on screen for its declared span to within 2%.
Starts do not. Every glow declares the same times 15,30,45 and every
logo the same 15,30,190,194,206,210, so on one clock they would overlap
almost entirely -- and they do not overlap at all. The glows run 94-115
and the logos 116-211, strictly sequential, the logos starting the frame
after the glows end. Fitting one origin needs f0 ~ 93.5 for gamearts_eff
and ~103 for gamearts, about 19 units apart, and aligning one throws the
other off by ~9 frames at both ends.
The obvious candidate is refuted. parse_placements reads each group
header as (element index, keyframe count) plus one undecoded LEAD-IN
WORD -- exactly where a per-group start offset would live. It is
0x00000000 for all seven elements, glows and logos alike.
Reach: not the keyframe times (identical within each family), not that
word (zero), not declaration order (which interleaves logos and glows
where the observed sequencing groups them), not the RATC child order.
What remains is that the sequencing is code-driven, which agrees with
what the boot-order work concluded independently.
For the port: a group says how long an element animates and what it does,
not when it starts relative to its neighbours. The observed order on the
developer splash -- both glows, then both logos -- is measured for one
screen, not a decoded rule, so the sequencing has to be authored.
METHOD: when a model reproduces durations but not positions, the missing
piece is an origin, not a rate.
The model's sharpest prediction, tested with its control. The draw log
says that on the developer splash the _eff glows are drawn on frames
94-115 and the logos on 116-211, so at the moment the reference capture
was taken EVERY glow is already finished -- including the two that have
plateaus and which rest_plateau therefore renders visible. Suppressing
them should help on the splashes and hurt where a screen genuinely
settles.
publisher splash +0.9604 -> +0.9982 +0.0377
developer splash +0.9659 -> +0.9980 +0.0321
title (control) +0.9500 -> +0.9480 -0.0020
main menu(control) +0.9460 -> +0.8544 -0.0916
EXTRAS (control) +0.9440 -> +0.8370 -0.1070
Both splashes jump to about 0.998; all three persistent screens get
worse. The control is what makes this a finding rather than a
coincidence: the same edit helps exactly where the model says it should
and hurts exactly where it says it should not.
So rest_plateau is not over-drawing in general -- it over-draws on
TRANSIENT screens. A plateau mid-animation means the element is held at
that point in the timeline, not that it is on screen once the screen has
settled. Where a screen settles, the held pose IS the settled pose and
the rule is measurably right.
And that answers the question left open several iterations ago -- what
"rest" means for a transient element. It does not mean anything: the
splashes never rest. A static composite of them can match a chosen frame,
and about 0.998 is what these captures' frame is worth, but the format
does not answer a question the screen never poses.
For the port: play the timeline for the two splashes, which the settled
keyframe timing now supports, and composite statically for title, main
menu and EXTRAS.
METHOD: an edit that improves one set of cases is only interesting once
you have shown it damages the cases where it should.
The shifted keyframe-time reading looked like it implied something
simple: the final pose is reached at a definite time and nothing follows,
so rest should just be the last keyframe and the plateau heuristic could
go. Tested by applying it to EVERY element:
title +0.9500 -> +0.6819 -0.2681
main menu +0.9460 -> +0.6416 -0.3044
EXTRAS +0.9440 -> +0.5745 -0.3695
publisher splash +0.9600 -> blank (zero variance, corr undefined)
developer splash +0.9643 -> blank
Refuted, and the failure supplies the model. A group is entry -> hold ->
exit, and the exit is the screen's DISMISSAL. While a screen is displayed
it has not reached its last keyframe; it is sitting at the hold. So
rest_plateau is the correct primary rule, and the last keyframe is the
post-exit state -- correct only once the screen is gone, which is why
applying it everywhere blanks the splashes.
This does not contradict the shifted reading. That reading says when each
pose is reached; it says nothing about the group being played to
completion while the screen is still up. The step between them was mine.
And it explains why last wins for the two plateau-less elements: an
element with no hold is a transient, it flashes and is over, and at any
settled moment it is gone -- which is its last keyframe. The draw capture
says the same independently: on the developer splash the _eff glows draw
on frames 94-115 and the logos on 116-211, so the glows are already
finished when the logos are up.
Three independent observables -- animation timing, static composites, and
the per-frame draw log -- now agree on one rule: plateau where there is
one, last keyframe where there is not.
METHOD: a blank render is a NaN correlation, not a low score, and that
NaN was the strongest form of the result; and when a model predicts
something the measurement refuses, suspect the step you supplied between
them.
Scored candidate rest-pose rules by rendering and correlating instead of
arguing, and both results correct something I had published.
First, the exposure. The guessing fallback is reached only by an element
that is plateau-less AND multi-keyframe -- a single-keyframe element
short-circuits at `match len { 1 => first }`. Per screen:
title (4) 24 elements 2 plateau-less 0 reach the fallback
main menu (5) 16 5 0
EXTRAS (6) 18 5 0
publisher splash (10) 3 2 1
developer splash (11) 7 2 1
So on the three screens the port cares most about, rest() never guesses.
That is why three different rules render builds 4/5/6 to identical
correlations -- the code is unreachable there, which I nearly read as
"the choice does not matter".
Second, where it does fire, the last keyframe is markedly better:
publisher splash dwell +0.9600 last +0.9982 maxalpha +0.9600
developer splash dwell +0.9643 last +0.9758 maxalpha +0.9643
That refutes my own earlier refutation. I had killed the last-keyframe
rule by arguing it makes palogo_anima_eff invisible while its two
siblings stay lit, which looked like an artefact. The capture says
otherwise: making it invisible is what improves the match. The sibling
symmetry was my expectation, not evidence.
Caveat kept in front: both captures are single frames of a transient
animation, so this fixes which pose matches THOSE frames, not which is
canonically at rest. Default unchanged -- better on both screens where it
fires and identical on the other three, but it would move 2 305 elements
disc-wide on two measurements. Reachable via SYLPHEED_REST_RULE=last.
Also confirmed: all 195 zero-scale rest poses are inside the corrected
2 305 ambiguous population; none is a single-keyframe element.
METHOD: score a rule where it can differ, or you measure nothing; and an
argument from symmetry is a prediction, not a refutation.
Two corrections from one experiment.
A keyframe group is entry -> hold -> exit, and the exit ends invisible:
on the five port screens the final keyframe is invisible for 21/24
(title), 8/16 (main menu), 12/18 (EXTRAS), 2/3 and 6/7 (splashes). So the
screen as seen is the HOLD, which is why rest_plateau is the right
primary rule and why "rest = last keyframe" would empty every screen.
That suggested a fix: an element with no hold has no representative pose,
so draw nothing rather than guess an endpoint. Tested through compose's
visible mask and correlated against the live captures:
title +0.9500 -> +0.6839 -0.2661
main menu +0.9460 -> +0.9037 -0.0423
EXTRAS +0.9440 -> +0.9094 -0.0346
Refuted on all three, and the reason invalidates a number I published. An
element with a SINGLE keyframe has no adjacent pair, so the plateau test
marks it plateau-less -- but its one pose is unambiguously its rest.
Suppressing those removes backgrounds and full-screen layers, which is
the title's -0.27.
no plateau (as published) 3 807 (24.57 %)
... single-keyframe 1 502 trivially at rest, not a guess
genuinely ambiguous 2 305 (14.88 %)
So rest() guesses for 2 305 elements, not 3 807 -- the figure I gave the
port overstated the defect by 65%. Corrected in HANDOFF and the page.
METHOD: a predicate over adjacent PAIRS silently misclassifies a
one-element list; and acting on a claim is a better test of it than
re-reading it -- this flaw survived a census, a write-up and a handoff
row, and died the moment the rule was used to change a rendering.
The case for reading +36 as "the time the NEXT pose is reached" rested on
one element's fade-out shape, then on one element's hold duration. Both
splash halves supply more, and they agree.
element screen observed hold as decoded shifted
palogo_gamearts developer splash 83 f 8 f 80 f
palogo_seta developer splash 83 f 6 f 80 f
palogo_sqex publisher splash >=77 f * 6 f 102 f
* the capture opens mid-hold at frame 1, so 77 is a floor.
The readings predict opposite structures. For palogo_gamearts, as decoded:
hold 8f, in 80f, hold 2f, out 6f, out 2f -- an eighty-frame FADE-IN and a
two-frame hold. Shifted: in 8f, hold 80f, out 2f, out 6f, out 2f. The
capture shows an 83-frame hold and no fade-in at all.
The elements that cannot discriminate are not contradicted:
palogo_gamearts_eff observed in 7f / hold 7f / out 8f, and both readings
give 8f phases -- with four blocks the shift only relabels which phase is
which. So the glows, which is where Q1's linear law was measured, say
nothing either way rather than arguing against.
The decoder's default is still unchanged, and the reason is now
articulated rather than assumed. The single thing opposing the shift is
rest() on ptlogo_eff3, where the shifted reading makes the longest-dwell
fallback return the bloom's 200% peak. That fallback is unsound whenever
it runs -- it returns an endpoint of a movement, neither of which is held
-- and checked: the shift does not fix it either. So the objection was
never evidence about the times. Timing had three discriminating
measurements; pose selection had a heuristic guessing.
For the port: animation timing should use the shift; static composites are
unaffected and the five screens' correlations stand. Classified measured,
not decoded -- three elements in one screen family, not a disc-wide check.
Last iteration I wrote that build-reborn test cannot finish in a working
session, from having watched it run 3h26m. That was the stronger claim
and I made it without measuring the work.
Timing `mesh info` on each of the 166 .xpr containers with a 25 s cap:
files scanned 166
exceeding 25 s 19 Hangar, 17 Stage_*, ptc_pack
Stage_S02 to completion 144 s, rc = 0
Nothing hangs. Nineteen heavy containers at roughly two minutes each is
about 45-60 minutes for one pass, before the 147 fast ones. The 3h26m
observed was that hour of work running at a load average of 9-14 --
inflated by the two duplicate runs I had left going, which did not merely
coexist with the slowness but multiplied it.
The practical conclusion is unchanged and only the wording softens: an
hour-scale suite is not an iteration-scale gate, and every "green" I
reported from it this session was partial. But an hour-scale gate can be
run deliberately, whereas a hung one cannot be run at all, so the
distinction is worth having right.
File list committed as reference data so the cost is attributable without
re-scanning.
METHOD: a slow thing observed under contention looks like a stuck thing;
measure the work before choosing between "cannot finish" and "takes an
hour".
Two findings from checking whether last iteration's partial green had
finished. It had not, and the reason matters for anyone using the gate.
build-reborn test contains twin_pairs_do_not_share_a_buffer, which
decodes every .xpr in hidden/resource3d -- 166 files, 1.4 GB -- through
the full Xbg7Model anchoring path, and is NOT #[ignore]d. Its sibling in
the same file walks the same 166 files and IS ignored as known-failing,
which makes the binary's cost easy to underestimate. Measured: one
instance accumulated 3h26m of CPU at 89% without finishing.
So every "green run" reported in this corpus from a workspace or
sylpheed-formats test is necessarily PARTIAL unless it says the suite
terminated -- including the ones I reported this session. The honest form
is the suite count and elapsed state, not the word "green". Not proposing
to #[ignore] or subsample it: that changes what the suite asserts and is
the project's call, not an audit side-effect.
And the mess is mine. Two cargo test -p sylpheed-formats runs launched
detached in earlier iterations never exited, because they were sitting in
that test:
pid 103375 4h12m elapsed child mesh_consistency_disc 3h26m CPU 89.3%
pid 99965 4h39m elapsed child pak_idxd_disc 1h16m CPU 93.8%
Load average 14.18 on 12 cores. Killed, after checking the legitimately
running workspace suite and leaving it alone; load fell to 9.68.
What this does NOT explain, because it is tempting: the session's
emulator troubles. screenshot cost 0.49 s with both runaways live and the
emulator stopped, against 10.8 s measured earlier with the emulator
running. The 92x figure really was emulator contention; the runaways were
a background tax on top. The black surface and the unreachable title
stand as measured, with their own controls.
METHOD: a detached job you never check can outlive many iterations --
setsid was added so a timeout could not kill them, which also means
nothing does; and know whether your verification gate can terminate.
Nothing had ever verified that a number written in prose matches the
reference data file committed beside it. The figure is written once from
a run; the prose is edited around it afterwards and the data file is
regenerated independently, so drift is silent.
All 19 headline figures across four censuses -- the eff-bit census, the
plateau census, the top-level rotation census and the eff-bit alpha test
-- currently agree with their data files.
The checker had to be numeric, and the first attempt is the reason it is
a script rather than a grep: comparing strings reported almost every
figure as a mismatch, because the data files write 14709 where the docs
write "14 709" with a thin space, and the docs round 33.66 to 33.7. A
consistency check that fails on formatting trains you to ignore it, so
the tolerance is explicit: exact against the data, within 0.05 against
the doc to allow rounding.
Also ran the full disc-gated workspace suite (build-reborn test, which
wires SYLPHEED_DISC -- without it the disc tests self-skip and green
means almost nothing), covering this session's three decoder changes:
rotation_deg on Keyframe, the scale-0 fix in blit/fill_quad, and the
flags field on T8adImage. 122 passed / 0 failed across the four suites
that had completed; the long disc-gated integration tests
(records_roundtrip_disc, first_header_word_is_record0_hash) were still
running and are not counted here.
A per-sprite premultiplied-vs-straight-alpha flag would matter a lot to a
port and has a sharp static signature: premultiplied means RGB <= A
everywhere. Over the 170 decoded GP_TITLE textures that pair to a flag
word:
bit SET n= 61 mean %(RGB>A) 55.52 median 52.52
bit clear n=109 mean %(RGB>A) 33.66 median 30.17
Premultiplied requires ~0% for the flagged group. Both groups are far
from it and the flagged group violates MORE -- the opposite of the
hypothesis. Refuted.
What remains is a weak association: flagged sprites carry more
bright-RGB/low-alpha pixels, which is what glow art looks like. But the
best single threshold classifies 76.5% against a 64.1% base rate -- a
12-point lift with badly overlapping distributions. A tendency, not a
rule, and reported with its base rate so it cannot read as more.
Noted for whoever returns: "0x02 selects an additive blend" was refuted
by blending those sprites additively and finding every measure worse
against the capture -- but that ran through a title render since fixed
twice (rest_plateau, and the 8AX background the composer drops). The
refutation may well stand; it was measured through a renderer with known
other errors, so it is worth one re-run if blit ever gains additive
blending.
Parking the field. Four candidate meanings are dead -- additive blend,
eff name in both directions, transient element, premultiplied alpha --
none produced a positive account, and the bit blocks nothing: the port's
screens composite at 0.947 correlation against a capture without it. The
negative space and the sound attribution method (child order, not size)
are written down so a later attempt starts here.
METHOD: report a classifier's lift over its base rate; and park a field
after N failed hypotheses, saying what was eliminated.
Last iteration I killed the biconditional and reported that the one-way
reading survived: all 10 bit-set sprites on GP_TITLE build 4 are eff
names, so "bit set => eff name". Checked over the disc, that is false.
sprites with a resolvable preceding name 14 709
bit SET & name has 'eff' 2 338
bit SET & name lacks 'eff' 2 657 <-- counterexamples
bit clear & name has 'eff' 1 399
bit clear & name lacks 'eff' 8 315
P(eff | set) = 0.468
P(eff | clear) = 0.144
The implication fails more often than it holds. What survives is an
association -- 3.3x enrichment -- and build 4's 10/10 was a local naming
habit in an 18-element bundle, not a format rule.
The counterexamples are the useful part: pv_loading_ring0,
pv_loading_light0-3, pv_loading_line, px_bunk_line, px_top_extra. Rings,
glows, lights, thin lines -- effect-like artwork that does not carry the
eff naming convention. Consistent with the bit marking effect sprites by
authoring intent rather than by name, which is a description and not a
decode, and is labelled as such.
Names here come from the string immediately preceding each T8aD,
validated 17/18 on build 4 against the RATC child order; the single
mismatch is the known pteff04.t32 -> registered as 8AX case, so this is
the element (opt) name rather than the sprite's registered name. That
mismatch is itself an independent confirmation of the 8AX finding,
reached from the opposite direction.
METHOD: a pattern perfect on one screen can be near-chance on the disc;
and when an association survives a refuted implication, the
counterexamples are the finding.
The bit at +0x04 was recorded as a real field with its meaning "not
diagnosed", noting ptlogo_back2eff is 0x8830 "despite its name". That note
rested on a size match -- and its size is ambiguous, which is the trap
this corpus already records.
First, a sound attribution. T8aD headers appear in the bundle in RATC
CHILD ORDER, verified on GP_TITLE build 4 against an independent property
-- each header's decoded dimensions versus the dimensions the named child
should have: 18 of 18 match, 0 mismatches. Two of those eighteen share a
size (ptlogo_back2eff and ptlogo_back2eff5, both 1133x280), so a size-keyed
lookup cannot separate them; ordering can. Index 12 is back2eff5 (0x8832,
bit set), index 14 is back2eff (0x8830, bit clear). The documented
counterexample is real and correctly attributed -- now on evidence.
Two candidate meanings tested and refuted:
bit <=> name contains "eff" REFUTED: ptlogo_back2eff is an eff
name with the bit clear. All 10
bit-set sprites are eff names, so
the implication holds one way only.
bit <=> the element is transient REFUTED: pteff03/pteff03a carry the
bit and run to t=250, ramping to
a=255 and holding.
Up close, the exception pair differs in two header words: +0x04
0x8832/0x8830 and +0x08 0x8083/0x8081 -- layer keys 32899 and 32897. They
are NOT duplicates: their alpha summaries agree to one decimal (4.5%
opaque, 86.7% clear, mean 19.3) but a pixel compare gives max abs diff 21.
Two renditions of one image at one size, which is why the summaries were
not trusted.
Still not diagnosed, and said so -- but the search space is two smaller
and the attribution beneath it is now sound.
METHOD: T8aD headers sit in child order, use that not the size; and
identical summary statistics are not identical data.
Last iteration left two candidates for why trace_gpu_stream produced no
file: the CLI flag not reaching the cvar, or BeginTracing failing
silently. Neither. Following the code instead of guessing:
BeginTracing only sets trace_state_ = kStreaming ("Streaming starts on
the next primary buffer execute"). The file is opened later, in
ExecutePrimaryBuffer, inside
#if XE_ENABLE_TRACE_WRITER_INSTRUMENTATION == 1
and trace_writer.h defines that as 0 under NDEBUG, 1 otherwise -- the
trace writer exists only in debug builds.
Confirmed against the binaries, with a control. The format string
"{:08X}_stream.xtr" lives only inside that guard:
build/bin/Linux/Release/xenia_canary 0 occurrences
build/bin/Linux/Debug/xenia_canary 1 occurrence
/sylph-home/re/canary-build/.../Release/... 0 <- what run-canary uses
The debug binary is the control: it proves the test finds the string when
it is present, so the release zero means something.
So trace_gpu_stream is a no-op in this container's emulator -- the cvar
parses, BeginTracing runs, and nothing can open a file. The kill -9 was
not the cause either, though it would have destroyed a trace had one
existed.
The route exists but is not cheap: a debug build with the writer compiled
in sits at build/bin/Linux/Debug/xenia_canary, 253 MB against Release's
18 MB, so a much slower boot plus a trace of every GPU packet on a disk
at 95%. Recorded as available rather than attempted -- what it would
confirm, the DC_LUT write, is already a well-supported inference, and the
cost is out of proportion to the gain.
METHOD: a cvar existing does not mean the feature is compiled in; and
test a compile-time gate against the binary, with a control.
