MiniMax H3 Finite Segment Finalize (Internal)

The economics of overlapping-segment generation are slightly absurd: you deliberately generate frames twice, then throw one copy away. This node is the throwing-away. It's internal, it's tiny, and if it gets skipped you get visible double-ups at every join.

How it works

One rule drives everything: the preceding segment owns the visual overlap. So the incoming segment's frames get sliced from the front by the aligned overlap, and when there's accumulated output already on hand, the previous frames are prepended to that trim rather than concatenated alongside it. If you'd instead appended the untrimmed segment, every join would replay the same half-second of action - which, honestly, is a mistake you'll make once by hand and never forget.

The trim count is zero for the first segment and zero when the overlap is zero. Otherwise it's the H3-aligned value, the same one the continuation node reported - not the number you typed into the planner.

Audio has a switch. trim_audio_head defaults to true, and that's correct for fixed audio: sliced by frame math into samples (trim_frames / 24 * sample_rate), removed from the front. But for generated soundtracks the pack deliberately sets it to false and hands the seam to the incoming segment instead, trimming the previous audio's tail with the dedicated tail-trim node and letting the Soft AV release land in the final mix. Setting this wrongly is the difference between a clean crossfade and a repeated syllable.

It validates before it cuts - if the decoded segment is shorter than the trim, it raises with both numbers instead of returning an empty tensor.

Inputs and outputs

Required: sampled_latent, images, iteration (force-input), overlap_frames (default 22), trim_audio_head (default true). Optional: audio, accumulated_images.

Optional inputs are worth understanding because this node is dual-purpose. With no accumulated_images, it's a plain deduplicator that returns this segment's trimmed output. With accumulated_images connected - which is what the sampler does from segment two onward - it returns the running merged timeline instead. Same for audio joining downstream. So the same node is used both as a per-step trimmer and as the merger, and the difference is purely which optional inputs you connect.

Outputs:

• Complete Latent - the sampled latent passed through untouched. It's here so the node sits between the sampler and whatever wants the latent without breaking the chain.
• Deduplicated Frames → the merge or the saver.
• Deduplicated Audio → the join.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Songssx/ComfyUI-MiniMaxH3-TimelineDirector.git

Restart and search MiniMax H3. No pip step - empty dependency list; the pack runs on PyTorch, torchaudio, PyAV and what a normal ComfyUI install already carries. Internal nodes like this one only show in the node menu with dev mode on. Prerequisites: native H3 nodes in ComfyUI, the H3 Ref2VA model, CLIP, video VAE and audio VAE, Python 3.10+.

Common issues

"This segment has only N frames; cannot remove an M-frame overlap." The decoded segment is too short for the trim - usually because the overlap snapped to a larger legal value than the window expected, or the segment's frame count is near the minimum. Lengthen the GEN window.

"This segment's audio is too short to remove the overlap." Same problem on the audio side, and note it's checked in samples at whatever sample rate the decoded audio carries. If the video frames pass and the audio fails, the segment is right at the boundary in time.

Visible doubled action at a join. trim_audio_head or the alignment value got out of sync - or something upstream is passing the untrimmed frames forward. The Actual Overlap Frames output exists precisely so every consumer uses the same snapped number.

Audio-only glitch, video fine. trim_audio_head is true when it should be false. For generated soundtracks the pack wants the tail-trim path, so the incoming segment's soft release reaches the final file.