H3 Audio Soundscaper (Local GGUF)

MiniMax H3 generates its audio with the picture - dialogue, sound effects, room tone, all in the same forward pass. That's great until you realize the prompt has to describe all of it, and writing "overall_soundscape: a lively street scene" isn't going to cut it. The H3 Audio Soundscaper is the node that turns a clip's actual audio track into the audio sections of an H3 prompt, using a local omni GGUF model. No API, no key, no cloud - it listens on your GPU.

The model in question is Qwen3-Omni-30B, served the same managed-llama-server way as the H3 Skill Promptor but on its own port (8736), so both servers coexist without kicking each other out of VRAM. Feed it the audio input (from LoadAudio, VHS, anything that emits AUDIO) and it transcribes four things: overall_soundscape (1–4 sentences, diegetic only), non_diegetic_music (1–3 sentences, or N/A), verbatim dialogue lines ready for <d> tags, and a full timestamped sound_log of design-worthy events. There's also a report output that tells you what the model said about its own work.

Design mode is the hidden trick

Leave audio unconnected and fill video_prompt with an H3 prompt or scene description, and the node flips from transcribing to designing: same four outputs, but now a sound designer's plan keyed to the described visuals. Dialogue is copied verbatim from your prompt rather than invented - because H3 renders <d> words literally, inventing lines would be worse than writing nothing. Design mode needs no mmproj at all, so any chat GGUF works, and you can even attach to the promptor's 8735 server via base_url.

What a beginner actually sets

• gguf_model - must be an omni (audio-capable) model. The dropdown floats omni files to the top. A text-only model will reject the audio input.
• mmproj - default auto pairs by filename, but it has to be the one carrying the AUDIO encoder. none is fine in design mode.
• scene_context - optional text describing what's on screen. Used only to sort diegetic from non-diegetic sound; the model still describes only what it hears. video_prompt with audio connected does double duty as extra context here.
• port / ctx_size / max_tokens / temperature - defaults are sensible (8736, 16384 ctx, 1500 tokens, temp 0.6); you can leave them alone.

Wiring it in

The natural companion is the H3 Skill Promptor. Its source_soundscape, source_music, and sound_log inputs exist specifically to receive this node's outputs as a "MEASURED AUDIO" block that anchors the prompt's audio sections. Wire overall_soundscape → source_soundscape, non_diegetic_music → source_music, sound_log → sound_log, and the dialogue goes into the promptor's dialogue input. Same contract as the promptor too: one corrective retry against the output rules, never a silent rewrite.

Install and model files

The pack install is shared with the rest of TrentNodes:

cd ComfyUI/custom_nodes
git clone https://github.com/TrentHunter82/TrentNodes.git
cd TrentNodes
pip install -r requirements.txt

(Or ComfyUI Manager, searching "Trent Nodes" - and if Manager flags it as unsafe, that's the author's day-one repo-rename ghost in the registry; the git clone path works regardless.)

Then drop both of these into ComfyUI/models/LLM from the ggml-org/Qwen3-Omni-30B-A3B-Instruct-GGUF repo:

• Qwen3-Omni-30B-A3B-Instruct-Q4_K_M.gguf - ~17.3 GB. It's an MoE, so only ~3B params are active at once.
• mmproj-Qwen3-Omni-30B-A3B-Instruct-Q8_0.gguf - ~1.2 GB. This one carries the audio encoder; it's required for listening mode.

Plus the same system prerequisite as the promptor: a current CUDA llama-server (llama.cpp ≥ b10450), on PATH or LLAMA_SERVER_BIN or at ~/llama.cpp/build/bin/llama-server.

Where people get burned

The README is refreshingly honest about the failure mode it was built against: "every audio captioner tested fabricates events past the real clip end otherwise." Captioners invent sounds after the clip stops. This node tells the model the exact clip duration and instructs it to ignore analysis-window padding, so if your sound_log shows events beyond the last second, that's the padding leaking - check the report output.

One genuine gotcha: Qwen3-Omni-30B at Q4 is ~17 GB of VRAM on top of whatever else you're running. The free_vram_first toggle unloads ComfyUI's resident models before the server spawns. If the node refuses to start, that's the VRAM gate doing its job - free the card, or point base_url at a server you already have resident.