H3 Context Trim

H3 Context Trim exists because of a dirty little secret about how clip chaining works: the next clip doesn't start where the last one ended. It re-treads the overlap first. When H3 Context pins a run of the previous clip's frames as conditioning, those frames land at the start of the new clip's timeline - so clip two begins by replaying the tail of clip one, then carries on into genuinely new footage. H3 Context Trim removes that overlap from the decoded output, so what you're left with is a clip that continues seamlessly.

Wire it once and you never touch it again. It's the "set once, forget" node in the suite's own description.

How it works

The honest version of the mechanism is in the source docstring, and it's the reason this node isn't just a frame-cropper. Trimming only the pictures would leave the audio a full trim_frames long - at 5 frames that's 208ms of sound floating ahead of the picture, offbeat on anything with a pulse. So this node trims both streams by the same duration: whole frames off the head of the images, the matching number of samples off the waveform.

Then there's the tail problem, which is sneakier. H3's audio latent runs at 40 Hz against 24 fps picture, and the rounding doesn't divide evenly - a 124-frame clip wants 206.67 audio steps, and the layout rounds up to 207. Every clip therefore ships about 8ms more sound than picture. One clip, imperceptible. Thirty clips in a chain, and the error has accumulated into a faint dampening at the first join and a short click at later ones. match_tail (default on) truncates or zero-pads the audio so its duration equals frames/fps exactly, and stops that drift from compounding down the chain. It's the kind of detail that takes the pack's author to notice and the rest of us to be quietly grateful for.

The inputs

• images - the decoded frames from the sampler, before you save anything.
• trim_frames - how many frames to cut. Wire this from H3 Context's trim_frames output, not a literal number - the count has to follow whatever the encoder actually produced. (On clip 1 of an empty project, H3 Context passes trim_frames=0 through, so this node trims nothing and the first render is untouched.)
• audio (optional) - decoded audio for the same clip, trimmed by the matching duration. Leave unwired for silent clips.
• fps (default 24) - used to convert the trim into an audio duration. Must match what you feed Create Video; if your audio comes out a beat off, this is the first thing to check.
• match_tail (default on) - the 8ms tail fix above. Leave it on.

The outputs

• images - the trimmed frames, which go to H3 Project Save (or anywhere else you'd send a finished clip).
• audio - the trimmed audio, locked to picture. Feed it to H3 Project Save alongside the images.

Install

Same as every node in this suite: ComfyUI Manager → search "H3 Project Suite", or cd ComfyUI/custom_nodes && git clone https://github.com/Adudeguyman/ComfyUI-H3-Project-Suite, restart, hard-refresh. It's pure tensor slicing - no extra dependencies of its own.

The only real failure mode is wiring trim_frames from anywhere other than H3 Context. Use a literal and the moment you change context_length on the Context node, the count silently stops matching what the encoder produced, and every join in the chain is either overlapped or gapped. That's why the pack hands it to you on a wire - take the wire.