在我们的应用程序中，我们使用ffmpeg处理音频文件。具体来说，我们使用NodeJS库fluent-ffmpeg，（npm链接）。

我们的音频文件是从各种文本到语音提供程序生成的。我们最近注意到，当我们使用ssml转换音频以向生成的音频添加停顿时，文件上的持续时间不再正确。经过进一步调查，我们注意到标准音频也不正确，只是由于数据更一致，总体上更准确。当我们在音频开始时暂停时，估计是最差的，超过了非常大的幅度（例如，25s的音频剪辑将读取为3分钟长，但在播放超过25s标记时跳到结尾。

我对MP3文件的结构进行了一些搜索和研究，对我来说，问题似乎是因为持续时间被各种音频播放器估计。Windows媒体播放器就是一个例子，但Firefox的网络播放器似乎也这样做了。我尝试将ffmpeg命令从使用. audioQuality（0）（设置ffmpeg使用VBR）更改为.audioBitrate（320），它告诉ffmpeg使用恒定的比特率。作为参考，我们使用的是libmp3lame，运行的完整命令如下，分别用于VBR和CBR情况：

对于VBR（中断持续时间）：ffmpeg-i

注意：然后我们在发送适当的文件头后将输出管道到请求的客户端应用程序，因此管道：1输出。输入是源文件所在的云存储url

这修复了我们拥有正确持续时间的问题，对我来说，如果问题是因为这些播放器/音频消费者中的一些人正在估计持续时间，那么这为什么会修复它是有意义的。但是，这是以文件大小明显更大为代价的，这对我来说也是有意义的。在测试时，我们发现与WAV中的同一文件相比，VBR mp3大约是WAV文件大小的10%，而CBR mp3仍然是WAV文件大小的50%。这实际上违背了我们用例支持mp3格式的目的，它是大型WAV文件的一个较小但略有损耗的替代方案。

在研究的过程中，我发现mp3文件的开头可以有一个块中的ID3标签，为音频的消费者指定信息，以便在可能处理整个文件之前知道持续时间。但是，我也发现似乎没有一个标准，至少在持续时间方面。更多的是歌曲标题、专辑、艺术家等。

我的问题是，有没有办法在使用VBR的同时，最好通过一些ffmpeg机制，在mp3文件上获得适当的持续时间？谢谢！