Per-request MP3 bitrate control#63
Per-request MP3 bitrate control#63ibarron9216 wants to merge 3 commits intoServeurpersoCom:masterfrom
Conversation
Add int mp3_bitrate to ServerFields (0 = use server default g_mp3_kbps).
Validate against the full 14-value allowlist {32,40,48,56,64,80,96,112,
128,160,192,224,256,320} in parse_server_fields; invalid values set a -1
sentinel so all 6 call sites return HTTP 400.
Replace the hardcoded g_mp3_kbps in synth_worker with:
(sf.mp3_bitrate > 0) ? sf.mp3_bitrate : g_mp3_kbps
Add post-atoi startup validation of --mp3-bitrate; exits with code 1 and
an error message on an invalid value.
config.ts: export VALID_MP3_BITRATES with all 14 server-accepted values [32,40,48,56,64,80,96,112,128,160,192,224,256,320] state.svelte.ts: add mp3Bitrate to app state and localStorage; validate stored value against VALID_MP3_BITRATES on load (default 0) api.ts: add optional mp3Bitrate=0 param to synthSubmit and synthSubmitWithAudio; inject mp3_bitrate into JSON only when format is mp3 and bitrate > 0 — never touches AceRequest type RequestForm.svelte: bitrate <select> in the format row, visible only when app.format === 'mp3', bound to app.mp3Bitrate, seeded from app.props.cli.mp3_bitrate on first load (fallback 128), with a conditional extra option for non-preset server-configured values
server.sh: add commented #--mp3-bitrate 128 example after --max-batch with inline comment listing all 14 valid kbps values tools/public/index.html.gz: rebuild from updated Svelte sources; includes full 14-value bitrate selector
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 48 minutes and 46 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Hi! Thanks for your contribution! I've already planned to move this field from the dedicated bitrate to the rest of the request JSON, along with adding a new "Advanced Flow Matching and Post-Processing" section to standardize the API (and work same on CLIs), as more advanced parameters will be added very soon! The commit only adds 14 lines. |
Great news! One quick question, any plan to add using an existing song (audio file) for the cover/lego/complete features? Or is it already there, and I just have not understood how to use it? I am talking about the WebUI, I know the functionality is there in acestep.cpp Thank you for your amazing repo! |
|
Anything is possible. It's a "playground," so everything is "folded in on itself" to be compact and work on mobile. If you check "Src audio" + "Ref timbre" on a song, the "Cover" task lets you make remixes, and you also have Cover (nofsq) to condition the DiT and force it to reproduce variations very close to the original, and even modify the lyrics. It takes a little time to find the right "Cover strength" The "Repaint" function even lets you edit the lyrics, and it works better than Suno! ("Src" switch to Region selection) |
Thank you for the quick response! Based on your explanation, I can confirm the user error was entirely mine. I haven't been using the correct workflow for the WebUI. Specifically, I didn't realize you could check the 'Src audio' box for the 'Cover' function, as it always shows up red and uninteractable for me. I was expecting a standard file explorer window to pop up so I could select my reference song, but that clearly isn't how it works! I know you aren't here to troubleshoot everything, but clarifying these UI interactions is really useful, may be once I get the hang of it, I could contribute to the documentation! |
Summary
Adds per-request MP3 bitrate selection, allowing callers to specify encoding quality on every
/synthrequest instead of relying solely on the server-wide--mp3-bitrateflag.Changes
C++ server (
tools/ace-server.cpp)int mp3_bitratetoServerFields(0 = use server defaultg_mp3_kbps)mp3_bitrateinparse_server_fieldsagainst the full 14-value allowlist{32,40,48,56,64,80,96,112,128,160,192,224,256,320}; invalid values trigger HTTP 400 at all 6 call sitesg_mp3_kbpsinsynth_workerwith(sf.mp3_bitrate > 0) ? sf.mp3_bitrate : g_mp3_kbps--mp3-bitrate; invalid value exits with code 1WebUI (
tools/webui/)config.ts: exportedVALID_MP3_BITRATESwith all 14 valuesstate.svelte.ts: addedmp3Bitrateto app state and localStorage with validation on loadapi.ts: addedmp3Bitrate=0param to both submit functions; injectsmp3_bitrateinto JSON only when format ismp3and bitrate > 0RequestForm.svelte: bitrate<select>in the format row, visible only for MP3, seeded fromapp.props.cli.mp3_bitrateon first loadConfig
server.sh: added commented#--mp3-bitrate 128example with all valid values listed inlinetools/public/index.html.gz: rebuilt from updated sourcesAPI Usage
Verification
--mp3-bitrate