COC跑团熟肉制作全流程：从录制到压制的避坑指南

COC跑团熟肉这个标签一出现就意味着眼前的内容不是一场普通桌游直播而是一条经历过规则准备、语音录制、剧本剪辑、翻译校对、字幕打轴和视频压制等环节的成品。很多人第一次看到《神话与科学》这类视频时会被剧情里“bug一样鬼畜”的节奏迷惑以为跑团就是一群人围坐着讲段子真正动手做一期的人才会发现最难的部分不是玩而是把一场四小时以上的多人语音游戏变成一条观看体验正常的熟肉视频。录制断片、音画不同步、字幕时间轴漂移、压制后字幕乱码每一步都可能让前期几小时的努力废掉。这篇文章以COC跑团熟肉制作全流程为线索讲清楚从线上跑团准备到最终视频输出的完整链路并重点整理这个链路里最容易出现的bug现象和排查方式。学完后你可以把这套方法直接复用到自己的跑团录像、多人播客或游戏实况剪辑上。文章会用到OBS、FFmpeg、Whisper、Aegisub这些常见工具也会给出可直接执行的命令和配置片段。1. 先理解COC跑团视频的形态再决定用什么流程做1.1 跑团视频不只是一个“录屏”COC跑团是Call of Cthulhu克苏鲁的呼唤规则下的TRPG玩法。主持游戏的玩家通常称为KP守秘人其他玩家扮演调查员。KP负责描述场景、扮演NPC、推动剧情并判定行动结果调查员则通过角色对话和投骰子推进故事。一场线下跑团动辄三到五个小时线上跑团因为不用考虑通勤和道具时长往往会更久。把跑团做成视频至少有两种常见形态。第一种是直播回放贵在真实后期只要做轻度剪辑和字幕注释第二种是录播精剪也就是熟肉常见的形态需要把废话、跑题、规则争论和等待时间剪掉把对话整理成字幕让观众能快速跟上剧情。后者更接近《神话与科学》这类跑团视频的做法。这里要澄清一个容易误解的地方“熟肉”不等于“手机对着屏幕录一段加个字幕”。它更接近一档多人语音节目的后期工程。你需要同时处理画面、语音、字幕、时间轴和编码格式并且每一步都要保留可回退的中间文件。没有中间文件出bug时就没有排查依据。1.2 “馒馒来式”跑团视频为什么后期工作量更大日本TRPG视频圈早期流行过一种做法不用真人出镜而是用角色立绘、表情差分、字幕气泡和音效来呈现跑团过程。这种风格后来被国内跑团观众统称为“馒馒来风格”。它的核心特点是戏剧化剪辑说话人的台词用字幕单独抽出画面配上对应立绘关键骰点加入特效和暂停剧情分支用跳跃剪辑加快节奏。《神话与科学》这一类“bug一样鬼畜”的跑团视频本质上就是在这个风格上再叠加一层喜剧化处理。它看起来自由、荒诞、节奏飞快但背后反而是大量精确工作立绘要提前准备好台词要能对应到发言人骰点结果要能在字幕里标注音效和BGM要卡在正确的时间点。如果后期流程没有规范任何一步失效都会导致整条视频重做。所以真正值得工程化的不是跑团过程中的口胡和脑筋急转弯而是下面这条链路录制、转写、翻译、打轴、压制、回放检查。只要这条链路稳定无论内容是不是鬼畜向你都能按时出片。1.3 先固定成片规格再开始录制很多跑团视频做到后期才发现无法收尾原因并不是剪辑水平不够而是录制阶段没有固定规格。视频编码、分辨率、音频采样率和字幕格式如果前后不统一后期每碰一次都会增加一类bug。建议在项目启动前先把成片规格写进文档全员按这个标准执行项目推荐规格理由视频编码H.264 或 H.265平台兼容性最好H.265更省空间但老播放器可能不支持分辨率1920x1080 或原素材分辨率大分辨率不会提升录音质量徒增压制时间帧率30fps 固定帧率CFR可变帧率VFR是音画不同步的重要来源音频采样率48kHz16bit 或以上混音时重采样误差更小音频声道至少双声道后期可以提供环境声和语音分离的空间字幕格式ASS可以精确控制样式、位置和特效输出容器MP4 或 MKVMP4通用MKV适合保留软字幕如果原始素材本身是手机录屏或语音软件录制不必强行升到4K。分辨率再高录的是多人语音观众关注的仍然是字幕和节奏。2. 搭建线上跑团与录制环境2.1 工具选型不追求复杂追求可回退线上跑团的工具组合没有标准答案但有一条原则音频录制不能只依赖语音软件。语音软件为了实时通话通常会对音频做压缩、降噪和丢包补偿这些处理会破坏原始音质甚至让后期无法分离出单个人声。常见的跑团工具组合如下环节工具说明注意点语音通话腾讯会议、QQ语音、其他语音软件负责实时沟通不要把平台录音当作唯一素材本地录制OBS Studio录屏、窗口采集、分轨录音提前设置采样率和轨道投骰记录QQ骰娘、DiceBot、网页骰子线上随机判定关键骰点截图或记录方便后期标注资料展示OBS窗口采集、腾讯会议共享展示剧本、地图、立绘采集窗口时锁定窗口避免切错素材整理文件夹命名规则管理录音、立绘、字幕见第5章目录规范这里要强调一个实操经验语音软件只负责“让大家听清”OBS或FFmpeg负责“把素材录好”。如果条件允许最好让每个参与者都单独录一条本地的完整音频哪怕只有手机录音也行。音频是所有跑团视频的底线画面丢了可以后期补静态图语音丢了就只能重录。2.2 OBS音频轨道设置OBS最容易被忽略的部分不是画面而是音频设置。打开OBS后先进入设置再进入音频把采样率设为48kHz。接着在输出设置里找到“音频”或“录音”相关选项卡为右侧的每条音轨选择来源。常见做法是分配两条音轨音轨1录系统声音用于保留可能出现的BGM、视频素材声音。音轨2录麦克风声音用于保留所有人说话的声音。在混音器面板中你需要确认麦克风设备没有静音也没有被软件自动增益拉满。跑团过程中如果某个人说话忽大忽小后期几乎无法恢复因此在录制前让每个人说一段测试句检查音量范围在负12dB到负6dB左右。如果你不想开OBS只想单录一条高质量音频也可以使用FFmpeg命令行。Windows下使用DirectShow设备采集ffmpeg -f dshow -i audio麦克风名称 -ac 2 -ar 48000 -c:a pcm_s16le pc_录音.wavmacOS下可以使用AVFoundationffmpeg -f avfoundation -i :0 -ac 2 -ar 48000 -c:a pcm_s16le pc_录音.wav这条命令的作用是直接采集麦克风并保存为无损WAV格式。相比MP3或语音平台录音WAV保留的信息最多方便后续降噪、混音和时间轴对齐。2.3 角色卡和记录给后期剪辑提供依据跑团视频的字幕需要频繁标注“谁在说话”“投骰结果是多少”“SAN值掉了多少”。如果后期重新回忆这些信息效率极低。建议在跑团开始前准备一份简单的角色卡同时让KP在游戏过程中把关键节点记录下来。下面是一个角色卡JSON示例用于说明思路{ game: 神话与科学, chapter: part1, kp: 守秘人A, pc: [ { name: 研究员A, player: 玩家甲, occupation: 研究员, hp: 10, san: 55 }, { name: 记者B, player: 玩家乙, occupation: 记者, hp: 9, san: 48 } ] }这份数据不一定需要写进代码也可以直接贴在文档里。重点是后期剪辑时需要知道每个昵称对应哪个玩家每个角色在当前时间点的生命值和理智值是多少。投骰结果最好由KP或一个玩家专门记录避免剪辑时回看录像一帧一帧找。注意不要因为流程方便就过度压缩准备阶段。角色信息、术语表和关键骰点记录是后期字幕能否及时更新的前提。3. 熟肉制作核心链路转写、翻译、打轴、压制3.1 用语音识别生成可校对的逐字稿跑团语音动辄数小时人工听写非常痛苦。现在可以使用Whisper等本地语音识别工具先转写出带时间轴的逐字稿。Whisper的优势是本地运行模型文件下载完毕后不需要网络也支持中文。如果你使用Python环境安装了openai-whisper可以直接运行whisper pc_录音.wav --model small --language zh --output_format srt参数含义如下pc_录音.wav输入音频文件。--model small选择模型大小。tiny最快但识别率低small在速度和质量之间比较均衡medium更准但更慢。--language zh指定识别语言为中文。--output_format srt输出标准SRT字幕文件。多人对话时如果所有人混在一条音轨里识别结果会经常串人。更稳妥的方式是每个人单独一个音频文件单独转写。这样会得到多个SRT后续在Aegisub里再按时间轴合并。如果只能混录则需要在人工校对阶段重新调整台词归属。3.2 翻译与术语统一跑团熟肉通常不只是给中文观众看英文原版还涉及规则术语和网络黑话。翻译时如果每个参与者的角色名、技能名、物品名不统一观众会很快混乱。建议在动工前先建一张术语表。COC跑团里的常见术语可以这样约定术语推荐译法说明KP守秘人跑团主持人PC调查员玩家操控的角色SAN理智值受到精神冲击时下降HP生命值生命值归零可能重伤或死亡克苏鲁神话克苏鲁神话用于角色接触禁忌知识的能力检定检定用于判定角色行动是否成功不要小看术语统一。字幕里同一名NPC一会叫“教授”一会叫“博士”观众就会弃坑。处理办法很简单翻译完初稿后统一执行一次关键词替换。3.3 用Aegisub打轴和做ASS样式Whisper生成的SRT可以直接导入Aegisub但时间轴只是参考。跑团视频需要精确到话出现的那一帧Aegisub是处理这类字幕最常用的工具。Aegisub的基本操作是打开视频文件播放到说话起点按快捷键“Ctrl1”设置起始时间播放到说话结束按“Ctrl3”设置结束时间。然后修改右侧字幕文本保存为ASS格式。ASS相对于SRT的优势是样式控制。下面是一个可用的最小ASS模板[Script Info] ScriptType: v4.00 PlayResX: 1920 PlayResY: 1080 [V4 Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding Style: Default,Microsoft YaHei,48,H00FFFFFF,H000000FF,H00000000,H80000000,-1,0,0,0,100,100,0,0,1,2,1,2,60,60,40,1 [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:01.00,0:00:03.50,Default,,0,0,0,,这是一条示例字幕这个模板里需要注意几个字段Fontname必须使用系统中已经安装的字体。如果系统没有“Microsoft YaHei”Aegisub和FFmpeg会用默认字体替代导致样式错乱。Fontsize48在1080P分辨率下比较合适。如果最终输出720P建议改成36左右。Alignment2表示底部居中。跑团字幕常用底部居中但如果要区分不同角色可以改用左下和右下位置。MarginL、MarginR、MarginV控制字幕边距。数值太小容易被播放器裁切。Aegisub保存时务必在“导出”时选择UTF-8编码否则中文在部分播放器上会变成乱码。3.4 用FFmpeg压制视频和烧录字幕字幕做完之后有两种输出方式软字幕和硬字幕。软字幕是指字幕以单独轨道存在MKV里播放时可以开关但很多在线视频平台不支持。硬字幕是把字幕画进画面里任何播放器都能看到但修改字幕需要重新压制。使用硬字幕的FFmpeg命令示例ffmpeg -i 视频.mp4 -vf subtitles字幕.ass -c:v libx264 -crf 20 -c:a aac -b:a 192k 输出.mp4这里的关键参数subtitles字幕.ass调用libass滤镜渲染ASS字幕。-c:v libx264使用H.264编码。-crf 20控制画质数字越小画质越高文件越大。20是清晰度和体积的平衡点。-c:a aac -b:a 192k把音频转成AAC码率192k。如果你只需要生成带软字幕的MKV用更简单的方式ffmpeg -i 视频.mp4 -f srt -i 字幕.srt -c:v copy -c:a copy -c:s srt 输出.mkv这个命令直接把视频、音轨和字幕封装进MKV不重新编码速度快也不会损失画质。缺点是多数在线平台无法直接播放适合本地存档或二次处理。注意Windows下使用FFmpeg的subtitles滤镜路径中的冒号和反斜杠需要转义。比如subtitlesfilenameC\:/path/字幕.ass否则会报找不到文件。4. 这个流程里最容易踩到的bug以及排查思路4.1 音画不同步现象是画面里的人嘴形和自己说的话对不上或者声音比画面晚一点。出现这个问题的原因通常有三个录制时生成的是可变帧率VFR文件、音频采样率设置不统一、播放器解码时产生了偏移。先检查文件信息用FFprobe确认帧率和采样率ffprobe -v error -select_streams v:0 -show_entries streamr_frame_rate,avg_frame_rate -of defaultnoprint_wrappers1 输入.mkv ffprobe -v error -select_streams a:0 -show_entries streamsample_rate,channels -of defaultnoprint_wrappers1 输入.mkv如果视频帧率显示为30000/1001这类分数说明它实际上是29.97fps如果显示0/0或频繁变化说明是VFR。压制时遇到VFR建议统一转成CFRffmpeg -i 输入.mkv -fps_mode cfr -r 30 -c:v libx264 -c:a copy 输出.mkv-fps_mode cfr让所有帧按固定帧率输出-r 30指定目标帧率。这里的教训是录制阶段就把帧率固定成30fps后期就不会出现这种问题。4.2 字幕乱码或加载不出来字幕文件内容在文本编辑器里正常但在播放器或Aegisub里变成乱码最常见原因是文件编码不是UTF-8。旧版软件导出SRT时常用ANSI或GBK编码中文字符在其他平台上就会乱码。在Windows下可以把字幕文件转成UTF-8编码Get-Content 字幕.srt -Encoding Default | Set-Content 字幕_utf8.srt -Encoding UTF8在Linux或macOS下可以使用iconviconv -f GBK -t UTF-8 字幕.srt 字幕_utf8.srt还有一类情况是ASS文件里指定的字体不存在。播放器会回退到默认字体中文显示成方块。解决方式是安装对应字体或者把ASS里的Fontname改成“Microsoft YaHei”“PingFang SC”“Noto Sans CJK SC”这类系统常见字体。Linux系统可以通过命令检查可用中文字体fc-list :langzh如果命令输出为空说明系统没有安装中文字体。安装后在FFmpeg压制前重新执行一次即可。4.3 FFmpeg压制失败找不到字体或路径错误FFmpeg错误信息里出现Cannot find a font或Fontconfig error说明libass找不到ASS中使用的字体。可以尝试在ASS模板中改用系统字体或者把字体文件放到系统的字体目录里。Windows路径问题也会导致压制失败。直接写相对路径通常最省事cd /d E:\project\subtitle ffmpeg -i ..\raw\视频.mp4 -vf subtitles字幕.ass -c:v libx264 -crf 20 输出.mp4把输入文件和字幕文件都放在当前目录或相对路径中可以避免大量转义问题。如果你必须在绝对路径中使用参考转义写法C\:/path/字幕.ass。4.4 录音有回声、电流声或音量过小回声通常来自外放。录制多人语音时外放音箱会把对方声音再录进麦克风形成二次混音。推荐使用耳机或者至少设置语音软件的降噪功能。电流声可能是麦克风增益过大或USB供电不稳定。先调低麦克风音量再用OBS的噪音门和压缩器处理。音量过小的问题要在录制前解决后期强行放大不仅会放大底噪还可能削波。正确做法是录制测试音让说话音量保持在OBS峰值表负12dB到负6dB区间。如果已经有录音文件音量偏小可以在FFmpeg中使用loudnorm滤镜统一响度ffmpeg -i 录音.wav -af loudnormI-16:TP-1.5:LRA11 录音_标准化.wav这个命令的作用是让音频整体响度接近统一标准避免多段录音音量忽大忽小。但它不能修复削波失真也不能凭空消除持续电流声。4.5 录音文件录制中断或损坏现象是OBS突然停止或者录制文件无法打开。常见原因包括磁盘空间不足、CPU占用过高、OBS崩溃。先检查磁盘空间df -hWindows下可以查看录制目录所在盘符的剩余空间。避免中断的最有效手段是设置自动分段录制。OBS设置里可以把录制文件按“一分钟”或“自定义大小”自动分割这样即使中断也只会丢失最后一段。如果文件已经损坏旧版本FFmpeg有时可以通过-c copy重新封装来修复ffmpeg -i 损坏.mp4 -c copy 修复.mp4但这个命令只对容器索引损坏有效如果编码数据已经丢失无法恢复。对于跑团视频最佳方案仍然是多轨备份OBS录一份每个参与者自己再录一份。4.6 转写结果错乱、人名识别不准Whisper对中文多人对话的识别效果有限尤其是两人同时说话时结果会混成一条。解决方法是按人分轨转写。可以为每个参与者分配一个单独音频文件再各自转写。专有名词识别不准时可以在Whisper命令中加入--initial_prompt指定热词。例如whisper 录音.wav --model small --language zh --initial_prompt 克苏鲁,守秘人,调查员,SAN值,神话与科学 --output_format srt--initial_prompt的作用是给模型一个词汇环境帮助它优先识别相关词。但这并不是万能的复杂人名仍需要人工校对。转写输出永远只能作为草稿不能作为成片字幕直接发布。5. 从bug现象倒推根因的排查链路5.1 先确认输入文件是否健康遇到任何异常第一步不是改参数而是先确认流入流程的文件是否正常。使用FFprobe查看文件流信息ffprobe -v error -show_streams -show_format 输入.mkv这一步会输出视频流、音频流、容器格式、时长、编码等信息。如果文件连FFprobe都解析不了说明文件本身已经损坏或没有录制完整。此时不必继续做字幕。确认文件是否健康按以下顺序检查文件大小是否为0或远小于预期。时长是否与现场跑团时间接近。视频流和音频流是否存在编码是否正常。采样率和帧率是否符合预期。播放器是否能正常打开打开后是否卡顿。如果播放器能打开但FFprobe解析异常建议先用-c copy重新封装一次再做后续处理。5.2 按“输入-处理-输出”三层定位很多bug排查半天没有结论是因为没有确定问题出在哪一层。跑团视频制作链路可以分成三层层级包含内容典型问题输入层原始录制文件、音频文件、立绘、BGM文件损坏、编码异常、采样率不一致处理层转写脚本、Aegisub操作、FFmpeg压制命令路径错误、字体缺失、滤镜参数问题输出层播放器、在线平台、字幕渲染编码不兼容、字幕乱码、音画不同步排查时先判断问题在哪个层。例如压制完成后用播放器播放正常但上传平台后音画不同步问题很可能在输出层如果原始文件就播放卡顿问题在输入层如果只有某一条字幕显示异常问题在处理层。这个分层法能避免一个常见的坑反复修改压制命令却忘记检查原始文件已经损坏。5.3 关键排查顺序面对具体bug时推荐按下面的顺序排查先检查原始文件能不能正常打开文件大小和时长是否合理。再检查文件帧率、采样率、分辨率是否符合录制前定的规格。确认中间文件是否存在转写SRT、ASS字幕是否已生成。检查字幕文件编码必须为UTF-8。在Aegisub中打开ASS确认样式和字体名。用完整FFmpeg命令压制记录错误输出。换一个播放器或换一个设备验证输出结果。这里最容易被忽略的是第3步。跑团音频长达数小时很多人会直接从原始视频跳到压制命令中间文件缺失后任何一步报错都只能从头再来。5.4 日志、中间产物和脚本没有它们就无法复盘建议把整个项目当成一个迷你工程来管理。不要在同一台电脑上把所有文件堆在桌面也不要只在FFmpeg命令行里写一次命令然后关闭终端。推荐采用以下目录结构project/ raw/ # 原始录制文件永不修改 transcript/ # 语音转写出的SRT和逐字稿 subtitle/ # 人工校对后的ASS字幕 audio/ # 分离出来的音轨和处理后的音频 output/ # 最终成片 scripts/ # 转写命令、压制命令、批量处理脚本每次跑转写、跑压制都写成脚本文件保存下来。这样下次遇到同样问题时你可以对比上一次成功执行的命令和这一次有什么区别。很多“这次失败上次成功”的问题最后都只是路径不同、字体不同或参数不同。注意把原始录制文件放在raw目录后不要在那个目录里做任何修改。原始文件是排查所有问题的最后凭据改坏之后连修复机会都没有。6. 更适合个人或小团队的制作规范6.1 学习环境用最小流程先跑通一期第一次做跑团熟肉时不要追求复杂特效不要急着上立绘替换和音效卡点。先用最小流程完成一期准备语音通话和OBS录制保存一份麦克风音频。使用Whisper转写SRT。在Aegisub中人工校对字幕生成ASS。使用FFmpeg硬字幕压制。用播放器完整看一遍重点检查音画同步、字幕错字。这个流程可以让你在一晚上之内理解所有工具的基本操作。第一期跑通之后再逐步加入立绘表情、特效字幕和音效。如果连录制环境都不稳定先不要想着“边录边做特效”。跑团视频的核心依序是听得清、字幕准、画面稳。前三项没达标前任何花哨剪辑都只是负担。6.2 连载或发布环境需要补足的保障当你要长期连载一个跑团系列时每期都临时准备工具会非常痛苦。发布前建议按下面清单检查检查项具体要求时长与分辨率确认成片参数符合发布平台要求音画同步在至少两个播放器中抽查开头、中间、结尾字幕完整性检查漏翻、错别字、人名统一、枪版字幕遮挡字幕编码ASS和SRT均为UTF-8字体已安装文件命名包含标题、期数和版本号比如sec1_part1_v2.mp4原素材归档raw目录保留所有原始录制文件压制脚本scripts目录保留本次使用的命令或脚本参与者确认视频发布前获得所有参与玩家同意生产环境里还有一个容易被忽视的点不要把“测试视频”和“正式视频”混在一起。每次压制前先输出一个低分辨率测试片段确认没有问题再用完整分辨率输出正式版。低分辨率测试可以节省大量时间。6.3 内容层面的合规要点跑团视频涉及多人语音、字幕翻译和原始素材授权发布前需要做好这几件事每个参与者的声音和角色名出现前先征得本人同意尤其是公开平台发布。字幕翻译和其他二次创作内容保留原视频标题、作者、翻译者等信息不以商业售卖为目的。字体、BGM、立绘、头像等素材注意授权情况。免费字体可以商用或非商用使用但字体名称和许可细节要提前确认。如果依赖某个在线工具或语音平台留意平台对录屏和录音内容的使用限制。这些事项看起来不是技术问题但一旦出事比音画不同步更难处理。小团队制作系列内容时最好在项目开始前就立一份简单的发布规则。6.4 想要做好“鬼畜式”剪辑先保证能回退《神话与科学》这类视频被观众形容为“bug一样鬼畜”本质上是剪辑和演出效果不是真的让流程充满bug。想尝试这种风格时建议先出一版“正常剪辑版”保证剧情能看懂、字幕能对上、声音不杂在这个版本基础上再叠加音效、表情差分和跳跃剪辑。这样做的好处是流程可控。一旦“鬼畜”特效加过头你始终有一版干净版本可以用来对比和回退。如果一开始就边剪边加特效所有问题混在一起后期基本没有修回的可能。做COC跑团熟肉真正决定成败的不是跑团本身而是能不能稳定复现一套流程录制不出错、转写可校对、字幕能定位、压制不丢格式。这篇文章里的思路不一定是最先进的却是个人和小团队最稳的做法每一条可复现的命令都尽量简单每一个中间产物都保留下来每一个bug都从现象倒推到根因。第一次做先用最小流程跑通一期第二期开始你会发现需要补的只有细节。