Persistent, key-independent drone/pedal tone at ~220.7 Hz (A3) in acestep-v15-xl-sft outputs
Bug: Persistent, key-independent drone/pedal tone at ~220.7 Hz (A3) in acestep-v15-xl-sft outputs
Summary
Across multiple generations with different prompts, genres, and declared keys, output audio consistently contains a sustained/repeated background tone locked to A3 (~220.7 Hz), audible as either a held pad note or a repeatedly strummed single-note guitar part running through the entire track. Prompt wording changes and declared key changes both failed to remove or relocate it. Spectral analysis (STFT presence + amplitude-stability over time) confirms this is a real, measurable artifact and not a subjective impression.
Environment
- Checkpoint:
acestep_v1.5_xl_sft_bf16.safetensors(XL SFT, bf16) - Frontend: ComfyUI (Windows Portable) —
TextEncodeAceStepAudio1.5+AceStep 1.5 SFT Generatenodes - GPU: RTX 5080 (16GB VRAM)
- Sampler:
jkass_quality, scheduler:sgm_uniform, infer_method:ode, guidance_mode:apg - Generate node settings: steps 25, cfg 2.0, denoise 1.0, shift 3.0, omega_scale 0.00, erg_scale 0.00, apg_momentum -0.75, apg_norm_threshold 2.5, guidance_interval 0.50, guidance_interval_decay 0.00, min_guidance_scale 3.0
- Same seed used across all four test generations below to isolate variables.
What was ruled out
Before concluding this is model/checkpoint-level, the following were tested and did not fix it:
- Adjusting
apg_momentum,guidance_interval,erg_scale(loosening these made pitch stability worse elsewhere without removing the drone) - Raising/lowering
omega_scale(confirmed this control is a spectral-balance/EQ parameter, not related) - Testing steps 25 vs 50 and cfg 2.0 vs 4.0 — no audible quality/behavior difference in this setup
- Rewriting genre-tag prompt language to remove static-texture words ("bed," "subtle," "swelling," "airy," "atmospheric") and replace with motion/chord-tracking language ("pulsing through the chord changes," "moving basslines," "chord voicings")
- Changing the declared song key entirely (see Test 4 below)
- No
audio2audio/reference-audio input is connected in the workflow
Test data
All four generations below used the same seed and node settings; only the text prompt (tags) changed.
| # | Declared Key | Prompt style | Drone reported by ear | Presence of 220.7 Hz (A3) component* |
|---|---|---|---|---|
| 1 | C major | "bed of synths / subtle percussion / swelling strings" | Yes | 0.91 |
| 2 | C# major | Dense instrumentation, explicit rhythmic/dynamic build language | No | 0.33 (normal — tracks with tonic/dominant bassline, not sustained) |
| 3 | C major | Revised prompt — chord-tracking language added to all harmonic parts | Yes | 0.63 (rhythmic/strummed pattern, still locked to A) |
| 4 | A major (changed specifically to move key away from A) | Same as test 3 | Yes | 0.96 (smoothest, most sustained of all four) |
*Presence = fraction of STFT time frames (nperseg=8192, 22.05kHz mono) where the 220.7 Hz bin is within 20dB of that frame's peak magnitude. Measured over full track, excluding fade-in/out.
Key finding
Test 2 (C# major) shows the model correctly centering persistent low-end content on the song's own tonic/dominant (C#/G#) with a jagged, rhythmically-varying amplitude pattern typical of a real bassline.
Tests 1, 3, and 4 all show a component locked to the same absolute pitch, A3/220.7 Hz, regardless of the declared key — including Test 4, where the key was deliberately changed to A major specifically to test whether the drone would "move" with a new tonic assignment. It did not shift in character; it became more sustained/prominent (0.96 presence, near-flat amplitude for the full track duration), rather than behaving like a legitimate tonic-anchored bassline as in Test 2.
This suggests A3 (220.7 Hz) is being generated as a fixed/default output component, largely independent of the conditioning (prompt tags or declared key), rather than being caused by prompt wording or workflow parameters.
Attached
spectrogram_song1.png— full spectrogram, Test 1 (C major, drone), dashed line at 220.7 Hzspectrogram_song4.png— full spectrogram, Test 4 (A major, drone), dashed line at 220.7 Hznarrowband_song1.png/narrowband_song2.png/narrowband_song3.png/narrowband_song4.png— amplitude-over-time at candidate frequencies for each test, showing the contrast between Test 2's normal jagged bassline pattern and the flat/sustained or rhythmically-locked A3 in Tests 1, 3, 4summary_comparison.png— bar chart of A3 presence across all four tests
Question for maintainers
Is there a known default/fallback embedding (e.g. the null/unconditional CFG branch, or a bias in the XL SFT fine-tune) that could produce a fixed A3 output component when guidance is insufficient to override it? Happy to share the exact prompts, seed, and full node graph if useful.
