了解网络音频中的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为单位;如果您使用 Byte 版本，则会根据minDecibels / maxDecibels映射值（请参阅minDecibels / maxDecibels说明）。

Answer 2

cwilso倒退了。

时间数据数组是较长的那个（fftSize），而频率数据数组是较短的那个（fftSize）的一半。

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

一些数学运算说明发生了什么：傅立叶变换是一种“向量空间同构”，即在相同维度的2个向量空间之间双射地（即可逆）映射。 “时域”和“频域”。我们在这两种情况下都具有的向量空间维数是fftSize。

那么“一半”来自哪里？频域系数“计数加倍”。要么是因为它们“实际上是”复数，要么是因为您具有“罪恶”和“ cos”的味道。或者，因为您有一个“量级”和一个“相位”，如果您知道复数的工作原理，就会明白这些。 （可以这么说，这是三种用不同的术语说相同的方法。）

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

Answer 3

Mozilla 's documentation describes the difference在getFloatTimeDomainData和getFloatFrequencyData之间，下面将对此进行总结。 Mozilla文档参考了Web音频 实验; voice-change-o-matic。 o-o-matic语音更改向我说明了概念上的差异（仅在Firefox中有效；在Chrome中不起作用）。

TimeDomain

• TimeDomain函数在一段时间内是 。
• 我们经常使用oscilloscopes可视化TimeDomain数据。
• 换句话说，我们使用折线图可视化TimeDomain数据，其中x轴是 time ，y轴是信号的度量。 / li>
• 将语音更改为自动的“可视化器设置”更改为 sinewave 参见getFloatTimeDomainData(...)

频率

• 频率函数（GetByteFrequencyData）在某个时间点。
• 我们有时会在mp3播放器/ winamp-style music players（又称“均衡器”可视化效果）中看到这些。
• 换句话说，我们用条形图可视化频率数据，其中x轴是频段，而y轴是每个频段的强度
• 将语音更改为自动的“可视化器设置”更改为频率条以查看getFloatFrequencyData(...)