The Decoder lost a finding whose only record was a script comment and asked
whether I have the same. Audited every measurement-shaped token in comments
across the exporter, the GDScript and the tools against everything in docs/.
Seven candidates, six were my matcher (thousands separators, ranges written
differently, precision). The findings are all in DECISIONS, including the leaf
comment's capture-measured centres and the 11.5 px residual.
The one real defect is the opposite: check-capture's control table and
AUDIO-VERIFICATION.md had DRIFTED -- 53.3% against 53.2%, twice each, for one
control whose file is gone so neither can be re-measured. They lost a finding to
having one record; I lost a digit to having two with nothing keeping them equal.
Fixed by citing rather than restating.
Also corrects a message: I told them my computation reproduces their published
centres to half a pixel. True, and MODEL against MODEL -- against the capture
this corpus already records 992.0/467.2, an 11.5 px residual. The half-pixel
agreement is two derivations of one model, the correlated-instrument shape I have
been careful about all week and did not apply to my own message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
The Decoder is moving to an ALSA `type file` tee, which writes float32. Read as
s16 that yields a plausible-looking file whose only tell is per-channel peaks
alternating exactly -- the two halves of each float landing in alternate
channels. My parser assumed s16 throughout and would have mis-read it
confidently.
An unreadable format now ends the run at PARTIAL (exit 2) rather than PASS:
channels were checked, starvation was not, and the tool says which. A checker
that claims a check it skipped is the shape of every failure this file documents.
AND THE FIRST VERSION OF THE GUARD WAS TOO STRICT -- it rejected one of this
tool's own controls, a six-tone file `ffprobe` correctly calls pcm_s16le, because
the file is WAVE_FORMAT_EXTENSIBLE (tag 0xFFFE) rather than plain PCM. A format
guard that refuses a legitimate capture is the same defect as one that mis-reads
an illegitimate one, pointing the other way. The check turns on wBitsPerSample,
which is what decides the layout; a float tee is 32-bit and still caught.
Control sweep, now the tool's real specification and all of it runnable here:
real music+SFX bed PASS
voice track, mono, 53% real pauses PASS
six distinct tones, PCM and extensible PASS
bed with 350 ms holes punched in FAIL
the starved capture FAIL
the same tones as float32 PARTIAL
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
The Decoder found a blind spot in the bar I shipped last iteration. Raising the
PulseAudio client buffer keeps cutting the gap RATE while total silence bottoms
out and then doubles -- an over-large buffer starves in a few enormous holes
instead of many small ones. Its 500 ms capture scores 1.3 gaps/s, better than a
genuine music bed at 3.3, while being 50% silence. My 20/s bar passed it.
Same shape as the level table that cannot see a duplicated channel: one number,
blind to the failure next door.
I did not set a bar on their numbers, because I do not hold those files and the
last two bars in this tool were wrong precisely from being invented. Instead I
built a control in that regime -- `bigholes`, a real bed with 350 ms holes
punched in -- and set the rule from four controls I can run:
real music+SFX bed 1.1% silence, 3.3 gaps/s PASS
voice track, mono, pauses 53.2% silence, 0.3 gaps/s PASS
bed with 350 ms holes 46.3% silence, 3.2 gaps/s FAIL
the starved capture 35.6% silence, 30.9 gaps/s FAIL
Rate alone cannot separate rows 2 and 3; silence alone cannot separate 1 and 3.
The pair does: fail when >=10% is silent on every channel AND there is at least
one gap per second. Real audio is either mostly not silent, or silent in a few
long stretches -- not both at once.
AND THE REGIME IT STILL CANNOT JUDGE IS PRINTED RATHER THAN PASSED. High silence
with very few gaps is what a real voice track looks like and what an
over-buffered capture looks like; nothing here separates them, so the tool says
UNJUDGED and tells the reader to check against a known source. Inventing a bar
for a regime with no control in it is how the previous two bars came to be wrong.
A CONTROL THAT DOES NOT EXECUTE IS NOT A CONTROL: the tool returned immediately
for single-channel input, so the mono voice track -- one of the four controls --
was never run through the check it was meant to control. Mono now skips only the
duplicate test.
Also recorded: the Decoder has withdrawn "the monitor-sink route cannot be fixed
by configuration". A ~200 ms client buffer is worth a retry 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_01N7FiFFFwbvG2uxdcEh8HyF
The Decoder diagnosed take 2 as a STARVED capture and I verified it here rather
than take it on trust: 35.6% of frames silent on all six channels, 10482
alternating runs, median burst 13.5 ms and gap 3.9 ms, a 17.4 ms period at 57 Hz.
Their untruncated original reads 39.3% and 10595 runs; the difference is exactly
the truncation and every other number agrees.
So my rebuilt correlator was working correctly on a file that could not carry the
signal. The alarming reading it produced -- that the game may not play the .wmv's
WMA track, so ADV.ogv's audio has been wrong since P4 -- is NOT SUPPORTED by this
capture and is not refuted either. Withdrawn as a concern arising from evidence,
with nothing changed in either direction. It was the most expensive-to-act-on
hypothesis in the port and it came from a file that could not speak to it.
THE REAL DEFECT WAS MINE: `check-capture` tested only for duplicated channels, so
it cleared a recording that was 36% holes. A provenance check that passes the
artefact it was built in response to is not a check.
It now measures starvation, and TWO THRESHOLDS I INVENTED WERE BOTH WRONG:
counting exact-zero frames -- real audio crosses zero constantly, so a clean
voice track scored 5947 "gaps" of median 0.0 ms and was called starved. A gap
is a RUN, not a sample; only runs over 1 ms count.
gap count and median length -- a genuine music bed shows 454 gaps at a median
of 1.4 ms, because quiet 16-bit passages really are zero for milliseconds.
What separates them is the RATE: 32.9 gaps/s starved, 3.3 for a real bed, 0.03
for a voice track that is 53% pauses. Bar at 20/s, derived from those controls
rather than chosen and then justified. Controlled both directions: real stereo
bed PASS, six distinct tones PASS, starved capture FAIL. It also reports a `data`
chunk declaring 0 bytes -- what a file copied mid-write looks like, which is what
happened.
VOICE CHANNEL ROLES ARE NOT OBTAINABLE THIS SESSION. Both routes closed: the
monitor sink is starved by construction, and the internal tap at
SDLAudioDriver::SubmitFrame needs a Canary rebuild the Decoder has costed at a
whole session. That is the human's call, not an agent's. The port keeps authoring
with the known recorded.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
The 6-channel capture I spent an iteration refuting was corrupt, and the Decoder
found the cause: PulseAudio remapping between two mismatched channel maps, where
a 6-channel remap SILENTLY DROPS AND DUPLICATES. Its control -- six channels, six
tones, same sink, same parec -- came back 400/3200/200/800/800/200 for an input
of 400/800/200/1600/3200/6400. Two source channels gone entirely.
So the negative was right, and the byte-identical pair I reported was the thread
that unravelled it. Worth recording precisely, because it nearly went unreported:
it began as an idle look at two channels whose peak AND RMS matched to six
decimals, and it only became evidence because a coincidence at six decimals is
cheaper to hash than to explain.
`tools/port/check-capture` makes that check one command -- split the file, hash
every channel, fail on any duplicate pair -- and AUDIO-VERIFICATION.md gains a
section 5 saying to run it FIRST, every time, plus the two conditions the same
incident produced: start the recorder before the process, and log what was on
screen against the recording's own clock so a miss is diagnosable.
Controlled both directions, because a checker nobody controlled is what this
incident is about: six distinct tones PASS; the remap's own output pattern FAILS
naming all four pairs; the corrupt capture FAILS on ch2 == ch5.
THE KNOWN-BAD CONTROL IS THE POINT. All six of its channels report a peak of
-18.063656 dB, identical to six decimals, while containing three duplicate pairs.
A level check cannot see this failure. That is why the tool hashes rather than
measures, and why the corrupt capture's "plausible per-channel levels" were never
evidence. The tool says of itself that it is necessary, not sufficient.
Withdrawn with the file, both the Decoder's: "all six channels carry signal", and
the non-zero-surround observation offered as weak support for 5.1. Unaffected:
the three-XMA-context concurrency result, read from the emulator's log rather
than the audio path, on two independent boots.
The corrupt file is dropped from the exchange so the next agent cannot pick it up
and repeat the work. Nothing in the export changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
