MiniMax H3 Speaker Routing Audit / 多人对白路由预检 (Advanced/T8)

Multi-speaker dialogue in H3 works by mapping each speaking character to an <Audio N> reference. Get that mapping wrong - two characters pointing at the same reference, a descriptor like "the other woman" that the model can't disambiguate, a laugh that isn't a structured line - and your render silently casts the wrong voice, or produces something unintelligible, and you've wasted the run. MiniMaxH3SpeakerRoutingAuditT8Advanced is a preflight that catches exactly this before sampling, by compiling the dialogue plan's speakers into deterministic <Audio N> ordinals and abstaining when the evidence is ambiguous.

It's from the pack's audio-integrity family of audit nodes, and it shares their personality: CPU-only, report-first, never modifies your dialogue plan. It says "this routing looks safe / looks broken," and leaves the plan untouched.

How it works

Give it a dialogue_plan (the pack's H3_T8_SPEECH_PLAN). It walks the plan, assigns each speaker a stable <Audio N> ordinal, and checks that each reference voice is present and unique. Then:

• require_reference_voice (True) - if a speaker has no reference voice, the audit abstains. You're doing clone-mode dialogue; a speaker without a reference is a missing input.
• descriptor_similarity_threshold (0.75) - how similar same-gender descriptors have to be before they count as ambiguous. This is the "two women talking, both just called 'the woman'" detector.

It also flags unstructured vocalizations (laughs, sighs, breaths that don't belong to a routed line) and descriptor ambiguity. If anything fails, you get an ABSTAIN decision - a clear "don't render this yet" - with a binding_json showing the exact speaker-to-<Audio N> mapping it compiled, so you can see what's broken and fix the plan.

Outputs: the unchanged dialogue_plan (pass-through), pass_audit (bool), decision, binding_json, and report_json.

Where it sits

The pack's speech workflow order is explicit (in examples/workflows/05-speech-dialogue/README.md): generate audio → integrity audit → speaker routing audit before multi-turn generation → perceptual drift audit after. So this node goes before the per-turn conditioning, ideally as a gate: run the audit, read the binding JSON, only proceed when it passes. The example workflow is 2026-08-22_H3_Speaker_Routing_Audit_Advanced.json.

Install

Pack standard -

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

then restart (or Manager, search "MiniMax H3 Audio T8"). No extra pip packages, no models - pure CPU plan analysis.

The honest take

This is a cheap node that answers a genuinely expensive question: "is my multi-speaker plan going to render the right voices?" Its fail-closed personality means you'll occasionally get an ABSTAIN on a plan that might have worked - that's the price of not wasting renders, and it's the right trade. The README's guidance on multi-speaker audio is blunt: the mapping must be one-to-one, reference audio per character, or the model can't route. Run this node and let it tell you which of those rules your plan is breaking.