H3 Audio Refine · Audit Separate Tail Candidate (T8 EXP)

Three nodes in this pack carry the display name "H3 Audio Refine · Audit Separate Tail Candidate (T8 EXP)". This is the dual_model one, and the only honest way to tell it from its siblings is the class name or the type on its plan socket: H3_T8_AUDIO_REFINE_PHASE2_PLAN.

Blame the pack for the naming, but not for the design. The typed socket means a mis-wire is a red line, not a silent numerical mess.

Where dual_model differs

The dual_clock family refines the audio tail on the same model that produced the first pass, with the video and audio clocks separated. The dual_model family is for the phase-2 route: a second model takes over for the refine, and the plan builder that feeds this audit is correspondingly strict - exactly 4 refine steps, and an audio denoise of either 0.35 or 0.50 as pre-registered points. No slider wandering here. If you want to sweep denoise, use the dual_clock plan instead; this contract is deliberately narrow because it's tied to a second model's geometry.

Practically that means: if you're re-running someone else's phase-2 recipe, this is the audit. If you're inventing your own schedule, this is the wrong family and the bind will refuse the plan anyway.

What it checks, and what it refuses to do

It re-derives the bind's assertions after your external sampler has finished. original_av_latent must still be the original AV - not the freshly sampled candidate. stage_latent must match what the signed boundary was created for. setup_report_json must still correspond to the Setup run that produced the plan. Any drift is an error, not a warning.

Then the abstain rule. If the plan signed ABSTAIN, this node returns the original AV exactly as it arrived, with no synthesised mask and no promotion of the candidate. A no-sample path stays a no-sample path.

And the limit people trip over: it never accepts the candidate. Its output is the candidate, plus a report - the verification is the product. The pack's Quality Gate and a human listen stay authoritative, and the pack's default is to deliver the original audio. If you queue this and expect the refined tail to have replaced anything, you'll conclude the node is broken. It isn't; you skipped the gate.

Sockets

Inputs are stage_boundary, plan, original_av_latent, stage_latent, setup_report_json and candidate_av_latent - the last one being your sampler's output. Outputs are candidate_av_latent and report_json, and it's an output node, so the report also draws on the node face. That report is where the useful information is: the abstain reason, the residuals, what the checks saw.

Getting it installed

ComfyUI Manager → search MiniMax H3 Audio T8. Or, which I'd do anyway given how often Registry lags GitHub here:

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

Quit ComfyUI completely and relaunch. Refreshing the page is not a restart and won't register new node classes. Nothing to install via pip - the pack's requirements file is intentionally empty of packages so it can't disturb ComfyUI's Torch/CUDA stack, which is a decision I wish more authors made. It needs a current ComfyUI with native H3 support, and it ships zero weights. H3 diffusion model → models/diffusion_models; Qwen text encoder → models/text_encoders; video and audio VAEs → models/vae.

Common snags

• Picking the wrong audit. Same display name, three families. Check the class name.
• Reusing an old setup report across setup changes. Validation failure, correctly.
• Feeding a non-AV latent as the source. The audit expects the joint latent with the audio-locked mask; a plain encoded latent won't classify.
• Two copies of this pack sitting in custom_nodes. This repo has a documented history of an old test copy shadowing the live module and producing tracebacks from code that isn't in your install. Keep one.