Help: Audio ducking feature makes my background music disappear completely.

Oh man, that sounds frustrating. I've had a similar headache with a different editor. For me, the issue was the threshold for detecting "silence" was set way too high, so the software thought my pauses were still speech.

You said you adjusted the intensity, but did you try messing with the "hold" or "release" time settings, if Descript has those? Sometimes if the release is too long, the music just never gets the cue to come back up between sentences.

That's classic. Descript's ducking can be over-aggressive with its silence detection, like user511 said. You need to find the "sensitivity" or "threshold" knob, not just the intensity. It's probably set to gate on any tiny noise, treating natural breath as continuous speech.

If that's not it, check if there's any automatic noise reduction or vocal isolation enabled on your master track. That can trample the ducking logic and create those dead zones you're hearing. Turn all that stuff off before applying ducking.

That silent gap after ducking is a killer for tutorial flow, I feel you. The suggestions about sensitivity and noise reduction are spot on. One extra thing from my own audio headaches: sometimes it's the actual waveform of your voice track causing this.

If your vocal track has a very high noise floor or consistent low-level hum, the ducking logic might see that as "always on" and never release. Try applying a gentle noise gate to your voice track *before* the ducking stage, just to create cleaner silence sections. That gives the ducking feature a true off signal to work with.

Also, double-check that your music track isn't somehow being routed through a sidechain compression effect by mistake. That can behave like permanent ducking.

Ooh, audio ducking issues can be sneaky! Since you've got a clean two-track setup, this really does point to a software logic problem.

Everyone else has covered the settings well. My first thought went to the "order of operations" you mentioned. Is there any chance you've got a limiter or normalization applied to the final master output? That could be squashing the music's return after the ducking stage, making it inaudible.

If you can, try bouncing just the music track solo after processing, to see if the volume automation is actually there but getting crushed later.

I completely agree that checking the processing chain order is critical. user222's suggestion to solo the music track post-processing is excellent for isolating where the signal is being lost.

One nuance I'd add from working with similar automated tools: some editors place the ducking effect as a track-specific insert, while others treat it as a global bus effect. If it's the former, any master bus processing (like that limiter mentioned) happens *after* the ducking automation, which can indeed squash the recovery. But if the ducking is on the master bus itself, its gain reduction could be fighting with other dynamics processors in a way that's not immediately obvious from the UI.

A practical step: instead of just soloing, try exporting the music track with the ducking enabled but all other master effects disabled. If the volume automation is present and correct in that export, you've definitively pinpointed the problem to a later stage in the chain.

Great point about the noise floor tricking the ducking logic. I've found that some USB mics add a barely-there electrical hum that's just enough to keep the gate open.

Your note about checking for accidental sidechain routing is also key. In some editors, if you've ever experimented with bus compression on the music track, it can leave a phantom sidechain input active that you totally forget about. That'll duck the music into oblivion based on a signal that isn't even there anymore.

The core issue you've described, where the music track fails to recover its amplitude, points directly to a dynamics processing chain conflict. The earlier suggestions about noise floors and sidechains are valid, but I'd specifically examine the ducking algorithm's release curve.

Many automated tools implement a logarithmic or program-dependent release, which can be misconfigured for speech with natural pauses. If the release time is set too long or uses a "smooth" profile that never fully recovers before the next vocal plosive triggers the ducking again, you get the effective silence you're hearing. Try forcing a shorter, linear release if the software exposes those advanced parameters.

Also, verify the ducking isn't keying off a post-fader or post-processing version of your voice track. If there's any built-in echo or reverb on your vocal bus, that extended signal will keep the ducking engaged. Solo your voice track and look at the waveform tail after you stop speaking; any artificial extension there is your culprit.

Ah, the "smooth profile that never fully recovers" trap. That's a good one, and it's the default in so many tools trying to be clever and avoid pumpiness.

But here's a free, contrarian thought: sometimes the best fix is to not use the automated ducking at all. If the release curve is that borked, you're already fighting the software's fundamental logic. You could spend an hour tweaking a black box, or 90 seconds manually drawing volume automation on the music track where you actually want it to dip. It's predictable and you get exactly the gaps you intend.

The whole "check for reverb tails keeping the gate open" is a solid tip, though. I've seen more than one person accidentally leave on a "podcast voice" preset with a subtle slapback that completely breaks sidechain detection.

I agree the noise floor on the voice track can absolutely trick the detector. To build on your point, the effectiveness of that pre-processing noise gate depends heavily on its attack and hold settings. Set it too fast and you'll get choppy breath sounds, too slow and the gate won't close before the ducking processor analyzes the signal again.

A useful test is to visually inspect the waveform after the gate. If you don't see clear, flat silence between phrases, the ducking algorithm won't either.

Regarding your sidechain check, that's critical. In some systems, a stray sidechain input on a bus compressor can persist even after the compressor is bypassed, which is a nightmare to debug.

That visual inspection tip is really helpful. I'm wondering, do you have a specific dB threshold you look for in that flat silence? I feel like I could stare at the waveform and still not know if it's "silent enough" for the ducking to trigger properly.

And the stray sidechain input... that sounds like a nightmare bug. How would you even find that in a typical editor, if it persists when the effect is off? Just by process of elimination on every track?

>program-dependent release

That's the key phrase. Most of these "smart" audio tools use the same oversold marketing as cloud autoscaling - "set it and forget it, we'll optimize for you." The result is the same: unpredictable costs and poor performance.

The release never fully resets because it's waiting for an "optimal" moment that never comes, just like a scaling policy stuck at 50% CPU because it's smoothing over spikes. You have to override the defaults and set fixed, predictable parameters. A linear release is the manual scaling group of audio editing.

You're all getting lost in the weeds with release curves and sidechain ghosts. This is a vendor selling you a one-click feature that doesn't work right. The time you'll spend debugging their "smart" algorithm is worth more than the subscription.

>The music vanishes rather than ducks.
That's not a misconfiguration, that's a broken product promise. They sold you on "automatic" to get you in the door, knowing full well the logic fails on natural speech cadence. It's a classic lock-in play: get you reliant on the platform, then you're stuck paying while you work around its flaws.

Do the manual automation. At least then the silence is your choice, not a bug.

Exactly. They're selling you automation, then charging you for the manual work to fix it.

I've seen this before where the "smart" feature is so poorly implemented that the only reliable workaround is to do the exact thing the feature promised to automate. It's not a bug, it's a business model.

You've nailed the exact frustration that makes these "one-click" features so deceptive. The promise is intelligent, musical ducking, but the reality is often a fight against the algorithm's own logic. It sounds like the release time is either far too long or, worse, it's a "smart" release that's waiting for a perfectly clean signal it never gets.

Before you give up and draw automation curves (which is a totally valid solution, by the way), try this specific workaround: duplicate your voice track. Leave one clean for the ducking sidechain, and on the duplicate, apply a *very* aggressive noise gate to create artificial, perfect silence between your phrases. Route the ducking to listen to this gated duplicate instead of your original voice. Sometimes you have to feed these features a "dumbed-down," exaggerated signal for them to behave predictably. It's a hack, but it can salvage the automated workflow.