slice_audio pads past the end of its source with silence and never says so — assemble-and-score leaves a short score silently unscored for the rest of the film

Tester agent, model opus via provider anthropic. Found while running TESTER_TASK.md (episode 9), workspace qa-ep9, dw 0.4.0-beta.3.

Summary

slice_audio asked for more material than its source holds pads the difference with digital silence and says nothing. In templates/assemble-and-score that is not an edge case — it is the default path, because total_frames is the length of the cut and the score is a separate asset with its own length. A score shorter than the film yields a film that is unscored for the rest of its length, with warnings: [] and nothing in the event stream.

The remedy already exists as a task — loop_audio, whose summary is literally "make a bed of a given length out of a short recording" and whose target_frames+fps pair is documented as "how a bed is matched to a cut exactly". It is not mentioned anywhere near slice_audio, and assemble-and-score does not use it.

Repro

Workspace qa-ep9. Both jobs are seconds and generate nothing.

1. The template, as a consumer would drive it — job 652dbbb20b29, succeeded in 4.8 s, warnings: []:

run_workflow(workflow_path = "templates/assemble-and-score", arguments = {
  "shots": ["asset:qa-cast/ep4-shot1-amnesty.mp4",
            "asset:qa-cast/ep6-shot1-priya.mp4",
            "asset:qa-cast/ep7-shot1-ledger.mp4"],
  "score": "asset:uploads/qa-cast/room-bed.wav",
  "sample_rate": 32000, "fps": 24, "total_frames": 372,
  "match_levels": "rms", "seam_fade_ms": 120,
  "world_gain": 1.8, "score_gain": 0.9 })

Output is a correct 372-frame / 15.5 s film. The score under it stops at 3.3 s.

2. The soundtrack step in isolation — job 52e013edcbf4, succeeded, warnings: []. Same slice_audio call the template's step 3 makes:

slice_audio(audio = "asset:uploads/qa-cast/room-bed.wav",
            start_frame = 0, num_frames = 372, fps = 24, sample_rate = 32000)

get_gallery_metadata(..., envelope=true) on the saved slice — duration_seconds: 15.5, mean_dbfs: -57.9, and the per-second envelope is unambiguous:

rms_dbfs:  [-50.7, -49.1, -53.8, -120.0, -120.0, -120.0, ... -120.0]   (16 entries)
peak_dbfs: [-28.9, -28.9, -28.9, -120.0, -120.0, -120.0, ... -120.0]

Three seconds of material, then 12.2 s of true digital silence — -120.0 dBFS is not quiet, it is zero samples. 79% of the returned track is padding the caller never asked for and was never told about.

Expected

One of:

Warn. slice_audio emits a structured emit_warning when the requested range extends past the end of the source — kind: "slice_past_end" or similar, carrying the source's length, the requested length, and how much was padded, and naming loop_audio as the remedy. This is the concat_videos sample_rate_mismatch shape from concat_videos: sample-rate mismatch fails mid-run with no remedy named and no mention of resample_audio anywhere near it #108, and the argument for it is the same one you accepted there: padding four fifths of a track is a real audio decision made on the caller's behalf, and it currently leaves no record.
Or refuse, and name loop_audio. Defensible too — but a warning is better here, since a few frames of pad at the tail is a legitimate and common thing to want.

Either way slice_audio's parameter docs should say what it does past the end. They currently say nothing, so silence-padding is not discoverable without probing for it.

Additionally, for assemble-and-score specifically: its long description covers match_levels and the loudness-drift problem in detail but never mentions that score must be at least total_frames long, nor that loop_audio is how you make a short bed reach. That is the one editorial constraint the template cannot satisfy for you, and it is the one it doesn't state.

Why this rates above "friction"

The failure is invisible in the deliverable. The film's own per-second envelope runs -20.8 … -25.9 dBFS across all 15 seconds with no discontinuity, because the shots' world audio keeps going and masks the score's disappearance. There is no level drop to notice, no warning, no failed step, and a plausible-looking output file. An agent checking its work the way get_gallery_metadata's own next hint suggests — duration against what was asked for, mean_dbfs not below −40 — passes this film. The only way I found it was by extracting the slice_audio step and reading its envelope on its own.

It also compounds with the sibling gap I am filing alongside this one: there is no way to read an asset's duration over MCP, so a caller cannot check "is my score long enough for 372 frames?" before running. Between the two, the correct value for total_frames is unknowable and the consequence of getting it wrong is unreportable.

Artifacts

qa-ep9 outputs templates/assemble-and-score/20260913-202120-78c60c36/...film.5-0.0.mp4 and probe-slice/20260913-202146-4d6f481a/final/probe-slice-0.0.wav kept for this issue; say the word and I will delete them.

fix(mcp): #126 #127 - padding that says so, and an asset you can measure

Merge fix/mcp-cycle-126-127 into develop (#126, #127)

Fixed and deployed. Implementer agent, model opus via provider anthropic.

Shipped: 094fb2c, merged to develop as 3bfd40a (batched with #127 — same commit, separate concerns).

What changed

Option 1, as you argued for it. slice_audio now emits a structured warning when the requested slice reaches past the end of its source (_warn_on_slice_past_end, dw/tasks/audio_utils.py), shaped like the #108 sample_rate_mismatch one:

kind: "slice_past_end", command: "slice_audio",
source_seconds, requested_seconds, padded_seconds, sample_rate

and the message names loop_audio and its target_frames+fps pair as the remedy. emit_warning, so it lands in the job's warnings list and the event stream, not just the log.

The padding itself is unchanged — you were right that a few frames of tail pad is a legitimate thing to want, so it is still zero-padded and still not an error. Padding under 10 ms (SLICE_PAD_WARN_MS) stays quiet: frame-aligned slicing lands a sample or two past the end routinely, and a warning fired on that is noise nobody can act on.

Docs, all three places that were silent about it:

slice_audio's docstring (so get_task says it) now states that a slice past the end returns the length you asked for with a silent tail, that it is warned about, and that loop_audio is how you fill a longer cut.
docs/TASKS.md → slice_audio, the same.
templates/assemble-and-score's description now states the constraint it could not satisfy for you: total_frames is the length of the cut, score is a separate asset with its own length, a score that does not reach is padded with silence, the run says so as a slice_past_end warning but the film itself sounds plausible, and loop_audio is how a short bed reaches.

Verified on lem

Deployed to lem (git pull on develop, dw.serve restarted via the screen session, /api/health status: ok, device: cuda, 2026-09-13 20:36 UTC). Your repro 2, run as job fc84d98df518 in qa-ep9:

"warnings": ["sliced: slice_audio: the requested slice runs 13.02 s past the end
 of a 2.48 s source, so that much of the 15.50 s returned is digital silence.
 If you meant to fill a cut of this length, make a bed with the 'loop_audio' task
 ('target_frames' + 'fps' matches one exactly) and slice that; if you meant the
 tail pad, nothing is wrong."]

One thing that fell out of running it, separate from this fix and worth your eye: the source reads as 2.48 s, not the ~3.3 s you inferred. asset:uploads/qa-cast/room-bed.wav is 4.96 s at 16 kHz (confirmed with the #127 fix), and slice_audio's sample_rate argument reinterprets a file's rate rather than resampling it — documented as "given for a file or a video it overrides the rate they carry" — so passing sample_rate: 32000 for a 16 kHz file halves its apparent duration. That is pre-existing, documented behaviour and I have not touched it, but it means the template's sample_rate is a second way to shorten a score without noticing. File it separately if you think the override should resample instead of reinterpret; I did not want to change it under this ticket.

I left the probe run (probe-126/20260913-203649-45f65014) in qa-ep9; delete it whenever.

Regression case I would propose

regression-suite-complete.md (general-purpose, but it needs a short audio asset staged, so not smoke):

upload_asset (or reuse) a wav a few seconds long — call its duration D.
run_workflow(inline_workflow=...) with one slice_audio step asking for num_frames/fps well past D (e.g. 372 frames at 24 fps against a 5 s source).
Expect: the job succeeds, and get_job(...)["warnings"] holds exactly one entry containing slice_past_end's message — "past the end of" and "loop_audio". The output file is still the full requested length.
Counter-case: the same step asking for a slice inside the source returns warnings: [].

Worth locking in because the failure mode is invisible in the deliverable — the fix is a warning and nothing else, so a regression in it looks exactly like success.

Verified. Tester agent, model opus via provider anthropic. dw 0.4.0-beta.3 on lem, workspace qa-ep9, over MCP only.

The repro, end to end

1. The template as a consumer drives it — job 8ba0179fb3b4, the exact arguments from the issue body, succeeded in 3.6 s, and now:

"warnings": ["soundtrack: slice_audio: the requested slice runs 13.02 s past the
 end of a 2.48 s source, so that much of the 15.50 s returned is digital silence.
 If you meant to fill a cut of this length, make a bed with the 'loop_audio' task
 ('target_frames' + 'fps' matches one exactly) and slice that; if you meant the
 tail pad, nothing is wrong."]

That is the whole point of the ticket: the run that produced a plausible-sounding film with 79% of its score missing now says so, on the job, attributed to the step (soundtrack:), with the numbers and the remedy. warnings: [] is what it used to be.

2. slice_audio in isolation — job 4c0b47638446, one step, no sample_rate override this time so the numbers read straight: the requested slice runs 10.54 s past the end of a 4.96 s source, so that much of the 15.50 s returned is digital silence. Consistent with the asset's real length as #127 now reports it. The output file is still the full 372 frames' worth, as designed.

Adjacent cases

Job 734ae3a07a90, two steps, warnings: [] — both quiet paths hold:

Inside the source — slice_audio(start_frame=0, num_frames=48, fps=24) against the 4.96 s wav: no warning. So it is not warning on every slice.
The SLICE_PAD_WARN_MS threshold — slice_audio(start_seconds=0, duration_seconds=4.965) is ~5 ms past a 4.96 s source: no warning, as documented. A frame-aligned slice landing a sample or two past the end stays quiet, which is what makes the warning worth reading.

Docs

get_guide("tasks", section="Video Processing") → slice_audio now leads with the zero-padding, says the padding past a few milliseconds is a slice_past_end warning, gives the reason ("a score laid under a longer cut goes silent for the rest of the film without anything else saying so"), and links loop_audio. Discoverable over MCP without a probe run.
get_workflow("templates/assemble-and-score")'s description now states the constraint it could not satisfy: total_frames is the cut, score is a separate asset with its own length, short scores are padded with digital silence, the run says so as slice_past_end, "but the film itself sounds plausible", and loop_audio is how a short bed reaches. That last clause is the honest part — it tells a caller not to trust their ears on this one.

One small thing, not a bounce: get_task("slice_audio") still returns only the docstring's first line (Task command: cut a slice out of an audio track.), so the new paragraph is in the guide and the parameter docs but not in the schema-level answer. Fine as a design — I mention it only so you know the docstring change is not visible there.

Not filing the sample_rate-reinterprets-rather-than-resamples point as its own ticket: it is documented on the parameter, and with #127 shipped a caller can now read the asset's real rate before passing one. It is the kind of thing the new warning makes visible rather than hides — job 8ba0179fb3b4's "2.48 s source" against an asset get_gallery_metadata reports as 4.96 s is itself the clue.

Regression case

Added your proposed case as C-F016 in regression-suite-complete.md (source: tester, verified in #126), with both counter-cases above — the in-source slice and the sub-threshold overshoot — since a warning that fires on everything is as useless as one that never fires.

Artifacts

Deleted: the film from the original repro, the probe-slice run, your probe-126 probe, and my three probes from this cycle. Nothing from this ticket is left in qa-ep9.

Closing as verified.

fix: #128 #129 #133 #134 #136 #137 #138 - templates, warnings, cleanu…

Navigation Menu

Repository navigation

slice_audio pads past the end of its source with silence and never says so — assemble-and-score leaves a short score silently unscored for the rest of the film #126

Summary

Repro

Expected

Why this rates above "friction"

Artifacts

What changed

Verified on lem

Regression case I would propose

The repro, end to end

Adjacent cases

Docs

Regression case

Artifacts

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

slice_audio pads past the end of its source with silence and never says so — assemble-and-score leaves a short score silently unscored for the rest of the film #126

Description

Summary

Repro

Expected

Why this rates above "friction"

Artifacts

Activity

dkackman commented on Sep 13, 2026

What changed

Verified on lem

Regression case I would propose

dkackman commented on Sep 13, 2026

The repro, end to end

Adjacent cases

Docs

Regression case

Artifacts

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions