LTX Audio Latent Trim

LTX-2 is the only open-weights model that spits out video and audio in the same pass, and it's genuinely good at it - 10-30 second clips are normal, which puts it way past Wan. But the moment you stop settling for one clip and start doing long-form sliding-window generation, you hit a wall that stock ComfyUI can't get you past: audio latents are a different shape than video latents, and every built-in trim node assumes the video shape.

That's the entire reason this node exists. LTX2 audio latents are 4D [B, C, T, F] (batch, channels, temporal frames, frequency bins). Video latents are 5D [B, C, T, H, W]. ComfyUI's LTXVSelectLatents and KJNodes' GetLatentRangeFromBatch either expect 5D tensors or index along the batch dimension - so feeding them an audio latent either errors out or trims the wrong axis entirely. LTXAudioLatentTrim handles the 4D case correctly, slicing along the temporal dimension the way your sliding window actually wants.

What you're actually setting

Three inputs, one output, all straightforward:

• audio_latent - the LATENT from LTXVEmptyLatentAudio, or the audio side after splitting a combined AV latent with SeparateAVLatent.
• start_index (default 0) - the first latent frame to keep.
• end_index (default -1) - the last frame to keep, inclusive. This is the one that trips people up: -1 means "keep through the last frame," not "drop the last frame." Python-slice semantics it is not. If you want everything up to the final frame, leave it alone.
• strip_mask (default false) - when on, drops the noise_mask from the output latent. Flip it if you're feeding the result straight into LTXVAddLatents (more on that below).

Negative indexing works on both ends, so start_index=-1 gives you just the last frame. The node clamps out-of-range values instead of erroring, and returns a LATENT that wires straight into whatever you're accumulating.

Why this matters in practice

Sliding-window long-form LTX2 AV is the workflow: generate a chunk, trim the overlap, keep the tail, generate the next chunk, repeat - while video and audio latents accumulate independently. Trim the audio with a video-shaped node and you either crash or silently corrupt the temporal axis, which is how you get audio that's out of sync with the picture by the third pass. This node is the audio-side half of that loop.

One caveat before you get excited: it's a scalar operation - it does not resample, reshape, or re-encode anything. If your workflow needs audio that's longer than the model's native window, you still need the windowing machinery around it. This node just makes the trimming step not-stupid.

Installing it

It's a two-node pack, so one install covers this node and its sibling LatentStripMask:

cd ComfyUI/custom_nodes
git clone https://github.com/ckinpdx/ComfyUI-LTXAudioLatentTrim

Then restart ComfyUI. Or use ComfyUI Manager - search "ComfyUI-LTXAudioLatentTrim" and hit install. It'll show up under the latent/audio category.

Good news on the scary parts: there are none. No model downloads, no requirements.txt, no compiled kernels, no PyAV. The whole thing is a handful of lines of pure tensor slicing. It's one of those rare custom nodes that can't break your install.

Where people get burned

• The 4D guard. Feed it a video latent (5D) and the code raises ValueError: Expected 4D audio latent [B, C, T, F], got shape ... - it won't silently do the wrong thing, which is honestly the right call.
• The LTXVAddLatents mask crash. LTXVAddLatents tries to merge the noise_mask from both inputs. If a trimmed audio latent still carries a mask from a previous generation pass, that merge dies with a dimension mismatch. The fix is built in: tick strip_mask, or run the output through LatentStripMask first.
• Forgetting to restart. Classic. If the node doesn't appear in your node list after cloning, restart ComfyUI before blaming the repo.

And if you're only ever doing single-pass generation, you don't need this node at all - it exists for people stitching LTX2 clips together, and for them it's the difference between "works" and "two hours of debugging axis order."