Ducking Music Under a Voiceover
The most common audio flaw in AI-assembled video is a music bed that won't get out of the way. What actually fixes it, and the stems escape hatch.
The single most common audio flaw in an AI-assembled video isn't a bad voiceover or a bad music track. It's both being fine on their own and fighting each other once they're mixed — a bed that's pleasant in isolation but sits loud enough under the voice that the words are technically audible and never comfortably so. Nobody sets out to build that. It's what happens by default when a track gets attached at whatever volume it generated at, without anyone deciding, deliberately, how loud it should be relative to the voice sitting on top of it. The fix is usually a two-minute setting, not a re-record.
What "ducking" actually means here, precisely
Worth being precise about, because the word gets used loosely: professional audio tools often mean dynamic ducking — a sidechain that automatically pulls the music down only while someone's talking and lets it back up in the gaps. That's not what's happening in a Versely mix, and it's worth knowing the difference before you go looking for a control that isn't there. Versely's attach_audio_to_video tool mixes on a static relative level: music_volume and original_volume are two separate volume settings applied for the full duration of the clip, not a level that moves automatically with speech. That's a simpler mechanism, and for most short-form content it's also the right one — a talking-head clip with a bed underneath doesn't usually have long musical passages with no dialogue over them, so a fixed low music level under a fixed full-volume voice covers the common case without needing dynamics at all.
The two-minute fix
attach_audio_to_video has two modes, and picking the wrong one is the first way this goes wrong before volume is even a question: mode: 'replace' strips the original audio and substitutes the new track entirely — the right call when there's no dialogue worth keeping. mode: 'mix' keeps the original audio and layers the new track on top, with the separate music_volume / original_volume controls — this is the setting for background music under an existing voice, and it's the one to reach for by default whenever there's a voiceover in the mix.
Once you're in mix mode, the actual fix is usually just: set music_volume meaningfully lower than original_volume, not marginally lower. The instinct is to nudge the music down a little and check if the words are audible; the better test is whether the words are comfortable, which usually needs the music pulled down further than feels necessary when you're listening for the music alone. If you want a reference point rather than mixing by ear alone, EBU R 128 s1 — the broadcast-industry supplement specifically covering short-form content like adverts and promos — targets an overall programme loudness of −23.0 LUFS with a ±0.2 LU tolerance, a maximum short-term loudness of −18.0 LUFS, and a maximum true peak of −1 dBTP to avoid clipping on ingest. That's a target for the finished mix as a whole, dialogue and music combined, not a setting you type into a slider — but it's a useful sanity check: if your finished export is peaking hot or the overall mix is louder than that short-form target once dialogue and music are combined, the music bed is very likely still carrying too much of the loudness budget.
When the mix lives inside the whole build, not a separate step
Not every job is "take a finished clip and attach audio to it" — a lot of the time the music is one layer inside a full multi-clip assembly built in a single pass. edit_video, Versely's one-call editor pipeline, takes music as a field alongside clips, texts, voiceover and captions, so the level decision for the bed lives in the same project state as everything else in the edit rather than as a bolt-on step afterward. The practical implication is the same principle as above — music under voice needs to be deliberately low, not left at whatever it generated at — but it means the decision gets made once, at build time, as part of the same EDL that holds the clips and the captions, rather than as a separate pass you might forget to run.
The stems escape hatch, for when turning it down isn't enough
Some tracks don't duck cleanly no matter how far down you pull the fader — a busy drum pattern, a vocal hook, anything with its own strong transients keeps poking through a voiceover even at a low relative volume, because the problem isn't loudness, it's that the track is competing for the same frequency space the voice needs. For a track generated in Versely, the fix isn't fighting the mix further — it's separate_music_vocals, which splits a previously generate_music (or extend_music) track into its vocal and instrumental stems. Swap in the instrumental-only stem as your bed and the competition mostly disappears, because the part of the track most likely to clash with spoken dialogue is exactly the part you've removed. Worth knowing the boundary on this one honestly: it only works on tracks generated in-app, referenced by their taskId and audioId — it's not a general-purpose splitter for an arbitrary uploaded MP3.
The problem that gets misdiagnosed as a ducking failure
One more failure worth naming because it looks like a volume problem and isn't: a music bed that's shorter than the video, looped to fill the runtime, produces an audible jolt at the loop point — a restart that reads as "the music got loud again" even when the level never actually changed. That's a duration mismatch, not a mix problem, and turning the music down further doesn't fix a seam. The actual fix is extend_music, which continues a previously generated track from (or near) a chosen point rather than looping it from the top — a genuinely longer piece of music instead of the same sixteen bars repeating with a hard cut back to the start. If a bed feels like it "jumps" partway through a video, check the runtime match before you touch the fader again.
Versely walkthrough: the full order of operations
Put together, the sequence that avoids re-doing work is: generate or select the track first, fix its length before its level, then fix its level, then decide whether it needs to be a stem at all.
"Generate a warm lo-fi background track for this 90-second video. If it's shorter than the video, extend it to match rather than looping it. Then mix it under the voiceover at a low volume so the dialogue stays clearly out front, and if the track still fights the voice once it's mixed in, split it and use the instrumental stem instead."
That one request chains generate_music → extend_music (only if the runtime doesn't already match) → attach_audio_to_video in mix mode with music_volume set low relative to original_volume → separate_music_vocals as the fallback if the low-volume mix still isn't clean. Each step solves a different failure mode — runtime, level, frequency competition — and running them in that order means you're not re-mixing a track that actually needed extending, or splitting a track that actually just needed to be turned down. For the full walkthrough on generating and attaching a bed in the first place, see adding music to a video; for the loop-seam fix specifically, extending a music track; and for the stems path, splitting a song into stems.
The takeaway
Most bad audio in AI-assembled video isn't a bad recording or a bad track — it's two acceptable elements mixed without a deliberate level decision between them. Use mix mode, not replace, whenever there's a voice worth keeping. Pull the music down further than feels necessary, and check it against a real reference like EBU R 128 s1's short-form target rather than by ear alone if you're not sure. Fix runtime with an extension before you touch volume, and reach for the instrumental stem when a track is fighting the voice for space rather than just sitting too loud. None of these are hard problems once they're correctly diagnosed — the entire flaw is usually just the wrong lever, pulled with the right intention.