hearing-step1-result.md

SHA-256 b45cc3c7d9d024e3488c3b07f76cea721134789f14597afcec1b7dacfd0da061 · download the original

# hearing, step 1: results

run 2026-10-23 05:05 to 05:15 bst, after the rules (`docs/hearing-step1.md`, sha256 `001f8186...`) and the tuning (`docs/hearing-step1-tuned.md`, sha256 `8da4bf4d26967b3e703badcbde02252c6586b745dd1843cca07b72e425af3aab`) were frozen. the code that ran is kept as it was in `~/Code/Foundation-lanes/ears-keep/frozen-0505/`.

## verdicts

1. rebuild: **pass.** every minute file overlapping 01:30 to 02:10, 42 files, 119,943,680 samples, rebuilt from the bets and the misses alone with 0 wrong. the misses carry 18.4 db less than the sound.
2. voices: **not scored.** in 01:30 to 02:10 only 11 stretches passed the voice rule: 8 of them his, none clearly another voice, 3 left out as unsure. the rule needs 10 of each. of his 8, 5 were too thin to sort (under 15 readings 50 ms apart) and 3 went into 2 places.
3. bets break at the gaps between words: **fail.** 1,021 boundaries scored: a boundary beat a moment inside a word 56.6% of the time, the placebo 51.6%, a gap of 5.0 points. it needed 65% and 10 points. memo minutes 5 to 15: 1,015 boundaries, 56.8% against 51.6%. his three talks: 6 boundaries scored, 32 lost to the bug below.

cost: offline, one thread, 1.04 to 1.12% of one core on the kept sound at 48 khz, under the 3%. the live hour is measured once it is wired in and goes below.

## a bug found by the test, and fixed after it

the live bet (recursive least squares in its plain form) lost its shape 4.4 minutes into the kept run: its inner matrix went negative, so from about 01:02 its guesses were wrong, and at 01:34:19, on a stretch of exact zeros, it blew up and gave nothing after. the plain form can't cope with inputs this alike (three neighbouring 10 ms frames are nearly the same). the memo run never blew up but carried the same flaw.

it does not change the verdict: if all 32 lost talk boundaries had been wins, rule 3 would still be at most 58.4%.

fixed after the test: the same learner kept as a square root (qr updates with givens rotations), which can't go negative; and a frame identical to the one before (only exact silence does that) teaches it nothing. new checks: a 20 minute stress of near identical frames (the old learner made 194 wild bets there, the new one none) and minutes of exact silence. `earscheck` 85 passed, 0 failed.

after the fix, for information only (the test data was already seen, so this is not a verdict): no blanks, no restarts, 0.84% of one core; rule 3 at 1,053 boundaries, 56.2% against the placebo's 52.2%, 4.0 points, still a fail. his three talks alone: 38 boundaries, 36.8% against 60.5%.

## what the fail means

the bet one 10 ms step ahead breaks about as often inside a word as between words. in his talking most word gaps are under 100 ms and the sound runs straight through them, so at this layer a gap between words is not an event. the pieces this layer finds are speech sounds, not words. that fits the q76 idea itself: the bottom bet gives pieces, and the layer above bets on sequences of pieces. a word gap is where what comes next stops being predictable, the way babies find words by which sounds follow which. the test asked step 1 to do step 2's job.

so, by the kill rule, this layer's claim is rethought before step 2: step 2 tests word gaps with bets over sequences of pieces, not with the 10 ms bet. the e's and the 10 ms bet stay, since the rebuild passed and step 2 is built on them.

## what else was found on the way

- the borrowed aligner put word starts 135 ms late and ends 45 ms late (measured against loudness on the development minutes, fixed before the test).
- a 40 minute transcript of the kept sound got stuck repeating one line after 01:35; short clips with no carried context fixed it.
- voice places as first built split one voice into a place per stretch; readings 50 ms apart fixed it on the development minutes (97% in one place). on the full 15 minutes of the memo (his voice only) they made 4 places.

## live (wired in 05:21, final form 05:34)

- first live build: the whole mic helper used 7.42% of one core against 2.83% before, so step 1 added 4.6%, over the 3%. the cause was the e finder: c++'s standard complex numbers multiply and divide through slow library calls. the same math in plain arithmetic is about 5 times cheaper (5.01% to 2.36% of an efficiency core offline, all checks unchanged). then the readings were computed once instead of twice.
- final form: 5.38% of one core for the whole helper over a minute, so step 1 adds about 2.5%. memory: 9.1 mb footprint for the whole helper. nothing dropped in any of the closing summaries. the hour's average, 06:15 to 07:15 (the build with the voice low-pass from 06:02): 158.5 s of cpu over 3,600 s, 4.40% of one core for the whole helper against 2.83% before step 1, so step 1 adds about 1.6% over a real hour, under the 3%. footprint after the hour: 9.3 mb.
- a restart at 05:30 killed the helper before it closed its minute file (sigpipe on its closed output). the 36 s file was repaired from its own bytes and checked against the live readings (correlation 0.999); the helper ignores sigpipe now. details in `handoffs/ears-keep.md`.