DreamX Split AV Latent

One input, two outputs, no widgets. DreamX Split AV Latent takes the latent that came out of SamplerCustomAdvanced and splits it into video_latent and audio_latent. It looks like the most disposable node in the pack. It is actually mandatory, and skipping it is the single most common way a first DreamX graph fails.

Why it has to exist

DreamX generates video and audio in one denoising pass, which means one latent object flows through the sampler holding both. The pack represents that as a ComfyUI NestedTensor - a nested, packed latent rather than a plain 5D tensor. Video is 48-channel latents at the Wan 2.2 layout; audio is a 128-channel stream, 50 frames per second; the sampler sees them as one thing because the guider slices them apart internally by counting elements.

Nothing downstream knows about that trick. Stock VAE Decode will not accept a packed latent, and DreamX Audio VAE Decode wants the audio stream alone, not the pair. So this node is the seam: it unbinds the two tensors and emits each one as a normal LATENT with its metadata intact.

That metadata detail matters more than it sounds. The split copies every key on the latent dict except samples and noise_mask onto both outputs - including dreamx_num_frames, dreamx_fps and dreamx_audio_samples. DreamX Audio VAE Decode uses dreamx_audio_samples to trim the decoded waveform to the exact requested length, which is how a 2-second ask comes back as 2 seconds of audio rather than whatever the latent's frame round-up produced. If some node in between rebuilds the latent from scratch and drops the dict keys, you keep the audio but lose the trim, and you get a tail of silence or an extra few tens of milliseconds on every clip.

Wiring

SamplerCustomAdvanced -> DreamX Split AV Latent
   video_latent -> VAEDecodeTiled -> Create Video -> Save Video
   audio_latent -> DreamX Audio VAE Decode -> Create Video

Order is fixed: video_latent is always the first stream in the pack, audio_latent the second. You don't get to choose, and there's nothing to configure - if you're expecting a dropdown here, you're thinking of a different pack.

The shipped example uses native VAEDecodeTiled at 512 px tiles with 64-frame temporal tiles rather than plain VAE Decode, and the pack's docs explain why: on long video, cuDNN reports memory pressure as a hard execution failure instead of an ordinary OOM, which bypasses the automatic fallback you'd normally get.

Install

Search DreamX Creator T8 in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-DreamX-Creator-T8.git
cd Comfyui-DreamX-Creator-T8
python -m pip install -r requirements.txt

Restart, then pull the weights into the shared model directory (they are not bundled):

python -m pip install -U huggingface_hub
hf download t8star/DreamX-Creator-Comfy --local-dir ComfyUI/models/dreamx_creator
python scripts/verify_models.py

Common issues

VAE Decode rejects your sampler output. You skipped this node. The error will be about tensor shape or an unexpected type, and it will not mention "nested" in a way you'll recognise.

Expected a packed DreamX audio/video NestedTensor. The opposite mistake - something downstream (a stock latent node, a reroute through a pack that rebuilds dicts) unwrapped the nested tensor before the split got to it.

The video is fine and the audio is a second too long. Metadata stripped between the split and the audio decode. Keep the two decodes close to this node and don't round-trip the latents through anything that doesn't preserve latent dict keys.

This is a plumbing node, and plumbing is most of any working graph. comfyui-node-plumbing.md makes the general case: the nodes that touch no pixels are the ones that decide whether a graph runs at all.