H3Kit 音画同步裁剪

MiniMax H3 makes short clips - that's the architecture, not a setting. So anyone doing a 20-second digital-human take ends up chaining segments, and chaining means every new segment is generated with a few frames of the previous segment pinned at its head so the motion carries over. Those pinned frames are genuinely inside your latent, and they genuinely come out of the decoder. Save that decode and your viewer sees the same beat twice at every join, with the soundtrack offset by the length of the overlap. The fix is subtraction, and this is the subtracting node.

H3Kit 音画同步裁剪 does one job: drop the leading pinned frames from a decoded H3 clip, and trim the audio by the same duration so picture and sound stay locked. This is the node for the plain (motion-bridge) continuation path - if you're on the SelfLift path, the SelfLift join node does the same cut automatically because the overlap is recorded inside the sampler's latent. Here you tell it the number.

How it works

Two required inputs, and only one of them is a decision. decoded_frames is this segment's full, uncut decode - do not trim it upstream, or you'll cut the wrong frames. prefix_frames is how many leading frames to remove, and you get it by wiring the prefix_frames output from H3Kit 动作续接 (the Motion Context bridge) rather than typing it. That bridge reserves the context block at the head; its prefix_frames output is the length of that block. First segment? Nothing is pinned and prefix_frames is 0.

The audio cut is computed, not guessed: frame_rate (default 24) converts prefix_frames into a duration and slices the same amount off decoded_audio. The author's tooltip is blunt about it - this value "must match what you feed Create Video", because 24 is the H3 grid and anything else makes your sound slide against your picture by a frame every join.

Then there's the detail I'd have never thought of. align_audio_tail (on by default) forces the audio duration to exactly frames / fps, trimming a long tail or padding a short one with silence. Why: H3 rounds its audio grid to the nearest step, so every clip carries roughly 8ms too much or too little sound - inaudible alone, and cumulative across a chain. Leave it on unless you have a reason not to.

delivery_frames handles the other end. Wire it to the bridge's delivery_frames to also drop the tail frames that H3's length alignment added; leave it at 0 and you keep everything after the head cut.

Outputs

trimmed_frames and trimmed_audio go straight into the same save/combine node - Video Combine or Create Video - at 24fps. decoded_audio is optional and can stay unwired for silent clips; you just get a silent trimmed_audio back.

Install

Same pack as the rest, one install for all of it. In ComfyUI Manager search ComfyUI-H3-upgrade-kit and restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/flywhale-666/ComfyUI-H3-upgrade-kit.git

Restart ComfyUI, then search H3Kit in the node search (H3 Upgrade Kit category). There is no pip step - requirements.txt in the repo is empty and the pack's declared dependencies are []; it rides on ComfyUI's own torch. It does need a recent ComfyUI that supports H3 with arbitrary keyframe anchoring, and the pack checks the layout the first time you use the continuation nodes, telling you to update if it doesn't match.

Where people get burned

Wiring an already-trimmed decode into decoded_frames. The cut is positional - feed it a clip that already starts 17 frames in and you're now 17 frames short. Decode the whole segment, hand it here, let the node do the arithmetic.

Second trap: hand-set prefix_frames on a SelfLift segment. SelfLift's overlap is stamped onto the sampled latent and read by the SelfLift join; adding a manual cut on top double-trims. Pick one path and stay on it.

Third: an fps mismatch between frame_rate and the save node. The picture is fine, the audio slowly desyncs, and it looks like a model problem when it's a metadata problem.