本文深入探讨了使用javascript mediarecorder进行实时音频录制并上传至php服务器时，导致生成文件损坏的常见问题。核心在于mediarecorder在初始化时未能正确指定音频mime类型和编码器。教程将详细指导如何在mediarecorder构造函数中正确配置`mimetype`选项，确保生成有效的音频数据块。同时，文章还将讨论服务器端文件处理（如连续录音的追加写入）以及数据块拼接的关键注意事项，旨在帮助开发者构建稳定可靠的实时音频录制解决方案。
MediaRecorder实时录音文件损坏的根源与解决方案
在Web开发中，利用MediaRecorder API实现麦克风实时录音并将数据发送至后端服务器进行存储是一种常见的需求。然而，开发者在尝试将分块的音频数据（通常是Base64编码后）保存为可播放的音频文件时，经常会遇到文件损坏或无法播放的问题。本文将深入分析这一问题的根源，并提供一个可靠的解决方案。
问题分析：为什么录音文件会损坏？
当使用MediaRecorder进行录音时，其ondataavailable事件会周期性地提供音频数据块（e.data）。开发者通常会将这些数据块收集起来，然后转换为Blob对象，再进行Base64编码并通过AJAX发送到服务器。服务器端接收到数据后进行Base64解码并写入文件。
导致文件损坏的核心原因在于MediaRecorder未能正确地在录音开始前知晓并生成指定格式的音频数据。许多开发者可能会尝试在ondataavailable回调中，当创建Blob对象时指定其type（例如{ 'type' : 'audio/ogg; codecs=opus' }）。然而，这种做法是错误的。Blob构造函数中的type参数仅仅是告知浏览器或接收方这个Blob对象的MIME类型，它并不能改变MediaRecorder已经生成的数据的实际编码格式。如果MediaRecorder在录制时没有被告知要生成audio/ogg; codecs=opus格式的数据，那么它可能生成默认的或不兼容的格式，即使你将Blob的类型声明为audio/ogg; codecs=opus，底层数据仍然是错误的，导致文件无法播放。
解决方案：在MediaRecorder初始化时指定MIME类型
正确的做法是在初始化MediaRecorder实例时，通过其构造函数的第二个参数（一个选项对象）来明确指定所需的MIME类型和编码器。这样，MediaRecorder从一开始就会按照指定的格式生成音频数据块，确保数据的有效性。
1. 前端JavaScript代码修正
首先，我们需要修改MediaRecorder的初始化部分，确保在录音开始前就指定好音频格式。
在上述代码中，我们引入了mrOptions对象，并在其中指定了mimeType: 'audio/ogg; codecs=opus'。这个选项被传递给MediaRecorder构造函数，确保MediaRecorder从一开始就生成符合Ogg Opus格式的音频数据。在创建Blob时，我们现在使用mediaRecorder.mimeType来保持类型声明与实际生成数据的一致性。
2. 后端PHP代码（保持不变但需注意）
PHP服务器端的处理相对简单，主要负责接收Base64编码的数据，解码并写入文件。
关键注意事项
-
MIME类型选择与兼容性：
- 选择一个广泛支持的MIME类型和编码器组合，例如audio/ogg; codecs=opus或audio/webm; codecs=opus。
- 不同浏览器对MIME类型的支持可能有所差异。在生产环境中使用前，请务必进行兼容性测试。可以通过MediaRecorder.isTypeSupported('audio/ogg; codecs=opus')来检查浏览器是否支持特定的MIME类型。
-
连续录音的文件处理：
- 原始PHP代码中的file_put_contents("r.ogg", ...)会在每次接收到数据时覆盖整个文件。这意味着最终只会保存最后接收到的2秒音频。
- 如果目标是实现连续的、长时间的录音，你需要将数据追加到文件中，而不是覆盖。这可以通过在file_put_contents函数中使用FILE_APPEND标志来实现：
file_put_contents("r.ogg", base64_decode($_POST["data"]), FILE_APPEND); - 然而，简单的文件追加对于某些音频格式（如Ogg）可能无法直接生成一个连续可播放的文件。Ogg/WebM等容器格式通常需要在文件头部包含元数据，简单的追加可能导致播放器无法正确解析。对于需要生成单个完整文件的场景，更健壮的方法是在录音结束时（例如用户点击停止按钮后）将所有收集到的chunks一次性发送到服务器，或者在服务器端进行更复杂的音频流拼接处理。对于本教程中每2秒发送一个独立可播放chunk的场景，FILE_APPEND结合正确的mimeType可能能生成一个包含多个独立Ogg流的文件，但播放器可能只会播放第一个或处理不当。最稳妥的方式是前端在录音停止后一次性发送完整Blob。
-
数据块（Chunks）的处理：
- 在ondataavailable事件中，e.data通常是一个Blob对象。chunks.push(e.data)会将这些小Blob收集起来。
- 在示例中，每次ondataavailable触发后，chunks被清空并立即发送。由于mediaRecorder.start(2000)意味着每2秒生成一个相对独立的音频数据块，这种处理方式是可行的。但如果start()没有参数（默认行为）或参数很小，ondataavailable可能频繁触发，生成非常小的、不完整的音频片段。在这种情况下，通常会将所有chunks收集起来，直到录音停止（mediaRecorder.onstop事件），然后将所有chunks合并成一个大的Blob一次性发送。
-
错误处理：
- 确保对getUserMedia的失败情况进行妥善处理，例如当用户拒绝麦克风权限或设备不可用时。
- 对AJAX请求也应添加错误处理机制，以应对网络问题或服务器端错误。
总结
解决MediaRecorder实时录音文件损坏的关键在于在初始化MediaRecorder实例时，通过mimeType选项明确指定所需的音频格式和编码器。这确保了MediaRecorder从一开始就生成符合规范的音频数据块。同时，开发者还需要根据实际需求，合理选择服务器端的文件写入模式（覆盖或追加），并理解ondataavailable事件中数据块的处理方式，以构建一个稳定、可靠的实时音频录制与存储解决方案。
