H3 Chunked · Learned Lift ONE Segment (T8 EXP)

The two-pass H3 recipe goes like this: sample the whole thing cheaply at low resolution, blow up the joint latent with the learned 3D upscaler, then spend the last few steps at high resolution. The pack's chunked route breaks that second pass into time segments so the high-res transformer never sees the entire timeline at once, which cuts the activation peak.

This node handles exactly one of those segments, and only the lift part of it.

What it does

It runs the legacy learned 3D latent upscaler - the same one the non-chunked two-pass route uses, not a reimplementation - on a single sliced first-pass segment. Inputs are source_segment (the slice), segment_spec (which segment this is, typed T8_CHUNKED_SOURCE_SEGMENT), pass2_context (the global state), and plan (the T8_H3_CHUNKED_TWO_PASS_PLAN). Output is lifted_segment plus a report_json.

Two things it explicitly does not do, both from the author's own description: it does not sample, and it does not create a cache receipt. The PASS2 model, conditioning, noise and sampler all stay external and independent. So if you queue a graph with only this node in it, you get a lifted latent and no video. The node's contract is one slice, one lift, done.

Why the separation is worth the extra node

Because "did the upscale actually run on this segment, with this geometry, from this source?" is a question that's miserable to answer retrospectively. Here the lift is a discrete, inspectable step with a spec and a context attached. When a later audit tells you the lifted target geometry didn't match the plan, you know which node to look at.

The practical consequence is that you get to choose the model for the second pass independently of whatever ran pass one - which is the entire point of a two-pass recipe. That's the pack's standard shape throughout: separate the pipeline into stages that can each be checked, and keep the effects external.

How it slots in

pass1 (low res) → slice into segments → [this node: lift one segment]
                                           ↓
                          PASS2 model/sampler/sigmas → sample that segment
                                           ↓
                                audit → cumulative AV for the next segment

pass2_context comes from MiniMaxH3ChunkedPass2PrepareEXPT8, which is the node that fixes the once-only global noise field and the original full-source mask before any chunk runs. Get that prepared first - this node wants the context, not a per-segment noise value, and the pack's rule is that PASS2 uses the same NOISE seed the prepare step saw.

Standard 4+4 runs on full_frame_safe plans: the whole spatial canvas, no tiles. If your plan is splitting into spatial tiles, you're outside this contract.

Install

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

Manager users: search MiniMax H3 Audio T8. Quit ComfyUI completely and relaunch - the browser refresh will not do it. There's nothing to pip install, deliberately: the pack's requirements file declares no packages so it can never replace ComfyUI's Torch or CUDA stack. What you do need is a recent ComfyUI with native H3 support, plus the weights placed by hand: H3 diffusion model in models/diffusion_models, Qwen text encoder in models/text_encoders, video and audio VAEs in models/vae. The learned 3D latent upscaler is a separate download too - this node runs it, it doesn't include it.

Errors you'll hit

• unexpected keyword argument on a chunked plan node, with a stack path pointing somewhere odd. That's the pack's famous shadow-install failure: an old test copy of the nodes sitting in custom_nodes alongside the real one, providing an outdated builder. Delete or rename the stale directory, restart, and check that /object_info reports the node's python_module as the real pack.
• Wrong segment spec. Passing a slice that doesn't correspond to the segment_spec gives you a geometry mismatch downstream, not here.
• Missing pass2_context. Prepare it first; don't hand-roll one.
• Treating a chunked run as "one 4+4 pass per video". Each window is its own 4+4. The pack's own docs are emphatic about this because people keep re-deriving the wrong forward-call count.