FrameFuse Trim End

FrameFuse Trim End is the cleanup half of the FrameFuse pack. The main node stitches a still frame onto a video batch; this one cuts extra frames off the end and trims the matching audio to match. If the first node is how you add a reference window, this is how you take it back off - or how you rescue a clip that a downstream pass grew past its intended length.

It ships in the same comfyui-framefuse install, so there's no separate setup: install the pack once (ComfyUI Manager → search "FrameFuse", or git clone https://github.com/headline-design/comfyui-framefuse into custom_nodes/ and restart), and you get both nodes. Zero extra dependencies, no model files - just torch, which ComfyUI already has.

How it works

Same simple philosophy as its sibling: your video is an IMAGE batch of shape [B, H, W, C], and "trimming the end" is a plain tensor slice - video_frames[:-trim_count]. The clever bit is that it keeps audio in lockstep. When you wire in ComfyUI AUDIO (the waveform + sample_rate dict that VHS_LoadVideo gives you) and leave trim_audio on, it slices the same trim_count / fps seconds off the tail of the waveform. Add 12 frames, cut 12 frames, and your audio still lands on the beat it did before.

The inputs that matter

Only four, and you'll touch maybe two:

• video_frames - the IMAGE batch to cut down.
• trim_count - frames to remove from the end (default 1, up to 1024).
• fps - only matters for audio math. Set it to the clip's real frame rate or the audio cut lands in the wrong place.
• trim_audio - default on; trim the matching duration off the end of audio. If no audio is connected, it just reports "No audio input" and moves on.

Outputs mirror the main node: TRIMMED_VIDEO (wire to VHS_VideoCombine.images), AUDIO, FRAME_COUNT, and a REPORT string that tells you exactly how many frames and how many audio samples came off.

The traps worth knowing

• It refuses to cut everything. trim_count that would remove all frames throws a ValueError - it won't hand you an empty batch. If you're trimming to zero, that's a sign you've pointed it at the wrong clip.
• The audio trim is duration-based, not sample-count-based. The math is sample_rate × trim_count / fps. If your fps is wrong, the audio cut and the frame cut silently disagree and you get drift - the same failure mode as the main node, just in reverse.
• REPORT is your debugging friend. "Trimmed 4000 audio sample(s) from the end" tells you whether the audio actually moved before you blame the encode step.

Honestly, it's a thin utility - a slice and an audio cut. But once you're doing scaffolded video editing, where the reference window comes off after the downstream pass, "thin" is exactly what you want: one node, no surprise behavior, and audio that stays where it belongs.