fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: my correlation instrument failed its own control -- the negative had to be re-earned

Browse Source 
Take 2 is a good file: it passes check-capture (I re-ran it rather than cite the
Decoder's run), carries a screen log, and was recorded with the sink's
channel_map set equal to Canary's own.

BEFORE REPORTING A SECOND NEGATIVE I ASKED WHETHER MY METHOD COULD DO THE JOB,
by building a synthetic mix -- the bed plus the three voice streams -- and
hunting the bed inside it. It failed: r=0.415, against the r>0.8 bar my earlier
negatives were judged against.

So the instrument that produced "the capture contains no ADV audio" could not
have found ADV audio in a mix even when it was certainly there. That conclusion
was right -- the Decoder's tone control proved take 1 corrupt independently --
but it was right BY LUCK and I reported it as measurement. The three controls I
was pleased with tested that the method finds a clean signal in a clean
reference, which was never the task.

REBUILT AND CALIBRATED IN BOTH DIRECTIONS. Band-limit so the target dominates,
then judge on LAG and MARGIN rather than absolute r -- r>0.8 is correct
clean-against-clean and meaningless for a component in a mix.

  bed, 40-180 Hz    in a mix containing it   r=0.663  lag 0.0 s   margin +0.111
  bed, 40-180 Hz    against a voice-only mix r=0.262  lag wrong   margin +0.005
  voice, 300-3000   in a mix containing it   r=0.810  lag 0.0 s   margin +0.248
  voice, 300-3000   against the bed alone    r=0.358  lag wrong   margin +0.005

A 20-50x separation in the discriminating statistic. Written up as
AUDIO-VERIFICATION.md section 6, retraction included.

THE NEGATIVE NOW STANDS ON SOMETHING. All six of take 2's channels, against both
targets, sit in the known-absent regime: margins 0.000-0.017, lags scattered from
-72 to +255 s. Take 2 contains neither the movie's WMA bed nor the cutscene
voice.

Two captures, differently configured, the second provably free of the channel-map
fault, with a screen log saying the movie was on screen, and neither carries
either source. Handed back: a capture path still losing the mix, or the guest not
emitting these sources during the movie, and only one side of the wall can tell
those apart. If it is the second it reaches the port directly -- the export's
movie audio comes from the .wmv's WMA track.

Also noted: the message gives 253.3 s, the file is 318.539 s. The screen log
agrees with the file, so it is a mis-stated number, but a length quoted in a
provenance claim should match the artefact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-29 16:15:59 +00:00
parent c346c65568
commit eb45f9320d
4 changed files with 148 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
docs/port/AUDIO-VERIFICATION.md
View File

@@ -181,6 +181,55 @@ And the failure this page already warns about, in a second costume:
`--mute=true`. Fix only the first and Canary attaches a healthy 6-channel stream
at 100 % volume, reports `Corked: no`, and emits a 19 MB WAV of zeroes.
## 6. Finding one component inside a mix — and why §1's method cannot
🔴 **This section begins with a retraction.** Two captures of the game's own
output were analysed with sliding envelope cross-correlation and declared not to
contain the intro's audio. **The instrument was never controlled for the actual
task**, and when it finally was, it failed:
> Can it find the movie's bed inside a synthetic mix of that bed plus the three
> voice streams? **r = 0.415** — below the `r > 0.8` bar those negatives were
> judged against.
The first negative happened to be right (the file was independently proved
corrupt by a tone control). **It was right by luck, and the reasoning behind it
was not supported.** A filter that fails its own known-positive is dead, not
tuneable.
### What was wrong: the threshold, not the idea
`r > 0.8` was calibrated on **clean-against-clean** comparisons, where it is
correct — a transcode against its source scores 1.000. A *component inside a
mix* can never score that, because everything else in the mix is uncorrelated
noise from the component's point of view. Judging one task by the other's bar
guarantees a false negative.
**Judge on the LAG and the MARGIN instead.** A real match lands at the *right*
lag with a clear gap to the runner-up; a false one is a plateau. And **band-limit
first**, so the component you are hunting dominates what you measure.
### The calibration, on a known-present and a known-absent pair
Both bands, both directions, envelope at 0.1 s, minimum 60 s overlap:
| hunting | band | against | *r* | lag | **margin** |
|---|---|---|---|---|---|
| the movie bed | 40–180 Hz | mix containing it | 0.663 | **0.0 s** ✓ | **+0.111** |
| the movie bed | 40–180 Hz | voice-only mix | 0.262 | −31.9 s ✗ | +0.005 |
| voice stream 2 | 300–3000 Hz | mix containing it | 0.810 | **0.0 s** ✓ | **+0.248** |
| voice stream 2 | 300–3000 Hz | the bed alone | 0.358 | −58.4 s ✗ | +0.005 |
**A 20–50× separation in the margin, and the lag is right or absurd.** That is a
decision rule set by controls rather than by tuning until the data agreed —
which is the distinction that matters, and the one the first version of this
method skipped.
⚠️ **Reach.** The known-positive is a *synthetic* mix at equal gains. A real game
mix weights its components differently, so this bounds the method rather than
modelling the real case exactly. It is enough to separate present from absent; it
is not a level measurement.
## What none of this establishes
That it *sounds right*. Every method here shows correspondence to a source, not

72
docs/port/DECISIONS.md
View File

@@ -3240,3 +3240,75 @@ would have failed the cheap check in thirty seconds.
The corrupt file is withdrawn from the exchange (`share drop`), so the next agent
cannot pick it up and repeat the work.
## 🔴 Take 2 is clean, my instrument was not, and the negative had to be re-earned
The Decoder's second capture passes `check-capture` — I re-ran it myself rather
than cite theirs — carries a screen log, and was recorded with the sink's
`channel_map` set equal to Canary's own. It is a good file.
⚠️ **One provenance discrepancy, minor but worth stating:** the message gives
253.3 s; the file is **318.539 s**. The screen log runs to 316 s and is
consistent with the file, so this is a mis-stated number rather than a bad
capture — but a length quoted in a provenance claim should match the artefact.
### The retraction that came out of measuring it
Take 2 also showed no alignment with the bed or the voice streams. Before
reporting a second negative I asked whether the method could do the job at all,
by building a **synthetic mix** — the bed plus the three voice streams — and
hunting the bed inside it.
**It failed. r = 0.415, against the `r > 0.8` bar my earlier negatives were
judged against.**
So the instrument that produced *"the capture contains no ADV audio"* could not
have found ADV audio in a mix even when it was certainly there. That conclusion
was right — the Decoder's tone control proved take 1 corrupt independently — but
**it was right by luck, and I reported it as measurement.** The three controls I
was pleased with tested the wrong things: that the method finds a *clean* signal
in a *clean* reference, which was never the task.
### The rebuilt instrument, calibrated in both directions
Band-limit so the target dominates, then judge on **lag and margin**, not on
absolute *r* — the `r > 0.8` bar is correct clean-against-clean and meaningless
for a component in a mix.
| hunting | band | against | *r* | lag | margin |
|---|---|---|---|---|---|
| the bed | 40–180 Hz | mix containing it | 0.663 | **0.0 s** ✓ | **+0.111** |
| the bed | 40–180 Hz | voice-only mix | 0.262 | wrong ✗ | +0.005 |
| voice stream 2 | 300–3000 Hz | mix containing it | 0.810 | **0.0 s** ✓ | **+0.248** |
| voice stream 2 | 300–3000 Hz | the bed alone | 0.358 | wrong ✗ | +0.005 |
A 20–50× separation in the discriminating statistic. Documented as
`AUDIO-VERIFICATION.md` §6.
### And now the negative, supported
Every one of take 2's six channels, against both targets, sits in the
**known-absent** regime:
| | bed (40–180 Hz) | voice stream 2 (300–3000 Hz) |
|---|---|---|
| margins | +0.000 … +0.014 | +0.001 … +0.017 |
| lags | −58 … +255 s, scattered | −72 … +183 s, scattered |
**Take 2 contains neither the movie's WMA bed nor the cutscene voice**, on an
instrument that demonstrably finds both when they are present.
### What that leaves, and it is not mine to answer
Two captures, differently configured, the second provably free of the channel-map
fault, with a screen log saying the movie was on screen — and **neither carries
either audio source.** That points away from a one-off setup error. The
possibilities I can see are a capture path that still loses the guest's mix, or
the guest not emitting these sources at all during the movie, and **only one side
of that wall can tell them apart.** Handed back with the numbers.
⚠️ **If it is the second, it reaches the port directly**: the export's movie audio
comes from the `.wmv`'s WMA track, and if the game never plays that track, then
`ADV.ogv`'s audio is wrong in a way no amount of transcode fidelity would fix. I
am not asserting that — it is a question about what the game does — but it is the
reason this is worth another boot rather than being written off.