科技 · 实用指南
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 并非每种应用都支持；仅容器支持不够。任务完成、流数量相同或第一轨可播放，都不能证明每种必要声音完整。全部检查通过前保留原文件。
