科技 · 實用指南
OBS 重封裝完成卻缺少聲音？逐軌核對來源與輸出
完成訊息、音訊串流數量與第一軌可播放，回答的是不同問題。保留原檔，區分缺失、靜音與無法解碼的音軌，接受重封裝前核驗每種必要聲音。
OBS 重封裝完成後若缺少麥克風聲音，不能只改播放器設定。保留原始錄製檔案，逐一檢查兩個檔案中的必要音訊串流：串流可能不存在、存在但靜音，或帶有編輯器無法解碼的內容。
現有指南已正確解釋單軌播放、來源路由與編碼相容性。剩下的陷阱，是把完成訊息或一次正常播放當成完整保全的證明。修改未來錄製設定或刪除唯一原件前，先診斷已錄下的位元組。
保留來源並盤點兩個檔案
保留原 MKV、重封裝 MP4、OBS 版本與完整重封裝紀錄。診斷寫入新檔名。記錄必須保留哪些聲音——麥克風、遊戲、解說或其他來源——以及需要分軌還是成品混音。
執行 ffprobe -v error -show_streams -show_format -of json recording.mkv，把範例換成實際來源，再對輸出執行。比較音訊串流索引、編碼、聲道配置、取樣率與長度。立體聲串流包含兩個聲道，並非兩份獨立錄製來源。保留未知值，不要解釋為零。
獨立解碼每條必要來源音軌
明確選擇每條音訊串流。例如 ffmpeg -v error -i recording.mkv -map 0:a:1 -c:a pcm_f32le second-audio-audit.wav，會把第二條音訊串流解碼至新的診斷檔案。a:1 序號不保證等同 OBS 第 2 軌；先對照盤點結果與可識別的內容。
聽取必要的開頭、中段與結尾，必要時查看解碼波形或 astats 測量。區分串流不存在、解碼失敗、數位靜音與預期錄下的聲音。非零取樣不證明正確擷取麥克風；解碼失敗留下的是不確定性，並非靜音或永久遺失的證據。
工作完成仍須讀重封裝紀錄
固定提交的 OBS 上游實作會為每條輸入串流建立輸出串流，並複製編碼參數。但寫封包迴圈遇到 AVERROR_INVALIDDATA 或 EINVAL 時仍繼續。最終讀到輸入結束且尾端寫入成功，仍可能返回成功。這是程式碼範圍內的發現，不證明你安裝的 OBS 略過音訊。
我們把三個未修改的控制流程函數搭配腳本樁編譯，測試六種情況。兩類指定寫入錯誤各自返回成功，但樁只接受兩次嘗試中的一次；正常成功則接受兩次。致命寫入、檔案頭與檔案尾失敗均返回 false。沒有重現 OBS 應用、實際編碼故障或讀者錄製檔案。
依來源與輸出差別選擇修復
若原檔能解碼必要聲音，輸出卻沒有，保留兩者，在相容目標上測試明確對應的轉換。FFmpeg 自動選擇可能只選一條音訊串流，-c copy 不改變選擇。若輸出帶有聲音而編輯器無法播放，檢查編輯器對編碼與分軌匯入的支援，不要直接判定音訊被刪除。
若錄製原件靜音或缺少必要音軌，修改目前 OBS 路由不會補齊舊檔。尋找獨立來源錄音或備份。未來錄製時，既要在 Advanced Audio Properties 分配來源，也要啟用必要錄製音軌，並測試實際輸出。混音播放軌很有用，但不能代替編輯所需的獨立音軌。
丟棄證據前核驗每條必要音軌
另一組 Ubuntu FFmpeg 6.1.1 合成測試中，MKV 含 H.264 影片與兩條單聲道 AAC：靜音與 440 Hz 音調。自動串流複製輸出的 MP4 只有靜音串流；明確對應兩條音訊串流，則保留兩者，本次測試的解碼取樣位元組一致。此命令列選擇行為並非 OBS 重封裝重現。
最後在目標播放器或編輯器中比較可識別的聲音、串流涵蓋、檔案末尾內容、長度與同步。目前 OBS 文件亦提醒，MP4 內 PCM 並非每種應用都支援；僅容器支援不足。工作完成、串流數量相同或第一軌可播放，都不能證明每種必要聲音完整。全部檢查通過前保留原檔。
