把讲座录像转成能在通勤路上听的音频、从手机录音里剪出一段发出去、把太小声的采访录音救回来——这些需求背后其实只有三个动作：解出音频流、按需要重新编码、必要时改一改内容。搞清楚哪一步会损伤音质、哪一步可以完全不损伤，比记住一堆参数更有用。
这几个工具的音视频处理都跑在浏览器内的 WebAssembly 引擎上，首次使用会下载约 30MB 的处理引擎，之后浏览器会缓存复用。好处是文件从头到尾留在本地，不上传任何服务器；代价是运算全靠你自己这台电脑，一部两小时的高码率视频提取音频，可能要等上好几分钟。
一、提取音轨：先决定要不要「原样保留」
视频提取音频 做的事是丢弃视频流、只把音频流写出来，可选 MP3、AAC / M4A、WAV、FLAC、OGG Vorbis、Opus 六种格式。
这里有个关键认知：这个工具会按你选的格式重新编码音频，而不是把原始音轨原封不动地复制出来。也就是说，如果视频里本来是 AAC 音轨，你选了 MP3，得到的是「AAC 解码成波形，再用 MP3 重新压一遍」的结果。想尽量贴近原始质量，就选 WAV 或 FLAC——它们是无损的，只承担一次解码，不引入新的压缩损失。
按用途给个直接的建议：
- 纯粹为了听内容（讲座、有声书、播客）：MP3 128kbps 单声道，一小时约 55MB，人声完全够用，通用性也最好。
- 要保留音乐质感：AAC 256kbps 或 MP3 320kbps。同码率下 AAC 的音质通常优于 MP3，代价是部分老设备不认 M4A。
- 要拿去做后期处理（降噪、混音、二次剪辑）：直接导 WAV 或 FLAC，别在中间环节反复有损压缩。
- 要压到极小体积：Opus 在 64kbps 这种低码率区间表现明显好过 MP3，适合语音存档。
二、有损转有损：二次损失究竟损失了什么
音频格式转换 支持同样这六种格式互转，但有两条规律必须先明白。
第一条：有损格式之间互转会叠加损失。 MP3、AAC、Vorbis、Opus 都是「感知编码」，它们靠丢掉人耳不敏感的成分来省空间——被掩蔽的弱信号、超出听觉范围的高频等等。问题是每个编码器的心理声学模型不一样，A 编码器认为可以丢的和 B 编码器认为可以丢的不是同一批数据。把 MP3 转成 AAC，第二次压缩面对的已经不是原始波形，而是被削过一轮的波形，它会再削一轮自己那份。反复几次，高频会变得毛糙，人声齿音发飘。
第二条：有损转无损不会让音质变好。 把 128kbps 的 MP3 转成 FLAC，只是把已经丢掉信息的波形无损地保存下来，文件从 5MB 涨到 40MB，能听到的东西一模一样。工具界面上会如实提示这一点。真正需要这么做的场景只有一个：某个软件只接受无损输入，你不得不迁就它。
所以能少转就少转。如果必须转，把「转成什么」这个决定尽量往流程末端推——中间环节全部走 WAV，最后一步再压成投放用的格式。
三、码率、采样率、声道：三个参数的取舍逻辑
工具提供 64 到 320kbps 共七档码率，采样率可选 22050、32000、44100、48000 Hz，声道可选单声道或立体声。三者对文件体积几乎是乘法关系，但对听感的贡献完全不对等。
- 码率是最该优先调的。它直接决定每秒能存多少信息。人声内容 96 到 128kbps 就已经听不出问题，音乐建议 192kbps 起步，320kbps 之后提升极其有限。
- 采样率决定能记录多高的频率，按采样定理，上限是采样率的一半。44100 Hz 是 CD 标准，对应 22kHz 上限，覆盖了人耳的全部听觉范围，所以除非源文件本来就低，没必要改。反过来，把 22050 Hz 的电话录音硬拉到 48000 Hz，只是插值出更多采样点，听起来还是那么闷。
- 声道最容易省空间也最容易踩坑。单人讲话录音转单声道，体积直接减半且几乎无损感知；但音乐、双人对谈的立体声定位、以及左右声道分别录了不同人的采访素材，转单声道就是把两路混成一路，混完不可逆。
需要注意，给 WAV 和 FLAC 设置码率是没有意义的，工具在拼接编码参数时会自动忽略无损格式的码率设定。
四、剪辑与音量：一个能无损，一个必须重编码
音频剪辑与铃声裁剪 是这批工具里唯一能做到「几乎瞬间完成且完全无损」的音频操作，前提是你选「保持原格式」并且不加淡入淡出。这种模式下工具做的是流复制——不解码、不重编码，只把指定区间的原始数据块搬到新文件里。
代价是切点精度。压缩音频是按帧组织的，流复制只能从某一帧的边界开始，所以实际切点会落到最近的关键位置上，可能与你填的时间有几十毫秒偏差。做手机铃声、切副歌，这个误差完全无感；要精确对齐到某个鼓点，就得放弃流复制。
一旦你勾选了淡入淡出，或者选了和源文件不同的输出格式，工具就会自动切换到重编码路径。淡入淡出本质是在时间轴上乘一条音量曲线，必须拿到解码后的波形才能算，绕不过去。工具还提供一键截取前 40 秒的铃声预设，以及「取当前播放位置」按钮——边试听边标记比盯着秒数猜要准得多。
音频音量调节 则必然重编码。增益以分贝为单位，每提升约 6dB 音量翻一倍，界面会同步显示对应倍数。这里有个物理上限要认清：如果原始录音的波峰已经接近满幅（0 dBFS），继续提升增益会让波峰超出可表示范围而被削平，听起来就是刺耳的破音。这不是工具做得不好，而是定点数字音频没有「满幅之上」这个概念，界面会在增益过高时给出警示。录音太小声的正确救法是小步试——先加 6dB 试听，不够再加，而不是一把拉到 +20dB。
五、视频消音：不动画面才是关键
视频去音轨 常被当成小功能，其实它是这几个工具里最该强调「无损」的一个。选择「彻底移除音轨」并保持输出容器与源文件一致时，工具对视频流用的是流复制，画面数据一个字节都不会被重新压缩，只是把音频轨道从容器里摘掉。结果是：处理速度极快（几乎只取决于文件读写）、画质与原片完全一致、体积还会比原来小一点。
另一个选项「保留静音音轨」用于应对一类具体报错：某些剪辑软件和上传平台要求视频必须包含音频流，拿到纯画面文件会直接报「无音频流」。这种情况下工具会额外生成一条采样率 44100 Hz 的立体声无声音轨接进去，并让它跟随视频长度结束。
要留意的是，一旦你把输出容器从「与源文件一致」改成别的（比如 MOV 改 MP4 或 WebM），视频流就可能需要重新编码以适配目标容器支持的编码格式，速度和画质优势也就没了。除非确实需要换容器，建议保持默认。
常见问题
提取出来的音频文件很大，是不是设置错了？
先看格式。WAV 是完全不压缩的，立体声 44100 Hz 十六位大约每分钟 10MB，一小时就超过 600MB，这是正常的。想要小文件就换 MP3 或 AAC 并把码率降到 128kbps，体积会缩到十分之一以内。
处理进度条走到一半就卡住或者页面崩溃了怎么办？
这类工具最常见的失败原因是浏览器内存不够。处理引擎需要把输入文件和输出结果同时放在内存里，超大文件（尤其接近或超过 1GB 的视频）很容易触碰到浏览器给单个页面的内存上限。可行的做法是：关掉其他标签页释放内存、用 64 位的桌面版 Chrome 或 Edge、或者先把长视频切成几段分别处理。手机浏览器的内存额度更紧，不建议处理大文件。
为什么同样的 128kbps，我这段音频听着比别人的差？
码率只是配额，实际音质还取决于源文件质量和压缩历史。如果你的源文件本身是从 96kbps 的文件转来的，再用 128kbps 编码也补不回丢掉的信息。另外单声道和立体声在同一码率下，单声道每个声道能分到的比特是两倍，所以人声内容用单声道往往比立体声更清晰。
能不能一次处理一批文件？
这几个音频工具都是单文件流程。原因是重编码本身就在挤占浏览器的内存和 CPU，并发处理多个文件反而更容易触发内存不足而全部失败。批量需求建议逐个处理，参数设定在一次会话内会保留，实际操作并不慢。