COC Replay制作全流程：本地语音转写、多角色配音、AI立绘与ffmpeg合成实战指南

短团跑完，语音素材堆了一堆，最后剪成 COC replay 时发现字幕、配音、立绘、渲染全是体力活，处理时间比跑团本身还长。这次以《壁橱的诱召》这类带有角色演绎的 COC replay 为例，把一套可复用的本地制作流程拆开来讲：音频转写、角色配音、场景配图、字幕合成、批处理渲染，每一步尽量用开源工具和脚本完成，而不是靠剪辑软件手动一点一点磨。

这套流程的关键在于：跑团语音可以先转录成文本，再由本地 TTS 生成多角色配音；立绘和场景图用本地 AI 绘图批量出图；字幕和音频用 ffmpeg 这类命令行工具合成。整个过程可以用显存 8G 左右的消费级显卡跑通，纯 CPU 也能处理部分环节，只是速度差别很大。接口层支持 HTTP API，批量任务可以做成目录监听和队列脚本，方便后续接入自己的工具链。

如果你是跑团 Replay 作者、视频工业化生产爱好者，或者只是想找一条减少重复劳动的本地工作流，这篇文章可以直接收藏。下面按“准备环境 -> 转写 -> 配音 -> 出图 -> 合成 -> 排错”的顺序展开。

1. COC Replay 制作流程核心能力速览

先给一张总览表，确认这套流程到底覆盖哪些功能、硬件门槛在哪里。

注意：这里不绑定某个具体整合包，而是基于社区常用开源模型给出可替换的通用方案。具体显存占用和生成速度要以本机实际测试为准。

2. 适用场景与使用边界

这套流程适合谁？本质上是给“需要把语音内容变成可发布视频”的人用的。

第一类是跑团 Replay 作者。跑团录音往往一小时起步，人工听写再打轴非常耗时。用语音转写先出一版带时间戳的字幕，再人工修正人名、术语、语气词，效率会高很多。

第二类是短剧本创作者。先把剧本文本写出来，再用本地 TTS 生成角色语音，最后用 AI 绘图生成静态画面，再通过 ffmpeg 合成视频。这种方式对拍摄设备和演员没有依赖，特别适合单人制作。

第三类是批量内容生产者。比如把多集跑团记录批量转成统一格式的视频，或者把一个模组的多个结局分支批量配音、批量出图。这类场景需要接口化、队列化和异常重试机制。

使用边界也要说明白。COC 是跑团规则，Replay 是跑团过程的视频化演绎，如果使用到已存在的动画、电影角色形象或世界观，需要确认是否符合原作的同人使用规则和发布平台规范。AI 绘图生成角色立绘时，不要直接复刻官方设定图用于商业用途。TTS 配音建议使用自己训练的合法音色或开源音色，不要未经授权使用真实演员、主播的声音。涉及人脸合成、声音克隆、真实玩家录音公开传播时，要取得当事人明确授权。

3. 环境准备与前置条件

做这套流程前，先检查自己的设备和依赖，避免装到一半发现某个模型跑不动。

3.1 硬件层面

• CPU：建议 8 核以上，主要用于数据预处理、ffmpeg 转码、编解码。
• 内存：16G 起步比较稳，处理长音频时内存占用会明显增加。
• GPU：优先考虑 NVIDIA 显卡。显存 6G 可以处理常见的 Whisper 模型和 TTS 模型；8G 到 12G 可以做 AI 出图；如果使用高分辨率模型或批量出图，显存越大越好。
• 磁盘：模型文件加音视频素材，准备 30G 到 50G 空闲空间比较稳妥。
• 操作系统：Windows 10/11 和 Linux 都可以，命令行方案基本跨平台。

3.2 软件层面

以下组件建议提前安装好：

• Python 3.10 到 3.12，按各模型要求选择。
• CUDA 和 cuDNN，版本要匹配 PyTorch 和模型要求，不要盲目装最新。
• ffmpeg，用于音频提取、音频拼接、字幕烧录和视频合成。
• Git，用于拉取模型仓库和工具源码。
• 浏览器，用于访问 WebUI 或 API 页面。

如果之前已经装过 PyTorch，可以先检查版本：

python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

输出True说明 PyTorch 能识别显卡，后续安装带有 CUDA 依赖的模型会顺畅很多。

3.3 素材目录规划

建议从一开始就按短团病例来建目录。这里以《壁橱的诱召》为例，目录结构可以是：

coc_replay/ ├── audio/ # 原始跑团录音 ├── segments/ # 按角色/场景切分后的音频片段 ├── transcript/ # 转写文本和字幕文件 ├── tts_output/ # 生成的每个角色配音 ├── images/ # 立绘、场景图、道具图 ├── subtitle/ # 最终字幕 ├── render/ # 合成后的视频输出 └── scripts/ # Python / shell 脚本

这样做的好处是批处理时只需要按目录遍历，不容易把输入输出搞混。

4. 音频转写与分幕字幕

第一步是把跑团录音变成带时间戳的文本。这里推荐采用 Whisper 类开源转写工具，社区常见的是 OpenAI Whisper 以及 faster-whisper 加速版本。faster-whisper 在 CPU 和 GPU 上都有优化，适合处理长音频。

4.1 安装与模型选择

以 faster-whisper 举例，先安装依赖：

pip install faster-whisper

模型尺寸一般有 tiny、base、small、medium、large-v3。对中文跑团录音，至少要 small 起步，medium 更稳。显存不足时，可以先用 small 模型出初稿，再人工校对。

4.2 转写脚本

下面给出一段通用脚本，把目录下所有音频转成带时间戳的文本和 SRT 字幕：

import os from faster_whisper import WhisperModel model_size = "small" model = WhisperModel(model_size, device="cuda", compute_type="float16") input_dir = "./audio" output_dir = "./transcript" os.makedirs(output_dir, exist_ok=True) for file_name in os.listdir(input_dir): if not file_name.lower().endswith((".mp3", ".wav", ".m4a", ".flac")): continue audio_path = os.path.join(input_dir, file_name) base_name = os.path.splitext(file_name)[0] segments, info = model.transcribe( audio_path, language="zh", vad_filter=True, word_timestamps=False ) srt_lines = [] for idx, seg in enumerate(segments, start=1): start_time = seg.start end_time = seg.end text = seg.text.strip() srt_lines.append(f"{idx}") srt_lines.append(f"{fmt_timestamp(start_time)} --> {fmt_timestamp(end_time)}") srt_lines.append(text) srt_lines.append("") srt_path = os.path.join(output_dir, f"{base_name}.srt") with open(srt_path, "w", encoding="utf-8") as f: f.write("\n".join(srt_lines)) print(f"[OK] {file_name} -> {srt_path}")

其中fmt_timestamp是 SRT 时间格式转换函数，需要自行补充，格式为HH:MM:SS,mmm。

4.3 判断是否成功

• 生成的字幕时间轴是否和语音对齐。
• 中文专名、人名是否准确，比如“骰子”“调查员”“克苏鲁”这类词有没有被转成同音字。
• 跑团里有多人同时说话时，转写是否出现串行漏字。

常见失败原因是录音格式不标准、噪声大、多人抢话。建议先把录音统一转成 16kHz 或 16bit 的 wav，再用脚本转写。

5. 角色配音：TTS 与参考音色处理

跑团 Replay 的配音可以分为两种方式：一种是直接用人声录音切分，另一种是用 TTS 生成角色台词。后者对单人制作更友好。

5.1 本地 TTS 的基本思路

当前开源 TTS 方案比较多，常见的有 CosyVoice、GPT-SoVITS、ChatTTS 等。它们的基本用法相似：输入一段文本，可选输入参考音频，输出一段自然语音，部分工具支持音色保存。

以通用 TTS 工具为例，命令行调用大致如下：

python cli.py \ --text "我打开壁橱，发现里面放着一条旧领带。" \ --ref_audio "./voices/kp_ref.wav" \ --out "./tts_output/kp_line_001.wav"

这里ref_audio是参考音频，用于控制音色和语调。第一次使用建议找一个干净、无人声底噪、时长为 5 到 15 秒的语音文件作为参考。

5.2 按角色切分和批量生成

跑团 Replay 里角色多，建议每个角色建一个音色目录：

voices/ ├── kp/ │ └── kp_ref.wav ├── ryu/ │ └── ryu_ref.wav └── mitsurugi/ └── mitsurugi_ref.wav

然后写批量脚本读取字幕文件，按正则或人工标记切出台词，再逐条调用 TTS。具体切分逻辑因项目而异，这里给一个简化思路：

import subprocess import json tasks = [ {"role": "kp", "text": "你听到壁橱里传来某种低沉的声音。", "out": "tts_output/kp_001.wav"}, {"role": "ryu", "text": "我慢慢走过去，伸手握住柜门把手。", "out": "tts_output/ryu_001.wav"}, ] for task in tasks: cmd = [ "python", "cli.py", "--text", task["text"], "--ref_audio", f"./voices/{task['role']}/ref.wav", "--out", task["out"] ] subprocess.run(cmd, check=True)

5.3 判断质量

• 多音字是否读对，比如“行”“藏”“重”这类常见多音字。
• 长句是否出现吞字、重复、语速突变。
• 角色音色是否稳定，连续几句话听起来是否像同一个人。
• 参数量小的模型容易出现机械感，可以用情绪标签、停顿符号或标点来调节。

如果 TTS 生成效果不稳定，优先检查参考音频质量和文本分段长度。单个片段不要超过 50 到 80 字，过长容易丢字。

6. 立绘和场景图批量生成

Replay 视频通常需要角色立绘和场景背景。这部分可以用 Stable Diffusion 或 ComfyUI 批量生成。

6.1 出图流程

在 ComfyUI 里可以保存工作流 JSON，再通过 Python 脚本提交任务。基本逻辑是：

• 加载工作流模板。
• 替换提示词、负面提示词、图片尺寸、批次数量。
• 提交到 ComfyUI API。
• 轮询任务状态。
• 保存生成结果到指定目录。

提示词建议分成三个部分：角色描述、场景描述、风格标签。比如：

masterpiece, best quality, anime style, a calm detective in suit, standing in a dim room, wooden closet in the background, dramatic lighting, negative prompt: lowres, bad anatomy, extra fingers, watermark

批量出图时一定要固定随机种子或使用脚本维护种子列表，否则人物形象会有很大跳变。

6.2 批量出图脚本思路

下面给出一段使用 requests 请求 ComfyUI API 的通用模板：

import json import requests webui_addr = "http://127.0.0.1:8188" def queue_prompt(workflow_json): url = f"{webui_addr}/prompt" resp = requests.post(url, json={"prompt": workflow_json}) resp.raise_for_status() return resp.json()["prompt_id"] pid = queue_prompt(workflow_template) print(f"task submitted: {pid}")

具体工作流 JSON 需要从 ComfyUI 保存的workflow.json中提取节点参数，再替换text、seed、batch_size等字段。第一次做的时候，建议先用一张图测试，确认参数改造没问题再上批量。

6.3 效果验证

• 单张图能否满足人物描述和场景要求。
• 多张图之间人物是否一致，必要时可以使用角色一致性 LoRA 或固定角色参考图。
• 高分辨率输出是否出现肢体变形、文字乱码、面部崩坏。
• 出图速度和显存占用是否在可接受范围内。

如果批量出图后需要统一风格，可以把生成图统一做一次局部重绘或图生图风格化，但这一步会增加大量时间，第一次不建议做。

7. 音视频合成与字幕烧录

当配音、立绘、背景图、字幕文件都准备好后，进入合成阶段。这里主要用 ffmpeg 完成。

7.1 生成单场景视频

假设图片是scene_001.png，配音是voice_001.wav，可以用以下命令生成一段固定时长视频：

ffmpeg -loop 1 -i scene_001.png -i voice_001.wav \ -c:v libx264 -tune stillimage -c:a aac -b:a 192k \ -pix_fmt yuv420p -shortest render/scene_001.mp4

-shortest会让视频长度和音频保持一致，适合逐场景合成。

7.2 合并场景并烧录字幕

多段场景合并时，可以先生成一个文件列表：

file 'render/scene_001.mp4' file 'render/scene_002.mp4' file 'render/scene_003.mp4'

然后执行：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy render/replay_no_srt.mp4

最后把 SRT 字幕烧录进去：

ffmpeg -i render/replay_no_srt.mp4 -vf "subtitles=replay.srt" \ -c:a copy render/replay_final.mp4

Windows 下 subtitles 路径如果包含中文字段，可能需要转义，建议先改成英文路径再执行。

7.3 合成检查清单

• 音频是否对齐，角色说话时画面是否切换合理。
• 字幕是否有溢出画面边界，中文字体是否正常显示。
• 视频码率是否过高导致文件过大，1080p 常见控制在 4M 到 8M 码率。
• 最终视频能否在主流播放器正常播放。

8. 接口 API 与批量任务队列

做到这一步，很多操作是可以接口化的。转写、TTS、出图、合成都可以拆成独立服务或脚本，再通过一个任务队列串联起来。

8.1 接口化设计

常见做法是把每个环节封装成 HTTP 接口：

实际项目里不一定每个服务都有官方 Web 方案，但自己写一个薄封装脚本即可。

8.2 批量任务脚本

把每个文件作为一条任务，统一写入队列：

import os import subprocess audio_dir = "./audio" task_queue = [] for root, _, files in os.walk(audio_dir): for f in files: if f.endswith(".wav"): task_queue.append(os.path.join(root, f)) for idx, audio in enumerate(task_queue): print(f"[{idx + 1}/{len(task_queue)}] processing {audio}") try: subprocess.run(["python", "transcribe.py", audio], check=True) except subprocess.CalledProcessError as e: print(f"[ERROR] failed: {audio}, exit={e.returncode}")

批量任务一定要记录日志和失败文件，否则跑到一半中断后很难定位是哪个文件出的问题。

9. 资源占用与性能观察

本地跑完整条链路时，重点观察三类资源：显存、内存和磁盘。

9.1 显存观察方法

Linux 下使用nvidia-smi：

watch -n 1 nvidia-smi

Windows 下也可以直接在任务管理器里看 GPU 显存占用。

转写模型、TTS 模型、出图模型同时启动时，显存会叠加。稳妥的做法是逐个调用，一个环节结束释放模型后再启动下一个，或者用批量脚本串行处理。

9.2 CPU 推理差异

• Whisper 转写：CPU 可以跑，但长音频耗时明显，建议先切分成片段。
• TTS：CPU 推理也能接受短句，但长文本批量合成建议使用 GPU。
• AI 出图：CPU 出图非常慢，一般建议 6G 以上显存。
• ffmpeg 合成：CPU 占用偏高，但多核并行下速度通常可以接受。

如果显存只有 4G 到 6G，优先把 AI 出图的分辨率降低，例如生成的底图先控制在 768 以下，再用后期放大流程处理。TTS 模型也要选轻量版本，不要多个模型同时驻留内存。

10. 常见问题与排查方法

11. 最佳实践与合规使用建议

到这里，整套流程已经能跑通。但要稳定用于实际项目，还需要遵守一些工程和合规原则。

第一，第一次做 Replay 时不要追求一步到位。先用 3 分钟短片段把“语音转写 -> 人工校对 -> TTS 配音 -> 单张立绘 -> ffmpeg 合成”的最小链路走通，再扩展到整段长音频。

第二，保留一套最小可运行配置。不管是 Whisper 模型路径、TTS 参考音色，还是 ComfyUI 工作流，都要记录版本和参数。环境一变，效果很难复现。

第三，素材分目录管理。原始录音、中间音频、字幕、图片、渲染视频必须分开，不要全部堆在一个 output 目录里。批量脚本跑崩之后，能快速定位哪些文件已经处理过。

第四，批量任务要加日志和失败重试。每条任务记录状态：pending、running、failed、done。失败任务单独放到failed/目录，下一次运行时自动跳过已完成文件。

第五，接口服务要限制访问范围。如果开启 HTTP API，监听地址不要直接绑到0.0.0.0，建议用127.0.0.1，或者加访问控制，防止局域网内其他设备误调用。

第六，涉及人脸、声音、版权素材时必须确认授权。Replay 中的跑团玩家录音，如果只是内部交流，问题不大；如果做公开视频，需要征得所有参与者同意。使用知名角色形象或世界观进行同人创作，先确认官方允许范围和平台规则。TTS 音色不要使用未经授权的真实声优、主播或艺人语音。

第七，发布前做效果复核。检查 TTS 生成的每一条台词是否读对，检查 AI 立绘是否出现不符合角色设定的内容，检查字幕时间轴是否准确。尤其在长文本和批量任务中，容易出现个别台词内容错误或图像异常，人眼复核不能省略。

12. 总结与下一步

这套流程的核心价值不是某个单点模型，而是把 ASR 转写、TTS 配音、AI 出图、ffmpeg 合成按流水线方式串起来。对一个短团案例来说，最先该验证的是转写质量和 TTS 音色稳定性；最容易踩的坑是模型之间显存叠加、批量任务中断、以及字幕和语音不同步。

后续可以扩展的方向：一是把转写、TTS、出图封装成独立 API 服务，通过任务队列串联，形成半自动 Replay 流水线；二是为固定角色训练一致性 LoRA，提升立绘稳定性；三是给最终渲染脚本加上参数化配置，比如一个 YAML 文件就能定义整集视频的分镜顺序、配音文本和字幕样式。

先把最小流程跑通，再逐步挂上自动化，这套链路是可以真正用于日常 Replay 制作的。建议收藏备用，下次做类似作品时直接按这个目录搭一遍环境。