我正在开发一个需要流式传输和同步多个音频文件的Web应用程序.为此,我使用
Web Audio API over HTML5音频标签,因为定时音频的重要性.
目前,我正在使用FFMPEG的分段功能将音频文件编码并分段为更小的块.我分割它们的原因是我可以从文件中间开始流式传输而不是从头开始(否则我只是使用UNIX split,as shown here分割文件.问题是当我对音频片段进行分组时回到一起,我得到段之间的音频流行音乐.
如果我在.wav文件中使用PCM编码(pcm_s24le)对段进行编码,则回放是无缝的,这使我相信编码器正在填充文件的开头或结尾.由于我将处理许多不同的音频文件,使用.wav将需要太多的带宽.
我正在寻找以下解决方案之一：
>如何无缝分割编码的音频文件,
>如何强制编码器使用ffmpeg(或其他实用程序)填充音频帧,或者
>在不使用音频标签的情况下,流式传输音频(从任意音轨时间开始)的更好方法是什么？
系统信息
>自定义node.js服务器
>上传音频文件后,node.js将数据传输到ffmpeg的编码器中
>需要使用HTML5 Web Audio API支持的编码
>服务器通过WebSockets套接字一次发送1个音频块
提前致谢.我试图尽可能清楚,但如果你需要澄清,我会非常愿意提供它.
解决方法
由于PCM是未压缩格式,因此需要无缝播放.没有什么可以造成故障.如果你使用像flac这样的无损编解码器,也会发生同样的事情.另一方面,如果你使用任何有损的编解码器,如mp3,wma等…没有任何干预就没有办法避免毛刺.例如,WMA解码器将始终为您提供比编码时最初提供的PCM更多的PCM.额外的字节会产生一个小故障,它也会搞砸持续时间.此外,这种连续播放(剪切列表)的持续时间应该更长.您可以尝试通过一些DSP过滤来平滑毛刺.你甚至可以尝试一些简单的动作,比如交叉渐变转换等等.也许它会给出一些有用的结果.
如果由于带宽而无法接受某些无损编解码器,则另一种方法是创建具有有损编解码器(如mp3)的压缩文件,并从计算位置开始流式传输.当然,你不能像在PCM中那样准确地搜索样本,并且你会在解码时获得少量无用的PCM,因为你将开始解码中间的压缩数据而没有解码器所需的“先前数据”.我建议在编码此类文件时保持恒定比特率,因为在开始流式传输之前,您将能够在压缩文件中计算更准确的搜索位置.
关于这里的故障,如果你开始编码这样的mp3文件,你创建这些文件而不停止编码器,那么在切换文件时不会出现任何故障,因为你只是将压缩数据分成更多的文件.当然,您可能需要自己实现.
