Direct cause of 10 of the 11 misses in #63's auto-cut pass, and the reason a human ear still beats the loop on this material.
The defect
The sweep transcribes each window as a whole and scans that text for repeated runs. A whole-window pass averages a repeat into one clean reading, which is the exact failure #44 was built to escape. It reappears one level down, inside the instrument #44 made mandatory.
Measured on the annotated render (run9.wav, 374.9s): where the audio says
abrimos la guia para vincular, abrimos la opcion para vincular
the sweep's own window text at 48s reads "...abrim". No finding is emitted, so nothing downstream can act.
Cross-checked against a human's list of 27 defects in that render: of the repetitions he named, 4 of 7 checked never appear in the sweep's output at all (1:00 "abrimos la guia/opcion", 2:39 "es esta, es esta", 4:29 "configurar una vps" x2). These are trivially visible in any word-level transcript.
Why it matters now
#63's deterministic pass cuts exact repeats the sweep reports. It caught 9 of 20 deterministic defects, and ten of the eleven misses are repeats that were never reported. Fixing this should take that pass from 9 to roughly 19 with no change to the pass itself.
Direction
Use word-level timings rather than the window's flattened text. trx transcribe --words already produces them and transcribeWindowWords already wraps it in transcribe-window.ts; say --transcribe --words uses that path today. A repeat becomes a comparison over word sequences carrying their own timestamps, which is also what an auto-cut needs to place a boundary, and it removes the dependency on a paragraph of prose surviving an averaging decoder.
Related leak found while implementing #63: mergeRepeats folds findStackedOpeners results past the content-word floor, so a zero-content-word opener like "te va" reaches repeatedPhrases. Worth fixing in the same pass.
Related: #44 (the gate this instrument backs), #57 (the content-word floor), #63 (the pass that consumes its findings).
Direct cause of 10 of the 11 misses in #63's auto-cut pass, and the reason a human ear still beats the loop on this material.
The defect
The sweep transcribes each window as a whole and scans that text for repeated runs. A whole-window pass averages a repeat into one clean reading, which is the exact failure #44 was built to escape. It reappears one level down, inside the instrument #44 made mandatory.
Measured on the annotated render (
run9.wav, 374.9s): where the audio saysthe sweep's own window text at 48s reads
"...abrim". No finding is emitted, so nothing downstream can act.Cross-checked against a human's list of 27 defects in that render: of the repetitions he named, 4 of 7 checked never appear in the sweep's output at all (1:00 "abrimos la guia/opcion", 2:39 "es esta, es esta", 4:29 "configurar una vps" x2). These are trivially visible in any word-level transcript.
Why it matters now
#63's deterministic pass cuts exact repeats the sweep reports. It caught 9 of 20 deterministic defects, and ten of the eleven misses are repeats that were never reported. Fixing this should take that pass from 9 to roughly 19 with no change to the pass itself.
Direction
Use word-level timings rather than the window's flattened text.
trx transcribe --wordsalready produces them andtranscribeWindowWordsalready wraps it intranscribe-window.ts;say --transcribe --wordsuses that path today. A repeat becomes a comparison over word sequences carrying their own timestamps, which is also what an auto-cut needs to place a boundary, and it removes the dependency on a paragraph of prose surviving an averaging decoder.Related leak found while implementing #63:
mergeRepeatsfoldsfindStackedOpenersresults past the content-word floor, so a zero-content-word opener like "te va" reachesrepeatedPhrases. Worth fixing in the same pass.Related: #44 (the gate this instrument backs), #57 (the content-word floor), #63 (the pass that consumes its findings).