Suno Get Mp3 (Ace Data Cloud)
Getting a real audio file out of a task ID
- status
- task_id
- media_urls_json
- first_media_url
- result_json
- trace_id
MP3 is the format you don't think about until you need it. Suno Get Mp3 (Ace Data Cloud) takes a track that already exists on your account and asks the service for an MP3 of it - which sounds redundant, since the generation nodes already hand you playable audio, until you remember that a media URL is a URL and not a file in your output directory.
This is one of five conversion nodes in the pack (MP3, WAV, MIDI, MP4, Timing), all built on the same pattern: point at an existing track by ID, get back a job that produces a different representation of it.
Inputs
audio_id- required. The ID of an existing track, found in theresult_jsonof a generation call. Not a URL, not a task ID.callback_url- optional webhook for job completion. Leave it empty; the pack's retrieve node is the supported polling route.parameters_json- default{}. This endpoint also takes anasyncflag, and the client turns it on automatically, so what comes back is a task rather than a finished file. Converting audio takes a moment; making it synchronous would just make your graph hang.
The pack's standard precedence rules apply: non-empty named fields override the same keys in the JSON, empty fields are omitted from the request, and the payload is validated against the published API contract before it goes anywhere. Strict validation is why a stale widget value produces a local error instead of a confused API response - cheap to fix, and never billed.
Outputs
Six strings, the same on every tool node here: status, task_id, media_urls_json, first_media_url, result_json, trace_id.
The MP3 arrives as a media URL. Because the job is async, the sequence is task_id → a retrieve node → the resulting link. Once you have that link, note the trap that catches people: Suno Load Audio only accepts https:// links on Ace's own CDN (cdn.acedata.cloud, cdn.acedata2.cloud) and decodes them as audio. That's fine for a normal MP3 on the Ace CDN. It is not a general file downloader, and a URL from anywhere else will be rejected with a host-check error rather than a confusing decode failure.
For a file you keep, connect whatever save-audio node you use and let it write into ComfyUI's output directory.
When you'd reach for it instead of the direct link
Two honest answers. First: consistency. If a downstream node wants a file, or you're building something that batches tracks and archives them, having every track arrive through the same conversion call beats hand-copying links. Second: format guarantees. What a generation call returns is whatever the service felt like returning; an explicit MP3 request is you deciding.
What it isn't is a quality upgrade. MP3 is a lossy target, and if fidelity is what you're after, Get Wav is the sibling you want - that one gives you the uncompressed version, at a larger download. Same node shape, same inputs, different format.
One more thing worth knowing about this pack's economics: the conversion itself is a metered call. It's a cheap one compared to generating a song, but it isn't free, and the node's transport enforces that by sending it exactly once - no automatic retry on a dropped connection, because a retry would be a second charge. Read-only lookups get three attempts; anything billable gets one.
Install
Part of SunoComfyUI. Manager → Custom Nodes → search Suno → publisher acedatacloud, package Suno by Ace Data Cloud (Registry ID ace-suno) → install → restart. Source:
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/SunoComfyUI.git
cd SunoComfyUI
python -m pip install -r requirements.txt
requests and jsonschema - that's the whole list. No model downloads, no GPU inference, no runtime package installation. Key into the environment of the ComfyUI process and restart:
export ACEDATACLOUD_API_KEY='paste-your-key-here'
python main.py
The endpoint is /suno/mp3; allow it if your Ace application restricts API paths.
When it goes wrong
Invalid audio_id: does not meet the API's ... constraint. Empty field, or an ID of the wrong kind. Task IDs and audio IDs are both opaque strings, and only one of them works here.
does not meet the API's pattern constraint. A URL-shaped field somewhere wasn't https.
Stuck at pending. Conversion jobs queue, so this is normal - and re-querying is free while re-submitting is not. The node will not retry a billable call, and it will retry a read-only one up to three times, which is the whole reason the retrieve nodes exist.
A green queue entry and no file. The queue going green means the graph didn't throw. It doesn't mean the conversion finished. Check status, then the task.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| parameters_json | STRING | {} | — |
| audio_id | STRING | — | |
| callback_url | STRING | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |
| task_id | STRING | — |
| media_urls_json | STRING | — |
| first_media_url | STRING | — |
| result_json | STRING | — |
| trace_id | STRING | — |