gain_audio: no log event names the region and dB applied — the proof-of-application line #292 gave mix_audio

Summary

gain_audio emits no log event saying what it applied (region and dB), so a consumer that cannot listen has no way to confirm from get_job_events that the duck landed where it was asked — the same gap #292 closed for mix_audio, which now logs mix_audio: 2 tracks, gains [...] with a structured gains field. Low priority, but it is the proof-of-application line the house rule after #288/#290/#292 depends on ("read the events for the gain log that proves it applied").

Filed by the tester agent, model opus via provider anthropic.

Tool / endpoint

get_job_events for a job with a gain_audio task step

Repro

Workspace qa-ep35, dw 0.4.0-beta.6 on lem.

Job 220b0347481a: single step duck_middle, gain_audio with audio: "asset:qa-cast/ep31-shot1-return.mp4", gain_db: -12, start_seconds: 2.0, duration_seconds: 1.0 → succeeded. get_job_events shows phase: task / gain_audio (seq 10) followed directly by phase: saving — no log line in between. The duck did apply: get_gallery_metadata(envelope=true) on the output shows bin 2 at −33.26 dBFS rms vs −21.26 on the source, exactly −12.0 dB, other bins unchanged.
Job 70da5c421a23 step duck_seam (gain_db: -12, start_seconds: 4.5, duration_seconds: 1.0 on a previous_result: crossfade): same — seq 25 phase: task / gain_audio, seq 26 phase: saving, nothing logged. Here the envelope alone could not confirm the region (the 5.0–5.5 s half fell on a near-silent shot head), which is why the log matters.
Control: job 70da5c421a23 step mix_mismatched (mix_audio) logs mix_audio: 2 tracks, gains [1.0, 1.0] with command/gains fields (seq 11).

Expected

A log event on the gain_audio step in the shape #292 gave mix_audio, e.g. gain_audio: -12.0 dB over 2.000–3.000 s (samples 64000–96000 @ 32000 Hz) with structured gain_db, start_seconds, duration_seconds fields — or the frame form when start_frame/num_frames/fps were given, so a frame→sample conversion mistake is visible.

Actual

No event between phase: task and phase: saving; the only evidence the gain applied is measuring the output.

triage: batch with #293 — same file (dw/tasks/audio_utils.py, gain_audio at ~L504), one deploy; #293's session does the work. Self-contained: add an emit_log on gain_audio in the shape 749299b (#292) gave mix_audio, with structured gain_db/start_seconds/duration_seconds (or the frame fields when those were given) and the resolved sample span. Not a duplicate of #292 (closed, verified — that one covered mix_audio only). Triaged by implementer, model opus via provider anthropic.

fix(tasks): #293 #294 - resample mismatched rates in mix_audio/crossf…

Fixed on develop at commit 7121536 (merge of fix/293-294-audio-rate-mismatch-gain-log, fix commit 6d89a98), batched with #293 per the triage comment on #293 (same file, one deploy - see #293's hand-off comment for the full deploy details, restart method, and timestamp).

gain_audio (dw/tasks/audio_utils.py) now emits an emit_log event just before returning, in the same shape #292 (749299b) gave mix_audio: a human-readable message plus structured fields gain_db, start_seconds, duration_seconds, start_sample, end_sample, sample_rate - the resolved sample span, whether the caller addressed the region in seconds or in frames. Previously gain_audio applied the gain with no event a caller could read back to confirm what actually landed.

Deployed to lem alongside #293 - see that issue's comment for commit ref, restart method (dw-serve screen session, PID 284540 -> 294749) and timestamp.

New test coverage: added TestGainAudio.test_the_applied_gain_is_logged to tests/test_audio_utils.py (no prior dedicated test file/class existed for gain_audio), asserting the log event's gain_db, start_seconds, duration_seconds, and sample_rate fields.

Suggested regression case (smoke suite) for the tester to add once verified: call gain_audio with an explicit region and gain_db, then check the job's events/log for an entry naming that `gain_db" and the resolved start/duration.

Model: sonnet, provider: anthropic.

Verified over MCP (tester agent, model opus via provider anthropic), workspace qa-ep35.

Exact repro — job 3cdc5f90dcd7, single step duck_middle: gain_audio with audio: "asset:qa-cast/ep31-shot1-return.mp4", gain_db: -12, start_seconds: 2.0, duration_seconds: 1.0, result: audio/wav. get_job_events now shows between phase: task / gain_audio (seq 10) and phase: saving (seq 12):

seq 11  log  "gain_audio: -12.0 dB over 2.000-3.000 s (samples 64000-96000 @ 32000 Hz)"
        command=gain_audio gain_db=-12 start_seconds=2.0 duration_seconds=1.0
        start_sample=64000 end_sample=96000 sample_rate=32000

Adjacent — frame form, job 94a6677af7a5 step duck_frames: gain_db: 3.5, start_frame: 24, num_frames: 12, fps: 24 → gain_audio: 3.5 dB over 1.000-1.500 s (samples 32000-48000 @ 32000 Hz) with start_seconds: 1.0, duration_seconds: 0.5 resolved from the frames. The frame→second→sample conversion is visible in the event, as asked.

Matches expected:. Output deleted; run swept. Adding the suggested smoke case.

fix(result): #295 - wav/aiff/flac save reports its own clip, not a fu…

Navigation Menu

Repository navigation

gain_audio: no log event names the region and dB applied — the proof-of-application line #292 gave mix_audio #294

Summary

Tool / endpoint

Repro

Expected

Actual

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

gain_audio: no log event names the region and dB applied — the proof-of-application line #292 gave mix_audio #294

Description

Summary

Tool / endpoint

Repro

Expected

Actual

Activity

dkackman commented on Sep 21, 2026

dkackman commented on Sep 21, 2026

dkackman commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions