nemo-asr List Segments

Plumbing, same shape as SDT_KotobaWhisperListSegments but for the nemo-asr side of this pack. SDT_NemoAsrTranscribe hands back its segment-level output as one bundled NEMO_ASR_SEGMENTS object - this node cracks it open into a list of individual segments you can actually loop over.

How it works

No transcription, no processing - it takes the bundle from SDT_NemoAsrTranscribe's segments output and re-exposes it as a list, one item per segment the NeMo decoding pipeline produced. Each item stays an opaque NEMO_ASR_SEGMENT until you run it through SDT_NemoAsrSegmentProperty to actually pull the start time, end time, and text out.

The inputs and outputs that matter

• segments (required, NEMO_ASR_SEGMENTS) - the bundle, from SDT_NemoAsrTranscribe.
• segments (output, NEMO_ASR_SEGMENT, list) - the exploded individual items.

How to install it

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

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 of its own - pure plumbing, downstream of whatever SDT_NemoAsrLoader/SDT_NemoAsrTranscribe already needed.

Common issues & troubleshooting

Wired in the subwords output by mistake instead of segments. Easy to mix up since both come off SDT_NemoAsrTranscribe and both get exploded by a similarly-named node - this one specifically wants NEMO_ASR_SEGMENTS. If you actually wanted token-level data, that's SDT_NemoAsrListSubwords instead, a different node entirely.

Not sure what to do with the exploded list. Feed each item into SDT_NemoAsrSegmentProperty to read its start, end, and text - this node only splits the bundle apart, it doesn't expose those fields directly.

Segment count looks different from what you'd expect compared to kotoba-whisper on the same clip. That's expected and not a bug - different ASR models segment speech differently based on their own internal pause/boundary detection. There's no guarantee nemo-asr and kotoba-whisper produce the same number or boundaries of segments on identical audio, since they're independent models with independent decoding.

Wondering why segments and subwords are separate bundles instead of one combined structure. They represent genuinely different granularities that most workflows only need one of at a time - sentence-level for dataset transcript building, token-level for finer alignment work. Keeping them as separate outputs (and separate explode nodes) means you only wire up the graph plumbing for the one you actually need.

Building a batch dataset and want one row per segment. This is the exact use case this node exists for: run SDT_NemoAsrTranscribe once per source recording, explode the result here, and each item in the resulting list becomes one row - an audio slice plus its transcript - once you pair it with SDT_NemoAsrSegmentProperty and a matching audio cut. It's more nodes than a single monolithic "transcribe to dataset" tool would need, but each step stays inspectable, which matters when a bad segment boundary or a garbled cut needs tracking down.