A real defect in the P4 output, found by the human on ADV.wmv and widened by the
RE agent to the whole disc: the disc ships 28 movies in 5.1 WMA Pro (every
cutscene, INCLUDING both movies this port needs) and 69 already in stereo. A
bare `-ac 2` therefore does two different things and records neither -- stereo
passes through, and 5.1 is folded by ffmpeg's DEFAULT matrix. How loudly
centre-channel dialogue sits against the music is a content decision, and it was
being made by accident and could move under an ffmpeg upgrade.
Now stated: ITU-R BS.775, LFE dropped, normalised by 1/(1+2*sqrt(1/2)) = 0.4142.
It appears in the recorded command, so the manifest determines the output.
MEASURED rather than chosen by taste, and the measurement is the interesting
part: the explicit matrix and ffmpeg's inherited default differ by a residual of
-91 dB -- about one LSB at 16-bit -- with peak and mean agreeing to 0.1 dB. So
ffmpeg's default IS this matrix, and the audio does not change; what changes is
that the manifest now says which matrix. The UNnormalised textbook form was
measured too and clips at 0.0 dBFS, which is why the scaling is there.
The filter is applied only to 6-channel sources, probed per file with ffprobe,
so a stereo source is never run through a matrix referencing channels it lacks.
Also: encode to a temp name and rename on success. ffprobe read a mid-write
.ogv as 33 s against a 137 s source -- no error, no warning, the exact shape of
catastrophic truncation. The filesystem is shared with the RE agent, so that is
a race, not an edge case, and a half-written file must never be visible under
its final name.
tools/verify-video-audio answers the second of the three questions
docs/AUDIO-VERIFICATION.md separates: does GODOT route the audio. An
AudioEffectRecord on the Master bus writes Godot's own mixed output to a WAV
from a headless run, so "no sound card" was never the obstacle I claimed. It
deliberately checks non-silence and level only -- a difference-signal RMS
against the source is inconclusive without cross-correlation alignment and an
agreed downmix, and would produce a confident wrong number.
A framing correction from the human, and it runs through everything I have
written, so it is a retraction rather than a silent edit.
Reborn "was/is just a GUI explorer and extraction CLI for verifying the decoding
of the various files. It may very well be wrong." The oracle is the Xenia Canary
capture and the game.
So verify-screen is a CONSISTENCY check between two decoders that share their
assumptions, plus a regression detector -- not a correctness check, and
agreement in it is not evidence of correctness. Its header now says so, it calls
the CLI the COMPARISON renderer, and DIFFERS means "we moved apart, find out
which of us moved".
The uncomfortable part, recorded because it is the actual failure mode: this
file already contained the sentence "two renderers reading one field through one
decoder agreeing is not evidence that the field is right", written after the
ptframe1 case -- and I then went on quoting 3/255 against sylpheed-cli as though
it meant the port was right. Having the principle written down did not stop me
leaning on the agreement.
Three times both renderers agreed and both were wrong, each caught only by a
capture: pteff05 (menu screens had no background), scale-0 (drawn full size
instead of collapsed), rest() (the menu bracket missing).
Correctness moves to the captures -- nine of them, indexed at
docs/re/captures/ORACLE-CAPTURES.md, covering all five screens in scope. Three
cautions travel with them: not gamma-neutral (there is a floor, don't chase it),
geometry IS sound (a positional disagreement is real), and each is one moment of
a still-animating screen.
verify-screen keeps running over all 16 screens every iteration. It is still
worth having -- total, cheap, and it catches a divergence introduced on the RE
side. It is just not a grade.
Gate: `godot --path port -- --boot --film=/tmp/boot` runs publisher_logo ->
developer_logos (4.65 s) -> title (8.57 s), holding on the title after 13.05 s,
each screen fading in, holding, and fading through black into the next.
verify-screen now covers all 16 screens and passes `--all` to the reference
renderer: the exporter addresses by pak entry index, which is the numbering
`--all` uses, and without it `--build 10` would land on entry 12. The four new
splash bundles come in at max 1-2/255. The three known differences are unchanged.
Also recorded, taken from the RE agent rather than re-derived:
* Focus stays "replace" -- over-vs-instead is unobservable (the focused sprite
covers the base at 100 % of base-visible pixels; the two compositions differ by
RMSE 1.1, under the gamma floor). The port guessed right for the wrong reason.
The real gap is that ptbtn0Nf.rat declares TWO sprites -- a glowing ring, then
the label -- where ptbtn0N.rat declares one. P5's, and the ring's placement is
not decoded, so it will be authored from the capture and marked as such.
* RMSE against captures has a FLOOR: capture ~ 255*(render/255)^g, g ~ 1.49 menu
and EXTRAS, 1.34 title, and it is a ramp the GAME installed, not a capture-path
artefact to subtract. Narrow reach (fitted on mostly-dark patches), so the port
will not extrapolate it and will not apply it to rendered output. It is a
comparison constant, not a rendering one.
* Rotation is escalated to a human and the port has NOT acted. The RE half is
answered -- about the declared pivot, measured -- and it has zero effect on the
five screens at rest.
The reference renderer was a revision behind for three consecutive diff runs and
nothing said so.
After the pin bump, `build-reference-cli` reported success at rev 5414db3 and
`verify-screen` showed main_menu jumping 3/255 -> 72/255. The natural reading was
that the port had regressed. It had not: the port was right and the REFERENCE was
stale. The shared CARGO_TARGET_DIR still held a `sylpheed-cli` built from
8b6dbcf, cargo said "Finished in 0.13s" and left it there. A clean target dir
built a binary resolving ptframe1 to (440,108) t=62; the shared one still said
(620,108) t=16.
The old check -- does `screen list` run -- cannot catch this. A stale binary runs
perfectly.
So: build into `$CARGO_TARGET_DIR/reference-cli/$rev`, keyed by the pin, where a
new revision has no artifacts to reuse. Then verify the binary AGAINST export/:
both come from the same pin, so if the CLI resolves ptframe1's rest differently
from what the exporter wrote, the two halves of the verification are not the same
revision and it fails loudly. It compares the two rather than asserting a
literal, so it stays true when the pin moves again.
docker/bin is baked into the image, so this needs an image rebuild to reach
PATH; until then invoke the repo copy by path.
agrees with the timeline
P2's gate is the buttons sliding in, and `tools/screen-strip` renders the strip
that shows it. But the useful result came out of checking where the animation
settles.
On 8 of 12 screens the settled timeline is BYTE-IDENTICAL to the declared `rest`
pose -- the port walks the keyframes with an authored time unit and arrives, to
the pixel, where the pinned decoders independently say the screen rests. On
`main_menu` the two differ in exactly one region, 400x470 at (440,108): the
bounding box of `ptframe1` and `ptframe2` and nothing else.
`rest` puts both at their first keyframe, off-position and transparent. The
capture of the running game shows them -- the bright circuit bracket around the
menu. Cropping the same region from the capture and from both renders puts the
ring and its elbow trace in the timeline render pixel-aligned with the game's,
and absent from the rest render. Geometry, so it does not depend on the
capture's gamma or on its having been taken with NEW GAME focused.
`ui_layout::rest_plateau` excludes a trailing run of identical keyframes because
it is normally the exit. On an element with NO exit animation the trailing run IS
the hold. The condition that identifies these exactly, with no false positives
here, is "the final untimed keyframe has the same pose as the last timed one" --
six elements, and `rest()` misses all six. Filed in BLOCKED.md for the RE agent:
the decoders are pinned and are not this port's to fix, and `sylpheed-cli screen
render` is missing the bracket too.
Worth saying plainly what this does to P1: the port and the reference agreed on
`main_menu` to 3/255 and BOTH were missing two elements the game draws. Two
renderers reading one field through one decoder agreeing is not evidence the
field is right. BLOCKED.md had already said that about the pivot; here it bit.
The title is NOT settled and P2 does not claim it. `rest` and the timeline
disagree there by 142-247/255, the only live title capture composites the PRESS A
plate over build 4 so it cannot be diffed against the title alone, and both of
the port's modes draw a cyan glow slab the game does not have -- a third problem,
P3's. Recorded as an open question rather than resolved by tuning.
Also reconciled against the RE agent's new work: Q8 is answered -- the SE waves
are located in `Static.slb` (move/confirm/back), which unblocks P6's audio; and
the title's transitions are a lookup by NAME, giving P3/P5 the game's own screen
vocabulary as candidate `goto` targets, marked as the name match it is.
The P1 gate is a pixel comparison, so it needs to be a command rather than a
paragraph. `tools/verify-screen` renders each screen in the manifest both ways
and reports the largest per-channel difference anywhere in the frame.
Both renderers are held to the same inputs on purpose:
* the reference CLI is the one `build-reference-cli` builds from the revision
the exporter is PINNED to -- not `/reborn/target/`, which is a live mount of
the other agent's checkout and moves mid-iteration. A pixel disagreement
against a moving decoder has a free variable in it and proves nothing.
* `--black`, because the screen carries its own background and the CLI's default
dim slate stands in for a 3D scene that is not on this screen.
* `--primitives --animated`, because the port draws every element at rest and
those two flags are what make the CLI draw the same set. NOT `--focus`:
nothing is focused at rest.
The threshold is 3/255 -- what integer-truncating compositing in the CLI and
float rounding on a GPU differ by. Above that is a placement, order or colour
disagreement that needs a reason, and the script says DIFFERS rather than
pretending a wider tolerance is a result.
