Nodes/FireRedAudio · T8star-Aix/FireRedAudio 采用创意候选 · T8star-Aix
ComfyUI Node

FireRedAudio 采用创意候选 · T8star-Aix

The 'commit' step for a line you picked by ear

By T8mars·Created 19 days ago·Updated 15 days ago· 21
FireRedAudio 采用创意候选 · T8star-Aix
  • source_audio_batch
  • reviewed_candidates
  • 回填后 AudioBatch
  • 已采用音频
  • 采用 Manifest 路径
  • 采用报告
selected_candidate_id
project_namecreative-candidate-adoption
subfolderfireredaudio/candidate-adoptions

Everything in the creative-candidate chain is deliberately non-committal. CreativeCandidatePool generates a handful of takes with random anonymous filenames. TakeReviewBoard plays them shuffled and records which one you liked. Neither of them changes a single byte of your production audio - that's the point of the design. T8_FireRedAudio_CandidateApply is where you finally say yes. You connect the source batch, the reviewed candidates, and the one candidate ID you picked, and it backfills that single line into the batch.

What it does

Three required inputs: source_audio_batch (the production batch), reviewed_candidates (the anonymous candidate batch from the review board), and selected_candidate_id - the string the review board writes back when you click "adopt." The node finds that candidate in the reviewed batch, verifies it's actually playable, and swaps it into the source batch for the matching source_line_id. Everything else stays byte-for-byte identical.

The output batch is a new, merged AudioBatch. You also get the adopted WAV itself (selected_audio), the adoption manifest path, and a report that records the old file, the candidate's seed, your human rating, and the candidate manifest. It's auditable: you can always see what was replaced, from where, and why.

Why the ceremony is worth it

This chain exists because "just re-roll until it sounds right and save" is how you lose the take you liked. The pool writes candidates with anonymous random filenames and keeps seeds only in an audit manifest, so your blind listening isn't polluted by knowing which take was seed 42. The review board defaults to no adoption - you must explicitly pick - and this node is the explicit pick, executed. The one-line-only scoping is the other deliberate choice: you can adopt candidate-002 for line L014 and the rest of the episode doesn't move.

One rule to respect: selected_candidate_id must be a candidate the review board actually produced - the node refuses a made-up or already-consumed ID with a clear error, so you can't half-wire it.

Inputs/outputs that matter

  • source_audio_batch - your production AudioBatch.
  • reviewed_candidates - the batch the board returned.
  • selected_candidate_id - wired from the board's adopted output.
  • Outputs: merged audio_batch, selected_audio, manifest_path, adoption_report.

Install

Same pack, one install:

cd ComfyUI\custom_nodes
git clone https://github.com/T8mars/comfyui-fireredaudio-T8.git
cd comfyui-fireredaudio-T8
python scripts\setup_runtime.py

This node itself needs no model - it's file bookkeeping. The model was already spent generating candidates upstream.

Gotchas

Run it again after the board, not in the same pass - the board writes the adopted ID back to its serializable input on re-execution, so you need a second run to have a valid selected_candidate_id. And if you adopt, then re-run the pool for the same line, the old adoption isn't silently overwritten; the new adoption is a separate manifest entry. That's intentional - you can always roll back to a prior manifest. Treat adoption as a one-way door per line and you'll never be confused about which take is live.

CategoryT8star-Aix/Audio/FireRedAudio

Inputs (5)

NameTypeDefaultDescription
source_audio_batchT8_FIREREDAUDIO_AUDIO_BATCH
reviewed_candidatesT8_FIREREDAUDIO_AUDIO_BATCH
selected_candidate_idSTRING
project_nameSTRINGcreative-candidate-adoption
subfolderSTRINGfireredaudio/candidate-adoptions

Outputs (4)

NameTypeDescription
回填后 AudioBatchT8_FIREREDAUDIO_AUDIO_BATCH
已采用音频AUDIO
采用 Manifest 路径STRING
采用报告STRING