FastH3 V2 · Accepted Remainder Window (T8 EXP)

What it is

A geometry node with an opinion hidden in a dropdown. When you continue an accepted H3 segment, the continuation pass has to re-see some of the frames you already accepted - that's the context that keeps motion, identity and audio continuous - and then render fresh frames past them. This node decides how big that second render window is.

Two choices, and they are not equivalent:

• compact_remainder (the default) gives you 90 frames: 22 frames of accepted context plus the 68 new ones. Exactly what the delivery needs, nothing more.
• old_fixed_124 gives you 124 frames, matching the legacy loop's fixed second-render window - and discards a 34-frame suffix that you never deliver.

Both trim the same delivery. The only difference is how much you make the sampler compute and then throw away. The node's description says it plainly: geometry only, no sampler in here.

The frame arithmetic

total_accepted_frames defaults to 192 - the pack's standing 8-second two-segment contract, where segment one contributes 124 frames and the continuation adds 68. The accepted timeline already ends at frame 124, so new_frames comes out at 68, and the compact window is context_frames + new_frames = 22 + 68 = 90.

Why 90 rather than, say, 84 or 100? Because H3's native lengths live on a 5 + 17n grid - the pack's own widgets use a minimum of 5 and a step of 17 - and both 90 and 124 land on it. The node actually validates this: if the computed window isn't a legal native render length, it refuses. You can't talk it into a window the model can't render natively.

And old_fixed_124 isn't a free choice on any old chain. The pack enforces the exact 8-second contract for it: the accepted timeline has to end at 124, the context has to be 22 frames, the total has to be 192, and the fresh count has to be 68. Anything else and it refuses rather than silently producing a mismatched window.

Ports

Inputs: contexts (the verified accepted-parent contexts), total_accepted_frames (default 192), and optional render_policy (compact_remainder by default, or old_fixed_124).

Outputs: length (the render window to feed your stage), new_frames (how many fresh frames you'll deliver), and report_json.

Which one should you pick?

compact_remainder unless you have a specific reason. Rendering 124 frames when you deliver 68 is 38% more sampling work for output you bin, and on an 8-step distilled student that's still a real chunk of your evening. The pack kept the old policy because existing workflows were pinned to it and old graphs don't get silently rewritten - not because it's better.

That said, there's one legitimate argument for the fixed window: comparability. If you're A/B-ing against a previous render made with the old 124-frame loop, using the compact window changes more than one variable at once. Same reasoning as any controlled experiment.

Reach for it in the right place

This node is a pure geometry calculation sitting between the accepted-context port and the stage setup. Its length output should drive the stage length, not be overridden by a number you type somewhere else - otherwise you queue a 124-frame render, trim to 68 on delivery, and wonder why the timing didn't change when you flipped the policy. Read report_json: it records the policy, the render frame count and how many frames were discarded, which is the only reliable way to know what your graph actually did.

Install

ComfyUI Manager → MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Quit ComfyUI fully, restart, refresh the browser. No pip install: the pack's requirements.txt is deliberately empty so nothing can replace ComfyUI's Torch/CUDA stack, and the optional EXP features check their own dependencies only when used. You need a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, video and audio VAEs in models/vae, and the FastH3 V2 ConvRot INT8 checkpoint for the V2 stages.

Where it goes wrong

The context input isn't a plain context - it's the pack's verified accepted-parent type. Feeding it something hand-built, or contexts from a chain you haven't accepted, gets you a refusal that reads like a type error. That's intended: the whole point of a window node is that the window is relative to a parent whose position in the timeline you can trust.

The other one is a total_accepted_frames that doesn't match the chain you're continuing. It defaults to 192, which is right for the standard 8-second pair and wrong for anything else - and the failure shows up here as a legality complaint about the render window, several steps before you'd otherwise notice.