H3 Auto Chain Motion Context Trim

Boring node, quietly doing the most important cleanup in the pack. When Motion Context pins frames from the previous clip, those pinned frames sit at the start of the delivered clip - so before you stitch clips together, they have to come off. If you only trimmed the images, the audio would stay a full trim_frames longer than the video, and muxing that puts the whole soundtrack ahead of the picture by trim_frames/24 seconds. At 22 frames that's almost a second of off-beat audio. This node removes the same span from both streams: whole frames from the images, the matching number of samples from the waveform.

It's also the fix for a subtler accumulation problem the author clearly got burned by. H3's audio latent runs on a 40 Hz grid against 24 fps picture, and the model rounds to the nearest step - so every clip ships with roughly 8ms too much or too little sound. A couple of clips is inaudible. Twenty clips, and the drift compounds into a faint dampening at the first join and a short click at later ones. That's what match_tail is for.

Wiring

Wire trim_frames from the MiniMaxH3AutoChainMotionContext node's trim_frames output into this node, so the count follows whatever the encoder actually produced - don't hardcode it. Feed the decoded clip into images, and the decoded clip audio into the optional audio input if your H3 clips carry sound (they do, that's H3's whole party trick). Out the other side you get images and audio, ready for the stitch node or a video encoder.

The inputs, quickly

• trim_frames - how many leading frames to drop. Comes from the Motion Context node; default 0 means "don't touch anything", which is fine for a chain's first clip.
• fps - the frame rate used to convert the trim into an audio duration. Must match what you feed your video encoder - a mismatch re-introduces exactly the drift this node exists to remove.
• match_tail - on by default, and leave it on. It forces the audio duration to exactly frames/fps, trimming a long tail or padding a short one with silence. The padded samples are sound the model never generated, so silence is the only honest fill - the alternative is letting the ±8ms error accumulate at every seam in the chain.

match_tail is one of those settings where the default is correct and the only reason to touch it is if you're doing something unusual with a silent clip. If your H3 clips have no audio at all, just leave the audio input unwired.

What can go wrong

• "Asked to trim X frames from a Y frame clip" - you asked to drop more frames than the clip contains. Usually a stale trim_frames hardcoded on a short final clip; wire it from the Motion Context output instead.
• Audio still drifts after trimming - check fps on this node matches the encoder's, and that the audio input is actually connected. Trimming images alone is the classic half-fix.

Install is the pack install - Manager, search "H3 Motion Context", or git clone https://github.com/Ltamann/ComfyUI-H3-Motion-Context-Auto-Chain-addon into ComfyUI/custom_nodes/, then restart. No dependencies beyond what your H3 workflow already pulls in (numpy, Pillow, imageio-ffmpeg). If this node looks familiar, it's because it inherits directly from the original H3 Motion Context package's trim node - the addon just names it under its own namespace so both can coexist.