Nodes/MiniMax-H3-Flow-Aligned-Regenerate/MiniMax H3 Audio Boundary Audit
ComfyUI Node

MiniMax H3 Audio Boundary Audit

Your H3 Continuation Audio Pops at the Join — Is It the Sampler or the VAE?

By xmarre·Created about a month ago·Updated about 18 hours ago· 21
MiniMax H3 Audio Boundary Audit
  • audio_vae
  • audio_latents
  • audio
  • assembly_plan
  • flow_model
  • audio
  • report

MiniMax H3 makes sound and picture in one pass, which is great until you stitch short clips together. Continuation stacks glue chunks at exact carried prefixes, and when the audio at that join clicks, jumps in level or swallows a syllable, you're stuck guessing: did the sampler generate a bad suffix, or is the AudioVAE decoding a fine latent differently because it can't see what came before?

MiniMax H3 Audio Boundary Audit answers that. It's a diagnostic that sits after Audio VAE Decode, forwards your audio untouched, and prints a JSON report about each physical join.

What it actually does

It's a pass-through node with an experiment hidden inside. For every decode group boundary (index 1 and up - the first chunk has nothing to compare against), it runs two extra bounded AudioVAE decodes of the same generated audio. Both contain identical suffix and right context; one gets 32 real earlier latent ticks prepended from the previous chunk.

Then it compares the same 20-tick window (about 500 ms, since H3's audio latent rate is 40 Hz) after the join in both decodes. If those two match, your generated suffix doesn't care about left context, and "the decoder was missing history" stops being a plausible explanation for what you're hearing. That's same_suffix_context_comparison.

Two more numbers matter. common_decode_boundary measures pre- versus post-join loudness inside the extended decode - if that stays discontinuous while the identical suffix is context-insensitive, missing left context isn't the culprit. And production_crop_comparison compares the ordinary full production decode against the bounded baseline, catching truncation or normalization effects before you extrapolate; it's only meaningful when production_crop_comparison_valid is true, which the node sets by checking that standard Comfy audio normalization was provably inactive.

The clever bit is optional flow_model. Plug in the same Flow-patched MODEL your continuation used and the node pulls the cached low_probe_clean audio witness out of the patched model's binding, swaps the generated suffix for the probe-stage version (prefix stays authoritative from the final latent, extra left context identical), and decodes once more. That's stage_localizer - it tells you whether the suffix was already bad at the low/probe stage, i.e. the sampler owns it, or whether it only looks bad after the VAE.

Production audio is never modified; the report carries "production_audio_modified": false.

Inputs and outputs

Four required inputs, all lists (the node runs with list input enabled):

  • audio_vae - the same VAE your decoder used.
  • audio_latents - the original physical audio-latent list, one per decode group.
  • audio - the decoded AUDIO list from that decoder.
  • assembly_plan - the H3_CONTINUUM_ASSEMBLY_PLAN your Continuum stack already carries, the same socket the Continuum Decode Context node takes. There's no generic-H3 mode: the audit reads this plan's magic, its 24 fps and each group's trim_frames to work out how many carried ticks sit at the join.

Optional: flow_model, the Flow-patched model, if you want the stage localizer.

Outputs are audio - the original list, unchanged, wired straight into Assemble exactly where it used to go - and report, a JSON string. Read it in the console, or feed it to whatever text/JSON display node you keep around.

Installing it

ComfyUI Manager, search the pack title MiniMax H3 Flow-Aligned Regenerate. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/xmarre/MiniMax-H3-Flow-Aligned-Regenerate

Restart ComfyUI. Pleasant surprise: the pack declares exactly one dependency, numpy>=1.25 - no PyAV, no exotic wheels, since the heavy lifting is ComfyUI's own H3 support. The functional stack is the expensive part: the production exact-prefix path expects coordinated Sol-H3, VDN-H3-Plus, H3 Continuum-Plus and Latent Upscaler-Plus releases at matching versions. And you need H3 weights you're licensed to run; the MiniMax H3 Community License excludes the US, EU, UK and South Korea from local-weights use.

Where people get burned

Every report says not_evaluated. The classic one. The audit is strict on purpose and each skip has a reason string: native_audio_latents_required if the latents aren't 4-D 32-channel stereo, insufficient_bounded_context if the carried prefix falls outside the 20–128 tick window or the latents are too short, carried_overlap_not_exact if the carried overlap isn't byte-identical between neighbours, production_audio_geometry if the audio isn't 32 kHz stereo or is too short. A "clean" run on a workflow that isn't really exact-prefix continuation produces pages of skip reasons, not errors.

ValueError: audio boundary audit requires a native H3 Continuum assembly plan. You're feeding it something that isn't a plan, or one whose fps isn't 24. There's no generic-H3 mode.

Length mismatch errors. audio_latents and audio must match the physical decode groups exactly. If your graph collapsed or regrouped those lists, the audit refuses rather than guessing.

flow_model_not_connected in stage_localizer. You skipped the optional input or connected an unpatched MODEL. Also watch for ambiguous_low_probe_witness - two sessions claiming the same chunk index, usually two Flow-patched paths in one graph.

Cost is bounded: at most three extra VAE decodes per eligible boundary, each capped at 212 latent ticks. AudioVAE decoding is cheap next to a sampling pass, and the cap stops a long continuation from turning a diagnostic into a second render. Run it while you're chasing a seam, then bypass it.

CategoryMiniMax H3/diagnostics

Inputs (5)

NameTypeDefaultDescription
audio_vaeVAE—
audio_latentsLATENT—
audioAUDIO—
assembly_planH3_CONTINUUM_ASSEMBLY_PLAN—
flow_modeloptMODEL—

Outputs (2)

NameTypeDescription
audioAUDIO—
reportSTRING—