JR MiniMax H3 Sequential Audio Chunk Driver
Slicing an hour of audio into H3-sized chunks without losing a sample
- av_latent
- audio
- audio_vae
- audio_driven_av_latent
- chunk_context
- chunk_seed
- audio_slice
- status
MiniMax H3 tops out around 15 seconds of video. That's a hard native limit - and a completely different problem from the one LTX or Wan solved with long-video tricks, because H3 also generates audio, and any naive chunking scheme that re-encodes each slice will give you clicks, pops and missing beats at every seam. This node is the answer: it's the per-chunk brain of a workflow that turns a long continuous audio file into a sequence of H3-sized, audio-locked generations that later get sewn back together. It slices exactly, on frame boundaries, and it never loses a sample.
The big picture
The sequential audio branch of the JR MiniMax H3 pack is four nodes: Chunk Driver (this one) → Continuation Guide → Latent Checkpoint → Video Output. Each chunk is its own ComfyUI prompt - the driver hands you one exact slice of your audio locked into an H3 AV latent, you sample and decode it, the output node commits it to disk, and only then does the next chunk run. The Driver is where the slicing happens, and it's the node that makes the whole chain honest.
How it works
On first execution it decodes your full AUDIO input once and writes two float32 PCM spools to disk: the original sample-rate stream (kept for the final one-time mux), and a copy resampled once to the audio VAE's rate for exact latent slicing. From then on, every chunk reads a slice out of those files.
The detail that matters is the boundary math. Chunk starts are computed from the global timeline as round(frame_boundary × sample_rate / 24), not by repeatedly rounding a per-chunk duration - which is exactly how naive implementations accumulate drift and duplicate or drop PCM samples at joins. Four strict H3 presets are baked in, each frame-aligned to H3's 5-token video grid:
14.375s / 345 frames / 575 audio ticks
10.125s / 243 frames / 405 audio ticks
8.000s / 192 frames / 320 audio ticks
5.875s / 141 frames / 235 audio ticks
Your Directed Video Conditioning length widget must match the preset's frame count or the driver refuses. Only the final chunk gets zero-padded (for audio-VAE encoding); its decoded video is trimmed back to the real remaining samples later.
Inputs that actually matter
av_latent- the Directed Video Conditioning latent; its frame count must match the preset.audio- the full continuous source audio. This is the thing that never gets re-sliced independently.audio_vae- the MiniMax H3 audio VAE used to encode the current slice.chunk_preset- the four presets above. Fewer frames per chunk means lower peak VRAM but more seams.continuity_mode-Previous Last Frame(recommended, feeds the next chunk's guide) orIndependent MV(allows visual cuts).seed_mode/base_seed-Derived per chunkgives each chunk a deterministic seed derived from the base seed and the chunk's absolute frame start;Fixedreuses the base seed.cache_path,job_name,run_id- where the job lives (defaulttemp/JR_H3_audio_jobsunderoutput/). Bumprun_idto start a new job; existing runs are never overwritten.
Outputs: the audio_driven_av_latent for this chunk, a chunk_context token that threads through the rest of the chain, the chunk_seed, the real unpadded audio_slice, and a status string that tells you the chunk number, preset, and sample range.
Installing it
Same pack as the rest - JR MiniMax H3 (Goldlionren/ComfyUI_JR_MiniMaxH3Node). ComfyUI Manager → search "JR MiniMax H3", or:
cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node.git
<ComfyUI-Python> -m pip install -r .\ComfyUI_JR_MiniMaxH3Node\requirements.txt
Use the Python your ComfyUI actually runs on. The core dependency is just imageio-ffmpeg>=0.5; torchaudio is needed only if your source audio sample rate differs from the VAE's, and it'll tell you so at execution rather than silently failing. Restart ComfyUI after installing.
Troubleshooting
The most common failure is the latent-length mismatch - the error literally tells you to set the Directed Conditioning length to the preset's frame count. Next up: "Existing job settings do not match the current workflow" - that's the fail-closed guard refusing to reuse a job whose audio, preset, continuity or seed settings changed mid-run. The fix is in the message: increment run_id to start a fresh recoverable job (your old files stay intact). And remember the driver never advances the chunk index itself - nothing moves forward until the Video Output node commits the chunk to disk, which is the whole point of the design.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| av_latent | LATENT | LATENT from JR MiniMax H3 Directed Video Conditioning. | |
| audio | AUDIO | Full continuous source audio. It is decoded/resampled once and sliced globally. | |
| audio_vae | VAE | MiniMax H3 audio VAE used to encode the current exact audio slice. | |
| chunk_preset | COMBO | 14.375s / 345 frames / 575 ticks | 4 options: 14.375s / 345 frames / 575 ticks, 10.125s / 243 frames / 405 ticks, 8.000s / 192 frames / 320 ticks, 5.875s / 141 frames / 235 ticks |
| continuity_mode | COMBO | Previous Last Frame | 2 options: Previous Last Frame, Independent MV |
| seed_mode | COMBO | Derived per chunk | 2 options: Derived per chunk, Fixed |
| base_seed | INT | 00–18446744073709550000 | — |
| cache_path | STRING | temp/JR_H3_audio_jobs | Relative paths are placed below ComfyUI/output; absolute paths are also supported. |
| job_name | STRING | audio_sequence | Safe job folder name; never used as a raw path. |
| run_id | INT | 11–2147483647 | Increment to start a new job. Existing runs are never deleted or overwritten. |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| audio_driven_av_latent | LATENT | — |
| chunk_context | JR_H3_AUDIO_CHUNK_CONTEXT | — |
| chunk_seed | INT | — |
| audio_slice | AUDIO | — |
| status | STRING | — |