Hello你好啊，好久不见。过去一段时间，我写博客的次数变得很少，我之前关注的一些博主也逐渐抛弃了博客。一个非常令人沮丧的现象是，现在的朋友们很少再关注博客，因为通过大模型应用，获取知识变得极为便捷，而传统的播客往往依赖搜索引擎，随着大模型的发展，播客的内容被扒光，很多人也就再也没有动力写博客。对我而言，写博客，可能只是换一种方式来表达自己，因此，偶尔还是会写一些，这种写作的心态，不去对抗AI抓取的焦虑，仅仅是自己的一种表达。

起因

在过去几年里，我其实做了很多期播客。而最近，视频播客的形式开始进入大众视野。播客这种内容形式其实非常有意思，特别是严肃内容播客，具有非常强的知识和主观见解。不过，在我已有的播客录制经验中，“停顿”或则是说“暂时的无话可说”会成为非常麻烦的一件事，因为一旦这种沉默时间过长，后期的剪辑会很麻烦，如果在一次节目中，这种沉默出现了很多次，剪辑就是灾难。而且经过剪辑的音频文件会迅速膨胀。因此，过去我基本上不剪辑，停顿就停顿吧，反正我的节目也没有很多人听。

但是，我发现网上很多其他博主的节目，却显得非常紧凑。仔细慢放可以发现，他们的剪辑频次极高，几乎所有的停顿都被剪掉了。我就在想，难道他们是使用了什么软件吗？经过搜索，我找到了一款autocut的软件可以实现这个功能。到这里，你以为我是来推荐软件的吗？当然不是。这款软件有着非常多功能，而部分功能还要收费，对于我这样的技术党来说，更喜欢web这种即用即走的产品形态。于是，我觉得，复刻该功能。

效果

经过2天的折腾，我完成了剪除静音这个应用，你可以通过这个链接使用剪除静音这款软件，完全免费，不需要用户登录。让我们先看感受一下使用这款应用前后的对比。

剪除静音前

剪除之后

可以听到，剪除之后，所有空白的部分都被剪除了，听起来显得紧凑连贯。

这在播客节目的音视频中，更加显得效果明显。

而且，对于用户来说，他可以很容易在分析结果图中看到被剪除的时间段，甚至，可以通过点击来避免某些片段被剪除。

当然，用户还可以实时点击生成预览，在下载前确定剪辑是符合预期的。

实现原理

整个应用完全由前端技术实现，没有后端。接下来，聊一聊它的实现原理。

音画剥离

在我们拿到用户上传的视频之后，我们要基于视频的音频数据来进行分析，因此，如何拿到视频的音频数据是关键。在这篇文章中提到，对于AudioContext而言，来源是视频还是音频没有区别，也就是说，我们直接把视频的ArrayBuffer丢给AudioContext，最后就能拿到纯音频的数据。

不过，因为我之前有开发Videa的经验，一开始我就用webav这个库解析视频，所以，我是通过直接向AudioClip中塞入视频的文件流，也可以获得音频的数据，而且AudioClip可以直接使用getPCMData来获取pcm数据，这样更方便。

作为开发者，选择任何一种都可以。

波形图和静音分析

音频数据的本质，就是一组声道的Float32Array数据，这些数据本质上代表了声音的量化。

我们在计算机中如何表达一份声音信息呢？或者说，我们如何将连续的声波信号转化为离散的数值（模数转换）呢？首先，第一个概念叫做“采样（Sampling）”，我们以固定的频率对声波进行测量，例如每秒钟测量44100次，那么采样率（SampleRate）就是44100。而每次测量都会得到一个数值，这个数值代表了采样的振幅，也就是声音的强度。把声音的强度用一个数值表示，就是第二个概念“量化”。而Float32数值表示带小数点的数值，这对精确白送声波振幅很有帮助。通常，这些浮点数会被标准化为-1.0到1.0的范围内，0.0表示静音。这个标准化实际上没有标准，不同的设备可能存在误差。而如果声音有多声道（立体声，双声道），数据通常以交错格式存储，例如，Float32Array中第一个元素是左声道的第一帧，第二个元素是右声道的第一帧，第三个是左声道的第二帧，依此类推。但是，在js中，通常，接口会返回多个Float32Array，每个Float32Array表示一个声道的数据。另外，Float32Array存储的是原始的PCM，也就是未经压缩的音频数据。

我们拿到一个声道的Float32Array数据之后，就可以基于它的特性，画出一条在固定范围内来来回回的折线图，它之所以是在固定范围，是因为数据被标准化在-1.0到1.0之间，如果我们使用了一个高度为20像素的canvas作为画布，那么上面的10像素画值在0-1之间的点，下面点10像素画值在-1～0之间的点，当然，由于我们使用简单点lineTo方法，就会让我们的整个图形是一个折线图。而这个图也就是我们音频文件所对应的声波图。

在理解了声波图的原理之后，我们做静音分析就很简单了，总的原则就是找出Float32Array中，数值靠近0的那些连续的点，并且找出它们对应的时间。

为了找到这些连续的点所形成的片段，我们需要引入3个设定值：

• dBFS：最大振幅表示为0dBFS，振幅越小dBFS越小，因此，我们只会考虑通过负值的dBFS来控制声音选择，例如我们设定 -40dBFS 代表我们会把声音小于 -40dBFS 的点标记为要剪除的点
• 最短静音时长：虽然我们会标记 -40dBFS 的点，但是，这些点必须是连续的点才能作为我们剪除的目标，最短静音时长就给了我们一个标准，例如我们设定为 400ms，那么这些静音点，必须达到连续时长在 400ms 以上，才能算一段空白，才需要被剪除，低于 400ms 的只能算停顿，不被剪除
• 分析窗口：对于一条Float32Array来说，其实是非常长非常长的，如果每个点都去计算和对比，就显得非常臃肿，因此，我们把整条Float32Array划分为平均的小片段，现在，我们把每一个小片段作为一个点来对待，取这个小片段内所有值的平均值为这个小片段所代表的点的值，再用这个值去和设定的dBFS值对比。分析窗口的目的是减少运算次数，提升性能。

另外，我们还可以获取音频的总时长作为参考，从而计算出每一个点所对应的时间点。通过上面这些设计，我们就能分析出这段音频在那些时间段内，是声音比较小的，需要被剪除的。

效果预览

我们通过静音分析，得到了一组时间片段。其实就是一个数值，数值每个元素表示一段静音的开始时间和结束时间。有了这个数值之后，我们就拿着它，对原视频文件进行不断的切割，把这些静音片段对应的部分给裁剪掉，再把剩下的拼接在一起，就是最后我们想要的视频。

但是，如何实时预览这个结果呢？

Webav提供了av-canvas来实时渲染。它本身通过clip来进行拆分音视频，我们只需要使用clip.split接口就可以进行视频切割。按照一定的逻辑，拆分后得到一大堆clip，在把这些clip转化为sprite，再根据各自的时长进行处理塞进canvas，就可以得到经过剪除后的连续视频实时播放器。

导出音频

通过webav进行导出比较简单，通过它combiner的output接口就可以得到一个readablestream，再遍历后创建一个blob就可以了。它有两种方式，一种是通过上面的av-canvas，实时预览播放器实例化后，从这个canvas创建combiner来导出，这样可以实时预览复用节省资源。还有一种是利用offscreensprite，实现离屏渲染，这种方式可以脱离界面上渲染后才能导出的窘境，做到没有预览也可以直接导出。

但是，webav没有直接导出音频的接口。一开始我也被卡住了，直到我再次搜到这篇文章才恍然大悟，虽然webav只能导出视频，但是导出视频的blob之后，读取其arrayBuffer，再塞入AudioContext，无视其是视频还是音频，也就可以导出音频了。

视频格式转换

在整个设计中，由于使用了webav作为预览，而它只支持mp4视频，因此，在进行后续的处理时，先将非mp4格式的视频转换为mp4的视频，就非常重要。在用户点击上传后，通过ffmpeg.wasm将视频格式进行转换。可是，要接入ffmpeg.wasm实在是太麻烦了，不仅要准备各种代码、文件，而且要修改服务端的headers配置。在经过一整天的折腾后，才最终完成了接入。而接入后，转换视频格式就显得非常简单了，只需要一条ffmpeg命令就可以完成。

使用链接

点击使用剪除静音工具

结束语

通过这篇，你可以掌握实现一个静音过滤器的实现思路。很久没有写技术性的文章了，也很难再细致的把每一个细节都写出来，从几年前开始，就只写思路，没有实现代码了。如果你在按照这个思路实现时，遇到什么问题，请在下面留言，我们一起讨论。

2025-08-25 65