了解网络音频中的getByteTimeDomainData和getByteFrequencyData

Question

无论我在哪里,这两种方法的文档都非常通用.我想知道我正在查看我从每个方法得到的返回数组到底是什么.

对于getByteTimeDomainData,每次传递覆盖的时间段是多少？我相信大多数的oscopes每次传球覆盖32毫秒.这也包括在内吗？对于实际的元素值本身,范围似乎是0 - 255.这相当于-1 - +1伏？

对于getByteFrequencyData,所覆盖的频率基于采样率,因此每个索引都是实际频率,但实际元素值本身又如何呢？是否有一个dB范围等于返回数组中返回的值？

Answer 1

getByteTimeDomainData(和更新的getFloatTimeDomainData)返回一个你请求的大小的数组 - 它frequencyBinCount,它被计算为请求的一半fftSize.当然,该阵列是在当前sampleRate暴露的电流AudioContext,因此,如果它是默认的2048 fftSize,frequencyBinCount将是1024,如果你的设备运行在44.1kHz,那将相当于大约23ms的数据.

字节值的范围在0-255之间,是的,映射到-1到+1,因此128为零.(这不是伏特,而是全范围无单位值.)

如果使用getFloatFrequencyData,返回的值以dB为单位; 如果使用字节版本,则基于minDecibels/ 映射值maxDecibels(请参阅minDecibels/ maxDecibelsdescription).

Answer 2

cwilso 倒退了。

时间数据数组较长（fftSize），频率数据数组较短（它的一半，frequencyBinCount）。

在通常的 44.1kHz 采样率下，fftSize 为 2048 意味着每个样本有 1/44100 的持续时间，您手头有 2048 个样本，因此涵盖了 2048/44100 秒的持续时间，即 46 毫秒，而不是 23 毫秒。frequencyBinCount 确实是 1024，但它指的是频域（顾名思义），而不是时域，在这种情况下，计算 1024/44100 与将您的出生日期添加到 fftSize 一样有意义。

一个说明正在发生的事情的小数学：傅立叶变换是一个“向量空间同构”，即在相同维度的 2 个向量空间之间进行双射（即可逆）的映射；“时域”和“频域”。我们这里的向量空间维度（在两种情况下）都是 fftSize。

那么“一半”从何而来？频域系数“计数双倍”。要么是因为它们“实际上是”复数，要么是因为你有“罪”和“cos”的味道。或者，因为你有一个“幅度”和一个“相位”，如果你知道复数是如何工作的，你就会明白。（可以这么说，这是用不同的行话表达相同内容的 3 种方式。）

我不知道为什么 API 在频率方面只给了我们一半的相关数字——我只能猜测。我的猜测是那些是“幅度”数字，而“相位”数字被丢弃了。这是我猜测的原因是，在应用中，幅度远比相位重要。尽管如此，我对 API 抛出信息感到非常惊讶，如果一些真正知道（并且不是猜测）的专家能够确认它确实是数量级，我会很高兴。或者 - 甚至更好（我喜欢学习） - 纠正我。

Answer 3

Mozilla 的文档描述了getFloatTimeDomainData和之间的区别getFloatFrequencyData，我总结如下。Mozilla 文档参考了 Web Audio 实验；的语音变化-O-MATIC。voice-change-o-matic 向我说明了概念上的差异（它仅适用于我的 Firefox；它不适用于我的 Chrome）。

时域

• TimeDomain 函数在一段时间内。
• 我们经常使用示波器可视化 TimeDomain 数据。
• 换句话说，我们用折线图可视化 TimeDomain 数据，其中 x 轴是时间，y 轴是信号的度量。
• 把voice-change-o-matic“可视化器设置”改成正弦波看看getFloatTimeDomainData(...)

频率

• 频率函数 (GetByteFrequencyData) 处于某个时间点。
• 我们有时会在 mp3 播放器/ winamp 风格的音乐播放器（又名“均衡器”可视化）中看到这些。
• 换句话说，我们用条形图可视化频率数据，其中 x 轴是频段，y 轴是每个频段的强度
• 把voice-change-o-matic“可视化设置”改成频率条看看getFloatFrequencyData(...)