fix: openai_image returns all n images; segmented_music stops halving narration#309
Conversation
The tool advertised `multiple_outputs: True`, accepted `n` (1-4) in its schema, requested `n` images from the API, and scaled `estimate_cost` by `n` — but the result handling was hardcoded to `response.data[0]`. Images 1..n-1 were decoded never, written never, and absent from `artifacts`, so a caller who set `n=4` paid for four images and received one. Iterate over `response.data`, writing each image to a distinct path (suffixed `_1`, `_2`, … when several are requested, mirroring `grok_image` / `dashscope_image`), and return `outputs` / `images_generated` alongside the full `artifacts` list. A single image keeps its exact requested path.
`_segmented_music` mixed the video's audio with the shaped music via `amix=inputs=2`, whose default `normalize=1` scales every input by 1/inputs (x0.5, -6 dB). Unlike `_mix` and `_full_mix`, this path has no `loudnorm` stage afterward to re-normalize, so the narration was permanently attenuated across the entire timeline — including the stretches where the music volume expression evaluates to 0. A one-second music segment quietly dropped the narration by ~6 dB for the whole video. Add `normalize=0` to the amix: the music is already scaled to `music_volume` by the `volume` expression, so speech passes at unity. Verified with ffmpeg — narration in a no-music region tracks the stereo/aac conversion baseline instead of sitting 6 dB below it.
calesthio
left a comment
There was a problem hiding this comment.
Thanks for the clear repros and focused regression coverage. I reviewed this against docs/PR_REVIEW_GUIDE.md, including the PR description, linked issue #308, changed files, CI result, and comments/reviews. Both fixes address real user-facing pain: openai_image no longer drops paid-for n>1 outputs, and segmented_music no longer attenuates narration through ffmpeg amix normalization.\n\nValidation run locally on the PR head:\n- python -m pytest tests/tools/test_openai_image_multi_output.py tests/tools/test_audio_mixer_segmented_music.py -q -> 6 passed\n\nCI is green, the tests are offline/focused except for the ffmpeg-backed audio regression that correctly skips without ffmpeg, and I did not find unrelated scope, dependency, security, or contract issues. The output/artifact behavior now matches the billed image count and the audio filtergraph change is appropriately limited to the segmented_music path.
…nd-segmented-music-volume fix: openai_image returns all n images; segmented_music stops halving narration
Fixes two independent media-tool defects where the tool silently delivers less than it charges/claims for. Separate atomic commits.
1.
openai_image— return allnimages (commit 1)The tool advertised
multiple_outputs: True, requestednimages, and scaledestimate_costbyn, but result handling was hardcoded toresponse.data[0]. Images1..n-1were dropped — a caller who setn=4paid for four and got one. Now iterates overresponse.data, writes each to a distinct path (suffixed_1,_2, … for multi; exact path preserved for a single image, mirroringgrok_image/dashscope_image), and returnsoutputs/images_generatedwith the fullartifactslist.2.
segmented_music— stop halving narration (commit 2)amix=inputs=2defaults tonormalize=1(x0.5 / -6 dB per input). Unlike_mix/_full_mix,_segmented_musichas noloudnormafterward, so the narration was attenuated ~6 dB across the whole timeline, including the no-music stretches. Addednormalize=0(music is already scaled by thevolumeexpression; speech passes at unity).Tests
tests/tools/test_openai_image_multi_output.py— allnimages written, artifact count == billed count,n=1keeps exact path, suffixing is unique (offline, stubbed SDK).tests/tools/test_audio_mixer_segmented_music.py— built amix carriesnormalize=0(offline); end-to-end ffmpeg check that narration in a no-music region tracks the stereo/aac baseline instead of sitting ~6 dB below it (skipped without ffmpeg).Verified the behavioral tests fail on
mainbefore the fix (segmented: baseline -24.1 dB vs output -30.1 dB).Closes #308