Audio Trim ⚡🅡🅞🅣🅘

The simplest node in this pack's whole audio family: give it a clip and a start/end time, get back the slice in between. No curve, no algorithm, no gotchas beyond the ones any time-based edit has.

Inputs and outputs

• audio - the clip to trim.
• start_time and end_time - both in seconds, 0 to 10,000, default 0.

Output is a single AUDIO.

What it's for

Cutting a full track down to just the section you actually want - the hook of a song, a specific verse, the bridge you're about to feed into an ACEStepRepaintGuider as source_latents. It's also the node you reach for before AudioFade, if a hard cut at your trim points is leaving an audible click: trim first, fade the edges second.

There's no tooltip guidance in this node's schema on what happens if end_time is less than or equal to start_time - treat that as undefined rather than assume it silently no-ops, and sanity-check the output length rather than trusting the widget values alone. Since this is a plain slice operation with no shape or curve parameters, the entire job comes down to getting those two numbers right, which is exactly why pairing it with AudioInfo upstream (to know your actual clip length before you start guessing at cut points) is worth the extra node.

Installing it

ComfyUI Manager: search RyanOnTheInside, install, restart. Manual:

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

No model downloads needed for a plain time-based cut.

Where people get burned

The units here are seconds, not frames - if you're eyeballing a trim point off a video timeline in your head, convert it against the audio's actual duration first (AudioInfo's audio_duration output, or your video editor's timecode) rather than guessing, especially once you're several minutes into a track and estimating by ear.

More importantly: trimming changes the clip's length, and nothing downstream recalculates automatically. If anything later in your graph depends on frame count or duration derived from the original audio - AudioInfo, EmptyImageAndMaskFromAudio - those numbers go stale the moment you trim upstream of them. Put the trim before whichever node computes frame count from duration, not after, so the numbers you're wiring around the rest of the graph actually match the audio you ended up with.

That ordering rule is worth internalizing across this whole audio family, not just here - AudioTrim, AudioPad, AudioTimeStretch, and anything else that changes duration all sit upstream of anything computing frame counts, or you end up chasing a sync bug that's really just a stale number three nodes back.