Phonograph.js:可容忍的移动网络音频
同步音量变化非常容易,因为Web音频API允许我们将诸如音量变化之类的时间安排到1千万分之一秒。 (真的!这是十亿分之一的百万分之一。当然,您的硬件可能无法达到这种精度,但这意味着在同一时间安排的两个事件肯定会同时发生。) 但是我们的问题才刚刚开始。 一段音频多长时间? 当您使用context.decodeAudioData(…)解码音频块时,所得的AudioBuffer具有duration属性,该属性表示剪辑的长度(以秒为单位)。 我们需要知道,以便安排后续块的回放。 问题是, 持续时间很可能是一部完整的小说。 Safari会根据mp3文件声称的持续时间(而不是实际解码的时间),根据duration属性读取第一个块的文件标题,而不是帧标题 。 在那之后,它做得更好,但是如果第二个块开始播放几分钟又太迟了,那对我们没有帮助。 同时,Chrome本质上会吐出随机数。 对于CBR文件(以恒定比特率(例如128kbps)编码的文件)来说,这很好,但是对于可变比特率(VBR)文件,它可能会被低估。 当浏览器API失败时,我们只有一种选择:用JavaScript的硬方法实现逻辑。 mp3文件的剖析 为了做到这一点,我们需要了解我们正在处理的数据在1和0级别。 有用的是,尽管mp3规范受版权保护(如果您愿意为之付费,则可以获取该文件;我不会),但是善良而聪明的人们对它进行了反向工程,并免费提供了他们的发现。 (如果您对此东西感兴趣,让我们来构建比约恩·埃德斯特罗姆(BjörnEdström)的MP3解码器也是必不可少的阅读材料,尽管它与我们使用留声机的工作并不完全相关。)…