Mpi Audio Splice
Sound stops early after an H3 edit? This node sews the audio window back in
- audio
- patch
- audio
Here's the failure this node exists for. You're doing windowed work on MiniMax H3 - cutting a clip down to a window, running the expensive model on just that piece, then splicing it back. That's normal for the picture. But H3 generates audio with the video, so you cut the soundtrack too, and the regenerated half comes back window-length while the picture comes back full-length. Play it and the sound just stops a second or two in. Nothing errors, every tensor is valid - which is precisely why it's a nasty bug to chase.
MpiAudioSplice is the return leg. It writes a regenerated run of audio back into the longer soundtrack at a frame offset - the same offset you cut at. Think of it as the audio half of MpiImageSplice and the inverse of the pack's own MpiAudioRange: the inclusive start number that cut your window writes it back. It ships in MadPonyInteractive/ComfyUi-MpiNodes ("ComfyUi-MpiNodes"), the same H3-heavy pack that gives you MpiH3EncodeAV and MpiH3DecodeAV for the regeneration itself.
The inputs that matter
There are only five, and a beginner really sets four of them:
audio- the clip's full soundtrack, the one MpiAudioRange was cut from.patch- the window to write back in. The natural source is theaudiooutput of MpiH3DecodeAV after a windowed H3 regeneration.start- the frame (inclusive) where the patch lands. Negative counts from the end. Same convention as MpiListRange and MpiAudioRange, so the number that cut the window is the number you type.fps- the frame rate the start index is counted in (default 24). Wire the loader's own fps rather than typing a guess: a guessed rate doesn't fail, it slides the patch against the picture. That's the subtle one.crossfade- milliseconds (default 50) ramped inside the patch at each end, so the rest of the track is untouched. A hard splice clicks, and a click is the one artefact an audio edit can't hide. Leave it at the default unless you hear one.
How it works
Mechanically it's honest plumbing. The patch is resampled to the full track's sample rate if they differ (it reaches for torchaudio only when it has to), a mono patch is expanded to match a stereo track rather than crashing, and the window is laid in with an equal-power crossfade - the sqrt kind, not linear, because the regenerated window is an uncorrelated take of the same moment and a linear pair dips through the middle of the crossover.
One detail is worth knowing before you hit it: a patch that runs past the end of the track raises, and the error tells you by how many samples. It names the two things that actually cause it - a start that names a different window than the patch came from, or a patch from a different clip. And a cut spliced straight back with no regeneration is a bit-exact no-op, so you can run it unconditionally.
The single output is audio (an AUDIO wire), ready to feed the audio input of your save-video node. If the picture and soundtrack are both windowed through the encode, you're fixing both halves - MpiImageSplice for the frames, this for the sound.
Install
Standard for the pack. Easiest is ComfyUI Manager: search ComfyUi-MpiNodes, install, restart. Or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes
Then restart ComfyUI. No model downloads and no requirements.txt to babysit for this node itself - the audio stack it needs is ComfyUI's own. The context is the heavy part: windowed H3 work needs ComfyUI 0.30.0+ (where H3 landed) and the H3 weights, which run around 42.5 GB and - honest warning - the MiniMax H3 Community License excludes the US, EU, UK and South Korea for local use. One licensing note on the pack too: versions 1.2.7 and later are AGPL-3.0 (earlier releases stay MIT), so if you redistribute a derivative, that licence travels with it.
Troubleshooting
- Sound lands in the wrong place but nothing errors - you guessed
fpsinstead of wiring the loader's own. The node has no way to know your rate was wrong; that's why it's a silent slide. - A click at the splice -
crossfadeis 0, or a window was cut without the crossfade the encode side applies. Give it 50–100 ms. X-sample patch ... runs N samples past the end- yourstartdescribes a different window than the patch came from, or the patch is from another clip entirely.- The sound stops early anyway - check you actually spliced the audio back and didn't just re-stitch the picture. That's the exact failure this node exists to remove, so the moment it happens, you know which half of the workflow you forgot.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| audio | AUDIO | The clip's FULL soundtrack - the one MpiAudioRange was cut from. | |
| patch | AUDIO | The window to write back in, e.g. the audio output of MpiH3DecodeAV. Resampled to the full track's rate if it does not already match. | |
| fps | FLOAT | 24.000.01–1000 | Frame rate the start index is counted in. Wire the loader's own fps - a guessed rate slides the patch against the picture instead of failing. |
| start | INT | 0-18446744073709550000–18446744073709550000 | Start FRAME (inclusive) the patch lands on. Negative counts from the end. Same convention as MpiListRange and MpiAudioRange, so the number that CUT the window writes it back. |
| crossfade | INT | 500–2000 | Crossfade at each end of the patch, in milliseconds, ramped INSIDE the patch so the rest of the track is untouched. A hard splice clicks, and a click is the one artefact an audio edit cannot hide. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| audio | AUDIO | — |