AudioX Audio Processor

AudioX generation nodes hand you a raw waveform that's been normalized to avoid clipping, but "good enough to play" and "clean enough to save" are different things. This is the little utility node you drop between a generator and your saver when you want the output normalized, forced to a specific channel layout, or just inspected.

It does three small jobs, all of them boring and all of them useful:

• normalize (default on) - scales the audio so its peak hits 1.0, then clamps to the safe [-1, 1] range. Generation already normalizes, so this is belt-and-suspenders unless you're processing audio from elsewhere.
• target_channels - mono, stereo, or keep (default). Mono averages channels down to one; stereo duplicates a mono signal across two channels. Handy before a save node that's picky about channel counts, or when you're about to feed audio into a pipeline expecting mono.
• Inspection - the node reports back.

The inputs and what you get back

Only one input is required:

• audio - any AUDIO (from a generation node, another pack, or a load node).

Outputs are where the value is:

• audio - the processed AUDIO, ready for the next node.
• sample_rate - an INT with the audio's sample rate, useful if a downstream node needs it explicitly.
• info - a STRING with "Channels: x, Duration: y, Sample Rate: z". Wire this into a text/display node or just read it in the console output.

There's no sample-rate conversion here - the sample rate in and out is the same. If you need a different rate, resample elsewhere.

Install & troubleshooting

The pack's standard setup applies (full detail in the AudioX Model Loader article):

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

This node doesn't need the AudioX model weights at all - it's pure tensor math on whatever AUDIO you hand it. The heavy requirements.txt (torchaudio, librosa, soundfile, and friends) still gets installed with the pack, and the pack's startup dependency check runs regardless, so first-launch slowness applies to you too.

Two things that bite:

• "Audio processing failed" on weird input. If a node hands it a tensor without the expected waveform/sample_rate dict shape, it'll throw. Make sure you're feeding it a proper AUDIO, not a raw tensor.
• Normalize can surprise you. Peak-normalizing makes things loud if your source is quiet. That's the point, but if you're chaining this after a volume node, you can undo the other node's work.

It's a boring node and that's its charm - when you need to force mono or grab a sample rate, it's the one you reach for.