D5 配音、字幕与音轨：多角色语音、时间轴对齐与字幕文件

今日目标

能按角色分配音色并批量合成台词，产出可直接使用的音频文件
能把音频时长与镜头时长对齐，并生成时间轴正确的字幕文件
能说清语音合成里影响成片质感的几个参数，以及背景音乐的处理边界

昨天你拿到了一批会动的镜头。今天给它们配音——顺便解决一个前四天一直被推迟的问题：这一镜到底该多长。读完回到页面顶部把三条目标勾掉。

小白版讲解

先破一个默认假设，否则今天整天的内容会被误当成唯一选择。

先破一个默认假设：并不是所有视频模型的产物都是默片。 有的模型只出画面、音轨全空；有的自带环境音；还有的能按提示词里写的台词连口型一起生成，官方文档里就给了「角色说话：某句台词」这样的写法，甚至允许再传一段参考音去指定音色。所以「拿到镜头之后必须配音」这句话，取决于你用的是哪个模型——动手前先看一眼产物里有没有音频流。

那既然模型能自己说话，为什么本课还要单独走语音合成？因为四条工程上的差别：

台词逐字可控。 剧本里的台词是定死的。让模型即兴，它说的永远不会正好是那一句——而剧情片的台词错一个字就是错。
音色跨镜稳定。 一个角色出现在六个镜头里，如果每段视频各自生成人声，同一个人会有六个声音。这是**「变脸」问题的听觉版**，而观众对声音的敏感度比对脸更高。
时间轴算得出来。 整条流水线的时间轴是从配音时长反推的（这就是今天下半段的内容）。语音烧在视频里，你量不出每句话何时说、说多久——字幕的时间码没法生成，背景乐的闪避也没法对齐。
改一个字的代价差四个数量级。 台词改一个字：重合成一段语音是几分之一分钱，重生成一个镜头是几块钱。

反过来说，如果你的片子明确不要字幕、台词不需要逐字精确、而且更看重口型贴合，那让视频模型自己说话是更省事的选择——它的口型是和画面一起生成的，后期对不出这种效果。这一天教的是可控的那条路；知道另一条路存在，你才知道自己在选什么。

一人一声：音色分配表

录音棚里，配音导演做的第一件事不是开录，是定角：谁配男主、谁配女二，定完写在墙上的表里，整季不换。观众对声音的记忆力远比你以为的强——同一个角色第二集换了个声线，弹幕立刻会问「这是谁」。

所以配音环节的第一步是一张分配表，而这张表不该在配音这一天现编。它属于 D2 定下来的人物卡：每个角色有一个 voiceId 字段，值就是厂商的系统音色标识。跨集一致性靠这份档案，不靠配音代码里的临时映射——这也是为什么本课把人物卡叫「档案」而不是「参数」。

MiniMax 的系统音色里有一批是专门做短剧适配的，名字本身就是角色定位：badao_shaoye 霸道少爷、junlang_nanyou 俊朗男友、lengdan_xiongzhang 冷淡学长、chunzhen_xuedi 纯真学弟、bingjiao_didi 病娇弟弟；女声有 wumei_yujie 妩媚御姐、danya_xuejie 淡雅学姐、tianxin_xiaoling 甜心小玲、qiaopi_mengmei 俏皮萌妹、diadia_xuemei 嗲嗲学妹。另外还有一批通用音色，像 male-qn-jingying、female-chengshu 这类，适合配旁白和路人。

除了音色，还有三个参数直接影响成片质感，值得一次说清：

情绪（emotion）是最容易被忽略、效果又最明显的一个。它的取值是一组固定枚举：happy、sad、angry、fearful、disgusted、surprised、calm、fluent、whisper。同一句「那部手机，不是你的」，calm 是冷静提醒，angry 是当场翻脸，两条音频的戏完全不同。工程上的做法是给每个角色一个基调情绪，再允许单条台词覆盖——短剧的情绪转折就藏在这些覆盖里。

语速（speed）取值范围是 0.5 到 2。它有个隐藏作用：语速直接改变音频时长，而时长会传导到镜头。所以语速不能在配音这一步随手调，调了就得重新对一遍时间轴。

音量与音高（vol、pitch）通常保持默认。想让某个角色显得更年轻或更沉，用换音色解决，不要靠拉音高——拉出来的声音会有明显的电子感。

最后是一个必须知道的返回值细节：data.audio 默认是 hex 字符串，不是 base64。在 Node 里落盘就是 Buffer.from(json.data.audio, "hex")，用 base64 解一次会得到一个能存下来、但播不出来的文件，而且报错信息完全不会指向这里。

tts.js

async function synthesize({ text, voiceId, emotion, speed, outPath }) {
  const res = await fetch(`${process.env.MINIMAX_BASE_URL}/v1/t2a_v2`, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.MINIMAX_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'speech-2.8-hd',
      text,
      stream: false,
      voice_setting: { voice_id: voiceId, speed, vol: 1, pitch: 0, emotion },
      audio_setting: { sample_rate: 32000, bitrate: 128000, format: 'mp3', channel: 1 },
    }),
  })
  const json = await res.json()
  if (json.base_resp?.status_code) throw new Error(`合成失败 ${json.base_resp.status_code}`)
  // data.audio 默认是 hex 字符串，不是 base64——用 base64 解会得到一个播不出来的文件
  await writeFile(outPath, Buffer.from(json.data.audio, 'hex'))
  // audio_length 的单位是毫秒，直接进时间轴
  return { path: outPath, durationMs: json.extra_info.audio_length }
}

tts.py

import os
import httpx
 
 
def synthesize(text: str, voice_id: str, emotion: str, speed: float, out_path: str) -> dict:
    res = httpx.post(
        f"{os.environ['MINIMAX_BASE_URL']}/v1/t2a_v2",
        headers={"Authorization": f"Bearer {os.environ['MINIMAX_API_KEY']}"},
        json={
            "model": "speech-2.8-hd",
            "text": text,
            "stream": False,
            "voice_setting": {"voice_id": voice_id, "speed": speed, "vol": 1, "pitch": 0, "emotion": emotion},
            "audio_setting": {"sample_rate": 32000, "bitrate": 128000, "format": "mp3", "channel": 1},
        },
        timeout=120,
    )
    data = res.json()
    if data.get("base_resp", {}).get("status_code"):
        raise RuntimeError(f"合成失败 {data['base_resp']['status_code']}")
    # data.audio 默认是 hex 字符串，不是 base64——用 base64 解会得到一个播不出来的文件
    with open(out_path, "wb") as f:
        f.write(bytes.fromhex(data["data"]["audio"]))
    # audio_length 的单位是毫秒，直接进时间轴
    return {"path": out_path, "duration_ms": data["extra_info"]["audio_length"]}

音色定好、参数调好、音频落盘之后，真正的问题才出现：这段音频有 3.3 秒，可你昨天生成的那一镜只有 3 秒。 谁让步？

时长是双向约束

这是本章的核心，也是整条流水线排列顺序的由来。

镜头时长有两个来源。一个来自剧本：编剧写这一镜是个快切，计划 3 秒。另一个来自台词：这句话说完要 3.3 秒。两个数不一样时，必须有一方让步——而这个选择决定了你的流水线长什么样。

本课的口径是台词优先：把镜头顶长，不裁剪语音。

理由很直接：观众能看出话被切掉，看不出这一镜比原计划多了 0.8 秒。剪半句话是硬伤，多零点八秒只是节奏略慢。反过来，如果为了守住计划时长而加快语速，你会得到一集听起来很赶的成片，而且加速带来的音质损失在人声上格外明显。

由此推出这条线的排列顺序：先生成画面，再合成语音，最后由语音时长回写镜头时长。 这看起来有点绕——为什么不先合成语音、按语音时长去生成刚好那么长的视频？因为视频接口的时长是有限档位的（默认 6 秒），你没法要求它精确生成 6.34 秒。所以现实的做法是：视频按计划时长生成，时间轴按语音时长排布，画面不够长的地方由剪辑台补足（定格或延长），这些是 D6 的手艺。

具体怎么算？一镜的实际需要时长等于：开头留白 + 全部语音时长 + 句间停顿 + 结尾留白。留白不是可省的装饰——台词一开始就响、说完立刻切镜，成片会有一种被掐着脖子的紧迫感。最终采用的时长取「计划时长」与「需要时长」的较大值，并把被顶长的镜头标记出来，交给 D10 的审核台让人复核。

还有一条铁律：写进时间轴的必须是从落盘文件里量出来的真实时长，不能是估算值。 字数乘系数只能用来排期。真实语音受语速、情绪、标点停顿影响，一句话差个几百毫秒很正常，而字幕漂移是逐句累加的——第一句差 200 毫秒，到第十句就差两秒，观众会觉得字幕在跟画面赛跑。

align.js

const LEAD_MS = 250 // 开头留白
const TAIL_MS = 400 // 结尾留白
const GAP_MS = 180 // 同一镜里两句台词之间的停顿
 
// 台词优先：把镜头顶长，不裁剪语音
export function planShot(shot, clips) {
  const plannedMs = Math.round(shot.durationSec * 1000)
  // clips 里的 durationMs 来自落盘文件，不是字数估算
  const spoken = clips.reduce((sum, c) => sum + c.durationMs, 0)
  const gaps = Math.max(0, clips.length - 1) * GAP_MS
  const requiredMs = clips.length === 0 ? plannedMs : LEAD_MS + spoken + gaps + TAIL_MS
  return {
    shotId: shot.id,
    plannedMs,
    requiredMs,
    finalMs: Math.max(plannedMs, requiredMs),
    conflict: requiredMs > plannedMs, // 被顶长的镜头要标出来，交给人复核
  }
}

align.py

LEAD_MS = 250  # 开头留白
TAIL_MS = 400  # 结尾留白
GAP_MS = 180  # 同一镜里两句台词之间的停顿
 
 
# 台词优先：把镜头顶长，不裁剪语音
def plan_shot(shot: dict, clips: list[dict]) -> dict:
    planned_ms = round(shot["durationSec"] * 1000)
    # clips 里的 duration_ms 来自落盘文件，不是字数估算
    spoken = sum(c["duration_ms"] for c in clips)
    gaps = max(0, len(clips) - 1) * GAP_MS
    required_ms = planned_ms if not clips else LEAD_MS + spoken + gaps + TAIL_MS
    return {
        "shot_id": shot["id"],
        "planned_ms": planned_ms,
        "required_ms": required_ms,
        "final_ms": max(planned_ms, required_ms),
        "conflict": required_ms > planned_ms,  # 被顶长的镜头要标出来，交给人复核
    }

字幕的时间轴从哪来

字幕的时间戳有两条来源，这题在面试里出现的频率不低。

第一条是接口给。 语音接口有 subtitle_enable 开关和 subtitle_type（按句或按词），开启后会返回一个字幕文件的下载链接。听起来省事，但它有两个现实问题：你要为它多发一次 HTTP 请求去取内容；更关键的是它给的时间戳是相对这一段音频的，而你的字幕要落在整集的时间轴上，中间隔着「这一镜从第几秒开始」这个偏移。所以就算用它，你也逃不掉自己排布这一步。

第二条是本地对齐。 你手里已经有每段音频的真实时长和每一镜的起始时刻，把它们累加起来就是字幕时间轴。它不需要额外请求、不依赖任何厂商字段，而且你自己控制断句——按台词行断，一句台词一条字幕，天然就是短剧要的那种节奏。

本课固定走第二条，全部字幕由本地时间轴计算生成。原因很实际：接口返回的字幕文件下载之后的逐字段结构，官方文档没有公开，我们不把课程建立在没验证过的字段上。你自己项目里要用它，先实测一遍再说。

对齐的关键只有一条：字幕游标和镜头游标必须是同一个变量。伪代码是这样的：整集有一个从 0 开始的游标，每处理一镜，先记下这一镜的起点，再从「起点 + 开头留白」开始逐句排字幕，一句排完游标推进这句的真实时长加上句间停顿；一镜排完，整集游标推进这一镜的最终时长。两个游标共用一个原点，是不漂移的唯一保证。

还有一个容易漏的自检：每条字幕必须落在它所属的那一镜里面。 字幕越界不会报错，只会让上一镜的台词飘到下一镜的画面上——观众看到的是「嘴没动，字先出来了」。这个检查很便宜，值得写死在流程里。

字幕文件的格式细节

SRT 是最通用的字幕格式，结构简单到可以手写：一个从 1 开始的序号、一行时间码、一到两行文本，条与条之间空一行。

TextText

1
00:00:00,250 --> 00:00:02,230
这手机怎么自己亮了
 
2
00:00:06,250 --> 00:00:09,550
五分钟后的新闻，
现在就推过来了

看着简单，但有三个地方写错了播放器就不认，而且通常不报错，只是一条字幕都不显示——这类问题排查起来特别费时间，因为你会先去怀疑编码、怀疑路径、怀疑播放器。

第一，时间码的毫秒分隔符是逗号，不是句点。 00:00:01.320 是 WebVTT 的写法，SRT 要写成 00:00:01,320。这是最常见的一处。

第二，时分秒必须补零，毫秒必须三位。 0:0:1,32 这种写法大部分播放器直接拒绝。

第三，序号从 1 开始且连续。 从 0 开始或者中间跳号，有些播放器会静默丢掉后面的全部字幕。

srt.js

// SRT 时间码：HH:MM:SS,mmm——分隔符是逗号不是句点，且每一段都要补零
export function formatTimecode(ms) {
  const p = (n, w = 2) => String(n).padStart(w, '0')
  const h = Math.floor(ms / 3_600_000)
  const m = Math.floor((ms % 3_600_000) / 60_000)
  const s = Math.floor((ms % 60_000) / 1000)
  return `${p(h)}:${p(m)}:${p(s)},${p(ms % 1000, 3)}`
}
 
export function toSrt(cues) {
  const blocks = cues.map((c) =>
    // 序号从 1 开始且连续，中间跳号会让部分播放器丢掉后面全部字幕
    [`${c.index}`, `${formatTimecode(c.startMs)} --> ${formatTimecode(c.endMs)}`, wrap(c.text)].join('\n')
  )
  return blocks.join('\n\n') + '\n'
}

srt.py

# SRT 时间码：HH:MM:SS,mmm——分隔符是逗号不是句点，且每一段都要补零
def format_timecode(ms: int) -> str:
    h, rest = divmod(ms, 3_600_000)
    m, rest = divmod(rest, 60_000)
    s, millis = divmod(rest, 1000)
    return f"{h:02d}:{m:02d}:{s:02d},{millis:03d}"
 
 
def to_srt(cues: list[dict]) -> str:
    blocks = []
    for cue in cues:
        # 序号从 1 开始且连续，中间跳号会让部分播放器丢掉后面全部字幕
        blocks.append(
            "\n".join([
                str(cue["index"]),
                f"{format_timecode(cue['start_ms'])} --> {format_timecode(cue['end_ms'])}",
                wrap(cue["text"]),
            ])
        )
    return "\n\n".join(blocks) + "\n"

最后是断行。竖屏画面窄，一行放十四个汉字左右就到头了，再多就会糊满屏幕或者被裁掉两端。超长的台词要断成两行，断点优先找标点（逗号、句号、顿号），找不到再硬断。硬断有个典型的丑陋后果：第二行只剩一个孤零零的字。所以标点的搜索范围要一直往前找到一个合理的最小行长，宁可两行长短不均，也不要孤字。

音轨叠加：人声、环境音、背景乐

一集短剧的声音通常有三层：人声是主角，环境音（雨声、街道、便利店的冷柜嗡鸣）负责让画面「实」起来，背景乐负责推情绪。

三者的关系可以用一句话概括：人声永远最响，环境音退到能感觉到但不抢的位置，背景乐再退一层，并且在有人说话时进一步压低。 最后这个动作叫闪避（ducking），它是让对白清晰的关键——不做闪避的成片，观众会觉得「音乐好大，听不清在说什么」，但说不出问题出在哪。

具体差多少分贝没有唯一答案，也不该在这一天写死成命令。今天要做的是把意图记下来：人声作为 0 分贝基准，环境音低一档，背景乐再低一档，说话时背景乐额外压低。这几个数字跟着时间轴一起交给剪辑台，由 D6 去落成实际的 ffmpeg 参数——时间轴与混音计划是数据，命令是数据的函数，这个分工是本课后半程反复用到的思路。

顺带说一个排查经验：成片出来觉得「人声发闷」，先怀疑的不是响度配比，而是采样率不一致。语音合成默认输出的采样率，和视频音轨的采样率如果不同，混在一起时的重采样会吃掉高频。统一采样率比调音量有用得多。

版权红线：背景音乐不能随便用

这一节技术含量最低，但它是这条流水线上最容易真正翻车的地方。

背景音乐几乎全部有版权。 从视频网站扒下来的、从别人短剧里录下来的、甚至很多标着「免费」的素材站资源，都可能带着不允许商用的条款。短剧一旦发出去有了播放量，权利方找上门是很现实的事，而平台的处理通常是直接下架加限流——你损失的不是那首歌，是整条内容的流量。

安全的做法只有三条：用明确授权可商用的曲库并留存授权凭证；用生成式音乐服务且确认其条款允许商用；或者干脆只用环境音不用配乐。短剧的情绪很大程度上由台词和节奏推动，没有配乐并不致命。

同一族的红线还有一条：不要生成真实人物的形象或声音。 用某位公众人物的名字去描述角色外貌、或者去克隆某个真人的音色，涉及的是肖像权与声音权益，性质比背景音乐更严重。本课的角色一律是虚构的，人物卡里的外貌描述也只用通用特征。

至于生成内容要打什么标识、导出物的元数据该怎么写、微短剧上线前的备案要求，是一整套合规话题，D11 会专门讲，那一天的口径以官方原文为准。今天你只需要记住这两条红线，并且在项目里把「音乐从哪来」写成一个必须填的字段——能追溯来源，才谈得上合规。

源码导读

动手实验

🧪 D5 实验：按角色批量配音并产出对齐字幕文件的配音环节

代码位置：labs/ai-drama-pipeline/day-05-voice-subtitle

验收标准：

第 1 步的分配表里两个角色是两个不同的音色，且与人物卡里的字段一致。
第 2 步每条台词打印出的时长来自落盘文件，而不是字数估算。
第 3 步台词装不下的那一镜被标成「已顶长」，且分镜数据里它的时长已经被改成校正后的值。
第 5 步打印自检通过：镜头首尾相接、字幕不重叠、每条字幕都落在自己那一镜里、时间码格式合法。
pnpm typecheck 通过，没有 any。

starter/ 里挖了四个练习点：两个在配音（音色分配、真实时长），两个在时间轴（时长校正、时间码格式）。MOCK=1 下完全离线跑通，占位音频的时长按台词字数生成，但时长仍然是用 ffprobe 从文件里量出来的——也就是说时长对齐这段业务逻辑一行都没被绕过。先原样跑一次，最后一步会列出一串问题：字幕越界、时间码不合法、两个角色同一个音色，这就是你的待办清单，每做完一个练习就少几行。

把人物卡里的音色字段接进分配表，跑一次，确认两个角色的音色标识不同。
批量合成全部台词并落盘，把每段音频的真实时长打印出来，与字数估算值做对照。
用真实时长校正镜头时长，找到那一镜被顶长的镜头，确认分镜数据里的时长真的被改写了。
由时间轴生成字幕文件，用播放器加载一次，确认字幕跟着画面走、没有整体偏移。
跑一遍时间码自检，把越界、重叠、格式三类问题全部清零。

面试题

今天 3 道题在下方题库区，侧重语音合成参数与质感的关系、时间轴双向约束的处理顺序、字幕时间戳的两条来源。展开后先看「分析过程」再看要点——第 1 题的答案里必须出现「为什么是这一边让步」的理由，只说结论会被继续追问。标注「国内高频 / 海外高频」方便按目标市场取舍。

检查清单与明日预告

能按角色分配音色并批量合成台词，产出可直接使用的音频文件
能把音频时长与镜头时长对齐，并生成时间轴正确的字幕文件
能说清语音合成里影响成片质感的几个参数，以及背景音乐的处理边界
能解释为什么时间轴必须用真实音频时长，而不是字数估算
能说出 SRT 时间码最容易写错的三个地方
实验的 5 条验收标准全部通过
3 道面试题不看要点也能答出至少 2 道

明天（D6）进剪辑台：把镜头视频、配音、字幕、背景音按今天这条时间轴拼成一条完整的竖屏成片，再截一张封面。顺序之所以是先定时间轴再剪辑，是因为剪辑台不应该自己算时间——它只是把一张结构化的表翻译成一串 ffmpeg 参数。明天你还会看到一个很实用的工程习惯：程序先探测本机 ffmpeg 有没有某个能力，再决定走烧录字幕还是软字幕，而不是假设读者的环境跟你一样。

配音、字幕与音轨：多角色语音、时间轴对齐与字幕文件