音频可视化中的信号处理解决方案
声明: 原创文章,未经允许不得转载。
音频可视化是一个“听”起来非常“美”好的话题,其复杂程度很大程度上依赖视觉方案(一些例子),不同的视觉方案决定了你的技术方案选型,比如three.js,pixi.js等引擎。
不管你选用什么渲染方案,处理音频信号部分是相通的,本文会围绕音频信号的处理进行阐述,期望能够给大家普及一下音频相关的基础知识(由于能力所限难免疏错,欢迎指出)。
前五部分主要是一些理论性的基础概念,如果你不敢兴趣可以直接跳过。
- github地址:sound-processor
- 三个示例(音频放在git上加载较慢,需要等久一点):
- demo1;
- demo2;
- demo3;
一、什么是声音?
声音来源于 振动,通过声波传播,人耳中无数 毛细胞 会将振动信号转换成电信号并通过听觉神经传递给大脑,形成人主观意识上的“声音”。声波进入人耳后,因为耳蜗的特殊构造,不同部位对声音的敏感程度是不一样的:
高频声音会被耳蜗近根部位置所感知,低频声音在近端部位置被感知,因此人对不同频率声的感受是非线性的,这是后续声学计权的基础。
二、声学计权
声学计权常见的有频率计权和时间计权,其作用在于模拟人耳对不同频率声音的非线性感受:
- 对低频部分声音不敏感;
- 最灵敏的区域在
1~5K Hz
之间; - 上限在
15~20K Hz
之间;
人耳听觉范围如图所示:
2.1 频率计权
频率计权是作用在音频信号的频谱上的,常用的有:A、B、C、D四种:
其中 A计权 是最接近人主观感受的,它会削弱低频和高频部分中人耳不敏感的部分,所以音频可视化里要选择A计权方式,详细说明可阅读wiki。
2.2 时间计权
现实里声音一般是连续的,人对声音的主管感受也是声音累加的结果(想象一下,第一波声波引起耳膜振动,振动还没停止,第二波声音就来了,因此实际耳膜的振动是声波在时间上累加的结果),时间计权就是就连续时间内声音的平均值。对于变化较快的信号,我们可以使用125ms的区间来求平均,对于变化缓慢的可以采用1000ms的区间。
三、声音测量
声音测量最常用的物理量是声压,描述声压的大小通常用声压级(Sound Pressure Level,SPL)。人耳可听的声压范围为2×10-5Pa~20Pa,对应的声压级范围为0~120dB。
常见声音的声压
声压常常用分贝来度量,这里要说明一点,分贝本身只是一种度量方式,代表测量值和参考值的对数比率:
声压级的定义:
其中
P
是测量幅值,P ref
代表人耳能听见1000 Hz
的最小声压:20 uP
。
四、倍频程
首先,连续的信号包含了大量的数据,我们没有必要全部处理,因此我们一般会进行采样,将连续的频率划分成一个一个区间来分析,频程就代表一段频率区间,倍频程代表频率划分的一种方案。具体来说倍频程中一段区间的上限频率与下限频率之比是常数:
具体可以看这篇文章《什么是倍频程》
当N等于1,就是1倍频程,简称倍频程,如果N等于2,则为1/2
倍频程。频程划分好之后,将分布于频程内的频谱求均方值得到的就是倍频程功率谱:
五、webaudio对音频的处理
在web端做音频可视化离不开webaudio的API,其中最重要的就是getByteFrequencyData
(文档),这个方法能获取时域信号转换之后的频域信号,详细过程如下:
- 获取原始的时域信号;
- 对其应用
Blackman window
(布莱克曼窗函数),其作用是补偿DFT造成的信号畸变和能量泄漏; - 快速傅里叶变换,将时域变成频域;
- Smooth over time,这一步是在时间维度对信号进行加权平均(webaudio只采用了2帧);
- 按照上文的声压公式转换为dB;
- 归一化,webaudio采用的归一化方式如下:
六、音频可视化中的信号处理方案
结合上述内容,我们觉得比较合理的处理方式如下:
6.1 滤波
有人会问,getByteFrequencyData
内部不是已经应用了窗函数滤波吗,为什么还要再滤波?
因为webaudio内部的窗函数主要是用于补偿信号畸变和能量泄漏,其参数都是固定的。而在音频可视化的场景下,往往视觉感受要优先于数据精确性,因此我们加了一个高斯滤波来滤除突刺和平滑信号,“平滑”的程度是可以通过参数任意控制的。
6.2 计权
视觉呈现应该要和人的主观听觉关联,所以计权是必要的,JavaScript的计权实现audiojs/a-weighting。另外我们也提供了额外的时间计权,内部会统计5个历史数据进行平均。
6.3 频程划分
我们会根据传入的上下限频率区间和置顶的输出频带数自动进行频程划分,核心代码:
// 根据起止频谱、频带数量确定倍频数: N
// fu = 2^(1/N)*fl => n = 1/N = log2(fu/fl) / bandsQty
let n = Math.log2(endFrequency / startFrequency) / outBandsQty;
n = Math.pow(2, n); // n = 2^(1/N)
const nextBand = {
lowerFrequency: Math.max(startFrequency, 0),
upperFrequency: 0
};
for (let i = 0; i < outBandsQty; i++) {
// 频带的上频点是下频点的2^n倍
const upperFrequency = nextBand.lowerFrequency * n;
nextBand.upperFrequency = Math.min(upperFrequency, endFrequency);
bands.push({
lowerFrequency: nextBand.lowerFrequency,
upperFrequency: nextBand.upperFrequency
});
nextBand.lowerFrequency = upperFrequency;
}
七、sound-processor
sound-processor 是一个极小(gzip < 3KB)的处理音频信号的库,作为音频可视化的底层部分,使用相对科学的方法处理原始音频信号并输出符合人类主观听觉的信号,内部的处理流程如下:
7.1 安装
npm install sound-processor
7.2 使用
import { SoundProcessor } from "sound-processor";
const processor = new SoundProcessor(options);
// in means original signal
// analyser is the AnalyserNode
const in = new Uint8Array(analyser.frequencyBinCount)
analyser.getByteFrequencyData(in);
const out = processor.process(in);
7.3 options
-
filterParams
: 滤波参数,对象,默认undefined
,表示不滤波:-
sigma
:高斯分布的sigma参数,默认为1,表示标准正态分布,sigma越大平滑效果越明显,一般取0.1~250
之间; -
radius
:滤波半径,默认为2;
-
-
sampleRate
:采样率,可以从webaudio的context中取(audioContext.sampleRate
),一般是48000; -
fftSize
:傅里叶变换参数,默认为1024; -
startFrequency
:起始频率,默认为0; -
endFrequency
:截止频率,默认10000,配合startFrequency
可以选取任意频段的信号; -
outBandsQty
:输出频带数,对应可视化目标的数量,默认为fftSize
的一半; -
tWeight
:是否开启时间计权,默认为false
; -
aWeight
:是否开启A计权,默认为true
;
7.4 频率截取
一般音乐的频率范围在50~10000 Hz
之间,实际中可以取的小一些,比如100~7000 Hz
,对于不同风格以及不同乐器的声音很难取到一个统一的完美区间,另外不同的视觉风格可能也会影响频率区间。
参考材料
- 为什么要进行声学计权
- A-weighting
- 什么是声压级?
- 什么是倍频程?
- AnalyserNode.getByteFrequencyData
- 一步一步教你实现iOS音频频谱动画
- 一维高斯分布
推荐阅读
-
epoll简介及触发模式(accept、read、send)-epoll的简单介绍 epoll在LT和ET模式下的读写方式 一、epoll的接口非常简单,一共就三个函数:1. int epoll_create(int size);创建一个epoll的句柄,size用来告诉内核这个监听的数目一共有多大。这个参数不同于select中的第一个参数,给出最大监听的fd+1的值。需要注意的是,当创建好epoll句柄后,它就是会占用一个fd值,在linux下如果查看/proc/进程id/fd/,是能够看到这个fd的,所以在使用完epoll后,必须调用close关闭,否则可能导致fd被耗尽。2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);epoll的事件注册函数,它不同与select是在监听事件时告诉内核要监听什么类型的事件,而是在这里先注册要监听的事件类型。第一个参数是epoll_create的返回值,第二个参数表示动作,用三个宏来表示:EPOLL_CTL_ADD:注册新的fd到epfd中;EPOLL_CTL_MOD:修改已经注册的fd的监听事件;EPOLL_CTL_DEL:从epfd中删除一个fd;第三个参数是需要监听的fd,第四个参数是告诉内核需要监听什么事,struct epoll_event结构如下:struct epoll_event { __uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */};events可以是以下几个宏的集合:EPOLLIN :表示对应的文件描述符可以读(包括对端SOCKET正常关闭); EPOLLIN事件:EPOLLIN事件则只有当对端有数据写入时才会触发,所以触发一次后需要不断读取所有数据直到读完EAGAIN为止。否则剩下的数据只有在下次对端有写入时才能一起取出来了。现在明白为什么说epoll必须要求异步socket了吧?如果同步socket,而且要求读完所有数据,那么最终就会在堵死在阻塞里。 EPOLLOUT:表示对应的文件描述符可以写; EPOLLOUT事件:EPOLLOUT事件只有在连接时触发一次,表示可写,其他时候想要触发,那要先准备好下面条件:1.某次write,写满了发送缓冲区,返回错误码为EAGAIN。2.对端读取了一些数据,又重新可写了,此时会触发EPOLLOUT。简单地说:EPOLLOUT事件只有在不可写到可写的转变时刻,才会触发一次,所以叫边缘触发,这叫法没错的!其实,如果真的想强制触发一次,也是有办法的,直接调用epoll_ctl重新设置一下event就可以了,event跟原来的设置一模一样都行(但必须包含EPOLLOUT),关键是重新设置,就会马上触发一次EPOLLOUT事件。1. 缓冲区由满变空.2.同时注册EPOLLIN | EPOLLOUT事件,也会触发一次EPOLLOUT事件这个两个也会触发EPOLLOUT事件 EPOLLPRI:表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);EPOLLERR:表示对应的文件描述符发生错误;EPOLLHUP:表示对应的文件描述符被挂断;EPOLLET: 将EPOLL设为边缘触发(Edge Triggered)模式,这是相对于水平触发(Level Triggered)来说的。EPOLLONESHOT:只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个socket的话,需要再次把这个socket加入到EPOLL队列里3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);等待事件的产生,类似于select调用。参数events用来从内核得到事件的集合,maxevents告之内核这个events有多大,这个maxevents的值不能大于创建epoll_create时的size,参数timeout是超时时间(毫秒,0会立即返回,-1将不确定,也有说法说是永久阻塞)。该函数返回需要处理的事件数目,如返回0表示已超时。-------------------------------------------------------------------------------------------- 从man手册中,得到ET和LT的具体描述如下EPOLL事件有两种模型:Edge Triggered (ET)Level Triggered (LT)假如有这样一个例子:1. 我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符2. 这个时候从管道的另一端被写入了2KB的数据3. 调用epoll_wait(2),并且它会返回RFD,说明它已经准备好读取操作4. 然后我们读取了1KB的数据5. 调用epoll_wait(2)......Edge Triggered 工作模式:如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志,那么在第5步调用epoll_wait(2)之后将有可能会挂起,因为剩余的数据还存在于文件的输入缓冲区内,而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第5步的时候,调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。在上面的例子中,会有一个事件产生在RFD句柄上,因为在第2步执行了一个写操作,然后,事件将会在第3步被销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据,因此我们在第5步调用 epoll_wait(2)完成后,是否挂起是不确定的。epoll工作在ET模式的时候,必须使用非阻塞套接口,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用ET模式的epoll接口,在后面会介绍避免可能的缺陷。 i 基于非阻塞文件句柄 ii 只有当read(2)或者write(2)返回EAGAIN时才需要挂起,等待。但这并不是说每次read时都需要循环读,直到读到产生一个EAGAIN才认为此次事件处理完成,当read返回的读到的数据长度小于请求的数据长度时,就可以确定此时缓冲中已没有数据了,也就可以认为此事读事件已处理完成。Level Triggered 工作模式相反的,以LT方式调用epoll接口的时候,它就相当于一个速度比较快的poll(2),并且无论后面的数据是否被使用,因此他们具有同样的职能。因为即使使用ET模式的epoll,在收到多个chunk的数据的时候仍然会产生多个事件。调用者可以设定EPOLLONESHOT标志,在 epoll_wait(2)收到事件后epoll会与事件关联的文件句柄从epoll描述符中禁止掉。因此当EPOLLONESHOT设定后,使用带有 EPOLL_CTL_MOD标志的epoll_ctl(2)处理文件句柄就成为调用者必须作的事情。然后详细解释ET, LT:LT(level triggered)是缺省的工作方式,并且同时支持block和no-block socket.在这种做法中,内核告诉你一个文件描述符是否就绪了,然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作,内核还是会继续通知你的,所以,这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表.ET(edge-triggered)是高速工作方式,只支持no-block socket。在这种模式下,当描述符从未就绪变为就绪时,内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪,并且不会再为那个文件描述符发送更多的就绪通知,直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如,你在发送,接收或者接收请求,或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误)。但是请注意,如果一直不对这个fd作IO操作(从而导致它再次变成未就绪),内核不会发送更多的通知(only once),不过在TCP协议中,ET模式的加速效用仍需要更多的benchmark确认(这句话不理解)。在许多测试中我们会看到如果没有大量的idle -connection或者dead-connection,epoll的效率并不会比select/poll高很多,但是当我们遇到大量的idle- connection(例如WAN环境中存在大量的慢速连接),就会发现epoll的效率大大高于select/poll。(未测试)另外,当使用epoll的ET模型来工作时,当产生了一个EPOLLIN事件后,读数据的时候需要考虑的是当recv返回的大小如果等于请求的大小,那么很有可能是缓冲区还有数据未读完,也意味着该次事件还没有处理完,所以还需要再次读取: 这里只是说明思路(参考《UNIX网络编程》) while(rs) {buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);if(buflen < 0){// 由于是非阻塞的模式,所以当errno为EAGAIN时,表示当前缓冲区已无数据可读// 在这里就当作是该次事件已处理处.if(errno == EAGAIN)break; else return; }else if(buflen == 0) { // 这里表示对端的socket已正常关闭. } if(buflen == sizeof(buf) rs = 1; // 需要再次读取 else rs = 0; } 还有,假如发送端流量大于接收端的流量(意思是epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发,当缓冲区满后会产生EAGAIN错误(参考man send),同时,不理会这次请求发送的数据.所以,需要封装socket_send的函数用来处理这种情况,该函数会尽量将数据写完再返回,返回-1表示出错。在socket_send内部,当写缓冲已满(send返回-1,且errno为EAGAIN),那么会等待后再重试.这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send内部,但暂没有更好的办法. ssize_t socket_send(int sockfd, const char* buffer, size_t buflen) { ssize_t tmp; size_t total = buflen; const char *p = buffer; while(1) { tmp = send(sockfd, p, total, 0); if(tmp < 0) { // 当send收到信号时,可以继续写,但这里返回-1. if(errno == EINTR) return -1; // 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满, // 在这里做延时后再重试. if(errno == EAGAIN) { usleep(1000); continue; } return -1; } if((size_t)tmp == total) return buflen; total -= tmp; p += tmp; } return tmp; } 二、epoll在LT和ET模式下的读写方式 在一个非阻塞的socket上调用read/write函数, 返回EAGAIN或者EWOULDBLOCK(注: EAGAIN就是EWOULDBLOCK) 从字面上看, 意思是: * EAGAIN: 再试一次 * EWOULDBLOCK: 如果这是一个阻塞socket, 操作将被block * perror输出: Resource temporarily unavailable 总结: 这个错误表示资源暂时不够, 可能read时, 读缓冲区没有数据, 或者, write时,写缓冲区满了 。 遇到这种情况, 如果是阻塞socket, read/write就要阻塞掉。 而如果是非阻塞socket, read/write立即返回-1, 同 时errno设置为EAGAIN. 所以, 对于阻塞socket, read/write返回-1代表网络出错了. 但对于非阻塞socket, read/write返回-1不一定网络真的出错了. 可能是Resource temporarily unavailable. 这时你应该再试, 直到Resource available. 综上, 对于non-blocking的socket, 正确的读写操作为: 读: 忽略掉errno = EAGAIN的错误, 下次继续读 写: 忽略掉errno = EAGAIN的错误, 下次继续写 对于select和epoll的LT模式, 这种读写方式是没有问题的. 但对于epoll的ET模式, 这种方式还有漏洞. epoll的两种模式 LT 和 ET
-
Q&A | 在雷达信号处理中,可以交换距离维度 FFT 和速度维度 FFT 的执行顺序吗?
-
人工智能制作 "外星人 "纪录片!人工智能正在改变电影和电视行业!-Runway ML:一个在线平台,任何人都可以使用机器学习来创建和编辑视频、图像、音频等。电影中的大部分场景和动画都是通过 Runway ML 生成的。 Elevenlabs:一个在线平台,任何人都可以利用自然语言处理和语音合成技术创建和编辑语音。电影中的旁白就是通过 Elevenlabs 生成的。 前景和影响
-
光谱公司的周强:实时音频通话中的人工智能与传统信号技术
-
FBX 的最大导出规范以及导出过程中可能出现的警告和错误的解决方案(Cesiumlab - 常规模型处理)
-
几个好用的音频数字信号处理开源地址标记(持续更新)--安卓双簧管
-
源码为您提供,零基础搭建的免费网址导航站--中国妖怪百集,收集了大量古代文献中的妖怪,非常详细的记录了妖怪的来历、描述甚至图片,让您对中国的妖怪文化有一个整体的了解,茶余饭后的消遣非常有趣,类似的网站还有很多,期待您的探索! 导航站的另一个特点是汇集了大量咖啡平时用的非常好的工具软件,其中大部分都是在线的,不需要下载安装,包括文档协作、分享,图片、音频、视频处理,格式转换,文件传输,各个网站的视频下载等等,兼职就是一个工具百宝箱! 如果你觉得这些网站不符合你的使用习惯,或者想添加一些自己收藏的网站,那么把源码交给你,只需简单修改就可以变成符合自己使用习惯的独特导航了! 如何修改 导航站采用纯静态构建,下载源代码后,只需要修改 html 文件中的代码块即可,代码块结构如下: 只需要修改四个地方,分别对应网站的四个关键信息: 修改相应网站的 URL 地址 修改相应网站的徽标 修改相应网站的名称
-
PHP 和 MySQL 中的队列并发数据处理和资源争用解决方案
-
音频可视化中的信号处理解决方案
-
阿里味 "的《Redis核心实践全彩手册》给你,还学不会转行--Redis基本是必考点。在 "阿里味 "的《Redis核心实战全彩手册》里,你还是学不会转行--Redis基本是必考点: - Redis 常见的性能问题有哪些?Redis 最常见的性能问题有哪些,如何解决?--性能相关 - Redis 缓存的雪崩、击落和穿透到底意味着什么?如何处理?--缓存相关 - Redis 主从集群有哪些常见问题?如何解决?--可用性 - 现有的 Redis 实例有 6GB 的存储空间,预计将来会扩展到 32GB,你能提供解决方案并分析其优势和潜在问题吗?--可扩展性相关 毕竟,10 家公司中至少有 8 家的架构系统中都有 Redis,基本上可以说是 IT 基础架构的必备系统。 因此,Redis 的开发和运维是很多大厂的重要工作,也是我们必须掌握的技术栈。 不过,Redis 毕竟是一个复杂的键值数据库,在实际使用中,有非常多的技术点需要注意,比如:各种数据结构、数据持久化机制、分片集群、主从集群等等。 一不小心,性能就会每况愈下,失去 "快 "的最大特点!