MiniMax H3 Face Refine Sampler-Mask Fix V1.1 / 采样遮罩修正 (Advanced)
The H3 Face Refine v1.1.1 Sampler-Mask Patch
- model
- av_latent
- model
- av_latent
- report_json
Open the pack's 06-face-refine workflows and you'll spot this node sitting wired into the chain with a toggle that's off, doing nothing. That's not a mistake. MiniMaxH3FaceRefineSamplerMaskPatchV11T8Advanced is an opt-in bug-fix switch - a backport of a fix from the upstream ComfyUI-H3-FaceRefine v1.1.1 - and the author's own blind test slightly preferred the old route. Leave it off until you have a reason to compare.
What it's for
This isn't a face-fixer. It's plumbing inside the pack's Face Refine Window feature, which repairs MiniMax H3 videos by re-rendering only the frames where a face broke, instead of re-rolling the whole clip. The good frames get protected by a video noise_mask; only the bad interval is denoised in a second pass. (H3, if you haven't met it: MiniMax's open-weights omni-modal model that generates video and its audio jointly, not an API - everything here runs locally.)
The bug being patched: on the original route, that mask handling wasn't quite right. The video noise_mask leaked into the model's condition path, and the held (already-good) video frames weren't re-noised to the current sigma, so protected frames could sit at the wrong noise level next to freshly denoised ones. Upstream fixed it in v1.1.1. This node applies that fix as an explicit toggle so you can A/B it against the original route frame-for-frame.
How it works
Disabled (the default), it's a pure pass-through: the exact model and av_latent you feed it come back unchanged, and report_json just says so. That's why the shipped workflows can be wired through it permanently without changing behavior.
Enabled, it gets serious about verification. It parses denoise_report_json and checks the live video/audio masks in the latent against the report's SHA-256 hashes, confirms the model is a native MiniMax H3 base, and refuses if anything conflicts. Mismatch, stale report, or a model that's already been patched - it errors out. Failing closed is the point; it would rather refuse than silently generate with wrong masking.
Then it clones the MODEL and attaches two object patches, the actual v1.1.1 fix:
_denoise_mask_conds- strips the videonoise_maskout of what reaches the model, leaving it on the sampler path only (the locked-audio mask condition still reaches H3 untouched).scale_latent_inpaint- re-noises the held video frames to the sampler's current sigma using H3's native noise scaling, with audio rescaled by the model's own time-shift so the two streams stay coherent.
The original MODEL is never mutated - you get a patched clone back.
Inputs and outputs
model(MODEL) - the H3 model from your Face Refine route, on its way to the sampler.av_latent(LATENT) - the joint audio-video latent whose masks get audited.denoise_report_json(STRING) - comes from the pack's Per-Frame Denoise node (MiniMaxH3FaceRefinePerFrameDenoiseT8Advanced) in the Face Refine chain. This is the report that carries the mask hashes.enabled(BOOLEAN, default false) - the only knob a beginner should touch.
Outputs: a (possibly patched) model, the unchanged av_latent, and report_json describing what it did. In the wired workflows the patched model feeds straight into the sampler.
Installing and getting it
Search ComfyUI Manager for "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 restart ComfyUI. This node itself needs no new model or pip package - it's pure code plumbing. The Face Refine workflows around it need the full local H3 stack though: the diffusion model in models/diffusion_models, Qwen3-VL in models/text_encoders, video and audio VAEs in models/vae, plus ffmpeg on PATH for safe saving. The pack expects a fairly new ComfyUI with native MiniMax H3 support; if nodes come up red, update ComfyUI, the frontend and Manager, then do a complete restart rather than just the plugin.
Gotchas
- Enable it and get an error? That's usually a stale or mismatched
denoise_report_json- regenerate the report from the Per-Frame Denoise node rather than reusing an old one. - Don't drop it into a plain T2VA/I2VA graph. It only makes sense inside the Face Refine Window chain (Parity, Window Manual or Studio Serial workflows). The Compose-only workflow doesn't load H3 and doesn't need it.
- The honest take: on the author's one blind-reviewed fixture, the fix didn't perceptually beat the original route - seams tied, quality went to "B" (old). So flipping it on isn't automatically "better"; it's a correction you test on your own bad-face sample. And remember the H3 Community License: its Applicable Territory excludes the EU, UK, South Korea and the US, so local weights aren't licensed in those regions regardless of what nodes you stack.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| av_latent | LATENT | — | |
| denoise_report_json | STRING | — | |
| enabled | BOOLEAN | false | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| av_latent | LATENT | — |
| report_json | STRING | — |