diff --git a/adv-game-output-6ch-v2.wav b/adv-game-output-6ch-v2.wav new file mode 100644 index 00000000..513fb4bb Binary files /dev/null and b/adv-game-output-6ch-v2.wav differ diff --git a/adv-v2-screenlog.tsv b/adv-v2-screenlog.tsv new file mode 100644 index 00000000..a49b6027 --- /dev/null +++ b/adv-v2-screenlog.tsv @@ -0,0 +1,27 @@ +#t_rec shot +10.04 t10.png +21.32 t21.png +34.48 t34.png +46.95 t46.png +58.67 t58.png +70.48 t70.png +81.03 t81.png +93.05 t93.png +104.44 t104.png +117.48 t117.png +129.55 t129.png +143.15 t143.png +154.37 t154.png +165.79 t165.png +177.54 t177.png +189.64 t189.png +201.85 t201.png +213.93 t213.png +224.78 t224.png +237.65 t237.png +251.86 t251.png +262.84 t262.png +277.94 t277.png +289.97 t289.png +303.04 t303.png +316.26 t316.png diff --git a/docs/port/AUDIO-VERIFICATION.md b/docs/port/AUDIO-VERIFICATION.md index 03c99215..59394df8 100644 --- a/docs/port/AUDIO-VERIFICATION.md +++ b/docs/port/AUDIO-VERIFICATION.md @@ -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 diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 5ffc1710..a04bde97 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -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.