这次我们不看剧情看制作流程。《绝望的孤岛》这类 COC 跑团熟肉本质上是一条“多人语音录制 - 转写 - 翻译 - 打轴 - 压制成片”的内容生产线。很多观众看到的是主持人控场、调查员丢骰子、守密人念描述但真正决定一条熟肉能不能稳定产出的是音频对齐、术语统一、字幕打轴和批量压制这些技术环节。如果你正在做跑团录播、字幕组协作或者想把自己桌面的跑团录像整理成可发布的视频这篇文章值得收藏。我会从素材整理开始讲到语音转写、字幕生成、术语一致性和 ffmpeg 压制最后给出一套完整的排错清单。所有命令都是通用模板实际使用时按你的文件路径、工具版本和操作系统调整即可。1. 核心能力速览下面这张表先帮你快速判断这套流程能干什么、门槛在哪、适不适合你的使用场景。能力项说明流程类型COC 跑团录像/录音后期制作链路主要功能多轨音频整理、语音转写、字幕生成、术语统一、视频压制核心工具ffmpeg、Whisper 类 ASR 工具、字幕编辑工具、翻译辅助工具支持平台Windows / Linux / macOS取决于各工具版本硬件需求CPU 可跑完整流程GPU 可明显加速语音识别和压制启动方式命令行 / 本地脚本 / WebUI 工具均有可操作方案是否支持 API取决于你选用的 ASR 和翻译工具可以自建 HTTP 服务是否支持批量任务支持建议按目录批量处理适合场景跑团熟肉字幕、播客转写、多人语音录制后期、桌游录播需要注意录音质量、人数、口音和背景音会直接影响转写准确率不要期望一条嘈杂的四人对录音频能直接得到零错误字幕。所有流程最终都需要人工复核尤其是克苏鲁神话专有名词和技能名。2. 适用场景与使用边界这套流程适合以下几类人跑团视频作者需要把 3 到 6 小时的多人语音整理成带字幕的成片。字幕组协作成员需要把分轨录音快速切成可翻译的片段。播客或访谈节目后期想用 ASR 先出一版粗字幕再精校。桌游社团做内部存档把一场跑团从录音整理成文字 log。它解决的核心问题是多轨录音混乱、人声转写耗时、专有名词翻译不一致、字幕和画面错位、批量压制费时间。不适合的场景也要说清楚如果录音本身严重爆音、多人同时说话、背景音乐盖过人声转写准确率会很难看需要先做降噪处理。如果需要舞台剧级别的精修、复杂特效字幕和逐帧调轴这套基础流程不够需要引入专业字幕软件。如果素材涉及他人肖像、声音、未授权的音乐、模组文本必须确认授权后再发布不能用自动化工具绕过版权限制。合规方面要特别强调跑团熟肉涉及玩家声音、角色命名、使用模组文本、可能出现的音乐和图片素材。制作前要确认录制时是否征得同意发布时是否需要注明模组来源字幕翻译是否允许公开传播。无论是本地转写还是调用在线 API都要避免上传包含敏感信息的录音到不受控的服务。3. 环境准备与前置条件先准备好基础环境避免后面每一步都卡在工具缺失上。3.1 系统与运行时Windows 10/11、Ubuntu 20.04、macOS 12 均可但路径写法有差异。Python 3.10 或 3.11用于跑 ASR、字幕脚本和批量处理。ffmpeg必须安装并加入 PATH后面所有音频提取、合并、压制的核心都靠它。Node.js 或 Go 不是硬性要求但如果要用一些字幕 Web 工具可能需要。有 NVIDIA GPU 时建议装好 CUDA 驱动没有 GPU 也能跑 CPU 推理只是慢很多。3.2 检查基础命令安装完成后先执行几条命令确认环境正常。python --version ffmpeg -version如果ffmpeg命令找不到需要把安装目录加入系统 PATH。Windows 用户也可以使用完整路径来调用C:\ffmpeg\bin\ffmpeg.exe -version3.3 目录规划跑团熟肉涉及的素材很多建议先建好目录结构后面所有脚本都按这个结构读写。coc_project/ ├── raw/ # 原始录像、分轨录音 ├── audio/ # 提取后的统一音频 ├── segments/ # 切分后的片段 ├── asr_output/ # 语音转写结果 ├── srt/ # 字幕文件 ├── translated/ # 翻译后字幕 ├── final/ # 压制成片 └── logs/ # 批处理日志这样的好处是不同阶段互不干扰批量任务出问题时能快速定位是哪一类文件出了问题。3.4 磁盘与端口一场 4 小时跑团录像原始文件可能占几十 GB。转写会生成中间音频和 json 文本翻译会生成多份 srt最终压制还要输出 1080p 或 4K 文件。建议至少预留原始素材两倍以上的磁盘空间。如果使用 WebUI 工具注意端口占用。默认端口可能被占用时可以换一个端口启动比如python webui.py --port 78614. 素材采集与音频整理4.1 录制阶段的建议跑团录音最怕的是各说各话、音量不统一。录制时尽量做到每人独立音轨至少分主持人和其他玩家两轨。使用固定采样率建议 48kHz16bit 或 24bit。避免使用压缩过度的在线会议录音码率太低会严重降低转写准确率。录制前让每个人做 10 秒试音检查是否有爆音、电流声和回声。4.2 用 ffmpeg 提取音频假设你拿到的是游戏录屏带内录声音或者会议平台导出的一条音轨先用 ffmpeg 统一提取为 WAV 或 FLAC。ffmpeg -i input.mp4 -vn -ac 2 -ar 48000 -sample_fmt s16 audio/main.wav如果有多条音轨文件可以先把它们合并。合并前先确认每条轨道的采样率和声道数一致否则 ffmpeg 会报参数冲突。ffmpeg -i track_1.wav -i track_2.wav -filter_complex amixinputs2:durationlongest audio/merged.wav4.3 切分片段跑团时间很长直接整段转写容易出现上下文丢失和显存溢出。建议按场景、按章节或按每 10 到 20 分钟切分。ffmpeg -i audio/merged.wav -ss 00:00:00 -to 00:20:00 -c copy segments/part_01.wav注意-c copy对 wav 不一定安全建议用 pcm 编码切分ffmpeg -i audio/merged.wav -ss 00:00:00 -to 00:20:00 -c:a pcm_s16le segments/part_01.wav切分后优先检查每一段开头是否有“上一段结尾的残留人声”避免转写出现莫名其妙的断句。4.4 常见问题音轨不同步多轨素材最常见的 bug 是音轨错位。症状是口型和声音对不上或者两个人的对话明显有延迟。排查方式是用播放器同时打开两个文件对比波形更稳妥的是在 Audacity 里看波形峰值是否对齐。如果录屏有帧率波动不要用-c copy直接合并应该重新编码并让视频和音频使用同一个时间基准。5. 语音转写与字幕初稿这是整条流水线里最耗时的一步。转写工具的选择取决于你的设备和隐私要求。5.1 本地转写工具选型如果录音涉及未公开的跑团剧情建议使用本地部署的 ASR 工具。Whisper 类模型对英文识别效果好中文场景可以选择针对中文优化过的模型或微调版本不同模型在专有名词、多说话人场景下的表现差异很大。使用前先确认模型文件完整。很多转写失败并不是工具问题而是模型文件下载不完整导致的“半路报错”这种 bug 很隐蔽。5.2 通用命令行转写示例以下命令是通用模板实际工具名和参数以你选定的 ASR 工具为准。python transcribe.py \ --audio segments/part_01.wav \ --language zh \ --model medium \ --output_dir asr_output转写完成后通常能得到带时间戳的文本、纯文本和 json 格式的完整结果。检查 asr_output 里的 json确认说话人时间轴是否连续。5.3 多说话人处理跑团一般是多人对话ASR 默认不区分说话人。常见的处理方式有两种用带说话人分离的 ASR 工具或插件按声纹区分玩家。先转写再人工根据语义和上下文标注说话人。第二种方式更通用但工作量大。建议在转写结果里用类似[PL1]、[PL2]、[KEEPER]的占位符标注方便后续翻译和字幕阶段替换成角色名。5.4 检查转写质量转写完不要直接进翻译先做一轮“错字扫描”。常见的 bug 有三类同音字错误“克苏鲁”被写成“克苏炉”或“克苏鲁” 之外的音节组合。断句错误一个长句被拆成多行影响字幕阅读。时间戳偏移说话内容与时间轴对不上。发现这些问题的处理方式是先在转写工具的参数层面调整分段长度再统一走术语表替换。6. 术语表与翻译一致性COC 跑团有大量固定名词直接机翻会出现同一个“Sanity Check”在不同位置被翻译成“理智检定”“神志检定”“SAN 检定”的情况。一致性需要靠术语表约束。6.1 建立术语表常用术语可以先整理成一张表原文统一译名备注Keeper守密人房规版本可能称“主持人”Investigator调查员玩家角色Sanity理智值简称 SANSanity Check理智检定不译成“神志检定”Mythos神话视上下文可补充“克苏鲁神话”Elder Sign旧神之印注意与“旧日支配者”区分Luck幸运值不译成“运气”把术语表做成 json 或 yaml 文件方便脚本批量替换。{ Keeper: 守密人, Investigator: 调查员, Sanity Check: 理智检定 }6.2 批量术语替换拿到 ASR 转写文本后用 Python 脚本做术语统一注意替换顺序先替换长词再替换短词避免“Sanity”先被替换成“理智”后Sanity Check变成“理智 Check”。import json with open(term_map.json, r, encodingutf-8) as f: term_map json.load(f) text The Keeper asks the Investigator to make a Sanity Check. # 按词条长度降序替换避免短词抢占长词 for term in sorted(term_map, keylen, reverseTrue): text text.replace(term, term_map[term]) print(text)这会输出“The 守密人 asks the 调查员 to make a 理智检定.”。这只是一个粗糙示例真实翻译代理里还需要处理英文词形变化比如Sanity Checks和Sanity Check。6.3 机翻与人工精校机翻可以处理大部分通用语句但跑团对话里有大量口语、双关、玩家之间的即兴接梗和模组道具描述这些必须人工精校。建议流程是先整理术语表。切分文本后做机翻。译者按角色和场景逐段精校。把精校后的文本回填到带时间戳的字幕文件。精校时重点关注投骰判定、技能检定这类影响剧情理解的段落避免出现把“检定失败”译成“测试失败”这种读起来很出戏的问题。7. 字幕生成、打轴与批量转换7.1 字幕格式选择常见格式有三种SRT通用性最好几乎所有播放器都支持。ASS支持样式、字体、颜色适合做跑团角色名字着色。VTT适合网页端和部分视频平台。基础熟肉先用 SRT 跑通再根据发布平台需要转成 ASS。7.2 生成 SRT 示例假设你已经有一个转写工具输出的 json里面包含每句的开始时间、结束时间和文本可以用 Python 生成 SRT。from datetime import timedelta def format_ts(seconds): ms int(seconds * 1000) hours ms // 3600000 minutes (ms % 3600000) // 60000 secs (ms % 60000) // 1000 msecs ms % 1000 return f{hours:02}:{minutes:02}:{secs:02},{msecs:03} def write_srt(entries, output_path): with open(output_path, w, encodingutf-8) as f: for idx, entry in enumerate(entries, start1): start format_ts(entry[start]) end format_ts(entry[end]) f.write(f{idx}\n{start} -- {end}\n{entry[text]}\n\n) entries [ {start: 0.0, end: 2.5, text: 欢迎来到绝望的孤岛}, {start: 2.8, end: 5.0, text: 今天我们要调查这座岛上的异常事件}, ] write_srt(entries, srt/part_01.srt)这个脚本演示了 SRT 的基础结构。真实项目里entries应该来自 ASR 结果的 json而不是手写。7.3 批量转换如果从其他字幕格式转 SRT可以用 ffmpegffmpeg -i input.ass output.srt批量处理时建议写一个循环脚本for f in asr_output/*.json; do python json_to_srt.py $f srt/$(basename $f .json).srt done注意文件名不要带空格和特殊字符否则循环脚本容易出 bug。Windows 下建议用 PowerShellGet-ChildItem asr_output -Filter *.json | ForEach-Object { python json_to_srt.py $_.FullName srt\$($_.BaseName).srt }7.4 检查字幕时间轴字幕与音频对齐的常见检查方法在播放器里连续播放观察字幕出现时间是否比说话早或晚 0.5 秒以上。用字幕编辑工具打开音轨和字幕文件看波形峰值与字幕文本切点是否对应。批量检查 SRT 文件里是否有“同时出现多个时间重叠”的情况说明说话人时间轴没有切干净。跑团熟肉里最容易出现的字幕 bug 是玩家笑场和插话导致字幕堆积成两行这时需要人工合并或拆分条目而不是只改时间。8. 视频剪辑与熟肉压制8.1 粗剪与精剪跑团素材通常很长先不要一开始就压全片。先确定三个内容节点开场、跑团实录、结尾复盘。粗剪可以使用任何主流剪辑工具关键是输出时保持统一的帧率和分辨率避免不同片段之间画质跳变。8.2 ffmpeg 硬字幕压制如果要发布到视频平台通常需要把字幕烧录进画面。ffmpeg 可以直接挂 ASS 或 SRT 字幕压制。ffmpeg -i input.mp4 -vf subtitlessubtitle.ass -c:v libx264 -crf 20 -c:a aac -b:a 192k output.mp4Windows 下路径包含冒号时容易出问题建议把字幕文件和工作目录放到同一层并使用相对路径。8.3 软字幕封装如果只是本地播放或后续仍需调整字幕更推荐软字幕封装把 SRT 作为独立轨道封装进 MKVffmpeg -i input.mp4 -i subtitle.srt -c copy -c:s srt output.mkv软字幕不会破坏画质也方便发字幕组版本时让观众自由开关字幕。8.4 批量压制脚本多集跑团视频需要批量压制。先建立一集一个目录的结构然后写循环处理。for episode in episodes/*/; do name$(basename $episode) ffmpeg -i $episode/raw.mp4 \ -vf subtitles$episode/subtitle.ass \ -c:v libx264 -crf 20 \ -c:a aac -b:a 192k \ final/${name}.mp4 done批量压制的关键不是命令本身而是命名规范。如果文件名不一致循环条件就会匹配失败这种 bug 在脚本里最难发现。9. 接口 API 与批量流水线9.1 是否需要 API如果你只是自己处理一两期熟肉不需要 API。但如果是字幕组协作多人同时提交录音就适合把转写和翻译封装成 HTTP 服务。9.2 通用 API 调用模板下面给一个通用的调用模板实际接口地址、请求字段和返回结构需要改成你本地服务的真实定义。curl -X POST http://127.0.0.1:8000/transcribe \ -H Content-Type: application/json \ -d {audio_path: segments/part_01.wav, language: zh}import requests url http://127.0.0.1:8000/transcribe payload { audio_path: segments/part_01.wav, language: zh } response requests.post(url, jsonpayload, timeout600) print(response.json())9.3 批量任务队列设计批量任务的关键是“可恢复”不要一个任务失败就重新跑整个目录。目录级队列可以这样设计queue/ ├── pending/ ├── running/ ├── done/ └── failed/脚本从pending取文件开始处理时移动到running成功移到done失败移到failed并写日志。这样即使中途机器重启也能从pending和failed里继续而不用重跑所有片段。9.4 失败重试建议转写和翻译偶尔会因为网络、显存、输入格式问题失败。建议重试规则网络类错误间隔 10 秒重试最多 5 次。显存不足降低 batch_size 或换用更小的模型。音频文件损坏跳过并记录文件名后续人工处理。翻译 API 返回超时先重试一次第二次失败就移入 failed 目录。10. 资源占用与性能观察10.1 如何观察显存与 CPU在跑转写和压制时可以用 nvidia-smi 观察显存占用nvidia-smi -l 2CPU 占用可以用系统自带的任务管理器或top。转写模型越大显存占用越高没有 GPU 时CPU 推理时间会成倍拉长。实际占用不能拍脑袋要以你本机跑一次测试任务为准。启动转写后观察前几个片段如果显存接近上限就降低模型尺寸或减少 batch_size。10.2 影响性能的关键参数语音识别模型大小、音频长度、batch_size、是否启用说话人分离。翻译源语言长度、是否保留原文、术语表长度。压制输入分辨率、目标编码器、CRF 值、音频码率。磁盘读写大量小文件读写会拖慢整体速度建议用本地 SSD。10.3 降低资源占用的方法音频先切段再转写避免一次性加载长音频。使用低精度推理能显著降低显存占用有些工具支持自动转换为低精度模式。压制时使用preset参数控制速度先出 1080p 版本确认无误后再出高规格版本。关掉不必要的浏览器标签页和后台工具跑团后期流程常会同时开剪辑软件、字幕工具和多个终端资源冲突时压制会变得极慢。11. 常见问题与排查方法问题现象可能原因排查方式解决方案音轨和画面不同步录屏帧率波动或多轨时间基准不一致在剪辑工具里对比波形峰值重新编码让音视频使用同一时间基准转写出现大量同音错字音频质量差或断句参数不合适播放原音频对比转写文本先降噪调整分段长度再跑一次转写字幕和声音对不上时间戳偏移或转写分段点错位用字幕编辑工具查看时间轴人工调整切点或重新转写该片段专有名词翻译不一致没有统一术语表搜索成品字幕里的同类词建立术语表并做批量替换压制后字幕乱码字体缺失或 SRT 编码不是 UTF-8检查字幕文件编码和字体目录统一转成 UTF-8安装对应字体批量脚本中途停止文件名含空格或特殊字符查看循环脚本日志给路径加引号规范命名转写显存不足模型过大或单条音频太长nvidia-smi 观察占用换小模型、切分音频、降低 batch_sizeAPI 调用超时音频过长或服务端排队查看服务日志先切分再调用增加 timeout人声重叠导致字幕混乱多人同时说话听原音频检查转写段落手动拆分重叠段落标注说话人输出视频体积过大码率设置过高检查文件大小和编码参数调整 CRF 值或使用两遍编码控制码率12. 最佳实践与使用建议12.1 第一次先用小样本跑通不要第一天就开跑完整 4 小时素材。先用 5 分钟片段从音频提取、转写、生成字幕到压制完整走一遍确认每个环节的输出都符合预期。小样本跑通后再放大到全片能省掉大量反复排错的时间。12.2 保留一套最小可运行配置把可用的命令、模型版本、目录结构、术语表记录到一个 md 文件或 README 里。换电脑、加成员、换工具版本时这套配置能帮你快速恢复环境。尤其是 ffmpeg 命令和 ASR 参数最容易在版本升级后行为变化。12.3 模型、素材、输出分目录管理原始录像、提取音频、转写结果、翻译稿和最终视频不要放在同一个目录。混放会带来两个问题批量脚本误匹配文件以及磁盘空间被中间文件占满。建议每期项目独立建目录目录名带日期和集数。12.4 批量任务要加日志和失败重试批量处理必须有日志。每处理一个片段往日志里写入文件名、开始时间、结束时间、结果状态。后面发现某个片段丢失时只看日志就能定位是转写失败、翻译失败还是压制漏跑。失败任务不要原地重试先把失败文件移动到 failed 目录单独处理。12.5 接口服务要限制访问范围如果自己搭建 ASR 或翻译服务不要监听公网地址。默认只绑定127.0.0.1即可内部协作可以用内网地址访问。必须暴露到外部时要加鉴权避免被非授权调用消耗资源。12.6 涉及人脸、声音、版权素材时必须确认授权这是重点跑团熟肉里有玩家声音、名字、角色卡可能有模组原文、背景音乐、图片来源。录制时是否获得所有人同意翻译后的字幕是否允许公开传播素材是否来自版权受限渠道都要先确认。自动化工具不能替代授权确认。12.7 发布前做效果复核发布前至少检查三点字幕是否有明显错别字或术语不统一。关键剧情段落的翻译是否连贯玩家之间的接话是否顺畅。压制后声音和画面是否同步字幕是否在安全区内。13. 总结与下一步这套流程最值得先验证的是一段 5 分钟的多轨录音能否在半小时内走完“去噪 - 切分 - 转写 - 术语替换 - 生成 SRT - 压制预览”全过程。先把这个闭环跑通再扩大到完整跑团视频。最容易踩的坑有三个音轨不同步切分后残留上一段人声以及专有名词翻译不一致。这三类 bug 不会在工具层面报错只会在成片里显现所以每一集都要做人工复核。后续可以扩展的方向很多。如果每期都能稳定产出可以考虑把转写和翻译封装成 API接入字幕组协作平台也可以在半自动流程里加入质检脚本自动检查字幕文本里的错别字、断句异常和术语不一致。再往后还能把 VTT 地图、角色卡、投骰记录和字幕时间轴做联动让跑团熟肉不只是“翻译视频”而是一套结构化的跑团档案。建议收藏备用下一篇可以继续拆解这个流程里的某一环比如语音转写参数怎么调或者 ASS 字幕样式怎么做成统一的跑团角色配色。
这次我们不看剧情看制作流程。《绝望的孤岛》这类 COC 跑团熟肉本质上是一条“多人语音录制 - 转写 - 翻译 - 打轴 - 压制成片”的内容生产线。很多观众看到的是主持人控场、调查员丢骰子、守密人念描述但真正决定一条熟肉能不能稳定产出的是音频对齐、术语统一、字幕打轴和批量压制这些技术环节。如果你正在做跑团录播、字幕组协作或者想把自己桌面的跑团录像整理成可发布的视频这篇文章值得收藏。我会从素材整理开始讲到语音转写、字幕生成、术语一致性和 ffmpeg 压制最后给出一套完整的排错清单。所有命令都是通用模板实际使用时按你的文件路径、工具版本和操作系统调整即可。1. 核心能力速览下面这张表先帮你快速判断这套流程能干什么、门槛在哪、适不适合你的使用场景。能力项说明流程类型COC 跑团录像/录音后期制作链路主要功能多轨音频整理、语音转写、字幕生成、术语统一、视频压制核心工具ffmpeg、Whisper 类 ASR 工具、字幕编辑工具、翻译辅助工具支持平台Windows / Linux / macOS取决于各工具版本硬件需求CPU 可跑完整流程GPU 可明显加速语音识别和压制启动方式命令行 / 本地脚本 / WebUI 工具均有可操作方案是否支持 API取决于你选用的 ASR 和翻译工具可以自建 HTTP 服务是否支持批量任务支持建议按目录批量处理适合场景跑团熟肉字幕、播客转写、多人语音录制后期、桌游录播需要注意录音质量、人数、口音和背景音会直接影响转写准确率不要期望一条嘈杂的四人对录音频能直接得到零错误字幕。所有流程最终都需要人工复核尤其是克苏鲁神话专有名词和技能名。2. 适用场景与使用边界这套流程适合以下几类人跑团视频作者需要把 3 到 6 小时的多人语音整理成带字幕的成片。字幕组协作成员需要把分轨录音快速切成可翻译的片段。播客或访谈节目后期想用 ASR 先出一版粗字幕再精校。桌游社团做内部存档把一场跑团从录音整理成文字 log。它解决的核心问题是多轨录音混乱、人声转写耗时、专有名词翻译不一致、字幕和画面错位、批量压制费时间。不适合的场景也要说清楚如果录音本身严重爆音、多人同时说话、背景音乐盖过人声转写准确率会很难看需要先做降噪处理。如果需要舞台剧级别的精修、复杂特效字幕和逐帧调轴这套基础流程不够需要引入专业字幕软件。如果素材涉及他人肖像、声音、未授权的音乐、模组文本必须确认授权后再发布不能用自动化工具绕过版权限制。合规方面要特别强调跑团熟肉涉及玩家声音、角色命名、使用模组文本、可能出现的音乐和图片素材。制作前要确认录制时是否征得同意发布时是否需要注明模组来源字幕翻译是否允许公开传播。无论是本地转写还是调用在线 API都要避免上传包含敏感信息的录音到不受控的服务。3. 环境准备与前置条件先准备好基础环境避免后面每一步都卡在工具缺失上。3.1 系统与运行时Windows 10/11、Ubuntu 20.04、macOS 12 均可但路径写法有差异。Python 3.10 或 3.11用于跑 ASR、字幕脚本和批量处理。ffmpeg必须安装并加入 PATH后面所有音频提取、合并、压制的核心都靠它。Node.js 或 Go 不是硬性要求但如果要用一些字幕 Web 工具可能需要。有 NVIDIA GPU 时建议装好 CUDA 驱动没有 GPU 也能跑 CPU 推理只是慢很多。3.2 检查基础命令安装完成后先执行几条命令确认环境正常。python --version ffmpeg -version如果ffmpeg命令找不到需要把安装目录加入系统 PATH。Windows 用户也可以使用完整路径来调用C:\ffmpeg\bin\ffmpeg.exe -version3.3 目录规划跑团熟肉涉及的素材很多建议先建好目录结构后面所有脚本都按这个结构读写。coc_project/ ├── raw/ # 原始录像、分轨录音 ├── audio/ # 提取后的统一音频 ├── segments/ # 切分后的片段 ├── asr_output/ # 语音转写结果 ├── srt/ # 字幕文件 ├── translated/ # 翻译后字幕 ├── final/ # 压制成片 └── logs/ # 批处理日志这样的好处是不同阶段互不干扰批量任务出问题时能快速定位是哪一类文件出了问题。3.4 磁盘与端口一场 4 小时跑团录像原始文件可能占几十 GB。转写会生成中间音频和 json 文本翻译会生成多份 srt最终压制还要输出 1080p 或 4K 文件。建议至少预留原始素材两倍以上的磁盘空间。如果使用 WebUI 工具注意端口占用。默认端口可能被占用时可以换一个端口启动比如python webui.py --port 78614. 素材采集与音频整理4.1 录制阶段的建议跑团录音最怕的是各说各话、音量不统一。录制时尽量做到每人独立音轨至少分主持人和其他玩家两轨。使用固定采样率建议 48kHz16bit 或 24bit。避免使用压缩过度的在线会议录音码率太低会严重降低转写准确率。录制前让每个人做 10 秒试音检查是否有爆音、电流声和回声。4.2 用 ffmpeg 提取音频假设你拿到的是游戏录屏带内录声音或者会议平台导出的一条音轨先用 ffmpeg 统一提取为 WAV 或 FLAC。ffmpeg -i input.mp4 -vn -ac 2 -ar 48000 -sample_fmt s16 audio/main.wav如果有多条音轨文件可以先把它们合并。合并前先确认每条轨道的采样率和声道数一致否则 ffmpeg 会报参数冲突。ffmpeg -i track_1.wav -i track_2.wav -filter_complex amixinputs2:durationlongest audio/merged.wav4.3 切分片段跑团时间很长直接整段转写容易出现上下文丢失和显存溢出。建议按场景、按章节或按每 10 到 20 分钟切分。ffmpeg -i audio/merged.wav -ss 00:00:00 -to 00:20:00 -c copy segments/part_01.wav注意-c copy对 wav 不一定安全建议用 pcm 编码切分ffmpeg -i audio/merged.wav -ss 00:00:00 -to 00:20:00 -c:a pcm_s16le segments/part_01.wav切分后优先检查每一段开头是否有“上一段结尾的残留人声”避免转写出现莫名其妙的断句。4.4 常见问题音轨不同步多轨素材最常见的 bug 是音轨错位。症状是口型和声音对不上或者两个人的对话明显有延迟。排查方式是用播放器同时打开两个文件对比波形更稳妥的是在 Audacity 里看波形峰值是否对齐。如果录屏有帧率波动不要用-c copy直接合并应该重新编码并让视频和音频使用同一个时间基准。5. 语音转写与字幕初稿这是整条流水线里最耗时的一步。转写工具的选择取决于你的设备和隐私要求。5.1 本地转写工具选型如果录音涉及未公开的跑团剧情建议使用本地部署的 ASR 工具。Whisper 类模型对英文识别效果好中文场景可以选择针对中文优化过的模型或微调版本不同模型在专有名词、多说话人场景下的表现差异很大。使用前先确认模型文件完整。很多转写失败并不是工具问题而是模型文件下载不完整导致的“半路报错”这种 bug 很隐蔽。5.2 通用命令行转写示例以下命令是通用模板实际工具名和参数以你选定的 ASR 工具为准。python transcribe.py \ --audio segments/part_01.wav \ --language zh \ --model medium \ --output_dir asr_output转写完成后通常能得到带时间戳的文本、纯文本和 json 格式的完整结果。检查 asr_output 里的 json确认说话人时间轴是否连续。5.3 多说话人处理跑团一般是多人对话ASR 默认不区分说话人。常见的处理方式有两种用带说话人分离的 ASR 工具或插件按声纹区分玩家。先转写再人工根据语义和上下文标注说话人。第二种方式更通用但工作量大。建议在转写结果里用类似[PL1]、[PL2]、[KEEPER]的占位符标注方便后续翻译和字幕阶段替换成角色名。5.4 检查转写质量转写完不要直接进翻译先做一轮“错字扫描”。常见的 bug 有三类同音字错误“克苏鲁”被写成“克苏炉”或“克苏鲁” 之外的音节组合。断句错误一个长句被拆成多行影响字幕阅读。时间戳偏移说话内容与时间轴对不上。发现这些问题的处理方式是先在转写工具的参数层面调整分段长度再统一走术语表替换。6. 术语表与翻译一致性COC 跑团有大量固定名词直接机翻会出现同一个“Sanity Check”在不同位置被翻译成“理智检定”“神志检定”“SAN 检定”的情况。一致性需要靠术语表约束。6.1 建立术语表常用术语可以先整理成一张表原文统一译名备注Keeper守密人房规版本可能称“主持人”Investigator调查员玩家角色Sanity理智值简称 SANSanity Check理智检定不译成“神志检定”Mythos神话视上下文可补充“克苏鲁神话”Elder Sign旧神之印注意与“旧日支配者”区分Luck幸运值不译成“运气”把术语表做成 json 或 yaml 文件方便脚本批量替换。{ Keeper: 守密人, Investigator: 调查员, Sanity Check: 理智检定 }6.2 批量术语替换拿到 ASR 转写文本后用 Python 脚本做术语统一注意替换顺序先替换长词再替换短词避免“Sanity”先被替换成“理智”后Sanity Check变成“理智 Check”。import json with open(term_map.json, r, encodingutf-8) as f: term_map json.load(f) text The Keeper asks the Investigator to make a Sanity Check. # 按词条长度降序替换避免短词抢占长词 for term in sorted(term_map, keylen, reverseTrue): text text.replace(term, term_map[term]) print(text)这会输出“The 守密人 asks the 调查员 to make a 理智检定.”。这只是一个粗糙示例真实翻译代理里还需要处理英文词形变化比如Sanity Checks和Sanity Check。6.3 机翻与人工精校机翻可以处理大部分通用语句但跑团对话里有大量口语、双关、玩家之间的即兴接梗和模组道具描述这些必须人工精校。建议流程是先整理术语表。切分文本后做机翻。译者按角色和场景逐段精校。把精校后的文本回填到带时间戳的字幕文件。精校时重点关注投骰判定、技能检定这类影响剧情理解的段落避免出现把“检定失败”译成“测试失败”这种读起来很出戏的问题。7. 字幕生成、打轴与批量转换7.1 字幕格式选择常见格式有三种SRT通用性最好几乎所有播放器都支持。ASS支持样式、字体、颜色适合做跑团角色名字着色。VTT适合网页端和部分视频平台。基础熟肉先用 SRT 跑通再根据发布平台需要转成 ASS。7.2 生成 SRT 示例假设你已经有一个转写工具输出的 json里面包含每句的开始时间、结束时间和文本可以用 Python 生成 SRT。from datetime import timedelta def format_ts(seconds): ms int(seconds * 1000) hours ms // 3600000 minutes (ms % 3600000) // 60000 secs (ms % 60000) // 1000 msecs ms % 1000 return f{hours:02}:{minutes:02}:{secs:02},{msecs:03} def write_srt(entries, output_path): with open(output_path, w, encodingutf-8) as f: for idx, entry in enumerate(entries, start1): start format_ts(entry[start]) end format_ts(entry[end]) f.write(f{idx}\n{start} -- {end}\n{entry[text]}\n\n) entries [ {start: 0.0, end: 2.5, text: 欢迎来到绝望的孤岛}, {start: 2.8, end: 5.0, text: 今天我们要调查这座岛上的异常事件}, ] write_srt(entries, srt/part_01.srt)这个脚本演示了 SRT 的基础结构。真实项目里entries应该来自 ASR 结果的 json而不是手写。7.3 批量转换如果从其他字幕格式转 SRT可以用 ffmpegffmpeg -i input.ass output.srt批量处理时建议写一个循环脚本for f in asr_output/*.json; do python json_to_srt.py $f srt/$(basename $f .json).srt done注意文件名不要带空格和特殊字符否则循环脚本容易出 bug。Windows 下建议用 PowerShellGet-ChildItem asr_output -Filter *.json | ForEach-Object { python json_to_srt.py $_.FullName srt\$($_.BaseName).srt }7.4 检查字幕时间轴字幕与音频对齐的常见检查方法在播放器里连续播放观察字幕出现时间是否比说话早或晚 0.5 秒以上。用字幕编辑工具打开音轨和字幕文件看波形峰值与字幕文本切点是否对应。批量检查 SRT 文件里是否有“同时出现多个时间重叠”的情况说明说话人时间轴没有切干净。跑团熟肉里最容易出现的字幕 bug 是玩家笑场和插话导致字幕堆积成两行这时需要人工合并或拆分条目而不是只改时间。8. 视频剪辑与熟肉压制8.1 粗剪与精剪跑团素材通常很长先不要一开始就压全片。先确定三个内容节点开场、跑团实录、结尾复盘。粗剪可以使用任何主流剪辑工具关键是输出时保持统一的帧率和分辨率避免不同片段之间画质跳变。8.2 ffmpeg 硬字幕压制如果要发布到视频平台通常需要把字幕烧录进画面。ffmpeg 可以直接挂 ASS 或 SRT 字幕压制。ffmpeg -i input.mp4 -vf subtitlessubtitle.ass -c:v libx264 -crf 20 -c:a aac -b:a 192k output.mp4Windows 下路径包含冒号时容易出问题建议把字幕文件和工作目录放到同一层并使用相对路径。8.3 软字幕封装如果只是本地播放或后续仍需调整字幕更推荐软字幕封装把 SRT 作为独立轨道封装进 MKVffmpeg -i input.mp4 -i subtitle.srt -c copy -c:s srt output.mkv软字幕不会破坏画质也方便发字幕组版本时让观众自由开关字幕。8.4 批量压制脚本多集跑团视频需要批量压制。先建立一集一个目录的结构然后写循环处理。for episode in episodes/*/; do name$(basename $episode) ffmpeg -i $episode/raw.mp4 \ -vf subtitles$episode/subtitle.ass \ -c:v libx264 -crf 20 \ -c:a aac -b:a 192k \ final/${name}.mp4 done批量压制的关键不是命令本身而是命名规范。如果文件名不一致循环条件就会匹配失败这种 bug 在脚本里最难发现。9. 接口 API 与批量流水线9.1 是否需要 API如果你只是自己处理一两期熟肉不需要 API。但如果是字幕组协作多人同时提交录音就适合把转写和翻译封装成 HTTP 服务。9.2 通用 API 调用模板下面给一个通用的调用模板实际接口地址、请求字段和返回结构需要改成你本地服务的真实定义。curl -X POST http://127.0.0.1:8000/transcribe \ -H Content-Type: application/json \ -d {audio_path: segments/part_01.wav, language: zh}import requests url http://127.0.0.1:8000/transcribe payload { audio_path: segments/part_01.wav, language: zh } response requests.post(url, jsonpayload, timeout600) print(response.json())9.3 批量任务队列设计批量任务的关键是“可恢复”不要一个任务失败就重新跑整个目录。目录级队列可以这样设计queue/ ├── pending/ ├── running/ ├── done/ └── failed/脚本从pending取文件开始处理时移动到running成功移到done失败移到failed并写日志。这样即使中途机器重启也能从pending和failed里继续而不用重跑所有片段。9.4 失败重试建议转写和翻译偶尔会因为网络、显存、输入格式问题失败。建议重试规则网络类错误间隔 10 秒重试最多 5 次。显存不足降低 batch_size 或换用更小的模型。音频文件损坏跳过并记录文件名后续人工处理。翻译 API 返回超时先重试一次第二次失败就移入 failed 目录。10. 资源占用与性能观察10.1 如何观察显存与 CPU在跑转写和压制时可以用 nvidia-smi 观察显存占用nvidia-smi -l 2CPU 占用可以用系统自带的任务管理器或top。转写模型越大显存占用越高没有 GPU 时CPU 推理时间会成倍拉长。实际占用不能拍脑袋要以你本机跑一次测试任务为准。启动转写后观察前几个片段如果显存接近上限就降低模型尺寸或减少 batch_size。10.2 影响性能的关键参数语音识别模型大小、音频长度、batch_size、是否启用说话人分离。翻译源语言长度、是否保留原文、术语表长度。压制输入分辨率、目标编码器、CRF 值、音频码率。磁盘读写大量小文件读写会拖慢整体速度建议用本地 SSD。10.3 降低资源占用的方法音频先切段再转写避免一次性加载长音频。使用低精度推理能显著降低显存占用有些工具支持自动转换为低精度模式。压制时使用preset参数控制速度先出 1080p 版本确认无误后再出高规格版本。关掉不必要的浏览器标签页和后台工具跑团后期流程常会同时开剪辑软件、字幕工具和多个终端资源冲突时压制会变得极慢。11. 常见问题与排查方法问题现象可能原因排查方式解决方案音轨和画面不同步录屏帧率波动或多轨时间基准不一致在剪辑工具里对比波形峰值重新编码让音视频使用同一时间基准转写出现大量同音错字音频质量差或断句参数不合适播放原音频对比转写文本先降噪调整分段长度再跑一次转写字幕和声音对不上时间戳偏移或转写分段点错位用字幕编辑工具查看时间轴人工调整切点或重新转写该片段专有名词翻译不一致没有统一术语表搜索成品字幕里的同类词建立术语表并做批量替换压制后字幕乱码字体缺失或 SRT 编码不是 UTF-8检查字幕文件编码和字体目录统一转成 UTF-8安装对应字体批量脚本中途停止文件名含空格或特殊字符查看循环脚本日志给路径加引号规范命名转写显存不足模型过大或单条音频太长nvidia-smi 观察占用换小模型、切分音频、降低 batch_sizeAPI 调用超时音频过长或服务端排队查看服务日志先切分再调用增加 timeout人声重叠导致字幕混乱多人同时说话听原音频检查转写段落手动拆分重叠段落标注说话人输出视频体积过大码率设置过高检查文件大小和编码参数调整 CRF 值或使用两遍编码控制码率12. 最佳实践与使用建议12.1 第一次先用小样本跑通不要第一天就开跑完整 4 小时素材。先用 5 分钟片段从音频提取、转写、生成字幕到压制完整走一遍确认每个环节的输出都符合预期。小样本跑通后再放大到全片能省掉大量反复排错的时间。12.2 保留一套最小可运行配置把可用的命令、模型版本、目录结构、术语表记录到一个 md 文件或 README 里。换电脑、加成员、换工具版本时这套配置能帮你快速恢复环境。尤其是 ffmpeg 命令和 ASR 参数最容易在版本升级后行为变化。12.3 模型、素材、输出分目录管理原始录像、提取音频、转写结果、翻译稿和最终视频不要放在同一个目录。混放会带来两个问题批量脚本误匹配文件以及磁盘空间被中间文件占满。建议每期项目独立建目录目录名带日期和集数。12.4 批量任务要加日志和失败重试批量处理必须有日志。每处理一个片段往日志里写入文件名、开始时间、结束时间、结果状态。后面发现某个片段丢失时只看日志就能定位是转写失败、翻译失败还是压制漏跑。失败任务不要原地重试先把失败文件移动到 failed 目录单独处理。12.5 接口服务要限制访问范围如果自己搭建 ASR 或翻译服务不要监听公网地址。默认只绑定127.0.0.1即可内部协作可以用内网地址访问。必须暴露到外部时要加鉴权避免被非授权调用消耗资源。12.6 涉及人脸、声音、版权素材时必须确认授权这是重点跑团熟肉里有玩家声音、名字、角色卡可能有模组原文、背景音乐、图片来源。录制时是否获得所有人同意翻译后的字幕是否允许公开传播素材是否来自版权受限渠道都要先确认。自动化工具不能替代授权确认。12.7 发布前做效果复核发布前至少检查三点字幕是否有明显错别字或术语不统一。关键剧情段落的翻译是否连贯玩家之间的接话是否顺畅。压制后声音和画面是否同步字幕是否在安全区内。13. 总结与下一步这套流程最值得先验证的是一段 5 分钟的多轨录音能否在半小时内走完“去噪 - 切分 - 转写 - 术语替换 - 生成 SRT - 压制预览”全过程。先把这个闭环跑通再扩大到完整跑团视频。最容易踩的坑有三个音轨不同步切分后残留上一段人声以及专有名词翻译不一致。这三类 bug 不会在工具层面报错只会在成片里显现所以每一集都要做人工复核。后续可以扩展的方向很多。如果每期都能稳定产出可以考虑把转写和翻译封装成 API接入字幕组协作平台也可以在半自动流程里加入质检脚本自动检查字幕文本里的错别字、断句异常和术语不一致。再往后还能把 VTT 地图、角色卡、投骰记录和字幕时间轴做联动让跑团熟肉不只是“翻译视频”而是一套结构化的跑团档案。建议收藏备用下一篇可以继续拆解这个流程里的某一环比如语音转写参数怎么调或者 ASS 字幕样式怎么做成统一的跑团角色配色。
