You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
align_footage's window-refusal rationale cites a mixing behaviour that no longer exists #98
Discovered while implementing reeleehq/mixing#43 (mixing PR reeleehq/mixing#51). No muvid code change is needed — this is about prose that will mislead the next reader.
What is stale
muvid/footage/align.py refuses to forward window_s/hop_s (WINDOW_PARAMETERS), and both the comment on that constant and tests/test_alignment_trust.py::test_a_wider_window_is_refused_because_it_would_turn_the_gate_off justify the refusal partly on this measurement:
the defaults give support=0.75 and a vouched alignment; window_s=45 on the same clip gives support=None, which drops the verdict onto the confidence coefficient — i.e. the support gate switches OFF and the caller is told nothing.
As of mixing 0.0.53, mixing.audio.align_clips_to_referenceraisesmixing.errors.WindowTooWideForClip for exactly that call rather than returning support=None. The silent-gate-off failure mode described there is no longer reachable through mixing.
Why the refusal still stands
The other leg is untouched and is the stronger one: narrowing the window deflates every support (measured 0.38–0.70 at a 20 s window vs 0.00–1.00 at a 4 s one), so correct alignments fall under MIN_SUPPORT. mixing refuses only windows a clip cannot hold — it says nothing about a window that re-scales the gate downward, which is muvid's concern. align_footage should keep refusing both parameters.
The work
Update the WINDOW_PARAMETERS comment: keep the widening measurement as history (it is what motivated the refusal) but say that mixing >= 0.0.53 refuses it outright, and rest the live argument on the narrowing side.
Rename/restate test_a_wider_window_is_refused_because_it_would_turn_the_gate_off so its name does not assert a mechanism that has moved. The assertion itself (pytest.raises(TypeError, match="MIN_SUPPORT")) is still correct and should stay — muvid must refuse before mixing gets the chance to.
Consider whether the mixing floor in pyproject.toml should move to 0.0.53. Not required (nothing muvid calls changed shape), so it is a judgement call about what the comment there is allowed to claim.
Activity
Address review: don't restate mixing's bound or an unmerged version f…
Fix align_footage window-refusal rationale to match mixing behaviour (#…