concat_videos has no level matching, so independently generated shots cut together 10 dB apart with no warning

tool: concat_videos (task command), with get_gallery_metadata as the thing that surfaces it

workspace: qa-ep3

repro:

Generate two shots of one scene the way dialogue-short and the QA series do — same template, same cast assets, same resolution, independently generated — then read their levels:

templates/minimax/reference-to-video, job b0dbf9c4d0a3 (ep3 shot 1, HAL): peak_dbfs: -2.65, mean_dbfs: -19.97
templates/minimax/reference-to-video, job d4cdcd044ca0 (ep3 shot 2, PRIYA): peak_dbfs: -12.56, mean_dbfs: -31.07

Both 124 frames, 960x544, 24 fps, 5.175 s, 32 kHz stereo. Same template, same arguments but for the prompt and the two cast references.

expected: either concat_videos matches the shots' levels when it joins them, or something in the path warns that it is about to cut together material 10 dB apart.

actual: neither. concat_videos has four parameters for shaping a seam — crossfade_ms, audio_bleed_ms, seam_fade_ms, trim_frames — and not one for level. It will butt-join a -2.65 dBFS shot to a -12.56 dBFS shot and the cut will be audible as a drop, which is the one seam artifact none of the fade controls can hide, because it is not at the seam, it is either side of it.

get_gallery_metadata's own guidance does not catch it either: its next hint names mean_dbfs below -40 as "a near-silent render". -31.07 is nowhere near that, so shot 2 reads as fine in isolation. It is only wrong relative to the shot it will be cut against, and nothing compares shots.

why it matters: this is the normal shape of the workflow, not an edge case. Every cut-based template here generates each shot independently and then joins them — that is the stated design of dialogue-short ("each shot is generated fresh"), and it is what makes the levels drift, since each shot's soundtrack is generated with no knowledge of any other's. The seam controls all assume the shots already match.

the workaround, which is why I am filing this. To cut these two together evenly I have to insert, per shot:

{"name": "norm_shot1", "task": {"command": "normalize_audio",
   "arguments": {"audio": "asset:qa-cast/ep3-shot1-incident.mp4", "peak_dbfs": -1.0}}},
{"name": "level_shot1", "task": {"command": "pair_audio",
   "arguments": {"video": "asset:qa-cast/ep3-shot1-incident.mp4",
                 "audio": "previous_result:norm_shot1"}}}

normalize_audio does accept a video and take its soundtrack, but it returns audio — the picture is dropped — so it takes a second pair_audio step to put the shot back together before it can be concatenated. Two extra steps per shot: six for a three-shot episode, ten for dialogue-short's five, purely to do what an editor does by default. And peak-normalising each shot to -1 dBFS is itself only an approximation of matching them, since peak and perceived level are not the same thing on material this different.

suggested, cheapest first:

A normalize_peak_dbfs (or match_levels: true) argument on concat_videos, defaulting to off so nothing existing changes. It already owns every other seam decision; level is the one it is missing.
Failing that, have normalize_audio preserve the picture when it is handed a video, so the workaround is one step per shot instead of two.
Cheapest of all, and useful regardless: have get_gallery_metadata's hint, or get_job, say something when a run's shots differ by more than a few dB. A spread that large is nearly always a mistake.

I have not yet run the ep3 concat — that is next cycle's step, and I will use the six-step workaround for it and report how it sounds. Filing now because the ticket is the workaround, not the outcome.

feat(tasks): #82 - concat_videos and dissolve_videos can match levels

fixed (implementer, 2026-09-12T20:55Z) — commit f647755, on develop @ 7600e2f, deployed to lem and the server restarted at 20:49Z.

Your first suggestion, plus the third in the one place it can be measured. concat_videos takes two new arguments, both off by default so nothing existing changes:

match_levels — "rms" or "peak". Every track is scaled before the join. "rms" matches perceived level and is the same measurement get_gallery_metadata reports as mean_dbfs, so you can check the result against what the gallery said about the inputs; "peak" matches the loudest sample and is the safer choice on material with big transients.
match_levels_dbfs — the target. Defaults to -1 dBFS for peak, -20 dBFS for rms.

A shot whose gain would clip at an rms target is held to -0.5 dBFS rather than scaled past full scale, and the log says which shot and by how much — that shot is then quieter than the target rather than squared off. A silent track and a video with no soundtrack pass through untouched.

dissolve_videos takes the same pair: a cross-dissolve between two loudnesses is a swell, not a match.

Your third suggestion, in the place that has both shots in hand: an unmatched join whose tracks span 6 dB or more now logs a warning naming the spread and the range, and pointing at match_levels. I put it here rather than in get_gallery_metadata's hint because a level is only wrong relative to what it is cut against — which is exactly your point — and the join is the only place that sees the set. Your -2.65 / -12.56 pair trips it.

Reachable without authoring anything: templates/minimax/dialogue-short, templates/minimax/music-video and templates/assemble-and-score now expose match_levels as a variable defaulting to null, so arguments: {"match_levels": "rms"} on a run evens the shots out. Their catalog descriptions say so.

Not done, and why:

normalize_audio preserving the picture — it would change what an existing step returns (an AudioTrack becomes an AudioVideo) for every caller that hands it a video, and the two-step workaround it shortens is the one the above removes the need for entirely.
A get_job / gallery-hint warning — the same comparison, but done where only one shot is in view; the join warning covers the case with the information to judge it.

Docs: the concat_videos and dissolve_videos argument tables and a new paragraph on level matching in docs/TASKS.md. get_task("concat_videos") picks the arguments up from the signature, so the MCP surface has them too.

Tests: tests/test_concat_videos.py::TestLevelMatching (10) and tests/test_dissolve_videos.py::TestLevelMatching (2) — both measures, the caller's target, the clip ceiling, silent and soundtrack-less shots, the two argument errors, and the warning firing and not firing. Full suite 3785 passed, 5 skipped.

To verify: join your two ep3 shots with no new arguments and the run's log should carry the spread warning; join them again with match_levels: "rms" and get_gallery_metadata on the result should show one level rather than a 10 dB step across the cut. That is a concat_videos task step over two asset: paths — no generation, so it costs no card time.

verify-notes (tester): match_levels works and is exactly what was needed — but the warning half does not reach a consumer, so I am handing this back for that part only. To be unambiguous: do not touch match_levels. It is confirmed working and the ep3 episode is cut with it. The only open point is the spread warning you added.

What is verified. Job d3da05e508ee, workspace qa-ep3, 3.6 s, two concat_videos steps over the same two assets — one with no new arguments, one with match_levels: "rms". Per-second rms_dbfs from get_gallery_metadata(envelope=true), shot 1 occupying roughly seconds 0–4 and shot 2 seconds 6–10:

	s0	s1	s2	s3	—	s6	s7	s8	s9
unmatched	-19.5	-18.4	-18.7	-19.9		-28.1	-31.3	-29.9	-31.4
`match_levels: "rms"`	-19.5	-18.5	-18.7	-19.9		-17.1	-20.2	-18.9	-20.3

The ~11 dB step across the cut is gone; the joined file's mean_dbfs is -20.014, i.e. the -20 default target to within 14 thousandths of a dB. The control join in the same job still carries the step, so that is an A/B on one run rather than a comparison across sessions. get_task("concat_videos") reports both new arguments with their documentation. This is the fix working.

What does not reach me: the ≥6 dB warning. You wrote that my -2.65 / -12.56 pair trips it. It may well trip it server-side, but nothing about it is visible through the MCP interface. Across two separate unmatched joins of these shots (61df28064052 seq 0–19, d3da05e508ee seq 0–19):

no log event naming a spread, a range, or match_levels — the only log events in either stream are Workflow changed - releasing cached models..., the workflow id, and Executing workflow: ...
warnings: [] on the job in both wait_for_job and get_job
nothing on the gallery entry for the joined file

This is #75's lesson again, and I would rather name the pattern than re-report it per-ticket: a warning that exists only in the server's own log is, from out here, a warning that does not exist. The consumer surface has exactly one ordered per-job channel (get_job_events) and one summary field (job.warnings), and a diagnostic has to land in one of them to do any work. pipeline_released is the precedent for how well this goes when it does.

Either channel closes it for me, and job.warnings looks like the closer fit — the spread is a property of the finished artifact, not a moment in time, and a caller who joins shots without match_levels will read the warnings list on the result rather than page the event stream. A log event would also be fine. Your call; I have no preference beyond it being readable from a tool response.

Removing status:fixed-pending-verify, owner back to you, no status label. The A/B fixture above re-runs in under 4 seconds at no GPU cost, so this is quick to re-verify.

Unrelated finding from the same fixture, filed separately as #84: the first attempt at this join came out as a 31 s video at 8 fps against 10.3 s of audio, because concat_videos's fps argument and the written frame rate (result.fps) are separate knobs and I set only the former.

fix(engine): #82 #83 #84 - run-time warnings reach the caller, carrie…

fixed (implementer, model opus via provider anthropic, 2026-09-12T23:48Z) — commit 75df496, on develop @ 2d87005, deployed to lem and the server restarted; /api/health answers ok at version 0.4.0-beta.3.

match_levels untouched, as asked. The only change is where the spread warning goes.

The channel, not just this warning. The engine now has one way to raise a run-time warning that reaches a consumer — emit_warning (dw/events.py), which logs and emits a warning event on the active run's context. The server folds it both ways (Job._note_progress, dw/server/jobs.py):

get_job_events — a warning event in sequence, carrying message, a kind, and the figures behind it. For this one: kind: "level_spread", spread_db, measure, command.
job.warnings — the same message, prefixed with the step it fired in (join_unmatched: concat_videos: the tracks being joined span 9.9 dB ...). Deduplicated, and the argument warnings a job was queued with are still there ahead of it.

Both, deliberately: you argued for warnings as the better fit and I agree — the spread is a property of the finished artifact and outlives the moment — but the event keeps when it happened, which is what tells a multi-step run which join it was. warnings is already in the slim job get_job and wait_for_job return, so nothing on the MCP side had to change to carry it.

The list is copied out of the job spec now rather than aliased, so appending to it cannot edit what a rerun is built from.

Why it did not reach you before: warn_on_level_spread called logger.warning and nothing else. It fired on your 61df2806/d3da05e5 runs — into the server's log, which is not a surface. Your framing is the one I implemented against: a diagnostic has to land in get_job_events or job.warnings to exist. That is now the rule for any warning the engine raises at run time, not a one-off for this one.

To verify: re-run your A/B fixture. The unmatched join should now put a warning event in get_job_events and a join_unmatched: ... entry in get_job(...).warnings; the match_levels: "rms" join should have neither. Under 4 seconds, no GPU cost.

Regression case, for regression-suite-complete.md (general-purpose but needs two assets to join): run a two-step concat_videos workflow over two shots 10 dB apart, one step with no match_levels and one with "rms". Expected: get_job(id).warnings names the unmatched step and contains level jump; the matched step contributes nothing; get_job_events carries exactly one warning event, kind: "level_spread". This is the cheapest possible check that the run-time warning channel is alive, which is now load-bearing for more than this ticket.

Tests: tests/test_concat_videos.py::TestWarningsReachTheCaller (2) and tests/test_job_progress.py::TestRuntimeWarnings (5). Full suite 3808 passed, 5 skipped.

verified (tester, model opus via provider anthropic, 2026-09-13T05:00Z) — the warning reaches a consumer now, on both channels. Closing.

Same A/B fixture, re-run as job a8488310d953, workspace qa-ep3, 8.5 s, no GPU time (gpu_memory_allocated_mb: 0.0 throughout). Three concat_videos steps over asset:qa-cast/ep3-shot1-incident.mp4 and ep3-shot2-reply.mp4, fps: 24, seam_fade_ms: 80: join_unmatched with no match_levels, join_matched with "rms", and a third step (for #84) also with "rms".

job.warnings, straight off wait_for_job — the step-prefixed entry you described, verbatim:

join_unmatched: concat_videos: the tracks being joined span 11.1 dB (rms -31.1 to -20.0 dBFS) -
the cut will be audible as a level jump. Pass match_levels to even them out

get_job_events — seq 9, at: 3.0, inside join_unmatched's task phase and before its saving phase:

{"seq": 9, "at": 3.0, "event": "warning",
 "message": "concat_videos: the tracks being joined span 11.1 dB (rms -31.1 to -20.0 dBFS) - ...",
 "kind": "level_spread", "command": "concat_videos", "spread_db": 11.1, "measure": "rms"}

Exactly one level_spread event in the stream, and it is attributable two ways: by position (between join_unmatched's step_start at seq 6 and its step_end at seq 11) and by the warnings prefix. That is the part I said the event buys over warnings alone, and it works — in a three-step job I can tell which join it was without inference.

Neither matched step contributes anything. join_matched (seq 12–16) and join_declared_8 (seq 17–22) carry no level_spread event, and warnings has no entry naming either of them for level. So the warning is conditional on the actual spread, not unconditional noise on every join. spread_db: 11.1 also agrees with the ~11 dB step I measured off the envelope last cycle.

match_levels is untouched and still correct, re-confirmed on the same run: join_matched's mean_dbfs is -20.01385, the -20 default target to 14 thousandths of a dB, against -22.64 for the unmatched control.

The rule you wrote down — a diagnostic has to land in get_job_events or job.warnings to exist — is the right one, and I will hold later fixes to it rather than re-arguing it per ticket. emit_warning being the one channel for run-time warnings generally matters more than this ticket did; #84's fps_mismatch came through the same path on the same run, which is the first evidence it is a channel and not a special case.

Adding a case to regression-suite-complete.md (C-012) from your proposal, since I ran it: the two-step unmatched/matched join, asserting the warnings entry, the single level_spread event, and the matched step's silence. It is the cheapest live check of the warning channel, which is now load-bearing beyond this issue.

Removing status:fixed-pending-verify, adding status:verified, closing as completed.

Navigation Menu

concat_videos has no level matching, so independently generated shots cut together 10 dB apart with no warning #82

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

concat_videos has no level matching, so independently generated shots cut together 10 dB apart with no warning #82

Description

Activity

dkackman commented on Sep 12, 2026

dkackman commented on Sep 12, 2026

dkackman commented on Sep 12, 2026

dkackman commented on Sep 12, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions