MiniMax H3 Atomic Audio Drive (R21)

MiniMax H3 doesn't just generate video - it generates sound, and one of the trickiest parts of a multi-chunk H3 timeline is deciding where each chunk's audio comes from. Is this segment generating its own audio? Is it being driven by a reference voice from earlier in the timeline? Is it locked to a source slice that must not be regenerated? IAMCCS_MiniMaxH3AtomicAudioDrive is the per-chunk router that answers that question. The docstring calls it "exclusive native/reference/locked/post audio router for one H3 chunk," and "exclusive" is the key word: exactly one behavior wins per chunk, and the node tells you which one it resolved.

The control is audio_behavior, with five choices that map onto the H3 audio model's real modes:

• from_cine_linx (default) - trust whatever the shotplan decided for this segment. Start here.
• h3_native_generated - let H3 generate the audio from the prompt, no external reference. The classic T2VA/I2VA behavior.
• h3_ref2va_audio - drive from REF2VA reference audio (a voice or sound to condition on).
• h3_custom_audio_drive - drive from the source_audio input as a custom signal. This is the R21 custom-drive path: the atomic backend can encode it into the AV latent before sampling, distinct from REF2VA reference audio.
• external_audio_post - don't touch the audio at sampling; the real soundtrack gets added afterward.

Inputs: av_latent (the AV latent in progress, passed through untouched on the latent output), cine_linx + segment_index (where the per-chunk plan lives), the optional source_audio (AUDIO, used by the custom-drive mode) and audio_vae (VAE, if encoding needs it). Outputs are the router's hand: latent (passthrough), reference_audio, locked_audio_slice (the slice that must stay fixed), external_post_audio (the audio reserved for post), and two diagnostics - resolved_behavior and report.

Think of it as four outgoing baskets plus one passthrough. Depending on the resolved behavior, the right audio lands in the right basket, and the downstream audio-output policy node (IAMCCS_MiniMaxH3AudioOutputPolicyR21) decides which of those baskets actually gets written to the master. The separation matters because the drive audio (what conditions the generation) and the output audio (what you keep) aren't always the same thing - H3 might be driven by a reference voice but you still want the master to use the clean source slice.

Installation: search IAMCCS in ComfyUI Manager or clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes, restart. It sits inside the H3 atomic pipeline, so it inherits the family's requirements - native H3 AV support in ComfyUI, the audio VAE, and the rest of the atomic backend wired around it.

The trap to plan around: from_cine_linx is only smart if the shotplan actually has an audio decision for this segment - if you're building a graph by hand and never set one, from_cine_linx resolves to whatever the backend defaults to, which may not be what you wanted. Check resolved_behavior on your first run. And don't confuse h3_custom_audio_drive (which conditions the latent) with external_audio_post (which leaves audio alone) - mixing them up is how you get a chunk that's both conditioned on audio you didn't want and missing audio you expected.