Nodes/comfyui-minimax-h3-audio-T8/H3 Face · Source-Bound Stage Audit (T8 EXP)
ComfyUI Node

H3 Face · Source-Bound Stage Audit (T8 EXP)

The node that checks your repair is still repairing the right thing

By T8mars·Created 2 months ago·Updated about 7 hours ago· 1,158
H3 Face · Source-Bound Stage Audit (T8 EXP)
  • stage_result
  • face_plan
  • source_frames
  • av_latent
  • candidate_av
  • report_json

Face repair is where a long render quietly goes wrong. The crop is right, the sampler ran, the frames came back - and the candidate belongs to a slightly different window, or a parent you have since re-rendered, or a plan you rebuilt. Stitch it in and you get a face that pops between two identities and you cannot tell which stage did it.

This node exists to make that specific class of mistake loud. It is a post-sampling audit: it takes the actual receipt from the sampling stage and compares it against the current plan, the source frames and the input AV.

What it checks

The receipt, not the intent. The stage result carries what actually executed - the bound plan hash, the source identity, the implementation identity - and the audit re-derives the same contract from the objects you are holding now. If the plan was rebuilt between binding and sampling, or the source frames changed, or the AV latent is not the one that was sampled, the two disagree and you get an error instead of a subtly wrong candidate.

That is the entire value proposition: the audit is bound to the source, so "I think this is a repair of segment 3" becomes "this is provably a repair of the source I just handed you".

Inputs and outputs

  • stage_result - the typed result from the sampling stage, not a LATENT. This node cannot audit something that has no receipt.
  • face_plan - the same standard face plan that was bound. Give it a different plan and the audit fails, correctly.
  • source_frames - the frames the repair was supposed to be based on.
  • av_latent - the input AV the repair was staged against.

candidate_av is the output you wire onward, into the pack's existing stitch node. report_json is the evidence: plan hash, source identity, the audio policy that was in force, and the checked values.

It is an output node, so it runs when you queue even if nothing downstream consumes it. That is intentional - you can park an audit at the end of a repair without having a save wired up, and get the report.

Wiring and ordering

Bind → stage sampler → Audit → stitch.

After the sampler, before the stitch. Auditing after you have already composited gets you a report about a video you have already committed to.

The caveats the author put in the description

Two, and they are the kind of honesty you want from an audit node.

First: you can lock the audio mask, and that does not guarantee bit-exact sampled audio. The mask constrains where denoising happens; it is not a promise that the audio tensor is byte-identical. Deliver the original source audio separately if the soundtrack matters.

Second: this node does not approve anything. It checks provenance, not quality. There is no score, no automatic acceptance, no replacement of your candidate. A repaired face that passes the audit can still look worse than the original, and only your eyes can rule on that.

Installing it

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

Fully quit and restart ComfyUI - the EXP classes only register on import. Manager search: "MiniMax H3 Audio T8". The pack installs no pip packages by design, so it will not stomp on ComfyUI's Torch/CUDA stack; optional features pull their own dependencies only when you use them. Recent Core with native H3 support plus the H3 checkpoint, Qwen encoder, video VAE and audio VAE are still required.

Things that will bite you

If the audit fails right after you rebuilt the face plan - say, because you re-detected faces on the same clip - that is working as designed. The plan hash is part of the identity, so a fresh plan means a fresh bind. Rebind and re-sample; there is no "ignore and continue" and you would not want one.

The other habit worth building: keep report_json when a repair passes. When a later stage looks wrong, the report is how you prove which of the three or four face candidates in a long chain actually produced the frames you are looking at.

CategoryT8/MiniMax H3/Modular Sampling/Experimental

Inputs (4)

NameTypeDefaultDescription
stage_resultT8_STAGE_RESULT—
face_planH3_T8_FACE_REFINE_PLAN—
source_framesIMAGE—
av_latentLATENT—

Outputs (2)

NameTypeDescription
candidate_avLATENT—
report_jsonSTRING—