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

port: check-capture passed a file that was 36% holes -- it now catches starvation

Browse Source 
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
This commit is contained in:
Sylpheed port agent
2026-08-29 16:25:17 +00:00
parent c1113b8cd6
commit ff8d608b1e
3 changed files with 228 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -181,6 +181,75 @@ 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.
## 7. A capture can be starved — right duration, holes punched through it
`check-capture` tests this too, and it is the second way a recording looks
perfect and carries nothing.
**A monitor sink advances at wall-clock rate and substitutes silence whenever the
producer is late.** An emulator running below real time therefore yields a file
of exactly the right duration, the right channel count, no duplicated channels —
chopped into fragments with holes between them, thousands of times over.
Measured independently on the capture that prompted this (the Decoder's numbers
on the untruncated original in brackets):
| | |
|---|---|
| frames silent on **all six** channels | **35.6 %** [39.3 %] |
| alternating runs | **10 482** [10 595] |
| median burst / gap | **13.5 ms / 3.9 ms** [13.6 / 3.9] |
| period | **17.4 ms → 57 Hz** [≈17.5 ms → 57 Hz] |
⚠️ **This destroys envelope correlation by construction.** What dominates the
envelope of such a file is the dropout schedule, not the content — so §6's method
was working correctly on a file that could not carry the signal, and the negative
it produced said nothing about the game.
### Two thresholds I invented were wrong, and the controls caught both
1. **Counting exact-zero frames.** Real audio crosses zero constantly, so a clean
voice track scored **5 947 "gaps" of median 0.0 ms** and was called starved. A
gap is a **run**, not a sample: only runs of ≥ 1 ms count.
2. **Gap count and median length.** A genuine music-and-effects bed has **454
gaps at a median of 1.4 ms** — quiet 16-bit passages really are zero for
milliseconds — so neither statistic separates it from a starved file.
**What does separate them is the RATE**, by an order of magnitude in both
directions:
| | gaps/s | median gap | all-channel silence |
|---|---|---|---|
| the starved capture | **32.9** | 3.9 ms | 35.6 % |
| a real music+SFX bed | **3.3** | 1.4 ms | 1.1 % |
| a voice track, 53 % pauses | **0.03** | — | — |
The bar is **20 gaps/s** — 1.6× below the bad case, 6× above the worst good one,
and set from those controls rather than chosen and then justified.
### 🔴 The monitor-sink route cannot be fixed by configuration
`parec` reads a monitor that advances at wall-clock rate and substitutes silence,
so **every moment the emulator runs below real time is a hole**, and the timebase
is warped non-uniformly — deleting the silences compresses time unevenly rather
than repairing it. 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 in the loop.
⚠️ That needs a Canary rebuild, and the Decoder has costed it: `build-canary`
targets a source root that does not exist in that container, the warm build tree
is configured against the same missing path, so any change is a full reconfigure
plus a full compile on a box with ~700 MB free and a history of parallel builds
OOM-killing the host. **A whole session for one probe** — the human's call, not
an agent's.
### And a header that never got patched
A streaming writer leaves `data` declaring **0 bytes**. `check-capture` says so
and tells you the duration is unverified — which is not pedantry: the file shared
here was **copied while it was still being written**, and the provenance claim
that came with it was wrong about both its length and what it contained.
## 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

63
docs/port/DECISIONS.md
View File

@@ -3370,3 +3370,66 @@ to its declared end. So declared and decoded agree to 12 ms and the trailing
silence is *inside* the decode, not the difference between two methods. The
cross-check stands — better than stated, since it is now three banks rather than
a coincidence — and the sentence explaining it should go.
## Take 2 was starved, my correlator was fine, and `check-capture` was incomplete
The Decoder diagnosed take 2: a **starved** capture. Verified here independently
rather than taken on trust — 35.6 % of frames silent on all six channels, 10 482
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 10 595 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.** ✅ And the alarming reading it produced — *"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.** It is withdrawn as a
concern arising from evidence, and nothing is changed on account of it in either
direction. That matters more than it looks: 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 deliverable: my own checker passed the starved file
`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 too. ⚠️ **Two thresholds I invented were both wrong,
and the controls caught both** — which is the part worth recording:
1. **Counting exact-zero frames.** Real audio crosses zero constantly; a clean
voice track scored 5 947 "gaps" of median 0.0 ms and was called starved. **A
gap is a run, not a sample.** Only runs ≥ 1 ms count.
2. **Gap count and median length.** A genuine music bed shows **454 gaps at a
median of 1.4 ms** — quiet 16-bit passages really are zero for milliseconds —
so neither statistic separates it from a starved file.
What separates them is the **rate**:
| | gaps/s | median gap | all-channel silence |
|---|---|---|---|
| the starved capture | **32.9** | 3.9 ms | 35.6 % |
| a real music+SFX bed | **3.3** | 1.4 ms | 1.1 % |
| a voice track, 53 % pauses | **0.03** | — | — |
Bar set at **20 gaps/s** — 1.6× below the bad case, 6× above the worst good one,
**derived from the controls rather than chosen and then justified.** Controlled
in both directions: real stereo bed PASS, six distinct tones PASS, starved
capture FAIL. It also now reports a `data` chunk declaring 0 bytes, which is what
a file copied while still being written looks like.
### 🔴 The voice channel roles are not obtainable this session
Both capture routes are closed and the Decoder has said so plainly. The monitor
sink is starved **by construction** — it advances at wall-clock rate and
substitutes silence, so every moment the emulator runs slow is a hole, and
deleting the holes warps the timebase rather than repairing it. The route that
works is an internal tap at `SDLAudioDriver::SubmitFrame`, and that needs a
Canary rebuild whose cost they have measured: the build root `build-canary`
targets does not exist in that container, the warm tree is configured against the
same missing path, so it is a full reconfigure and compile on a box with ~700 MB
free and a history of parallel builds OOM-killing the host.
**A whole session for one probe.** That is a human's call and neither agent
should start it mid-loop. Until then the port keeps authoring with the known
recorded: one stream of three, 🔴 in the manifest, the console line and
`authored/audio.json`.