AudioQualityEvaluator
Can a Number Tell You if Your AI Song Is Good? Sort Of.
- audio
- quality_score
Generating AI music has a workflow problem the image world solved ages ago: how do you compare ten renders without listening to all ten? AudioQualityEvaluator is the pack's answer - one AUDIO input, one quality_score float from 0.0 (poor) to 1.0 (excellent), computed with real audio signal metrics instead of a vibe. It's the same scoring function the KSampler's enable_quality_check feature uses internally, exposed as a standalone node so you can score any audio in your graph.
What it measures
The score is a composite: 70% audio quality plus 30% "word clarity" (how much the audio suffers from vocal cutting). The quality half is built from six librosa-derived metrics:
- Spectral centroid stability (25%) - timbre consistency. Low variance is good; a monotone, robotic voice has an abnormally flat centroid.
- Spectral rolloff (20%) - brightness/harshness. Flags both muffled (rolloff too low) and harsh (too high) audio.
- RMS energy variation (20%) - dynamics. Flat/robotic energy kills this; glitchy over-variation also scores badly.
- Zero crossing rate (15%) - noisiness.
- Spectral bandwidth (10%) - richness; a thin, metallic signal scores low.
- Clipping detection (10%).
It's the industry-standard toolbox, and the node's own comments name the failure modes it's hunting: robotic voice (flat spectral centroid), metallic timbre (thin bandwidth), word-cutting, clipping.
How to actually use it
Wire the AUDIO output of your decode (or your sampler's audio output) into it, and the score shows up as a float you can display, log, or even feed into a conditional to auto-skip bad renders. The intended pattern: render a few seeds/steps, compare scores, keep the winner, then listen to confirm.
The critical caveat
The author is unusually explicit, and you should believe them: scores are comparative only. Electronic music - heavy bass, distortion, dense synths - naturally scores lower than acoustic, because the metrics penalize exactly those things. A 0.65 on Dubstep can be a great render; a 0.65 on a solo piano piece is probably a bad one. Never compare across genres, and never treat the number as an absolute quality judgment. It's a within-workflow A/B tool, not a critic.
Also: it needs librosa for the full metric set (the pack installs it via requirements.txt). If librosa is missing it falls back to cruder numpy metrics, so if scores suddenly look weird, check that librosa actually made it into your environment.
Install
ComfyUI Manager (search "JK AceStep Nodes") or
cd ComfyUI/custom_nodes
git clone https://github.com/jeankassio/JK-AceStep-Nodes.git
restart. Output node wiring is trivial: audio in, number out. For iterating on ACE-Step prompts and seeds, this plus a good ear is a solid workflow - the number does the sifting, your ears do the final call.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| audio | AUDIO | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| quality_score | FLOAT | — |