• 为已有音轨添加结尾淡出效果,异步任务
  • 参数与「淡入」完全一致,只是作用位置在末尾
  • 常与淡入配合做完整的首尾处理
POST/v1/music/generations/fadeOut

认证

string必填

所有接口均使用 Bearer Token 进行认证。

获取 API Key:访问控制台 创建。

请求时在请求头中添加:

Authorization: Bearer YOUR_OAIRoute_KEY

引用源音轨

string必填

产出源音轨的那次任务的标识。缺失或无法解析出源音轨时,提交阶段立即返回 400。

integer可选

从源任务结果的 data.result.music[] 中选取曲目,默认 1,从 1 起始。

请求参数

string可选

音频模型,省略时默认为 suno。

number必填

淡出时长,单位秒。须大于 0 且不超过源音轨的已知时长,允许小数秒。

string可选

处理后音轨的标题,默认 Untitled。

与淡入的对照

项目淡入淡出
路径fadeInfadeOut
作用位置音频开头音频结尾
参数完全一致完全一致

淡出时长通常可以比淡入长一些。听众对「慢慢消失」的容忍度比「慢慢出现」高,2 到 4 倍的差距都常见。

本端点没有版本参数,传 version 会被忽略,也不影响计费。

响应与轮询

integer

响应状态码。

data[] 的元素字段 · 2 项
string

提交成功为 submitted。

string

任务唯一标识。

轮询用 GET /v1/music/tasks/{task_id},间隔 3 到 5 秒,典型耗时 30 到 120 秒。终态为 completed 或 failed。完成后从 data.result.music[] 的 audio_url 取音频,失败原因见 data.error.message。

首尾都要淡入淡出怎么办

这两个接口是独立操作,不能一次搞定两头。做法是串联:

  1. 先调 fadeIn 拿到 task_id
  2. 等它完成后,用新的 task_id 再调 fadeOut

顺序反过来也可以。注意第二步要用第一步产出的 task_id,不是最初那个。

每次处理都会重新编码。首尾各处理一次意味着两次编码,音质会有轻微损失。对音质要求高的场景,考虑在自己那边用无损工具做首尾处理。

错误码

错误响应的格式、状态码与重试建议见错误码与限流,常见报错的排查步骤见常见问题。

使用示例

提交一个任务并拿到 task_id:

提交成功只表示任务已受理。真正的产物要拿返回的 task_id 去任务查询接口轮询,status 变成 completed 之后才有结果。