83da9bd1ea503b4bdd947f02cce2847838228f18
1137 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
sylph-decoder
|
83da9bd1ea |
method: an insensitive observable fails twice, and the second way sends you hunting
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 |
||
|
sylph-decoder
|
f0fc4afd10 |
re: the 11.5 px residual was the alpha-only fit s resolution, and it closes
Left open earlier as do-not-fit. Closed by adding observables rather than tuning a parameter. The draw s vertex buffer carries positions and colours at the same instant, so all four quantities must agree on one t. Solving independently: quad A x gives 357.88, quad B x 357.58, quad A alpha 355.75, quad B alpha 354.09. The alphas are about 50x less precise per unit of time because alpha is a byte changing by only 0.27 to 0.33 levels per keyframe unit, so a single level of quantisation is worth 1.5 to 1.9 units, which at 4 px per unit is 6 to 8 px of sweep. The 11.5 px was that. At the position-derived t = 357.7 every observable lands: centres within 0.70 and 0.48 px, both alphas inside one level, and the parent alpha is 0 throughout. And there is no pivot correction to find -- the leaf pivot is (200,90) against a 399x180 sprite, so the pivot is the sprite centre and rotation displaces it by nothing. The methodological point is the one this exchange started with, inverted. Earlier a rule looked confirmed because it was checked against alpha, the insensitive field. Here the same insensitivity manufactured an apparent 11.5 px error. The insensitive quantity does not merely fail to falsify, it invents residuals. Solve on the fastest-moving field and check the slow one, never the reverse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
382112d63a |
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
|
143912ea4f |
re: the port s leaf x = -324 is the OLD keyframe association, not a geometry gap
They implemented the leaf rule and reported the leaf top-left at x about -324 at t=355, off-screen left, against 781 here, and asked how a rotated 600-percent quad s declared pos relates to its drawn centre. It is not a geometry question. Their stated pairing is t=150 at x=-639, t=540 at x=-39. On the disc the poses -639 / -39 / 1521 carry times 0 / 150 / 540. Their pairing gives each pose the NEXT pose s time -- exactly the association ui-keyframe-record-layout.md refuted and HANDOFF carries a red banner about. Feeding their pairing into the same interpolation reproduces -324 to the digit. With the corrected association t=355 gives top-left 781 and centre 980.5 for the 399-wide sprite, against 992.0 measured off the capture. So the leaf path still carries the pre-fix association although the top-level parser was corrected: a leaf is parse_build on a sub-slice, so anything reading leaves through a separate path can still be shifted. And the reason it looked confirmed is worth keeping: alpha at t=355 sits inside a long segment where a one-keyframe shift barely moves it, while x sweeps 1560 px over the same span. The rule matched on the insensitive quantity and was wrong on the sensitive one -- check a new interpretation against the fastest-moving field, not the one that happens to agree. The residual 11.5 px between 980.5 and 992.0 is left open rather than fitted; a rotation about a declared pivot rather than the centre would displace by roughly that much and nothing here measures it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
03b0bdb423 |
handoff: deliver the leaf-versus-parent alpha rule
The port asked for the composition rule and declined to guess it, which was the right call. Delivered on the page they read: draw the leaf on its own timeline, do not multiply the parent s alpha in, with the refutation stated -- multiplying predicts zero at the observed time and the sweeps would be invisible. Keeps the two limits that matter to a consumer. It is not a universal precedence rule: here the parent is a container with no sprite, while for a button the leaf duplicates the parent and the parent wins, so the discriminator is which record carries the geometry. And because every observation has parent alpha zero, leaf wins is not separated from parent ignored because it draws nothing. Also flags their title_jp ptlogo_eff2 lead as untested by me, with the reason it is worth checking: if its two-element leaf carries the geometry the same way, the 125 percent scale may be the parent s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
a923954a1f |
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
|
856f93ac3a |
handoff: the port s title residual is the rotated ptloop quads, not a blend mode
The port asked whether a blend field exists and whether _eff layers draw additively, naming it as their largest remaining oracle gap. Both answers are no and the cause is already decoded. Additive blending is refuted specifically: T8aD +0x04 bit 0x02 as an additive selector was tested and every measure worsens against the capture. The export carries no blend field because none has been found -- the per-draw capture records primitive type, index count, shader hashes, texture bindings and vertex attribute 0, but no RB_BLENDCONTROL, and reading real blend state needs a Canary change that is blocked here. One of their three eliminations is overturned. They ruled out the ptloop sweeps as 399x180 at (441,270) with keyframes holding position constant -- that is the unscaled, unrotated geometry. Measured off a GPU draw capture, the live title submits two rotated quads: ptloop01 at 400x1076 rotated +30.26 degrees centred (992,359), and ptloop02 at 400x1444 rotated -45.28 degrees centred (467,360), the scales being 600 and 800 percent. Two quads at x about 467 and 992, leaning opposite ways, is exactly their signature of darker centre-left and brighter right nearly cancelling. Our own renderer shows the same residual from the same cause, tiles running -38.6 then +33.8 across the band, so it is a shared decode gap rather than a defect in their compositor. The rotation itself is decoded: keyframe block +12, degrees, clockwise-positive, confirmed against a framebuffer capture. So their biggest oracle gap and the rotation question they raised for the human are the same item. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
bf6a79166e |
re: S00A is unreachable here -- the new-game path crashes on a cache it cannot build
Drive 4 worked. With focus detected and the detector validated live against a known transition (NEW GAME, down, LOAD GAME -- CONTROL PASSED), the drive navigated and pressed through, and every step confirms against a committed capture: main menu +0.999, newgame-difficulty +0.999, newgame-selectdata-crash +0.997. Then the guest throws, PC 0x82307128 times 349, and no S00A voice stream ever decodes. It is on the new-game path rather than the boot: the log order is ADV attract, then BGM_103 menu music, then the throw. So it is not the ~100 s boot throw that title-crash-stl-tree.md documents. That page attributes the throw to an incomplete on-disc cache and Q4 s note cites it for this crash. The attribution survives, but not through the container the page names. aab216c3 is complete here at 7 files. The line immediately before the exception resolves \1b556564\9\00c8dcd, and 1b556564 holds exactly one file plus a stray 1b556564900c8dcd.tmp -- precisely the page s run C, partially rebuilt, which throws. So the new-game path builds a different cache container from the title path and that one is incomplete. The page s remedy does not transfer. It restores a previously complete cache, and no complete 1b556564 has ever existed here: the game crashes while building it, leaving the .tmp, so the cache cannot complete and re-running does not escape it. Its own run B shows a fully cold cache throws as well, so deleting does not help. Consequence recorded: the centre-channel voice result stays resting on ADV alone, because the corroborating asset is behind a crash that is outside menu-port scope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
0bc729639d |
re: initial focus is TUTORIAL x3 / NEW GAME x3, and never anything else
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 |
||
|
sylph-decoder
|
c65f5ed1c9 |
handoff: BGM_103 as the menu music now has a runtime leg
The port asked for this to have its own line rather than sitting inside a drive report, and they are right -- it is a third independent confirmation of a claim that the port authors from. The claim rested on GamePart_Title s sub_821C5580 playing cue 1103 (static code) and on the bank s two declared wave sizes matching what an XMA probe saw (disc census). On a driven boot, BGM_103 s two waves were handed to the XMA decoder at the moment the main menu appeared -- observed being decoded on arrival at the screen, rather than inferred from a table or matched by size afterwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
f96f0cc985 |
re: the S00A drive failed -- initial menu focus was TUTORIAL, not NEW GAME
Reported as a route finding rather than retried silently, because the cause is a defect in shared harness tooling that will bite the next drive. Drive 1 sat 396 s reporting other with two spurious menu hits while the guest was healthy and decoding audio throughout. screen_id.py thresholds on green and only returns title once the PRESS A plate has faded in, so it cannot see the plate-less build-4 title this corpus documents. It also calls difficulty-screen a menu. Both reproduce on committed frames, and newgame_path.sh, nav_probe.sh and boot_menu.sh all gate on it. Drive 2, with a classifier controlled 6/6, reached title_plate at t=398 s and drove on -- into a TUTORIAL MISSION. The screen 60 s after the last A correlates +0.960 with the committed tutorial-mission-reached-then-crash.png, and no S00A voice stream ever decoded. newgame_path.sh s header assumes NEW GAME is the first item so no d-pad movement is needed; that contradicts this corpus s own Q5 result, where four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME. Incidental corroboration: BGM_103 s two waves decoded on reaching the menu, an independent runtime confirmation of the menu-music claim that HANDOFF rests on static code and a disc census. What is needed is a focus DETECTOR, and wrap-around means counting presses cannot substitute -- up from the first item goes to the last. I do not have one: a per-row brightness statistic failed its control, picking NEW GAME on the capture whose filename says OPTIONS. Also records a refutation attempt on the port s focus identification that FAILED. Differencing the two captures and binning by row appeared to show NEW GAME and EXTRAS changing, contradicting them. That was my error -- I placed row bands as rest_y plus or minus 24, treating the resting position as a band centre. The offset-independent check settles it: the changed bands are 254.9 design-y apart against a button pitch of 80, so the two focused buttons are 3 apart and not 4 -- NEW GAME to OPTIONS. Their identification stands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
722b8e3f4d |
re: the tone curve s single exponent is refuted above render 40
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 |
||
|
sylph-decoder
|
b77da80966 |
method: screen_id.py cannot see a plate-less title, and calls DIFFICULTY a menu
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 |
||
|
sylph-decoder
|
54a719c286 |
re: stripping additive padding is exact -- controlled, and only one side needs it
The page recorded the substituted-versus-additive distinction as unverified, with the port controlling it. It passes. A real music and SFX bed of 137.37 s, itself carrying 454 genuine zero runs -- which is what makes it an honest control -- had 1149 holes inserted at 8.37 gaps/s to +9.9 percent length, matching the measured ALSA profile, then stripped: original vs itself (ceiling) r 1.000 lag 0.0 s margin +0.141 padded vs original r 0.436 lag -12.2 margin +0.006 stripped vs original r 1.000 lag 0.0 margin +0.142 Two things beyond the yes. It runs the inference forwards: padding at this profile puts correlation squarely in the known-absent regime on a file whose contents are controlled, so the earlier captures were unusable for the reason claimed rather than for some other one -- until now that was reasoning backwards from a failure to a cause. And only one side needs stripping, since the stripped capture matches the UNSTRIPPED source at the ceiling, so a capture needs no preprocessing before being handed over and there is no shared step to get out of sync on. The danger is recorded as the part to repeat: stripping removes genuine silence too and cannot tell the two apart, so it is exact on additive ALSA padding and vandalism on a PulseAudio monitor capture where the silence replaced real audio. Running it on the wrong artefact would look like it worked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
798d7a2d4e |
handoff: deliver the centre-channel result and the S00A capture that is not taken
Records the port s measurement on the page they read, because it closes the last open question and my own pages carried the hypothesis it settles. Keeps all three limits as they stated them, including that streams 2 and 3 are indistinguishable to the instrument so no selection rule is vindicated, and that the one-of-three-streams warning stands with its character changed rather than its colour. Also names the capture that would strengthen it most and says plainly that I have not taken it: S00A rather than a longer ADV, why it is structurally different, and what it costs -- a driven rendered run, so no --gpu=null and the additive padding comes with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
8841fe9c91 |
re: the voice dialogue is in the CENTRE channel -- measured, not inferred
The 5.1 reading of a voice cue s three concurrent streams was recorded here as a hypothesis with counter-evidence attached. It is now answered, by the port fitting the disc s decoded streams against a clean capture of the game s own 6-channel output, with the instrument controlled first (known-present margin +0.248, known-absent +0.005). Speech-band margins put streams 2 and 3 at +0.305 and +0.307 on FC, r = 0.989, above the known-present control, while stream 1 sits in the noise on every channel. The low band mirrors it exactly: the movie bed at 0.76 to 0.84 on the four corners against 0.32 on FC. Dialogue in the centre, bed in the corners. The hypothesis was right for a reason the file could never have supplied. ChannelMask reads 0x0002 on all three streams, so the header is not merely unhelpful, it is actively misleading -- refusing to call it 5.1 from the header was correct, and the oracle answered what the header could not. Three limits recorded as the measurer stated them: streams 2 and 3 are indistinguishable to this instrument, so no rule for choosing between them is vindicated; the one-of-three-streams warning stands, since nothing says what streams 1 and 3 contribute; and the reach is 59.7 s of a 137 s movie, one run, one asset. Also records the capture that would strengthen it most and why it is not taken: S00A rather than a longer ADV, because its second full-length stream is digital silence where ADV s is a 0.60x copy, so a structurally different movie would agree. Reaching it needs a driven rendered run -- S00A starts about 4.5 s after A on the save slot -- so it cannot use --gpu=null and will carry the additive padding. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
18d4fe61f4 |
re: substituted silence destroys information, additive padding does not
The distinction is the port s and it is sharper than the framing this page had. PulseAudio s monitor SUBSTITUTES: audio that existed is replaced by silence to keep the wall clock, so information is destroyed and deleting the holes only compresses time unevenly. Xenia s padding is ADDITIVE: the silence is inserted between samples the guest emitted, so nothing is lost and every real sample is present and in order. So stripping all-channel-zero runs from an ALSA-tee capture is exact rather than a repair, which means even the 0.70x rendered capture at 9.98 percent padding is usable for correlation, where none of the PulseAudio-monitor captures ever were however they were tuned. Recorded as unverified: the port is controlling it by padding a known source to match and checking the stripped result correlates back. Consequence for check-capture recorded too: its silence and gap-rate rule was built when only damage existed and cannot distinguish genuine emulator padding from capture damage, so a FAIL on an ALSA-tee capture is a statement about the recording path rather than the file s usability. Also promotes the runaway guard to a first-class CONTAINER-NOTES entry at the port s request -- 7.34 GB in 50 seconds at about 250x real time is not a footnote -- and adds --gpu=null there, which is what takes the guest from 0.70x to 0.96x and stops the padding, with its two caveats: no video for provenance, and runs die at about 70 s with PM4_DRAW_INDX failures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
41b47fa281 |
re: --gpu=null gives a clean audio capture -- 0.31 percent silence, 0.01 gaps/s
The residual padding in the ALSA tee was the guest running at 0.70x real time, and the dominant load is llvmpipe software rendering -- which an audio capture does not need at all. PulseAudio monitor, xenia default 39.3 percent silence 30.5 gaps/s ALSA tee to paced slave, rendered 9.98 percent silence 8.37 gaps/s ALSA tee to paced slave, --gpu=null 0.31 percent silence 0.01 gaps/s One gap in 67.7 s. Six distinct channels, no duplicates, sensible peaks. For scale the port s genuine music bed control measures 1.1 percent silence at 3.3 gaps/s, so this capture is cleaner than their known-good reference. Control that the run is still comparable: ADV s three XMA contexts appear in the --gpu=null log, so the movie s voice is decoding exactly as in a rendered boot. That is also better provenance for an audio question than screenshots were, since it evidences the thing being recorded rather than what was on screen. Records the full working recipe. Caveat: --gpu=null means no video, so screen-based provenance is unavailable and it is only appropriate when the question is about audio. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
7ff56fee3f |
notes: point the container page at the working audio-capture route
The entry already warned that run-canary is silent twice over, but stopped there -- and fixing only the mutes still yields an unfaithful capture, because a PulseAudio null sink s monitor is wall-clocked and invents silence when the client is late. Adds the pointer to the ALSA file-tee page, with the two things a reader needs before starting: the slave must pace or the tee free-runs at about 250x real time, and a size guard is not optional. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
5d3afc526d |
re: the ALSA tee measured on Canary -- faithful now, but the guest still pads
150 s boot with --apu=alsa --mute=false, tee in front of the paced pulse slave. PulseAudio monitor, default 5.3 ms 39.3 percent silence 30.5 gaps/s PulseAudio monitor, 200 ms 15.6 percent silence 3.5 gaps/s PulseAudio monitor, 500 ms 50.1 percent silence 1.3 gaps/s ALSA tee to paced pulse slave 9.98 percent silence 8.37 gaps/s 106.2 s captured over about 151 s of wall clock, i.e. 0.70x real time: the file is SHORT rather than gap-riddled, which is the intended trade. Six distinct channels, no duplicates, sensible peaks. A format trap worth recording: xenia s ALSA driver is SND_PCM_FORMAT_FLOAT_LE and its log confirms 6 channels, so the raw tee is float32 and not s16. Reading it as s16 yields a plausible-looking file whose giveaway is peaks alternating exactly -0.00 / -4.82 across channels -- the two halves of each float landing in alternate channels. I measured it wrongly that way first. The residual 10 percent silence is not removed, but its meaning has changed. It is no longer invented by PulseAudio s monitor; the tee records exactly what Xenia wrote, and Xenia wrote silence, because its writer thread pads whenever the guest has not filled the ring. So the capture is faithful -- every sample in it is a sample the emulator emitted -- while the emulator is still padding, because the guest runs at about 0.7x real time here. No capture method can remove that. So this is a 3.9x improvement in silence and a change of attribution, not a clean capture. At 9.98 percent and 8.37 gaps/s it sits right on the port s fail bar, and should not be treated as an oracle without saying which side of the line it fell on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
12146ca11d |
re: capture audio through an ALSA file tee, not a PulseAudio monitor
The human identified that both agents were fighting the wrong subsystem, and
testing it here confirms the diagnosis and finds the limit.
A PulseAudio null sink s MONITOR is sampled on a wall clock: when the client is
late PulseAudio does not wait, it emits silence to keep its own timeline. So the
39.3 percent silence in the take-2 capture was never audio that went missing, it
was silence PulseAudio invented -- which is why PULSE_LATENCY_MSEC gave a
non-monotonic curve and never won. The instrument was wrong, not mistuned.
ALSA s file plugin has no clock; it tees exactly what the client writes, so a
slow producer yields a shorter file rather than a gap-riddled one. Control with
six distinct tones: 12.000 s against a 12.000 s source, 0.00 percent silence,
zero gaps, no duplicate channels. Channel order comes out as ALSA s
FL FR BL BR FC LFE rather than WAV s FL FR FC LFE BL BR -- deterministic and
invertible, not data loss.
Three configuration traps recorded in the order they bite: ALSA_CONFIG_PATH
replaces the whole config so the stock one must be included; but WITH that
include a pcm.!default override silently does not take, in either the inline or
the alias form, so the slave must be declared with an inline plugin type and no
include; and a pipe to head SIGPIPEs the producer before it writes, which looks
exactly like a broken config.
And the limit the proposer honestly flagged, now measured: a bare file tee is not
enough for Xenia, because its ALSA writer thread pads silence whenever the ring
buffer is empty (alsa_audio_driver.cc:359). Against a device that never blocks it
free-ran at about 250x real time -- 7.34 GB, 12746 s of nominal audio, in 50 s of
wall clock, nearly all driver-generated silence. Killed and deleted; it would
have filled the disk.
The configuration that satisfies both constraints is a tee in FRONT of a paced
slave: type file with slave.pcm { type pulse }. The file plugin captures what the
client writes and the slave supplies the clock, so the wall-clock silence
insertion happens downstream of the capture point. Control through that exact
config: 12.000 s, 0.00 percent silence, zero gaps.
Consequences for verification: short file becomes the failure mode, so a capture
check needs an expected-duration test alongside silence and gap rate, and a
runaway guard is not optional.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
d75b3a752d |
re: the buffer/dropout relationship is not monotonic, and a gap-rate bar misses it
Extends the latency finding with a third point, and it changes the advice. xenia default (~5.3 ms) 347.5 s 39.3 percent silence 30.5 gaps/s 3.94 ms median PULSE_LATENCY_MSEC=200 88.0 s 15.6 percent silence 3.5 gaps/s 37.33 ms median PULSE_LATENCY_MSEC=500 87.9 s 50.1 percent silence 1.3 gaps/s 346.67 ms median 200 ms is 2.5x better than the default; 500 ms is worse than either. Raising the buffer keeps cutting the gap RATE while total silence bottoms out at 200 ms and then doubles, because an over-large buffer starves in a few enormous holes rather than many small ones. That is also a warning about the metric. The port s check-capture bar is 20 gaps/s, derived from sound controls -- starved 32.9, genuine music bed 3.3, voice track 0.03. The 500 ms file scores 1.3 gaps/s, better than a real music bed, while being 50 percent silence: a gap-rate test alone would pass the worst capture of the three. It needs a total-silence companion. Same shape as the defect that made a per-channel level table useless -- one number that cannot see the failure mode next door. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
76d19f8551 |
re: the capture dropouts are largely a client-buffer size, not the guest running slow
Withdraws my conclusion that the monitor-sink capture route cannot be fixed by configuration, and with it the claim that only an in-emulator tap would work. The container has no audio hardware -- no /proc/asound/cards, no /dev/snd, no asound.conf -- so PulseAudio s stock default.pa module-always-sink supplies a null sink, whose whole purpose is to exist when there is no device. A null sink has no hardware clock: it is timer-driven, and anything the client fails to write in time becomes silence in the monitor. That much was right. What was wrong was inferring from it that the holes mean the guest runs below real time. The alternative was never tested: xenia asks SDL for channel_samples_ = 256, which is 5.33 ms at 6 channels, and daemon.conf here is stock with no fragment tuning. PULSE_LATENCY_MSEC overrides what SDL s PulseAudio backend requests. Measured, same title and sink and parec invocation: xenia default (~5.3 ms) 347.5 s 39.3 percent silence 30.5 gaps/s PULSE_LATENCY_MSEC=200 88.0 s 15.6 percent silence 3.5 gaps/s An 8.7x reduction from one environment variable. Against the port s controls -- starved 32.9 gaps/s, genuine music bed 3.3, voice track 0.03, bar at 20 -- the default is squarely starved and 200 ms lands at the level of real content. Not yet a clean bill of health: the runs are not like-for-like at 88 s against 347 s, and the short one covers the splash logos where silence is real. What is established is direction and scale. The consequence that matters is that the capture route should be retried at raised latency before anyone spends a session on a Canary rebuild. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
3d4310bc05 |
handoff: tell the port the settle-time numbers carry an unmeasured real-time factor
The pulse-period argument for trusting the settle-time run is withdrawn, and the port authors from those numbers so it belongs on the page they read. The plate delay survives because it agrees with three independent prior readings; the menu build-in and B-to-title are anchored by nothing, so a few per cent of emulator slowdown sits inside them undetected. That is a second, independent reason to treat those two as provisional beyond their being one-run figures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
52a2eae4bf |
re: withdraw the pulse-period argument, and the shared WAV declares itself empty
Two corrections to my own recent work, both prompted by the port checking it. First, the settle-time page argued the plate delay discrepancy was an instrument artefact on two legs, and one of them is withdrawn. It said the plate pulse period acts as an internal clock for presentation rate and measured 2.369 s against the corpus s 2.3. That estimate rests on ONE interval between two distinct troughs at a 125 ms sample interval -- uncertainty 0.177 s or 6.7 percent -- and trough-picking on a noisy plateau is fragile enough that re-running it gives 2.628 s, because an adjacent local minimum had been counted as a separate trough. Against the corpus s 2.24 that is +17.3 percent, about two sigma. So the pulse period does not show the run at normal speed; it is too weak to show anything, and cannot resolve a real-time factor below about 7 percent. The conclusion survives on the other leg, which is the sound one: the content-measured 2.247 s agrees with three independent prior readings (2.13 / 2.132 / 2.138), and both its landmarks are sharp content transitions rather than a trough on a plateau. A 17 percent slowdown would have put it at 2.49 s. What that leaves open matters because the port authors from these numbers: the run carries an unmeasured real-time factor under about 7 percent. The plate delay is anchored by agreement with prior runs; the menu build-in and B-to-title are anchored by nothing, so that is a second reason to treat them as provisional. Second, the shared capture is worse than truncated: parec writes the WAV header with zero sizes and patches them on clean exit, so the mid-write copy has RIFF size 8 and data size 0 against 183 MB of actual bytes. Python s wave module refuses to open it; ffmpeg and ffprobe recover by scanning and report a plausible duration, which is exactly why it went unnoticed -- the lenient reader hid it. Also corrects the attribution of the starvation numbers: 39.3 percent and 16680453 frames were measured on the finished local recording, not on the shared artefact. The port measured the shared copy and got 35.6 percent and 15289876 frames, with burst and gap medians agreeing to 0.1 ms. The diagnosis is unaffected but a number must say which artefact it came from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
64b30969d5 |
notes: build-canary points at a source root that does not exist here
Recorded as a blocker rather than worked around, because it changes what the
next session can plan.
The faithful-capture route is an internal tap at SDLAudioDriver::SubmitFrame,
which receives exactly frame_size_ bytes of the guest s own frame in guest order
with no wall clock in the loop. A cvar-gated WAV writer there would record what
the guest PRODUCED rather than what a device CONSUMED, so it would be gap-free
however slowly the emulator runs -- which is precisely the defect that made both
ADV captures unusable.
The change is small. The build is not. build-canary builds
${PROJECT_DIR:-/work}/xenia-canary, which does not exist in this container; the
source is at /canary. The warm 235 MB tree at /sylph-home/re/canary-build is
configured with CMAKE_HOME_DIRECTORY=/work/xenia-canary, also missing, and its
build-Release.ninja carries no per-file rules -- it re-runs CMake first, and that
reconfigure fails on the absent root. So any Canary change is a full reconfigure
against /canary plus a full compile, at SYLPH_JOBS=4 on a box sitting at about
700 MB free with a documented history of full-parallel builds OOM-killing the
host.
Not attempted: that is a whole session s risk for one probe, and the next session
should decide with the cost in front of it rather than discover it halfway
through.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
03c70458ad |
re: withdraw a wrong explanation of the BGM_001 duration gap
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 |
||
|
sylph-decoder
|
68b8f8db7f |
re: take 2 is also unusable -- the sink is starved, 39.3 percent digital silence
The port could not find the movie bed or the cutscene voice in take 2 either, this time with a correlator they had rebuilt and calibrated in both directions after retracting the first one. Their negative stands. They named two readings: the capture path is still losing the guest s mix, or the guest is not emitting these sources -- and flagged the second as landing on them hard, because if the game never plays the .wmv s WMA track the port s intro audio has been wrong since P4. It is the first, and take 2 says so on its face: digital silence on all six channels 6557892 / 16680453 = 39.3 percent non-silent runs 10595, median 13.60 ms, longest 1.19 s silent runs 10596, median 3.94 ms burst+gap period about 17.5 ms, 57 Hz, duty cycle 60.7 percent The recording is chopped into 13 ms fragments separated by 4 ms holes, ten thousand times over -- a starved sink, PulseAudio filling underruns with silence. That destroys envelope correlation by construction, since the envelope is dominated by a 57 Hz chop unrelated to the content. The file s strongest periodicity is 5.2 s rather than BGM_102 s 37.487 s loop; the estimator was controlled first, recovering a synthetic 37.487 s loop as 37.480 and scoring non-repeating noise at 0.019. So the port s alarming hypothesis is NOT supported. Nothing here says the game fails to play the movie s audio; it says this capture cannot answer either way. A monitor sink cannot fix it: parec reads a monitor that advances at wall clock and substitutes silence, so every moment the emulator runs below real time is a hole and the timebase is warped non-uniformly. The route that would work is an internal tap at SDLAudioDriver::SubmitFrame, which sees every frame the guest produces in guest order with no wall clock -- same shape as xma_param_probe, additive and default-off. Not attempted this iteration. Also corrects a provenance number I got wrong: I told the port take 2 was 253.3 s when the shared file is 318.5 and the full recording 349. I read ffprobe while the recorder was still writing and copied the file before it finished, so the shared artefact is itself a truncation. Corrected provenance: movie 10-251, title 262-318, back to movie at 329 -- meaning the file includes the title screen, contrary to what I told them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
c479d59f52 |
handoff: deliver the BGM_102 identification and the header-derived durations
States the identification, the caution that it does NOT establish which screen BGM_102 belongs to, and the one thing the port can use today: BGM durations from the corrected XMA1 PsuedoBytesPerSec with no decoder. Flags that those durations include trailing silence -- BGM_001 reads 173.821 declared against 167.663 decoded, a gap matching the 6.15 s of silence this page already records -- so a menu loop point must use the decoded figure. Also records that a refutation attempt on this page s own BGM_103 wave sizes failed: both match the disc exactly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
8340cc9b00 |
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
|
a4c05bb96b |
re: the capture recipe that passes, and a five-stream observation it turned up
Take 2 of the ADV audio capture verified with the port s independent tools/port/check-capture -- six distinct channel MD5s, PASS -- run before sharing and deliberately using their tool rather than the hand that made the file. Records the recipe: sink channel_map set equal to Canary s own stream map and the same map passed to parec, so PulseAudio does no remapping; both of run-canary s mutes off; recorder started before the emulator so WAV t=0 precedes process launch; and a screenshot every ~11 s keyed to the recording s own clock. That last pair is what makes it self-checking, and both were the port s asks. Classified against the committed references, this run reads movie/other for t=10..251 and then title_noplate at t=262 (r=+0.998) and title_plate at 277/289 -- so the 253 s of audio sits wholly inside the movie with the title arriving just after. A miss is now diagnosable instead of ambiguous, which is the whole difference from take 1. Still the full mix: movie WMA bed plus voice, nothing at this boundary separates them. Also records something unexplained that the run turned up: the probe logged FIVE distinct XMA byte_size values, not three -- ADV s 1294336 / 1118208 / 1171456 plus 1150976 and 1269760. The extra pair belongs to some other cue, is not BGM_103 s two waves, and a pair is the shape bgm-two-stems documents for music banks. Untested. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
cfcc6d90a2 |
re: a per-channel level check is blind to remap corruption, by construction
The port made this point while building a checker for the channel-map trap, and it refutes a sentence in my own write-up. In the known-bad control all six channels report a peak of -18.063656 dB, identical to six decimals, while the file contains three duplicate pairs. Equal tone amplitudes make the peak table uniform however the channels are permuted or duplicated; on real content the peaks simply differ from one another, which looks equally healthy. The table is uninformative either way. So "the WAV has plausible per-channel levels" was not weak evidence that a capture was sound, it was none, and this page implied otherwise. The per-channel peak table is the natural thing to eyeball after a capture and it cannot see this failure at all. What detects it is hashing each channel. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
7c16bec4cc |
re: a 6-channel capture scrambles and duplicates channels unless the maps match
The ADV audio capture I shared with the port is withdrawn as evidence. They
could not match it against anything -- the movie bed, any of the three voice
streams, BGM_103, S00A -- with best-vs-runner-up margins of 0.001 to 0.016
everywhere, and they controlled that three ways before saying so. They also
noticed capture channels 3 and 6 were byte-identical.
That duplicate pair reproduces without the emulator, and it is my capture chain.
Six channels each carrying a different tone, played to the null sink and
recorded from its monitor with the same parec invocation:
sink map NOT matching the client (the original setup)
expected 400 800 200 1600 3200 6400
captured 400 3200 200 800 800 200 ch2 == ch5 byte-identical
sink map made identical to Canary s stream map, and passed to parec too
captured 400 800 200 1600 3200 6400 no duplicates -- CONTROL PASSED
PulseAudio remaps when the maps differ, and a 6-channel remap silently drops
channels and duplicates others. No error, no warning; the WAV has the right
length, channel count and plausible per-channel levels.
Withdrawn with it: "all six channels carry signal", and the observation that
non-zero surround and LFE weakly supported the 5.1 reading of a voice cue s
three streams. The port said a duplicated channel is not an independent one and
they were right before this control existed.
Unaffected: the three-XMA-context concurrency result, which is read from the
emulator s own log rather than the audio path, on two independent boots.
The control needed no emulator, no disc and thirty seconds. It was not run, an
artefact was published, and the person who found the defect was the one who
could not see the instrument.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
68aa19283d |
notes: run-canary is silent TWICE over, and the 6-channel stream is a red herring
Completes an entry committed an hour ago that was incomplete, which is worse than absent because it looked authoritative. Fixing SDL_AUDIODRIVER alone still records silence: run-canary also passes --mute=true on its own command line (line 98). With the driver fixed and the mute left alone, Canary attaches a healthy 6-channel stream, holds it at 100 percent volume, reports Corked: no, and emits nothing. Both layers have to go, and "$@" is last so --mute=false on the caller s side wins. Also records that parec defaults to stereo/44.1 kHz and will resample a 6-channel monitor without saying so -- the first successful-looking capture came back 2ch 44100 from a 6ch sink. And a red herring I nearly published as a finding. pactl shows Canary s stream as float32le 6ch 48000Hz with a full 5.1 channel map, which reads as the guest requesting 5.1 and would have been strong support for the hypothesis that a voice cue s three streams are 5.1 channel pairs. It is not evidence about the game at all: AudioDriver::kFrameChannelsDefault is a hardcoded 6, and the code path actually used, SDLAudioSystem::CreateDriver(index, semaphore, &driver), constructs SDLAudioDriver(semaphore) taking every default. The format is Xenia s; only the content of those six channels is the guest s. That is the same failure this corpus recorded in METHOD earlier today -- the specific observation and the general rule reading identically -- caught this time before it was written down rather than after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
cb612a82ff |
notes: run-canary is silent by default, which records perfect silence
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
|
||
|
sylph-decoder
|
4d2482816d |
handoff: deliver the concurrent-streams refutation to the page the port reads
The finding landed in docs/re/ in the previous commit; an answer not reachable from HANDOFF is not delivered. States plainly that "take one stream" was mine, that the port implemented it, and that it is withdrawn -- together with the caution that summing is not thereby right, because an equal-gain 1/n sum of channel pairs is not a downmix and the port s measured 6.02 dB loss was real. Neither rule is established, so the manifest should say the value is authored. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
0e03e7496e |
re: the three streams of a voice cue are decoded CONCURRENTLY, not alternatives
Refutes a framing of mine that two documents and the port s exporter were built on, so it is a new page rather than an edit. voice-region-leading-chunk.md read a long cue s three streams as three presentations of one take, and from that came the instruction "take one stream, do not sum", which the port implemented. The open question was which presentation the game plays. It has no answer. Booted with --xma_param_probe=true, the cvar whose own comment says it is keyed to reveal which sub-wave of a movie s .slb the game actually decodes. The guest opens three XMA contexts and decodes all three concurrently: ctx=0 packets=632 byte_size=1294336 ch=2 48000 ADV stream 1 ctx=1 packets=546 byte_size=1118208 ch=2 48000 ADV stream 2 ctx=2 packets=572 byte_size=1171456 ch=2 48000 ADV stream 3 Byte-exact against the three streams payloads taken independently off the disc (RIFF size minus 60). Only these three contexts appear in the run. So a consumer that picks one discards two thirds of what the game mixes. Both "three presentations of one take" and "take one stream" are withdrawn -- and the previous behaviour is not thereby right either, because an equal-gain 1/n sum of channel pairs is not a downmix and the port s measured 6.02 dB loss was real. Neither rule is established; a consumer is authoring. Three concurrent stereo streams is six channels and N stereo streams is how XMA carries multichannel on the 360, which would also explain the 1-or-3-never-2 span census. Recorded as a hypothesis, not a result: all three fmt chunks declare ChannelMask 0x0002 identically, which is not what distinct channel roles should look like. Everything byte-level survives: the leading chunk being stream 1 clipped by our own guard, the 70 + 8 + 17 decomposition, the bank-header discriminator. Reach: one cue, one boot. That 28 cues are 3-stream is decoded; that all three decode concurrently is measured on ADV alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
aad050cb4a |
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
|
877c028f54 |
method: the specific observation and the general rule read identically
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
|
||
|
sylph-decoder
|
7a0e18889f |
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
|
4bd4779f8b |
re: settle_time measured -- the title is drawn at 2 s, not at rest.t s 4.18
The port s boot sequencer paces every screen off rest.t, which is the last hold keyframe rather than when a screen arrives. Measured on one cold boot: the container had no Xenia storage root at all, so this is a fresh profile with no shader cache, the slowest case. title build-in (first ink -> art fully drawn) 0.23 s title settled -> PRESS A plate on 2.247 s (disc declares 120 units) plate pulse period ~2.37 s main menu build-in 0.531 s B -> title 0.482 s A -> menu 3.763 s DO NOT AUTHOR, see below The title s rest.t is 251 units = 4.183 s and its art is finished at about 2 s, so a sequencer pacing off rest.t holds it roughly twice as long as the game does. Instrument controlled before the run: 9/9 on the content classifier including the movie-frame and difficulty-screen negatives, 4/4 on the plate detector; the run sampled 7.99 fps against a requested 8 with an independent one-shot grab cross-checking every 20 s. Records a refutation attempt of mine that FAILED. The probe s own marks gave a plate delay of 3.203 s against the corpus s 2.13 s, which on a cold-cache boot looked like a real effect. It was the instrument: the plate pulse period is an internal clock for presentation rate and measures 2.369 s here against the corpus s 2.3, so the run is not slowed, and re-measuring from content gives 2.247 s. The probe s title_static mark fires during the crossfade out of the attract movie, before the wordmark has drawn -- glyph was still 0 when it fired. Also a third independent reproduction of the A-path load stall: 13 frames, 1.53 s, surface mean 26.631 against the earlier 14/1.53 and 12/1.39 at 26.626. This boot had no shader cache, so it is not a warm-cache artefact. Noted that the earlier pair agreed to six decimals and mine agrees to three. Reach: one run. The menu build-in and B->title rest on it alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
82281df804 |
method: the plate glyph counter false-positives on the attract movie by 13x
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 |
||
|
sylph-decoder
|
ff715938f5 |
re: withdraw a stream-selection recommendation that contradicted itself
The port implemented "take the highest-rate stream" and reported that on ADV it selects the QUIETER presentation -- chunk 2, 1171516 B at -8.3 dBFS, over chunk 1, 1118268 B at 0.0. They were right to flag it rather than accept it. My sentence was "the highest-rate, highest-gain one is chunk 1". Those two criteria do not select the same stream and the sentence should never have joined them; the parenthetical named chunk 1 while the rule named chunk 2. Withdrawn. What the header does decode, read off the bytes: the fmt chunk is a 32-byte XMAWAVEFORMAT, little-endian, and +0x20 is a declared PsuedoBytesPerSec -- 8142 and 8530 on ADV s two presentations, agreeing with the computed rates to 0.02 percent, with 48000 Hz at +0x24. So the rate is decoded rather than inferred. What it does not decode: wEncodeOptions (0x10d6), channel count and channel mask are byte-identical across the presentations. Nothing in the header ranks them, so stream selection stays an authored choice and the port must know it is authoring. Settleable in one emulator run -- a capture of the intro with the dialogue audible says which level the game plays -- and not yet done. Also records that sylpheed-cli audio info is misaligned for XMA1: its "16 channels / 4310 Hz / 2-bit" is wBitsPerSample, wEncodeOptions and the channel fields read at the wrong offsets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
801062c933 |
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
|
06a1779b19 |
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 |
||
|
sylph-decoder
|
7e12a3b1f9 |
re: the voice-region third chunk is a different structure from the BGM one
The port hit a 2+1 chunk signature on a resolved movie-voice region and asked
whether the bank-header explanation that closed HANDOFF Q10 also covers it,
rather than assuming it. It does not, and the discriminator is mechanical.
Disc-wide over the 95 English movie-voice regions the manifest binds:
78 open with a bank header -- bank_header_len fires, 10240 B = 5 packets
exactly, every time. That is the BGM case.
17 open with a leading headerless stream -- bank_header_len is None, and all
17 have length congruent to 1392 mod 2048, the disc s own derived data
offset. No other residue occurs.
0 begin at a RIFF.
Counting chunks does not discriminate: 8 bank-header regions also yield three
chunks. slb.rs already predicted this in its own doc comment -- the header
signature has "zero false positives on the 7993 mid-bank windows, where the
leading region IS real" -- and a voice region is a mid-bank window by
construction.
Also tested the obvious defence of dropping the leading chunk, that it is the
predecessor cue s audio: 0 of 17 leading spans lie inside any other resolved
region, 0.0 percent on every one. The test finds overlaps where they exist (16
overlapping pairs among the regions, 60 exactly-adjacent boundaries, 73 of 78
bank-header regions starting where another ends), so the zero is not the
instrument.
Left open, with reach: the census covers movie-voice regions only, and the same
stream carries the in-mission VOICE_D_* cues, which are not enumerated -- the
leading bytes plausibly belong to one of those. Could not be settled by
listening: no XMA1 decoder in this container, and sylpheed-cli audio info
reports these chunks as 16 channels / 4310 Hz / 2-bit, which is visibly wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
cdbf752311 |
re: a cross-reference kept recommending a route the cited page had killed
`menu-navigation-semantics.md` advertised "the cheap way to finish this": read 0x828A690C as a live screen id and 0x828F38AC as the cursor, under --gpu=null with no screenshots. `menu-state-in-memory.md` withdrew exactly that identity ON THE SAME DAY it was published -- three back presses send the "cursor" 36 -> 38 -> 40 -> 41, and a cursor returns when you go back. They are monotonic counters; the cross-run agreement is the same key sequence producing the same count. The recommendation stood for three days after the page it cited had killed it, and either document would have been believed on its own. Marked withdrawn where it was recommended, with what the words ARE still good for (did the game react?) and the consequence: a measured button->GamePart-id binding stays unfinished because no screen enum has been located. Also delivers Q4 to HANDOFF in the shape the port asked for -- exactly one main-menu button opens a GP_TITLE entry (EXTRAS -> entry 6/9); the other four leave the archive. That was measured on 2026-08-28 and was reachable only from docs/re/, which the protocol counts as undelivered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
202a512a12 |
re: a refutation attempt that failed -- EXTRAS really is a three-button screen
The port reported GP_TITLE entries 6/9 as a three-button submenu. This page and HANDOFF call 6/9 EXTRAS and never recorded a button count, and 18 elements looked like too many for three buttons, so I challenged it -- from the count, without listing the elements. Wrong. `screen info --all --build 6` shows ptbtn11/12/13 among fifteen frame, title, background and effect layers, and entry 9 is identical. Both things are true: 6/9 are EXTRAS (our composite correlates +0.944 whole-frame with the committed live-extras.png) and EXTRAS is a three-button screen. The port established the button count; the corpus did not have it. Recorded per the adversarial duty, which is worth nothing if only the successful challenges get written down. The retraction has gone to the port as well. Also checked in the same pass, and it constrains Q2: entries 5 and 8 have identical element lists and identical button placements, as do 6 and 9. The EN/JP difference lives in the baked sprite pixels, so no layout field will ever separate the members of either pair -- that needs the sprite images or a capture, and the "English is the first half of the data segment" rule stays a heuristic rather than something a field will replace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
10a57dcdd9 |
handoff: say which index space a build number is in -- 10/11 meant two different screens
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 |
||
|
sylph-decoder
|
ae42f7f850 |
re: the paint-order tie-break costs the port zero pixels, not 24 pairs
The census bounded WHERE a wrong tie-break could show and said outright that nobody had measured how many of those pairs change a pixel. Measured. `compose_with_order` renders a bundle in a caller-supplied order; the new example renders each screen twice, once derived and once with one tied pair swapped, and diffs. Same-key elements are contiguous under a stable sort on (key, i), so a swap paints nothing else in between. Controlled per entry: swapping an OVERLAPPING pair with DIFFERENT keys moves 36 305 to 771 479 px (max delta 254). Where no such pair is drawn the output says so rather than reporting an uninterpretable zero. * EXTRAS (entries 6/9) and the main menu (5/8): 0 px. The tied ptframe pairs ink ~3 600 px each and share NONE of them -- the 102x132 rect overlap was an artefact of approximating an element as pivot x 2. Blend-independent. * Across all 31 drawable overlapping tied pairs in GP_TITLE, the largest change any of them makes to any channel is 3/255. * Withdrawn: "a wrong tie-break can be wrong by a whole layer". That rested on ptlogo_back2eff5 geometrically containing two other glows. Rendered, the swap moves 6 390 px by max delta 2. Containment is not occlusion when the container is a near-transparent glow, and nobody had rendered it before asserting it. Reach: this measures our compositor's sensitivity to order, not the game's. The zero-shared-ink results hold under any per-pixel blend; the delta<=3 figures assume ours. 13 disc-gated ui_paint_order_disc tests and 114 lib tests pass unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |