YuE2 Decode Latents

A YuE2 song happens in four stages: the model writes an ABC score, sings it into semantic tokens, renders those into acoustic latents, and finally a VAE turns the latents into a 48 kHz stereo waveform. The first three are the expensive ones. The last is seconds of work.

YuE2 Decode Latents does only that last stage. Feed it the latents that YuE2 Render Plan handed out and it gives you back the audio again, without singing anything. That sounds like a parlor trick until you want to know what the legacy decoder actually sounds like next to standard on the same performance - and then it's the only honest way to do the comparison.

Why you'd want this

Two decoders ship with this model. standard is the one released for listening. legacy is the decoder the published benchmark numbers were measured with, so you use it to reproduce those numbers and not much else. Same size, different weights, and the same latents through each do not sound the same.

The trap is comparing them the normal way. If you re-render the song with a different VAE setting you've changed the seed's whole path, and now you're hearing two different performances, not two decoders. Keep the latents fixed, decode them twice, and the only variable left is the decoder. The pack author checked this on a real run rather than asserting it: the same latents through standard and through legacy gave different audio, and putting the node back to standard gave audio identical to the render's own output, down to the last sample.

It's also just cheap. Decoding is a couple of seconds against minutes for a full song, so re-listening costs you almost nothing.

Inputs and outputs

Only two inputs, and one of them is optional:

• latents - a YUE2_LATENTS handle, from the latents output of YuE2 Render Plan. Required, and the node refuses with a clear message if you leave it empty or haven't wired anything into it.
• options - the optional YUE2_OPTIONS socket from YuE2 Options. The author's own note on it is the useful part: only vae, device and keep_model_loaded change anything at this stage. Everything else - the CFG scale, the sampling numbers, max_seconds - was settled while the song was sung. This node is a decoder, not a sampler, so those incoming values are simply carried along and ignored.

The single output is audio, a plain ComfyUI AUDIO. Wire it to SaveAudio (or anything else that takes audio) and you're done. There's no score output here, and no latents passthrough.

Under the hood the latents you receive are a small bundle, not just a tensor: the packed latents (kept on the CPU by the render node), plus the settings the render was run with and the seed. The node starts from the released defaults, lays the render's settings over them, and then lays your options node over that - so an unconnected options socket changes nothing at all.

Install

Same as the rest of the pack. ComfyUI Manager, search YuE2-ComfyUI (the pack lists as YuE2 Music), or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/pytraveler/YuE2-ComfyUI

Restart ComfyUI afterwards. The only Python requirement the pack adds is tiktoken; if it's missing the node tells you so and prints the pip line for the interpreter ComfyUI is actually running on, which is the part a bare pip install gets wrong on a portable build.

Want legacy? Set vae to legacy in an options node and the pack switches itself from Comfy-Org's repackaged checkpoint to the three files m-a-p released, because Comfy-Org doesn't publish the legacy decoder - about half a gigabyte for the VAE. Like the rest of YuE2 it's CC BY-NC 4.0, non-commercial, so keep that in mind before building a paid pipeline on the comparison you just made.

Where it goes wrong

The realistic failures are boring ones. You connected a plan instead of latents, or nothing at all, and the node says exactly that. Or you wired a fresh YuE2 Render Plan into it and expected one run to give you two files - it doesn't; the render already decoded its own latents and handed out audio.

The one worth thinking about is VRAM. Decoding itself is tiled and light, but the pack loads the 6.8 GB model (and the decoder) to do it, so with keep_model_loaded off, each decode is fiveish seconds of loading plus the decode. If you're flipping through takes, turn that on; if a video or image model runs next in the same graph, leave it off. And remember the whole audio layer of this ecosystem is a pile of node packs sharing one Python environment - "it worked yesterday" is usually a dependency, not this node.