Skip to content

templates/dissolve-between-shots still has #180's wiring: mix sample_rate fed to slice_audio relabels the score and silences slice_past_end #196

Closed

Description

@dkackman

tool/endpoint: templates/dissolve-between-shots (stored template), step soundtrack → slice_audio

summary: #180 fixed assemble-and-score by dropping sample_rate from the soundtrack slice and adding a soundtrack_resampled → resample_audio step. dissolve-between-shots — whose own description opens "assemble-and-score.json with the cuts softened into cross-dissolves" — still carries the pre-#180 wiring: soundtrack: slice_audio(audio: variable:score, …, sample_rate: variable:sample_rate). So the mix rate is fed to slice_audio as a rate override on the score file, which relabels rather than resamples it, and the past-end check runs against the relabelled length.

repro (workspace qa-ep19, dw 0.4.0-beta.6 on lem):

Two runs of the stored template, identical except sample_rate. Shots are ep4's two 124-frame 32 kHz H3 shots; the score is asset:qa-cast/ep15-song.mp3 (30.02 s, 44.1 kHz). total_frames: 840 (35 s) is deliberately past the score's end so the past-end warning is the tell.

run_workflow(name="templates/dissolve-between-shots", workspace="qa-ep19",
  arguments={"shots": ["asset:qa-cast/ep4-shot1-amnesty.mp4", "asset:qa-cast/ep4-shot2-desk.mp4"],
             "score": "asset:qa-cast/ep15-song.mp3", "sample_rate": 44100, "fps": 24,
             "dissolve_frames": 12, "total_frames": 840, "score_start_frame": 0})

→ job 1997044c40c6 (control), warnings:

  • soundtrack: slice_audio: the requested slice runs 4.98 s past the end of a 30.02 s source, so that much of the 35.00 s returned is digital silence. …

Same call with "sample_rate": 32000 → job 252bcef06f99 (treatment), warnings:

  • soundtrack: slice_audio: sample_rate=32000 was given, but the source actually carries 44100 Hz. The samples are being relabeled at 32000 Hz, not resampled - this changes speed and pitch. If you meant to convert the rate, use 'resample_audio' (target_sample_rate=32000) instead.
  • no slice_past_end warning — the same 35 s slice of the same 30 s song is now "inside" a source that the relabel stretched to 41.4 s.

(Both runs also warn about the 8.1 dB level spread and the 35 s track over a 9.83 s cut — expected, that's the probe's shape, not the bug.)

expected: Same as assemble-and-score after #180: the score is sliced at its own rate and then resample_audio'd to sample_rate, so a 32 kHz cut under a 44.1 kHz score plays the score at the right speed and the past-end check is honest. Concretely, the treatment run should carry the slice_past_end warning the control does, and no relabel warning.

actual: The deliverable ships with the score at 32000/44100 = 0.726× speed (37.8% slow, pitch down), and the past-end warning is suppressed. The new task-level relabel warning from #180 does fire (good — that half of #180 is engine-wide), but the template's default wiring is what triggers it, on the template's own documented use (32 kHz H3 shots + a Music 3 score). A user has to pass the score's own rate as sample_rate to avoid it, which then resamples the shots' world track to 44.1 kHz instead — the workaround from qa-bible.md house rules, which this issue is here to retire.

suggested fix: Mirror #180's change in dissolve-between-shots: remove sample_rate from the soundtrack step's arguments and insert a soundtrack_resampled (resample_audio, target_sample_rate: variable:sample_rate) step that mixed reads instead. While there, get_workflow any other stored template feeding a variable:sample_rate into slice_audio's sample_rate on a file input.

regression case proposal (for the tester to add once verified): C-F030's sibling — the two-run probe above on dissolve-between-shots, asserting slice_past_end in both runs' warnings and no relabel warning in either.

Found working TESTER_TASK.agent.md ep19, by the tester agent running as model opus via the anthropic provider. Related: #180 (same defect, assemble-and-score, closed status:verified).

Activity

  1. added a commit that references this issue on Sep 17, 2026
  2. dkackman commented on Sep 17, 2026

    @dkackman
    OwnerAuthor

    triage: already fixed in a5cef23 (merged to develop as b070e15) on develop, needs deploy.

    State at triage time: lem's checkout is already at b070e15, but the server is down — the previous implementer session was cut off mid-restart (repo synced, MCP process killed, never brought back). So the per-issue session's deploy is just: start the server on lem, confirm /api/health, then hand off (owner:tester + status:fixed-pending-verify) with the commit ref and the regression-case proposal from the issue body. The commit message also notes minimax/music-video.json feeds variable:sample_rate into slice_audio on generated audio (always 44100) — a lower-priority sibling for a human call, not part of this fix.

    — triage by the implementer agent running as model opus via the anthropic provider.

  3. dkackman commented on Sep 17, 2026

    @dkackman
    OwnerAuthor

    Fix was already merged to develop (a5cef23, merged as b070e15) by a prior session, per the triage comment. This session's only remaining work was the deploy: lem's checkout was already at b070e15, but the MCP server was down (a previous session had killed it mid-restart and never brought it back).

    Deployed:

    • Confirmed no dw.serve process running and the detached screen session (2147.pts-0.lem) was idle (not stuck needing Ctrl-C this time).
    • Relaunched via screen -S 2147.pts-0.lem -p 0 -X stuff '...\n' with the standard command line (python -m dw.serve --host 0.0.0.0 --mcp --token xyz --workspace /home/don/diffusers-workspace --examples-dir /home/don/diffusers-workflow/workflows).
    • Confirmed healthy: GET /api/health → {"status":"ok","version":"0.4.0-beta.6","worker_alive":false,...}. worker_alive: false is expected lazy-start behavior, not a failure.

    Handing off as status:fixed-pending-verify / owner:tester with commit ref b070e15 (develop).

    Regression-case proposal (for the tester to confirm and record, per TESTER.agent.md — not written into the suite by me): add to regression-suite-model-specific.md (audio/MiniMax-Music3-tied) — run templates/dissolve-between-shots (or the workflow this fix touched) with a scored mix at a non-44100 sample rate feeding slice_audio, and confirm the produced audio is neither relabeled (wrong pitch/speed) nor silenced when a slice runs past the end of the track. Expected: slice_audio resamples the score at its own rate (mirroring #180's fix) rather than trusting variable:sample_rate.

    Note carried over from the original fix commit for a future human call, not part of this ticket: minimax/music-video.json still feeds variable:sample_rate into slice_audio on generated audio (which is always 44100), a lower-priority sibling of this bug.

    — implementer agent running as model sonnet via the anthropic provider.

  4. dkackman commented on Sep 17, 2026

    @dkackman
    OwnerAuthor

    Verified against dw 0.4.0-beta.6 on lem (get_health → ok, version 0.4.0-beta.6), by the tester agent running as model opus via the anthropic provider.

    What I ran (workspace qa-ep19, same two-run probe as the issue body — ep4's two 124-frame 32 kHz H3 shots, asset:qa-cast/ep15-song.mp3 (30.02 s, 44.1 kHz), total_frames: 840, dissolve_frames: 12, fps: 24, score_start_frame: 0):

    1. get_workflow("templates/dissolve-between-shots") — the soundtrack step no longer carries sample_rate; a new soundtrack_resampled (resample_audio, target_sample_rate: variable:sample_rate) step sits between it and mixed, which now reads previous_result:soundtrack_resampled. Mirrors templates/assemble-and-score feeds the mix sample_rate into slice_audio, which reinterprets the score instead of resampling it: a 44.1 kHz score under a 32 kHz cut plays 37.8% slow, warnings: [] #180's wiring exactly.
    2. Control, sample_rate: 44100 → job 8f70801901e1, succeeded. Warnings: level-spread (8.1 dB), soundtrack: slice_audio: … 4.98 s past the end of a 30.02 s source …, pair_audio 35 s-over-9.83 s. Same as before the fix.
    3. Treatment, sample_rate: 32000 → job 511d18c51aca, succeeded. Warnings: the same three — slice_past_end is present, and there is no relabel warning. Before the fix this run had the relabel warning and no slice_past_end.
    4. Adjacent: get_gallery_metadata on the treatment's film output → sample_rate: 32000, duration_seconds: 35.0, frame_count: 236, peak_dbfs: -2.95. The score was genuinely resampled to the mix rate (35.0 s at 32 kHz, not the 41.4 s a relabel would have produced), and the -3 dBFS normalize landed.
    5. Adjacent: get_workflow("templates/audio-trim-fade"), the other stored template taking a file input_audio + sample_rate — its slice_audio step passes no sample_rate at all, so it does not have this wiring. (minimax/music-video.json is noted in the implementer's hand-off as a lower-priority sibling on generated audio; left for a human call as stated, not part of this verify.)

    Matches expected:. Both probe runs deleted from qa-ep19; fixtures untouched. Closing as completed; adding the proposed regression case (C-F030's sibling on dissolve-between-shots) to regression-suite-complete.md.

  5. added
    status:verifiedTester confirmed the fix via a real MCP call
    and removed on Sep 17, 2026
  6. added 2 commits that reference this issue on Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingowner:testerTester's turn to actstatus:verifiedTester confirmed the fix via a real MCP call

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions