H3 Face Parity · Bind Separate Stage (T8 EXP)

Face drift in video is not uniform. Frame 12 is fine, frame 40 is fine, and somewhere around frame 26 the nose changes shape for four frames. A single global denoise strength either under-fixes the bad stretch or over-processes the good one, which is how you trade a wobble for a plastic face.

The parity variant of this pack's face pipeline exists for that case. It uses a parity plan - a per-frame denoise plan with an optional sampler-mask patch - and this node binds that plan to a separate sampling stage.

What "separate stage" buys you

Exactly what it sounds like: the repair runs on its own MODEL, SAMPLER, SIGMAS and AV latent, entirely outside the main generation. You can run a refinement-tuned model here, or a different attention backend, without touching the pipeline that produced the film. The parity plan decides where, this node decides with what.

The per-frame denoise values and the optional sampler-mask patch stay external - they are properties of the plan, not of this bind. That is why the node's own description says they are kept external: you change them in the plan, not by re-wiring.

Inputs and outputs

• face_plan - the parity plan. Not the standard face plan and not a window plan; each variant has its own bind node, and mixing them is an error rather than a creative re-interpretation.
• source_frames - the frames the plan was built against, checked for count and dimensions.
• model, sampler, sigmas - your repair stack, checked to be consistent with the plan's geometry and with the AV latent.
• av_latent - the packed AV being repaired.
• audio_policy - require_locked (default) demands an exactly all-zero nested audio mask, so the audio region is pinned and nothing gets resampled there. preserve_existing keeps whatever mask came in, which is what you want when you accept that the audio is in play.

Outputs: the bound model, sampler, sigmas for the sampling stage, a typed stage_context, and report_json.

The sampler identity detail worth knowing

The plan's completion can be certified when the sampler is an exact match to the source - that is the default Core er_sde case. Run an unknown or third-party sampler and it still works, but the pack will not claim portable identity for the result; the completion stays unverified rather than being dressed up as validated. If you are chasing a bug across runs, use the recognised sampler so the receipt means something.

Wiring

Parity plan + source frames → Parity Bind → sampling stage → Parity Stage Audit → Parity stitch.

Two nodes, not one, because the pack separates "did I set this up consistently" from "did the sampler actually produce what I think it produced". Skipping the audit is allowed and tempts people; you lose the source-bound check, which is the only thing standing between you and stitching a candidate from a stale plan.

Install

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

Then fully restart ComfyUI, because node registration happens at import - a page refresh will not surface these classes. Or use ComfyUI Manager and search "MiniMax H3 Audio T8". The pack's requirements.txt deliberately installs nothing; the base nodes use ComfyUI's own torch, numpy and Pillow, and optional EXP features check their own dependencies only when invoked. You do need a recent Core with native H3 support, plus the H3 weights, Qwen encoder and both VAEs.

Things that will bite you

Parity plans are geometry, and geometry drifts. Re-detect or rebuild the plan and its hash changes, so an existing bind becomes invalid - you will see a mismatch rather than a subtly misaligned repair, which is the good version of that problem. Rebind and re-sample.

Also resist stacking this with the pack's other face variants on the same model. The pack maintains separate adapters precisely so that a standard face stage, a parity stage and a window stage do not get conflated; each has its own plan type and its own recipe, and the code refuses cross-wiring rather than guessing. Pick the one that matches the problem you actually have: whole-clip softness is the standard plan, frame-specific wobble is this one.