MiniMax H3 Audio Refine Audit / 音频精修前置审计 (T8 Advanced EXP)
The bouncer for H3's audio-refine chain — check everything before you burn a run
- model
- positive
- av_latent
- protected_audio
- audit
- decision
- report_json
MiniMax H3 generates picture and sound together, which is exactly why fixing the sound is annoying: re-run the whole model to fix a bad line of dialogue and you risk changing the video too. The T8 answer is "Audio Refine" - re-sample only the audio stream with a short masked tail while the video stays pinned. It's powerful and it's expensive, so the chain starts with a bouncer. This node is that bouncer. It's a read-only audit that checks whether a refine run is even mechanically safe to attempt, and it says so before you spend the GPU time.
The audit is the first node of the single-model refine chain (Audit → Plan → Dual-Clock Setup → SamplerCustomAdvanced → Quality Gate). Everything downstream treats its audit output as the signed pass to proceed. The important word in the node's description is precondition: ALLOW is only a mechanical precondition - it means "nothing here obviously breaks the refine," not "this will sound better." The gate for "does it actually sound better" is the human quality gate at the end of the chain, not this node.
What it checks
- model, positive (CONDITIONING), av_latent - the exact artifacts the refine would run on
- conditioned_prompt, media_map_json, conditioning_report - the prompt and media wiring, so it can tell whether the run is telemetrically complete
- minimum_free_vram_mib (512) and minimum_commit_headroom_gib (16) - resource floors
- hash_chunk_megabytes (8) - chunk size for hashing, only relevant to the audit internals
- protected_audio (optional AUDIO) - here's the interesting one: if you connect audio that must not be touched, the audit ABSTAINs, because an uncached refine tail could alter it
It outputs an audit object (signed, feeds the next node), a decision (ALLOW / ABSTAIN), and a report_json explaining the verdict. The tooltip-worthy gotcha: protected audio, unvalidated patches, and insufficient telemetry all force an ABSTAIN even when everything else looks fine. That's the design - when in doubt, it refuses to bless the run.
Installing it
Part of the T8mars/comfyui-minimax-h3-audio-T8 pack - search "MiniMax H3 Audio T8" in ComfyUI Manager, install, restart, or:
cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8
Update ComfyUI itself first (recent core: comfy_api.latest, comfy.weight_adapter, comfy.patcher_extension, comfy.ldm.minimax); requirements.txt is intentionally empty. Audio Refine is an EXP feature, so start from the bundled workflow rather than hand-wiring the chain.
Where people get burned
The most common stumble is wiring the wrong artifacts: the audit hashes and validates what you connect, so if media_map_json doesn't match the actual inputs, it'll ABSTAIN on a run that would have been fine - or worse, bless one built on bad telemetry. Keep the prompt tags (<Audio 1>, <Video 1>…) numbered to match real connections; that's the pack's standing rule and this node is where it bites. And treat an ABSTAIN as information, not a bug: it's usually telling you a real reason the refine would misbehave, like a protected audio input you forgot was connected.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| positive | CONDITIONING | — | |
| av_latent | LATENT | — | |
| conditioned_prompt | STRING | — | |
| media_map_json | STRING | — | |
| conditioning_report | STRING | — | |
| minimum_free_vram_mib | INT | 512512–65536 | — |
| minimum_commit_headroom_gib | FLOAT | 1616–512 | — |
| hash_chunk_megabytes | INT | 81–64 | — |
| protected_audioopt | AUDIO | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| audit | H3_T8_AUDIO_REFINE_AUDIT | — |
| decision | STRING | — |
| report_json | STRING | — |