MiniMax H3 Audio Output Policy (R21)

Every audio policy node has the same job, and the job is more interesting than it sounds: decide what gets written. In the H3 atomic backend, a chunk can generate its own audio, be driven by a reference, be locked to a source slice, or get its soundtrack added entirely in post. But the master timeline only keeps one version per chunk. IAMCCS_MiniMaxH3AudioOutputPolicyR21 is the node that makes that final call - it selects the soundtrack that is actually saved for one rendered chunk.

Its docstring lays out the logic cleanly: "Native and REF2VA-reference modes keep H3's decoded audio. Custom-drive and external-post modes use the original source slice, avoiding an unnecessary lossy AudioVAE round trip in the saved master." Read that again, because it's a quality decision disguised as plumbing. When audio is only used to drive the generation, H3 has still decoded it - but shipping that decoded, re-encoded audio to the master means a lossy round trip through the audio VAE for no benefit. This node knows the resolved behavior (from the audio drive node upstream) and picks the source slice instead when the audio was a drive signal, not a deliverable. That's the kind of detail that separates "the master sounds a bit soft" from "the master is the source, untouched."

Inputs: h3_audio (the H3-decoded audio for this chunk), video_frames (the chunk's frames, so the policy can align duration), cine_linx and segment_index (for the per-chunk plan and resolved behavior), plus two optional AUDIO inputs - locked_audio_slice and external_post_audio - which feed the modes that preserve a source slice. Outputs: master_audio (what gets written to the master), resolved_behavior (which mode won - always check this), and report.

It pairs with IAMCCS_MiniMaxH3AtomicAudioDrive upstream: the drive node routes audio into the right baskets, this node picks which basket is the deliverable. If you're only ever generating native audio, this node is nearly a pass-through with a gain stage - but the moment your timeline mixes generated chunks with source-locked ones (dialogue sync, a voice you refuse to let H3 reinterpret), the policy is what keeps the master honest.

Installation: search IAMCCS in ComfyUI Manager or clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes, restart. No extra models; it inherits the H3 atomic backend's requirements (current ComfyUI with native H3 AV conditioning, the pipeline wired around it).

The "R21" in the name is a version marker, and it's worth one honest warning: this family is moving fast (R21/R30 variants exist across the audio nodes), so saved workflows can land on slightly different widget sets after a pack update. If resolved_behavior ever comes back empty or the report looks thinner than expected after an update, refresh the node rather than assuming the logic changed. The thing people get wrong with the policy itself is expecting it to mix - it selects. Mixing is the timeline mix node's job; this one just decides which single soundtrack represents the chunk.