支持转换哪些格式，以及各自的适用场景
六种格式几乎涵盖了录音、播客节目或语音备忘录可能遇到的所有情况。下表是快速参考版本，其后的章节会解释背后的原因。
| 格式 | 有损 / 无损 | 典型用途 | 兼容性 |
|---|---|---|---|
| MP3 | 有损 | 分享、电子邮件、即时通讯、播客 | 通用——所有设备和平台 |
| WAV | 无损（未压缩） | 编辑、混音、视频后期制作 | 通用，但文件体积大 |
| M4A / AAC | 有损 | 苹果设备、流媒体、语音备忘录 | 在 iPhone、iPad、Mac 上原生支持；其他平台亦可支持 |
| OGG (Vorbis) | 有损 | 网页嵌入、开源项目 | Chrome、Firefox、Edge 支持；Safari 或较旧的 Windows 应用不原生支持 |
| FLAC | 无损（压缩） | 存档、母带、发烧级聆听 | 桌面端广泛支持；在 iOS 和较旧硬件上支持不稳定 |
对于任何需要传播的内容，MP3 仍然是默认选择：它几乎可以在过去二十年间生产的所有手机、笔记本电脑、车载音响和网页浏览器上播放，而且文件足够小，可以作为附件添加到电子邮件中，或通过即时通讯应用发送而不会触及体积上限。WAV 则处于另一个极端——它在存储音频时完全不进行压缩，这正是编辑人员和视频专业人士偏爱它的原因，但几分钟的立体声音频就可能达到数十兆字节。M4A（即封装在 MP4 容器中的 AAC 编解码器）是苹果自家录音和语音备忘录应用生成的格式，在相同文件大小下通常比 MP3 音质更好，因此在需要兼容苹果设备时，它是一个不错的折中选择。OGG 主要是一种面向网页的编解码器：它在 Chrome、Firefox 和 Edge 中都能流畅播放，深受开源和自托管音频项目的青睐，但 Safari 和许多旧版 Windows 媒体播放器并不原生支持它，因此对于要通过电子邮件发送给陌生人的文件而言，它并不是好的选择。FLAC 以无损方式压缩文件——比 WAV 更小，音质完全相同——是任何您打算长期保存、或日后需要重新编辑且不希望损失任何保真度的内容的理想目标格式。
如何逐步转换文件
整个流程在设计上就很简短。打开音频转换器，拖入或选择源文件——它可以是从手机导出的 MP3、从便携式录音机中取出的 WAV，或您刚用录音机录制的片段。工具会在本地读取文件，并显示其当前的格式和时长。从列表中选择目标格式（MP3、WAV、M4A/AAC、OGG 或 FLAC），并在需要时选择比特率或质量设置；WAV 和 FLAC 这类无损目标格式会跳过这一步，因为不存在需要权衡的质量损失。点击转换，WebAssembly 引擎便会在内存中重新编码音频——对于典型的几分钟语音录音，这只需几秒钟，较长的多轨文件则需要更久。完成后，转换后的文件会直接下载到设备上；没有任何内容存储在远程服务器上，关闭标签页即可清除工作数据。
如果源音频本身单薄、削波或有噪音，将其转换为其他容器格式并不能解决问题——编解码器只改变现有波形的存储方式，而不改变其质量。值得在录制之前先确认输入麦克风工作正常；在 microphone-test.org 上快速检测一下只需几秒钟，可以在您花时间反复转换一段有瑕疵的录音之前，排除输入设备故障的可能。
有损与无损详解
有损与无损之间的区别在于编码过程中原始波形发生了什么变化，而不在于哪种文件作为副产品体积更大或更小。无损格式——WAV 或 FLAC——会存储原始录音的每一个采样，或者就 FLAC 而言，以更高效但仍完全可逆的方式存储。解码一个 FLAC 文件，您得到的是与输入时逐位完全相同的音频数据。有损格式——MP3、AAC/M4A、OGG——则会主动丢弃编码器判定为听不见或优先级较低的信息，利用基于人类听觉工作原理构建的心理声学模型，从而大幅缩小文件体积。这种丢弃是永久性的：音频一旦被编码为 MP3，被移除的细节便无法恢复，即使您之后再将该 MP3 转换为 WAV 或 FLAC 也无济于事。转换后的文件表面上看起来是无损的——它会很大且未经压缩——但其底层的质量上限在有损编码的那一刻就已经确定了。
这一点在文件需要多次转换时尤为重要。将无损转换为有损只会损失一次质量，这在预期之内，而且在合理的比特率下通常听不出来。而再次将有损转换为有损——例如 MP3 转 AAC——则会叠加两轮各自独立的数据损失，可能引入可闻的失真，尤其是在高频部分。安全的做法是：为任何日后可能需要重新编码的内容保留一份无损母带（WAV 或 FLAC），并按需从该母带生成有损副本（MP3、AAC、OGG），而不是由有损转有损。
比特率与质量选择
比特率决定了有损编码器每秒可用于音频的数据量，也是 MP3、AAC 和 OGG 输出感知质量的最大单一影响因素。语音录音——采访、口述、播客、语音备忘录——在 96–128 kbps 下表现良好，因为语音占据的频率范围比音乐更窄，在失真变得可闻之前能承受更激进的压缩。音乐和混合内容通常需要 192–256 kbps 才能让大多数听众听起来通透，而 320 kbps 实际上是 MP3 的实用上限，超过这个值再提高也不会带来可闻的改善。AAC 和 OGG 是比 MP3 效率更高的编码器，这意味着一个 128 kbps 的 AAC 文件通常听起来更接近 160–192 kbps 的 MP3——如果文件体积紧张但又仍看重质量（例如将配音音轨发送给客户），这一点值得纳入考量。
对于 WAV 或 FLAC 而言，无需做比特率决定，因为无损格式无论设置如何都能精确还原源文件；FLAC 唯一真正的选择是压缩级别，它以编码速度换取文件体积，而完全不影响音频质量。如果转换后的文件仍然比预期的大，音频压缩器正是为此而设计的——它会以更低的比特率或更紧凑的格式重新编码，以达到目标文件大小，这虽然与格式转换在底层运行着类似的编解码器，但仍是一项截然不同的任务。
设备端隐私模式：绝不上传
每一次转换都在浏览器本地使用 WebAssembly 完成，这项技术让编译后的音频编解码器能够直接在页面上以接近原生的速度运行。其实际结果是，源文件永远不会被传输到服务器：没有上传进度条，因为根本没有任何东西需要上传。这对于任何敏感内容都至关重要——机密的商务通话、法律录音、医疗口述，或包含个人信息的语音备忘录——在这些情况下，即便只是短暂地将文件发送到第三方服务器，也是某些用户不愿承担的风险。它还消除了基于服务器的转换器常见的种种烦恼：没有与订阅等级挂钩的文件大小上限，不必在共享服务器处理他人任务时排队，页面加载完成后也不再依赖互联网连接。关闭浏览器标签页即可丢弃工作数据；没有账户，服务器端不存储任何历史记录，也不会留下任何副本需要日后管理或删除。
实际应用场景
大多数转换决定都清晰地对应于文件接下来的用途，而非某种抽象的“最佳”格式概念。
- 通过电子邮件或即时通讯应用分享片段：转换为 MP3。它体积小、普遍可播放，也不会像 WAV 文件那样常常因附件大小限制而被拒收。
- 编辑或混音录音：在将其载入编辑器之前先转换为 WAV。无损、未压缩的音频为编辑软件提供了完整的波形以供处理，而且编辑过程中的反复保存不会像反复的有损重新编码那样使文件质量下降。音频编辑器可直接在波形上完成修剪、剪切、分割和淡入淡出，同样无需上传。
- 将音频发送到 iPhone、iPad 或 Mac：转换为 M4A。它是苹果语音备忘录、音乐和照片应用的原生格式，在苹果硬件上播放不会出现任何兼容性警告。
- 长期存档母带录音：转换为 FLAC。它以约为 WAV 一半的体积保留完整质量，在存档多年的采访、实地录音或录音棚母带时尤为重要。使用 FLAC 录音机从一开始就直接录制为 FLAC，可为任何新录制的内容完全省去转换这一步。
- 在网站上嵌入音频：转换为 OGG，因为它是一种轻量、开放的格式，Chrome 和 Firefox 都能原生播放且无需支付授权费用，不过为 Safari 访客搭配一个 MP3 后备方案仍是值得的。
无论转换朝哪个方向进行，结果都只会反映源录音的质量。如果一段人声音轨在转换前就已经听起来单薄、遥远或削波，那么值得读一读应当以哪种音频格式录制，并检查输入设备本身——在 microphone-test.org 上快速过一遍即可确认麦克风是否被正确拾取，该网站的平台指南还详细介绍了 Windows 11、Mac 和 iPhone 上的常见故障。
常见问题
将有损文件转换为 WAV 或 FLAC 能提升其质量吗？
不能。将 MP3 或 AAC 转换为无损容器只改变文件的存储方式；在原始有损编码过程中丢弃的细节已永久消失，之后重新编码为无损格式也无法恢复。
转换后的文件会被上传到服务器吗？
不会。音频转换器使用 WebAssembly 在浏览器本地对文件进行解码和重新编码，转换完成后文件会直接下载到设备上。
语音录音应该使用多少比特率？
对于语音而言，MP3 或 AAC 的 96–128 kbps 通常已经足够，因为人声占据的频率范围比音乐更窄，在压缩下表现良好。音乐和混合内容通常需要 192–256 kbps 才能避免可闻的失真。
为什么 OGG 文件无法在 iPhone 或 Safari 上播放？
Safari 和 iOS 不原生支持 OGG 容器，因此面向苹果设备的文件应改为转换为 M4A/AAC 或 MP3，这两种格式都能在苹果生态系统中顺畅播放。
我应该转换录音，还是改用压缩器？
当目标是出于兼容性原因换用不同格式时，请使用转换器；而当目标是在相同格式或有损目标格式内获得更小的文件体积时，请使用压缩器——这两个工具解决的是相关但不同的问题。
转换器有文件大小限制吗？
由于处理在设备端而非服务器上进行，因此不存在与订阅挂钩的上传上限；实际限制来自设备本身的内存和处理能力，而非任何强加的配额。