H3 Motion Recovery · Audit Pass 2 Candidate (T8 EXP)

What it is

The last thing between a sampled Motion Recovery pass two and your delivery path. It takes the stage_result the sampler produced (the pack's typed result, not a raw latent), the motion plan, the original baseline frames and audio, the smeared expanded frames and audio seed, the prepare report and the AV latent - plus the optional parent plan/frames/audio if you chained from an accepted segment - and then recomputes the source contract from scratch and compares it to the one that was bound into the stage receipt.

If they differ - different plan, different source frames, different input AV - it raises. The failure mode it prevents is a repaired segment that belongs to a different take than the one you think you're inspecting, which is genuinely hard to catch by eye when the whole point of the route is subtle motion repair.

Output: candidate_av plus report_json.

The sentence worth reading twice

The node's own description says the quiet part: original pass-1 audio remains the safe delivery default. The report confirms it, carrying delivery_audio: pass1_original_default_only and automatic_accept: false.

Translation: the audit is not blessing the repaired audio. Pass two regenerates a joint AV, so its audio is a new audio - and this pack will not tell you it's better than the pass-one track. You get the choice, made deliberately and outside this node: keep the original audio as the delivery default, or explicitly swap in the recovered track after listening. Window collection, the recover-AV step and any human motion/audio review all stay external too. Nothing here auto-accepts.

There's also cache_reuse_authorized: false in the report, which means what it says - this is a verification of a live run, not a portable receipt you can lean on later.

Inputs and outputs

Inputs: stage_result (type T8_STAGE_RESULT - a sampler-produced result, not a plain LATENT), motion_plan, baseline_frames, baseline_audio, smeared_frames, smeared_audio, prepare_report_json, av_latent, and optionally parent_plan, parent_frames, parent_audio.

Outputs: candidate_av, report_json. It's flagged as an output node, so it's a legitimate place to end a graph branch - but remember you still need decode and mux after it.

A sanity check the node performs in passing: the stage receipt's recipe must be the native explicit recipe with the native_high role. Feed it a result from some other route and it will refuse, which is a nice way to catch a mis-pasted stage in a big graph.

Install

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

ComfyUI Manager: search MiniMax H3 Audio T8, install, then fully quit and restart ComfyUI, then refresh the browser tab. Registry and GitHub publish on separate clocks, so clone if Manager lags. Red nodes usually mean core + frontend + Manager need updating together, not just this repo.

Models: H3 transformer in models/diffusion_models, Qwen3-VL text encoder in models/text_encoders, H3 video and audio VAEs in models/vae. No weights ship with the repo and no Python packages get installed by it - requirements.txt is intentionally bare so it can't clobber ComfyUI's torch/CUDA stack. Work from examples/workflows/57-motion-recovery-split; the ..._cold_second_... and ..._full_... variants differ in whether pass one runs.

Common issues

"Motion source, plan or input AV changed after binding." You edited an upstream node after binding, or reloaded a frozen pass one that no longer matches. Rebinding the stage is the correct response - the audit is doing its job.

"Motion stage audit needs a sampler-produced StageResult." You wired a plain LATENT, or a latent from SamplerCustomAdvanced. Use the pack's stage sampler for this route so a T8_STAGE_RESULT exists.

"Motion audit received another stage recipe." The stage result came from a different route in the pack. In graphs that mix HyperFlow, VAE or Progressive stages, this is the error that stops you pasting the wrong branch in.

Audio sounds different after the repair and you don't like it. Then deliver the pass-one audio, which the report says is the default for good reason. Don't patch around it by muting things downstream; decide explicitly, then rebuild the mix.