MiniMax H3 Audio Plan Step V2

A MiniMax H3 render can legally be 124 to 362 frames and nothing else - the frame count has to sit on the 17k+5 grid, which is why nobody hand-writes a long H3 video as one graph. You generate task after task and append them. The Planner V2 decides what those tasks are; MiniMax H3 Audio Plan Step V2 is the node that cashes one task out into concrete values: this audio slice, these frames, this crop, this image, this prompt.

If you're building or debugging a segmented H3 timeline, this is the node you'll be staring at, because it's where a plan turns into things you can wire.

How it works

You feed it the plan, a zero-based task_index, and the same master/guide audio and image batch the planner saw. It validates all of that, then resolves task N:

It slices the conditioning audio at native sample rate to that task's exact sample range - including warmup context, which is real preceding master audio, with silence padding only past the edges of the master timeline. It picks the original image that owns this interval. It pulls the last 22 accumulated frames as the continuity clip when the task is a generated-continuation task. And it reports the legal render length, how many leading frames are hidden warmup or hidden endpoints, and exactly how many frames you keep from the decoded result.

Everything about that is deliberately explicit: an H3 task renders more frames than it contributes, and the difference has to be cropped before the frames are stitched, or your timeline slides.

Inputs that matter

• plan - the MINIMAX_H3_SEGMENT_PLAN from Planner V2. It's strict: legacy version-4 plans, malformed ranges and invalid render lengths are rejected outright.
• task_index - which task to resolve. Task 0 is your base, everything after it is an extension task.
• conditioning_audio - must be the same source the planner planned: same sample rate, same sample count. A different node output with the same content will still fail the check.
• image_batch - the same original sequence, same count.
• previous_frames (optional) - the accumulated retained output before this task. Task 0 must not receive it; extension tasks must, or they can't continue the timeline. It's sliced only when the plan actually wants generated technical continuity.

Outputs

Fifteen of them, and the contract is stable, so a workflow can wire them by name. The ones you'll actually connect: audio_slice into the H3 audio guide, continuity_clip and its has_continuity flag into the image guide chain, source_image plus has_start_guide / start_guide_frame_index into the conditioner, and last_image with has_last_image / endpoint_frame_index for bridges and endpoints. render_frames is what you render; crop_start_frames and keep_frames are what you crop and append. prompt_index, conditioning_family and ref_image_size travel through to Segmented Conditioning V2 so the prompt and the payload family stay the same on both sides of the seam.

has_continuity, has_start_guide, has_last_image and the index outputs are all booleans/ints plus the tensors they gate - that's on purpose, so you can branch lazily and not evaluate a guide you don't need. Hidden anchors, endpoints, warmup padding and grid padding all have to be removed by the planned crop before frames hit the retained timeline.

The reading of the timeline that follows from this: stitch retained decoded frames directly, trim to the exact planned count, and mux the untouched master audio once at the end. No crossfades. A crossfade hides a failed transition instead of fixing it, and it also desynchronises the frame math.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse
pip install -r ComfyUI_Eclipse/requirements.txt

Or install "ComfyUI Eclipse" from ComfyUI Manager (registry publisher rvage) and restart. The dependency list is unremarkable and ComfyUI already ships most of it, so the pip step is often unnecessary. You will separately need H3 weights and the matching checkpoint family; Ref2VA needs Ref2VA weights.

Where people get burned

The validation errors are unusually good, so read them literally:

• "Accumulated timeline drift at task N: expected X frames, received Y" - you appended the wrong number of frames somewhere upstream. Usually a crossfade, a missed crop, or a trim by the wrong output.
• "conditioning_audio sample rate/count differs from the V2 plan" - you swapped audio nodes between the planner and this one. Point both at the same loader output.
• "Task 0 must not receive previous_frames" - your loop is feeding task 0 output back into itself.
• "Generated continuation requires 22 accumulated frames" - a continuation task was reached before 22 frames existed.
• "task_index N is outside the plan's M tasks" - off-by-one in your loop, usually because extension_task_count was treated as inclusive.

One structural caveat: these three V2 nodes are new in Eclipse 4.3.41 alongside the still-shipped legacy H3 nodes. If a tutorial's graph carries a MINIMAX_H3_AUDIO_PLAN, that's the old path; this node won't accept it.