短團跑完語音素材堆了一堆最后剪成 COC replay 時發(fā)現(xiàn)字幕、配音、立繪、渲染全是體力活處理時間比跑團本身還長。這次以《壁櫥的誘召》這類帶有角色演繹的 COC replay 為例把一套可復用的本地制作流程拆開來講音頻轉寫、角色配音、場景配圖、字幕合成、批處理渲染每一步盡量用開源工具和腳本完成而不是靠剪輯軟件手動一點一點磨。這套流程的關鍵在于跑團語音可以先轉錄成文本再由本地 TTS 生成多角色配音立繪和場景圖用本地 AI 繪圖批量出圖字幕和音頻用 ffmpeg 這類命令行工具合成。整個過程可以用顯存 8G 左右的消費級顯卡跑通純 CPU 也能處理部分環(huán)節(jié)只是速度差別很大。接口層支持 HTTP API批量任務可以做成目錄監(jiān)聽和隊列腳本方便后續(xù)接入自己的工具鏈。如果你是跑團 Replay 作者、視頻工業(yè)化生產(chǎn)愛好者或者只是想找一條減少重復勞動的本地工作流這篇文章可以直接收藏。下面按“準備環(huán)境 - 轉寫 - 配音 - 出圖 - 合成 - 排錯”的順序展開。1. COC Replay 制作流程核心能力速覽先給一張總覽表確認這套流程到底覆蓋哪些功能、硬件門檻在哪里。能力項說明流程目標把跑團錄音制作成帶字幕、配音、立繪、場景圖的 COC Replay 視頻核心模塊語音轉寫ASR、文本轉語音TTS、AI 立繪/場景圖、字幕燒錄、音視頻合成代表性工具方向Whisper 類轉寫、本地 TTS 模型、Stable Diffusion / ComfyUI、ffmpeg顯存需求取決于模型選型轉寫和 TTS 通常 4G 到 8G 可用AI 出圖常用 6G 到 12GCPU 支持轉寫和 TTS 基本支持 CPU 推理速度明顯低于 GPU啟動方式命令行啟動 WebUI/API 服務部分模型提供一鍵啟動腳本是否支持 API支持Whisper、TTS、ComfyUI 都有常見 HTTP 接口方案是否支持批量任務支持按目錄批量轉寫、批量配音、批量出圖都可以腳本化適合場景短團/長團 Replay、有聲劇本、同人動畫短片、自動化字幕流水線注意這里不綁定某個具體整合包而是基于社區(qū)常用開源模型給出可替換的通用方案。具體顯存占用和生成速度要以本機實際測試為準。2. 適用場景與使用邊界這套流程適合誰本質上是給“需要把語音內容變成可發(fā)布視頻”的人用的。第一類是跑團 Replay 作者。跑團錄音往往一小時起步人工聽寫再打軸非常耗時。用語音轉寫先出一版帶時間戳的字幕再人工修正人名、術語、語氣詞效率會高很多。第二類是短劇本創(chuàng)作者。先把劇本文本寫出來再用本地 TTS 生成角色語音最后用 AI 繪圖生成靜態(tài)畫面再通過 ffmpeg 合成視頻。這種方式對拍攝設備和演員沒有依賴特別適合單人制作。第三類是批量內容生產(chǎn)者。比如把多集跑團記錄批量轉成統(tǒng)一格式的視頻或者把一個模組的多個結局分支批量配音、批量出圖。這類場景需要接口化、隊列化和異常重試機制。使用邊界也要說明白。COC 是跑團規(guī)則Replay 是跑團過程的視頻化演繹如果使用到已存在的動畫、電影角色形象或世界觀需要確認是否符合原作的同人使用規(guī)則和發(fā)布平臺規(guī)范。AI 繪圖生成角色立繪時不要直接復刻官方設定圖用于商業(yè)用途。TTS 配音建議使用自己訓練的合法音色或開源音色不要未經(jīng)授權使用真實演員、主播的聲音。涉及人臉合成、聲音克隆、真實玩家錄音公開傳播時要取得當事人明確授權。3. 環(huán)境準備與前置條件做這套流程前先檢查自己的設備和依賴避免裝到一半發(fā)現(xiàn)某個模型跑不動。3.1 硬件層面CPU建議 8 核以上主要用于數(shù)據(jù)預處理、ffmpeg 轉碼、編解碼。內存16G 起步比較穩(wěn)處理長音頻時內存占用會明顯增加。GPU優(yōu)先考慮 NVIDIA 顯卡。顯存 6G 可以處理常見的 Whisper 模型和 TTS 模型8G 到 12G 可以做 AI 出圖如果使用高分辨率模型或批量出圖顯存越大越好。磁盤模型文件加音視頻素材準備 30G 到 50G 空閑空間比較穩(wěn)妥。操作系統(tǒng)Windows 10/11 和 Linux 都可以命令行方案基本跨平臺。3.2 軟件層面以下組件建議提前安裝好Python 3.10 到 3.12按各模型要求選擇。CUDA 和 cuDNN版本要匹配 PyTorch 和模型要求不要盲目裝最新。ffmpeg用于音頻提取、音頻拼接、字幕燒錄和視頻合成。Git用于拉取模型倉庫和工具源碼。瀏覽器用于訪問 WebUI 或 API 頁面。如果之前已經(jīng)裝過 PyTorch可以先檢查版本python -c import torch; print(torch.__version__, torch.cuda.is_available())輸出True說明 PyTorch 能識別顯卡后續(xù)安裝帶有 CUDA 依賴的模型會順暢很多。3.3 素材目錄規(guī)劃建議從一開始就按短團病例來建目錄。這里以《壁櫥的誘召》為例目錄結構可以是coc_replay/ ├── audio/ # 原始跑團錄音 ├── segments/ # 按角色/場景切分后的音頻片段 ├── transcript/ # 轉寫文本和字幕文件 ├── tts_output/ # 生成的每個角色配音 ├── images/ # 立繪、場景圖、道具圖 ├── subtitle/ # 最終字幕 ├── render/ # 合成后的視頻輸出 └── scripts/ # Python / shell 腳本這樣做的好處是批處理時只需要按目錄遍歷不容易把輸入輸出搞混。4. 音頻轉寫與分幕字幕第一步是把跑團錄音變成帶時間戳的文本。這里推薦采用 Whisper 類開源轉寫工具社區(qū)常見的是 OpenAI Whisper 以及 faster-whisper 加速版本。faster-whisper 在 CPU 和 GPU 上都有優(yōu)化適合處理長音頻。4.1 安裝與模型選擇以 faster-whisper 舉例先安裝依賴pip install faster-whisper模型尺寸一般有 tiny、base、small、medium、large-v3。對中文跑團錄音至少要 small 起步medium 更穩(wěn)。顯存不足時可以先用 small 模型出初稿再人工校對。4.2 轉寫腳本下面給出一段通用腳本把目錄下所有音頻轉成帶時間戳的文本和 SRT 字幕import os from faster_whisper import WhisperModel model_size small model WhisperModel(model_size, devicecuda, compute_typefloat16) input_dir ./audio output_dir ./transcript os.makedirs(output_dir, exist_okTrue) 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, languagezh, vad_filterTrue, word_timestampsFalse ) srt_lines [] for idx, seg in enumerate(segments, start1): 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, encodingutf-8) as f: f.write(\n.join(srt_lines)) print(f[OK] {file_name} - {srt_path})其中fmt_timestamp是 SRT 時間格式轉換函數(shù)需要自行補充格式為HH:MM:SS,mmm。4.3 判斷是否成功生成的字幕時間軸是否和語音對齊。中文專名、人名是否準確比如“骰子”“調查員”“克蘇魯”這類詞有沒有被轉成同音字。跑團里有多人同時說話時轉寫是否出現(xiàn)串行漏字。常見失敗原因是錄音格式不標準、噪聲大、多人搶話。建議先把錄音統(tǒng)一轉成 16kHz 或 16bit 的 wav再用腳本轉寫。5. 角色配音TTS 與參考音色處理跑團 Replay 的配音可以分為兩種方式一種是直接用人聲錄音切分另一種是用 TTS 生成角色臺詞。后者對單人制作更友好。5.1 本地 TTS 的基本思路當前開源 TTS 方案比較多常見的有 CosyVoice、GPT-SoVITS、ChatTTS 等。它們的基本用法相似輸入一段文本可選輸入?yún)⒖家纛l輸出一段自然語音部分工具支持音色保存。以通用 TTS 工具為例命令行調用大致如下python cli.py \ --text 我打開壁櫥發(fā)現(xiàn)里面放著一條舊領帶。 \ --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, checkTrue)5.3 判斷質量多音字是否讀對比如“行”“藏”“重”這類常見多音字。長句是否出現(xiàn)吞字、重復、語速突變。角色音色是否穩(wěn)定連續(xù)幾句話聽起來是否像同一個人。參數(shù)量小的模型容易出現(xiàn)機械感可以用情緒標簽、停頓符號或標點來調節(jié)。如果 TTS 生成效果不穩(wěn)定優(yōu)先檢查參考音頻質量和文本分段長度。單個片段不要超過 50 到 80 字過長容易丟字。6. 立繪和場景圖批量生成Replay 視頻通常需要角色立繪和場景背景。這部分可以用 Stable Diffusion 或 ComfyUI 批量生成。6.1 出圖流程在 ComfyUI 里可以保存工作流 JSON再通過 Python 腳本提交任務。基本邏輯是加載工作流模板。替換提示詞、負面提示詞、圖片尺寸、批次數(shù)量。提交到 ComfyUI API。輪詢任務狀態(tài)。保存生成結果到指定目錄。提示詞建議分成三個部分角色描述、場景描述、風格標簽。比如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(ftask submitted: {pid})具體工作流 JSON 需要從 ComfyUI 保存的workflow.json中提取節(jié)點參數(shù)再替換text、seed、batch_size等字段。第一次做的時候建議先用一張圖測試確認參數(shù)改造沒問題再上批量。6.3 效果驗證單張圖能否滿足人物描述和場景要求。多張圖之間人物是否一致必要時可以使用角色一致性 LoRA 或固定角色參考圖。高分辨率輸出是否出現(xiàn)肢體變形、文字亂碼、面部崩壞。出圖速度和顯存占用是否在可接受范圍內。如果批量出圖后需要統(tǒng)一風格可以把生成圖統(tǒng)一做一次局部重繪或圖生圖風格化但這一步會增加大量時間第一次不建議做。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然后執(zhí)行ffmpeg -f concat -safe 0 -i filelist.txt -c copy render/replay_no_srt.mp4最后把 SRT 字幕燒錄進去ffmpeg -i render/replay_no_srt.mp4 -vf subtitlesreplay.srt \ -c:a copy render/replay_final.mp4Windows 下 subtitles 路徑如果包含中文字段可能需要轉義建議先改成英文路徑再執(zhí)行。7.3 合成檢查清單音頻是否對齊角色說話時畫面是否切換合理。字幕是否有溢出畫面邊界中文字體是否正常顯示。視頻碼率是否過高導致文件過大1080p 常見控制在 4M 到 8M 碼率。最終視頻能否在主流播放器正常播放。8. 接口 API 與批量任務隊列做到這一步很多操作是可以接口化的。轉寫、TTS、出圖、合成都可以拆成獨立服務或腳本再通過一個任務隊列串聯(lián)起來。8.1 接口化設計常見做法是把每個環(huán)節(jié)封裝成 HTTP 接口接口作用入?yún)⒊鰠OST /asr/transcribe音頻轉寫音頻文件路徑或上傳文件字幕文件路徑POST /tts/generate文本配音文本、參考音色、輸出路徑音頻文件路徑POST /image/generate批量出圖提示詞、數(shù)量、尺寸圖片路徑列表POST /video/render合成視頻圖片、音頻、字幕列表視頻文件路徑實際項目里不一定每個服務都有官方 Web 方案但自己寫一個薄封裝腳本即可。8.2 批量任務腳本把每個文件作為一條任務統(tǒng)一寫入隊列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], checkTrue) except subprocess.CalledProcessError as e: print(f[ERROR] failed: {audio}, exit{e.returncode})批量任務一定要記錄日志和失敗文件否則跑到一半中斷后很難定位是哪個文件出的問題。9. 資源占用與性能觀察本地跑完整條鏈路時重點觀察三類資源顯存、內存和磁盤。9.1 顯存觀察方法Linux 下使用nvidia-smiwatch -n 1 nvidia-smiWindows 下也可以直接在任務管理器里看 GPU 顯存占用。轉寫模型、TTS 模型、出圖模型同時啟動時顯存會疊加。穩(wěn)妥的做法是逐個調用一個環(huán)節(jié)結束釋放模型后再啟動下一個或者用批量腳本串行處理。9.2 CPU 推理差異Whisper 轉寫CPU 可以跑但長音頻耗時明顯建議先切分成片段。TTSCPU 推理也能接受短句但長文本批量合成建議使用 GPU。AI 出圖CPU 出圖非常慢一般建議 6G 以上顯存。ffmpeg 合成CPU 占用偏高但多核并行下速度通常可以接受。如果顯存只有 4G 到 6G優(yōu)先把 AI 出圖的分辨率降低例如生成的底圖先控制在 768 以下再用后期放大流程處理。TTS 模型也要選輕量版本不要多個模型同時駐留內存。10. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案轉寫字幕出現(xiàn)大量亂碼或同音字模型過小錄音噪聲大檢查原始音頻和模型大小換 medium/large 模型統(tǒng)一音頻格式開啟 VAD 過濾TTS 生成音頻有雜音或吞字參考音頻不干凈文本過長試聽參考音頻縮短輸入文本重新錄制/裁剪參考音頻按句分段合成ComfyUI 提交任務后無輸出工作流 JSON 節(jié)點配置不對查看 ComfyUI 日志和任務狀態(tài)接口用保存好的原始工作流先做單張測試批量出圖人物不一致隨機種子變化或沒有固定參考圖對比多次生成結果的種子固定種子使用角色一致性 LoRA 或參考圖插件ffmpeg 字幕燒錄失敗字幕文件路徑有中文或字體缺失檢查日志中的字體報錯將字幕文件放到英文路徑指定系統(tǒng)中文字體視頻合成后音畫不同步音頻長度和圖片時長不一致檢查每段音頻時長和視頻時長使用-shortest按音頻時長生成對應圖片時長GPU 顯存不足多個模型同時駐留或參數(shù)過大查看 nvidia-smi 顯存占用串行執(zhí)行任務降低 batch size 和分辨率端口沖突端口被占用檢查端口占用情況換端口啟動如 8189、786111. 最佳實踐與合規(guī)使用建議到這里整套流程已經(jīng)能跑通。但要穩(wěn)定用于實際項目還需要遵守一些工程和合規(guī)原則。第一第一次做 Replay 時不要追求一步到位。先用 3 分鐘短片段把“語音轉寫 - 人工校對 - TTS 配音 - 單張立繪 - ffmpeg 合成”的最小鏈路走通再擴展到整段長音頻。第二保留一套最小可運行配置。不管是 Whisper 模型路徑、TTS 參考音色還是 ComfyUI 工作流都要記錄版本和參數(shù)。環(huán)境一變效果很難復現(xiàn)。第三素材分目錄管理。原始錄音、中間音頻、字幕、圖片、渲染視頻必須分開不要全部堆在一個 output 目錄里。批量腳本跑崩之后能快速定位哪些文件已經(jīng)處理過。第四批量任務要加日志和失敗重試。每條任務記錄狀態(tài)pending、running、failed、done。失敗任務單獨放到failed/目錄下一次運行時自動跳過已完成文件。第五接口服務要限制訪問范圍。如果開啟 HTTP API監(jiān)聽地址不要直接綁到0.0.0.0建議用127.0.0.1或者加訪問控制防止局域網(wǎng)內其他設備誤調用。第六涉及人臉、聲音、版權素材時必須確認授權。Replay 中的跑團玩家錄音如果只是內部交流問題不大如果做公開視頻需要征得所有參與者同意。使用知名角色形象或世界觀進行同人創(chuàng)作先確認官方允許范圍和平臺規(guī)則。TTS 音色不要使用未經(jīng)授權的真實聲優(yōu)、主播或藝人語音。第七發(fā)布前做效果復核。檢查 TTS 生成的每一條臺詞是否讀對檢查 AI 立繪是否出現(xiàn)不符合角色設定的內容檢查字幕時間軸是否準確。尤其在長文本和批量任務中容易出現(xiàn)個別臺詞內容錯誤或圖像異常人眼復核不能省略。12. 總結與下一步這套流程的核心價值不是某個單點模型而是把 ASR 轉寫、TTS 配音、AI 出圖、ffmpeg 合成按流水線方式串起來。對一個短團案例來說最先該驗證的是轉寫質量和 TTS 音色穩(wěn)定性最容易踩的坑是模型之間顯存疊加、批量任務中斷、以及字幕和語音不同步。后續(xù)可以擴展的方向一是把轉寫、TTS、出圖封裝成獨立 API 服務通過任務隊列串聯(lián)形成半自動 Replay 流水線二是為固定角色訓練一致性 LoRA提升立繪穩(wěn)定性三是給最終渲染腳本加上參數(shù)化配置比如一個 YAML 文件就能定義整集視頻的分鏡順序、配音文本和字幕樣式。先把最小流程跑通再逐步掛上自動化這套鏈路是可以真正用于日常 Replay 制作的。建議收藏備用下次做類似作品時直接按這個目錄搭一遍環(huán)境。