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

Fair warning before anything else: this node, MiniMaxH3AudioRefineCompatStageAuditEXPT8 and MiniMaxH3AudioRefineDualModelStageAuditEXPT8 all display as "H3 Audio Refine · Audit Separate Tail Candidate (T8 EXP)". Identical. Searching the node list gives you three results you can't tell apart. The difference is the plan socket's type, and yes, you will wire the wrong one at least once.

This one belongs to the dual_clock family - the flexible one.

What dual_clock means here

H3 samples video and audio on separate sigma clocks. That's why the pack's standard recipe carries a video shift of 12 and an audio shift of 3: the two modalities get their own noise schedule inside one joint latent. A dual_clock audio tail refine therefore resamples the audio stream on its own clock while the video stays frozen.

The plan behind this family is the permissive one. Refine steps anywhere from 1 to 8, audio denoise anywhere from 0.01 to 1.0, seed up to 2^64−1. Compare that to the compatibility plan, which allows exactly 4 steps and a denoise of 0.35 or 0.50 - nothing in between. If you're experimenting with values rather than reproducing a known-good recipe, this is the family you want.

What the audit does after your sampler runs

It re-derives the checks the bind made. The source AV still has to be the original (not the candidate you just produced), the stage_latent still has to be the one the boundary was signed for, and the setup_report_json still has to match the Setup run that produced the plan. If any of those drifted - a re-run with a changed widget, a half-executed graph - it errors instead of quietly blessing the output.

The abstain rule is the one worth internalising. When the plan signs ABSTAIN, this node returns the original AV byte-for-byte unchanged, with no invented sampling mask and no attempt to promote the candidate. It cannot turn a no-sample path into a sample path, even if the graph around it looks like it should have sampled.

And a blunt limitation: it does not accept the candidate either. Its job is to verify, report, and hand the candidate on. The pack's Quality Gate and a human listen remain the authority. If you were expecting this node to "apply" the refined audio, the graph will look like it did nothing.

Sockets

Inputs: stage_boundary (from the matching dual_clock Bind), plan (typed H3_T8_AUDIO_REFINE_PLAN), original_av_latent, stage_latent, setup_report_json, and candidate_av_latent - the sampler output you want checked. Outputs: candidate_av_latent and report_json. It's an output node, so the report also renders on the node.

Read the report. It's where the abstain reason and the residual picture live; the output latent alone won't tell you whether you got a refined tail or a passthrough.

Install

ComfyUI Manager, search 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

Then fully quit and restart ComfyUI. Refreshing the browser will not surface new nodes. There's nothing to pip install - the pack declares no extra dependencies on purpose, so it can't disturb your Torch/CUDA setup. It does require a reasonably current ComfyUI with native H3 support, and it contains no model weights: H3 goes to models/diffusion_models, Qwen to models/text_encoders, the video and audio VAEs to models/vae.

Where it bites

• Wrong family, same name. Check the class name on the node (or let the typed plan socket reject the wire) before you assume the audit is broken.
• Stale setup report. Feeding a report from another setup run fails validation, correctly.
• Assuming it approves. It doesn't; Quality Gate plus listening does.
• Two installs of the pack. This repo has a documented history of an old test copy shadowing the real module. One copy only.