Trim Audio By Sample

The same job as SDT_TrimAudio, addressed in samples instead of seconds. Most of the time seconds are fine - they're what a transcript timestamp or a VAD detection hands you. This node is for the cases where "close enough" isn't good enough and a boundary needs to land on one specific sample, not wherever a float-second value happens to round to.

How it works

Audio in this pack's AUDIO type is a tensor - a waveform array plus a sample rate - and every sample in that array is one discrete measurement of amplitude at a fixed point in time. SDT_TrimAudio takes seconds and converts them into a tensor index internally before slicing; this node lets you skip that conversion and hand over the index directly. It slices the waveform tensor directly between start_sample and end_sample - raw indices into the underlying array, no time-to-sample conversion and no rounding involved anywhere. It's the most literal, precise trim this pack offers.

The inputs and outputs that matter

• audio - the clip to trim, required.
• start_sample and end_sample (both default 0, integers) - the exact sample indices to keep.
• audio (output) - the trimmed clip.

How to install it

Via ComfyUI Manager: search ComfyUI-speech-dataset-toolkit, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kale4eat/ComfyUI-speech-dataset-toolkit
cd ComfyUI-speech-dataset-toolkit
pip install torchaudio --index-url https://download.pytorch.org/whl/cu121
pip install -r requirements.txt

No extra dependencies beyond the pack's torchaudio baseline.

Common issues & troubleshooting

Not sure whether to use this or SDT_TrimAudio. Seconds are more intuitive and perfectly fine for anything not requiring sample-exact precision - most transcript- or VAD-timestamp-based trims fall here. Reach for this node specifically when your source of boundaries is already in samples, or you need to guarantee zero rounding error.

end_sample beyond the clip's actual length, or less than start_sample. Sanity-check against the clip's real total sample count first - SDT_AudioProperty gives you the sample rate, and total samples is duration × sample rate if you need to compute bounds before trimming blindly.

Result sounds identical to a seconds-based trim with similar values. Expected for most everyday clips - the sample-level precision matters at the margins, avoiding a fraction-of-a-millisecond misalignment, which usually isn't something you'll hear as a difference. It matters for exactness downstream in a pipeline (matching another sample-accurate tool), not necessarily for audible quality.

Same sample indices give a different-length result on two clips. That's expected if the clips have different sample rates - a sample index is a position in the tensor, not a fixed duration. 16,000 samples is one second at 16kHz but only half a second at 32kHz. Check SDT_AudioProperty on both clips before assuming a shared set of sample bounds will behave the same way across them.