最近在做体育赛事自动解说时重新测试了一遍中文TTS在长音频场景下的稳定性。一开始以为问题主要出在模型。但连续跑了几组长文本后发现很多生成失败的问题其实并不是“音色不好”而是长文本处理链路本身出了问题。尤其体育解说这种场景本身就有几个比较特殊的特点文本长语速快情绪波动大连续生成时间长实时性要求高这些因素叠加后长音频生成会比普通短视频旁白更容易出现异常。这次主要记录一下最近测试过程中遇到的几个典型问题。一、长文本连续生成时最容易出现的是“断流”最开始测试时我直接把整段赛事解说文案一次性提交生成。例如response client.tts( textfull_commentary, voice_typesports_male, formatmp3 )短文本时问题不明显。但文本长度一旦超过几千字后就开始出现websocket中断音频生成超时mp3损坏返回不完整尤其比赛高潮阶段因为文本本身节奏快连续生成时间会明显增加。后来排查后发现很多TTS服务在长文本场景下本质上还是“分段推理”。文本过长后buffer压力chunk拼接流式传输这些环节都容易出问题。二、体育解说里的“高语速”会明显增加推理压力体育解说和普通旁白不太一样。它天然会包含大量连续动作描述球员名称比分变化高频情绪词例如詹姆斯突破分球库里三分出手命中比分反超现场已经彻底沸腾这种文本如果直接进入TTS会明显增加断句错误重音异常语速失衡后面测试时我开始先做文本切分。例如segments split_text(commentary, max_length80)先把长文本拆成短chunk再逐段生成。稳定性会明显提高。三、长音频场景下chunk切分比voice_type更重要一开始我比较关注男声选择情绪强度体育解说风格后面测试下来发现真正影响生成稳定性的很多时候反而是chunk长度。尤其连续生成超过10分钟后长文本不切分很容易出现内存占用增加websocket断开音频丢帧拼接异常后来改成句号切分逗号预切固定token长度之后生成成功率会稳定很多。四、轻量试听层反而能提前发现很多问题最近测试不同体育旁白风格时我没有直接进入API批量生成。而是先做试听层验证。目前比较常测试的方案包括叮叮配音配朵朵媒小三配音主要目的不是正式生产。而是提前验证解说节奏男声稳定性高语速表现长句停顿因为体育解说和普通旁白不同。一旦语速、停顿处理不好“AI念稿感”会特别明显。尤其长时间连续输出后问题会越来越明显。五、ffmpeg拼接阶段也容易出现问题后面进入正式生产后另一个比较容易忽略的问题是音频拼接。因为长音频通常不会一次生成。而是chunk → 分段生成 → ffmpeg拼接。例如ffmpeg -f concat -i list.txt -c copy output.mp3这里如果采样率不一致编码格式不同chunk长度异常就容易出现爆音音频跳帧时间轴错位尤其体育解说本身语速快这类问题会更明显。六、现在体育解说类TTS更像“工程问题”最近重新整理这些测试后一个感觉越来越明显。现在中文TTS在短文本场景里其实已经比较成熟。真正的问题反而开始集中在长文本稳定性chunk调度websocket持续连接流式生成音频拼接尤其体育解说这种高频输出场景本质上已经不只是“配音”。而更像一套长音频生成工程。
