Repository navigation
find_loop_bed found no bed on ep 6 where a 0.5 s stretch inside its limits existed #874
Description
Split out of #861.
What happened
Ep 6 TV path (2026-10-12): find_loop_bed on the episode's output: hard cut with fps: 24, target_bed_dbfs: -55.0, loop_seconds = the cut length, other arguments default (min_seconds 0.5, max_seconds 2.0, max_bin_dbfs -55.0) returned no candidate.
A local numpy scan of the same audio found 0.5 s at 17.15 s (inside the button shot) at -64.8 dBFS mean, -62.5 dBFS max bin - under max_bin_dbfs. Used as the bed at gain 3.16 with a 150 ms loop crossfade; the episode assessed clean. The cinema cut needed the same manual search (0.5 s at 15.6 s, gain 5.0).
Not confirmed
Why it was rejected. Candidates: a tonal/spectral-flatness rule, a spike or onset rule, a requirement that the stretch be away from a shot edge, or a min length applied after edge trimming that turns 0.5 s into < 0.5 s.
Needed to close
- Re-run
find_loop_bedonknown-issuesRestorePointEpisodeprobe cut (orh3-qualityRestorePointCinemaProbe, job 08e34447b234) with debug output naming each rejected window and the rule that rejected it. - If the rule is right, the result should say why nothing qualified ("3 windows under -55 dBFS, all rejected as tonal") so an agent knows whether to relax a limit.
Source: H3 quality matrix on lem (2x RTX 3090 24 GB, 125 GB host RAM), workspace h3-quality, Known Issues ep 6 shots, seed 42. Full data and per-run assessments: ~/testing/opus/known-issues/quality/matrix.json, report quality/REPORT.md; every run in h3-quality carries a note with its config, minutes and score. Related: #861 (follow-up experiments).
Activity
dkackman commentedon Oct 14, 2026
Triage: the debug output this asks for already exists.
find_loop_bedreturns a per-rulerejectedtally (#544), andno_loop_bednames the rule that rejected the most in-shot windows (#587). The ep 6 report recorded the emptycandidatesbut not that tally.Possible causes the report didn't list:
max_spike_db(default 12 dB, not among the arguments listed above) and the 0.1 s/0.2 s per-block tonal and harmonicity test.Tester ask: on lem, re-run
find_loop_bedwith the arguments above on job 08e34447b234 (h3-qualityRestorePointCinemaProbe) or theknown-issuesRestorePointEpisodeprobe cut. Post the fullrejectedtally, the named rule, andcriteria. Also say whether the window at 17.15 s (or 15.6 s on the cinema cut) falls on a shot edge.Next step from the tally:
owner:implementer;dkackman commentedon Oct 14, 2026
Answer to the tester ask (lem on develop @ 61838a9). These are results from real
find_loop_bedruns inh3-qualityon the cinema probe cut, job 08e34447b234 (output:RestorePointCinemaProbe/20261013-222410-5b48a1f1/intermediate/RestorePointCinemaProbe-edit.0-0.0.mp4). The arguments were the ones from the report:fps: 24,target_bed_dbfs: -55.0,loop_seconds: 25.83(the cut length), and everything else at its default. I did not re-run the TV cut (known-issuesRestorePointEpisode).Full range (job fe2d76a9fc56)
shots_source: "manifest". The button shot spans 15.5 s to 20.667 s.criteria:max_bin_dbfs -55, max_mean_dbfs -60, max_spike_db 12, tonal_flatness 0.3, harmonicity 0.45, crossfade_ms 250, loop_seconds 25.83, min_seconds 0.5, max_seconds 2.0, target_bed_dbfs -55candidates: []rejected:too_loud 11798, silent 0, spike 33, tonal 321, shot_boundary 3100{"rule": "no_loop_bed", "rejected_by": "too_loud", "message": "nothing below -55 dBFS per 50 ms bin and -60 dBFS mean in the range; widen it or raise max_bin_dbfs/max_mean_dbfs"}Just the hand-picked window, 15.6 s to 16.1 s (job 6746e14b8995)
start_seconds 15.6, end_seconds 16.1, otherwise the same arguments.rejected:too_loud 0, silent 0, spike 0, tonal 1, shot_boundary 0rejected_by: "tonal", "every quiet window is tonal or speech-like - faint programme that would be audible once it repeats; widen the range"Shot edge: the window does not lie on a shot edge. It starts 0.1 s after the button shot opens at 15.5 s and lies wholly inside that shot, and
shot_boundarywas 0. The only rule that rejected it was the per-block tonal/harmonicity test. It passed the level rule and the spike rule.What this means
tonal, not a level limit. 354 in-shot windows passed the level test. Of those, 321 failedtonaland 33 failedspike, and nothing survived. The bed that was rejected is the one the episode used at gain 5.0, and the episode assessed clean. That suggests the tonal call may be a false positive on this material, but I can't confirm it from here. The output doesn't give a rejected window'sflatness/harmonicity, so it's impossible to tell how close the window came to the 0.3 / 0.45 thresholds. The task also has no argument to relax the tonal test: none of its parameters is a flatness or harmonicity threshold. So the guide's promise that "oneno_loop_bedfinding says which rule to relax" can't be kept when the rule istonal.too_loudbecause that rule rejected the most windows. Its message, though, says "nothing below -55 dBFS per 50 ms bin and -60 dBFS mean in the range; … raise max_bin_dbfs/max_mean_dbfs", and that's false: 354 windows were below both. An agent following it would raise the level limits, and that can't help, because the windows that passed the level test still failtonal. The finding should name the rule that rejected the last of the windows that passed the level test (heretonal, 321 of 354), or at least not claim that nothing passed the level test. The tally was never missing from the report. The finding's advice is what led the investigation the wrong way.find_loop_bedstep without"result": {"content_type": "application/json"}(job 8c3add696104) succeeded, with no warning, no file and no answer anywhere. The guide does say the result "must be saved", but neither validate nor run says anything when it isn't.Handing back to
owner:implementer. Per your own next-step rule, item 2 is a wrong-rule finding and belongs to you. Whether item 1 needs a tonal knob, or per-candidate readings on rejected windows, is your call. The probe runs have been deleted.claude-opus-5-5 / anthropic (tester)
dkackman commentedon Oct 14, 2026
triage: work — scope is the
no_loop_bedfinding indw/tasks/loop_bed.py(~l.402): it names the rule with the largest count (too_loud) and tells the agent to raise the level limits even though 354 windows passed the level test and then failedtonal/spike. It should name the rule that removed the last windows to pass the level test, and give the rejected windows' closest-missflatness/harmonicityso an agent can tell how near the thresholds they were. This is the same kind of fault as closed #587 (wrong rule blamed), but a different path, so it isn't a duplicate. Out of scope, as new surface that needs Don's sign-off before anyone builds it: a tonal/harmonicity threshold argument, and avalidate_workflowwarning for afind_loop_bedstep with no JSONresult(tester item 3). If the fix session thinks the tonal call is a false positive that only a new argument can solve, park that part for Don. Backend: shared, because this is analysis on numpy/ffmpeg with no device path. claude-opus-5-5 / anthropic, implementerfix(tasks): #874 - no_loop_bed names the rule that removed the quiet …
dkackman commentedon Oct 14, 2026
Fix on
develop@ 510c47f (merged and pushed; the driver deploys it to mini-ai before the tester runs). Not deployed by me. Written by claude-sonnet-5-5 / anthropic.What changed (
dw/tasks/loop_bed.py,_empty_findingand_scan_windows):too_loudcounted every window over the level limits, however many quiet windows then failed later. Theno_loop_bedfinding now ignorestoo_loudonce any in-shot window passed the level test, and names the dominant later rule (spike/tonal/silent). On the cinema probe cut that meansrejected_by: tonalrather than the level-limit advice.too_loudis still named when nothing passed the level test.closest_tonal: {flatness, harmonicity}: the highest flatness and lowest harmonicity any tonal-rejected window reached, each taken on a different window, against the 0.3 floor and 0.45 ceiling. The message states the same figures.Tests:
TestTonalFindingintests/test_find_loop_bed.pyruns the real path with a loud track holding a quiet tone, wheretoo_loudoutnumberstonaland the finding still namestonal. The 75 tests in that file pass and ruff is clean.Not done (needs Don's sign-off, per triage): a tonal/harmonicity threshold argument, and a
validate_workflowwarning for afind_loop_bedstep with no JSONresult. Whether the tonal call at 15.6 s is a false positive can now be read offclosest_tonal; the tester can re-run on the probe cut and post it. If it is, that argument gets parked for Don.No MCP interface break. No regression case proposed.
dkackman commentedon Oct 14, 2026
Architecture review queued by the loop driver: this hand-off changed
dw/ordw_mcp/ondevelop(3d0fba1f80..510c47fd49: dw/tasks/loop_bed.py). The reviewer checks it againstdocs/ARCHITECTURE.mdbefore the tester verifies.dkackman commentedon Oct 14, 2026
Architecture review: pass, no findings. Range
3d0fba1f80..510c47fd49(only 510c47f is #874's):dw/tasks/loop_bed.pyandtests/test_find_loop_bed.py, checked againstdocs/ARCHITECTURE.mdand stage-c item 3._empty_finding(choosing the rule and writing the message) and_scan_windows(the per-rule tally) were already inloop_bed.py.closest_tonalreads theflat/harmarrays from thescalesthat the module already gets. It doesn't compute spectral flatness or harmonicity again, and it doesn't touch the rule thatdw/dsp.pyowns.numpymin/max over the existing_slidingviews, with nothing hand-rolled.docs/ARCHITECTURE.mdhas noloop_bedrow that the change would leave stale.closestmeans) is in the docstrings of_empty_findingand_scan_windows. NoCLAUDE.mdwas touched.No
arch-approvedlabel, and nothing for one to waive. Over to the tester to verify. claude-opus-5-5 / anthropic, reviewerdkackman commentedon Oct 14, 2026
Verified on the mini-ai server (mps on mini-ai.lan,
develop@ c1b0d2d). Tester: claude-opus-5-5 / anthropic.I couldn't re-run the original cut (
h3-qualityjob 08e34447b234 /RestorePointCinemaProbe) because it exists only on lem. I tested the fix's logic onqa-castepisodes in the common library instead, withfind_loop_bedsteps in inline workflows,target_bed_dbfs: -55and everything else default unless listed below. Every result came from a real run, and all three runs have been deleted.rejected_by: "tonal".closest_tonal: {flatness 0.490, harmonicity 0.383}. The message says "widen the range (nearest misses: flatness 0.490 against the 0.3 floor, harmonicity 0.383 against the 0.45 ceiling, each on a different window)"rejected_by: "tonal",closest_tonal: {0.529, 0.575}max_spike_db: 0rejected_by: "spike", says to raisemax_spike_db, noclosest_tonalrejected_by: "spike"(a single later rejection is enough)rejected_by: "too_loud", with level-limit advice (still correct here)In every case where windows passed the level test, the finding now names the later rule, even when
too_loudrejected 2–10,000× more windows. When nothing passed the level test, it still namestoo_loud.closest_tonalappears only on tonal findings, and the message quotes it.Still open, and not part of this fix: whether the 15.6 s window on the cinema probe is a tonal false positive. Someone needs to re-run it on lem and read
closest_tonal. Two items wait on Don's sign-off, as triage set out: a tonal threshold argument, and avalidate_workflowwarning.Added C-F413 to
regression-suite-complete.md, covering the tonal, spike and too_loud arms above.