MiniMax H3 舞蹈动作参考 / Dance Motion Source (EXP/T8)
H3 Dance Motion Source
- source_frames
- source_audio
- source_motion
- report_json
- aligned_original_audio
What you actually get
You have a dance clip you like. You want H3 to shoot it again with your character instead. MiniMaxH3DanceMotionSourceEXPT8 is the input half of that trick: you hand it the source frames in their original constant-frame-rate order, and it hands the long-video loop a motion reference the loop can read segment by segment.
Motion transfer was the thing people grabbed onto at H3 launch - the community's own shorthand for the model was "V2V motion transfer like Kling" (MiniMax H3 panel). This node is the T8 pack's own implementation of that editable-reference role. It is not a port of some upstream DanceTransfer sampler, and it is explicitly not pose control: the author's own description says soft RGB reference, and the video prompt rules in the pack's docs make you say so out loud - the source provides motion, timing, direction and camera, and your target image provides the person.
If you came here expecting ControlNet-for-video, there isn't one - on 2026 video models, hard structure control runs through VACE or IC-LoRA adapters instead (ControlNet essay). This node is the looser thing: a reference clip the generator follows, not a skeleton it obeys.
How it works
Wrap your source in a DanceMotionSource: a floating-point RGB IMAGE batch of shape [frames, height, width, 3], at least 5 frames, kept contiguous on CPU. Only the per-segment windows get encoded to the VAE, which is why the node is fussy about handing it CPU tensors.
Frame rate is a rational, not a float - source_fps_numerator / source_fps_denominator, 24/1 by default. That's deliberate: 23.976 and 29.97 are exactly representable, so a 362-frame source doesn't drift a frame or two by the end of a long take. Each segment of the loop computes its own source interval, overlap included, and pulls frames with a zero-order hold at floor(timestamp × fps). There is no automatic speed change and no resampling - if your source is 30 fps and your timeline is 24, that is your problem to fix, not the node's.
The loop hashes the full RGB content of the reference as part of its cache identity before sampling or resuming, so two different dancers never share a cache entry by accident.
Inputs and outputs that matter
source_frames- the IMAGE batch. This is the one input you must wire.source_fps(optional) - connect it to the fps from Get Video Components. It overrides the manual rational pair and fails loudly if your value can't be represented exactly as a fraction.source_start_seconds- offset into both the frames and the audio. It moves your music start at the same time, which is the point.source_audio(optional),source_fps_numerator/source_fps_denominator- leave at 24/1 unless you know better.
Three outputs. source_motion (type H3_T8_DANCE_MOTION) plugs into the optional source_motion input on the pack's in-node long-video loop node. aligned_original_audio slices the original PCM to your start offset - no resample, no remix - and goes to the loop's final audio. report_json is a status string: prepared_not_sampled with the frame count, the rational fps and the audio alignment report.
Installing it
The pack is MiniMax H3 Audio T8 in ComfyUI Manager - search that, install, then fully restart ComfyUI, not just the frontend.
cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8
Its requirements.txt is deliberately empty; the heavy dependencies come from your existing ComfyUI Torch/CUDA stack, so an install can't break it (ecosystem essay). It does need current native H3 support in ComfyUI - red nodes after install usually mean core and frontend are behind.
Where people get burned
Variable-frame-rate sources. The author says it plainly: normalize first. A phone clip that reports 30 fps while carrying a variable cadence will align "correctly" and still look wrong.
Watch your source length. LoadVideo decodes the whole thing into RAM. The accepted Dance example used a 15-second, 362-frame constant-rate source and only delivered the first 192 frames at 24 fps.
Then the usual H3 caveats. This is an EXP node in a pack that publishes failed experiments alongside passing ones; the pack's own record says the accepted 8-second Dance sample needed the segment-low-context seam fix, and that the result is one accepted sample, not a promise about your footage. Keep the character description in the prompt honest - the reference gives you movement, not hair, clothes or a body.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| source_frames | IMAGE | — | |
| source_fps_numerator | INT | 241–240000 | — |
| source_fps_denominator | INT | 11–10000 | — |
| source_start_seconds | FLOAT | 0.0000–86400 | Offset into source frames and source_audio; aligned original music is output below. |
| source_fpsopt | FLOAT | Connect Get Video Components fps. Overrides the manual rational frame rate. | |
| source_audioopt | AUDIO | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| source_motion | H3_T8_DANCE_MOTION | — |
| report_json | STRING | — |
| aligned_original_audio | AUDIO | — |