DiffusionGemma Decoded Song Audition & Lock

Music generators (ACE-Step in the earlier workflows, MiniMax Music 3 in the ad stack) produce several candidate songs per seed, and you can't tell which one's any good from a text caption. DiffusionGemma Audio Candidate Selector is the node that decodes the candidates it's given, measures the actual waveforms, picks a usable excerpt, and - this is the part people love and fear - blocks the whole LTX render when no candidate passes QC. It would rather stop your video than silently mux a clip of clipping or silence.

Read the tooltips and you'll see the author is precise about what this is: a lightweight CPU signal heuristic, not transcription, not source separation, not note-level proof of musicality. It measures tempo plausibility, onset pressure, vocal activity, tonal continuity, clipping, and artifact-like spectra, scores candidates, and picks. The heavy claims are deliberately left to you: listen to the selected song, then lock it.

Inputs and outputs that matter

• candidate_count - default 2; the number of lanes actually auditioned.
• candidate_1…candidate_4 - decoded AUDIO inputs. They're lazy: only the requested candidate lanes are rendered/decoded, so a 4-candidate workflow with candidate_count=2 decodes just two.
• selection_mode - auto_select, lock_candidate_1…4, or lock_by_hash. Locking is the repeatability feature: pick the winner after listening, and production re-locks the same candidate/excerpt instead of re-judging.
• expected_bpm - the requested tempo, used to interpret equivalent pulse rates (half-time can be advisory; double-time only with tight error bounds). 0 means signal-only analysis.
• excerpt_duration_seconds (default 20) and minimum_score (default 0.52) - the excerpt length and the numeric production-score floor. The floor is only a floor: duration, clipping, tempo, onset, tonal, vocal-activity, and artifact failures block independently of score.
• locked_waveform_sha256 - required by lock_by_hash; any mismatch fails closed.
• source_policy - ace_step applies full generated-candidate audition gates. uploaded_song flips posture: the user already chose the music, so technical integrity stays blocking while tempo/vocals/style heuristics become advisory.

Outputs: selected_audio (the AUDIO you mux), suggested_start_seconds, waveform_sha256, plus director_report_json and audit_report_json so the Director and your review both know what was selected and why, plus status/ready.

The failure philosophy

This is where the pack's "fail closed, never silently substitute" attitude is loudest. Automatic selection favors direct/aligned candidates, then recovery coverage, then the actual LTX excerpt score. But a failed lock blocks rather than falling back to a different song - the whole point of hash-locking is that production never muxes something you didn't approve. For uploaded tracks, the posture inverts deliberately: the file must be technically usable (shape, size, no silence/clipping/artifacts) but its tempo and production score are advisory, because you already chose it.

Installing it

Part of exportAnything/ComfyUI-DiffusionGemmaPromptBuilder, under prompt/diffusiongemma/audio-production:

cd ComfyUI/custom_nodes
git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder

or ComfyUI Manager → DiffusionGemma Prompt Builder → restart. It's CPU signal analysis - no model of its own. The heavy stuff is upstream: ACE-Step (or Music 3) weights to generate candidates, and whichever audio-VAE path your workflow uses.

Common issues

• LTX silently blocked with no obvious error. The selector blocked because no candidate passed - check status/audit_report_json for the specific failing check (clipping, tempo alias, onset pressure, artifact-like spectrum). Lowering minimum_score won't bypass the hard checks; that's deliberate.
• "Lock mismatch" after you changed something. The waveform_sha256 output and any locked hash must match the actual decoded waveform. Regenerate/relock when you swap candidate seeds or source audio.
• Tempo keeps flagging. Music generators drift (the README's own runtime-proven candidate measured ~87.9 BPM against a requested 122 and recorded it as an advisory). If exact tempo matters, lock a real upload or tighten candidate policy rather than trusting generation to hit 122 on the nose.