问题标签 [lamemp3]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
audio - 在将 OGG 音频转换为 MP3 时，FFMPEG 在文件开头添加了额外的内容
我使用以下内容ffmpeg -i <ogg-file> <mp3-file>将 ogg 音乐文件转换为 mp3。但是，我意识到某些 ogg 文件上生成的 mp3 文件稍长，并且在开头包含原始文件前半秒的重复。（听 MP3 时这很烦人）。
还有其他人遇到过类似的问题吗？
仅供参考，我使用的是 ffmpeg 版本 4.0.3，它libmp3lame用作 MP3 输出的编码器。
根据评论中的要求，这是@ffmpeg@ 的完整日志
奇怪的是错误消息Invalid picture type，而 ogg 文件不包含任何封面照片。并查看长度的差异：
mp3 - 如何使用lame.h中的preset_mode？
我想使用预设，lame.h但不知道要与预设模式常量一起使用哪个函数？
常数：
我的假设是尝试lame_set_VBR_qor lame_set_VBR_quality，但这确实令人困惑。有没有可用的例子？
提前非常感谢。
audio - MP3 存储库与引用它的帧的最远距离是多少？
MP3 帧的压缩数据可以小于帧中的可用空间。发生这种情况时，我们将可用空间称为水库。
当未来的框架太大而无法容纳一个框架的可用空间时，它可以使用一个水库来储存剩余空间。这允许恒定的比特率和可变的压缩长度，包括对于正常帧来说太大的长度。
我想知道水库离当前帧有多远？
例如，在下面我展示了 8 帧。当前帧 (CF) 和它之前的 7 帧。
假设 CF 是第 100,000 帧，它可以使用第 0 帧中仍然可用的水库吗？
还是有限制，例如 255 帧返回？
audio - 从 wav 转换为 mp3 后上传音频 blob
我需要在浏览器中录制音频（短片、语音、单声道）并以 mp3 格式上传。Chris Geirman 的这个几乎有我需要的一切，除了我不想使用 firebase，我想使用 jquery 将音频 blob 上传到我服务器上的文件夹。我对这一切都很陌生，但我猜我需要用我自己的 uploadAudio() jquery(?) 函数（类似这样的东西）替换 saveAudio() 函数，它将链接到 / 中的脚本上传.php。到目前为止一切顺利（？），但我无法从 Chris 的脚本中弄清楚我应该上传/传递到 /upload.php 的确切内容。我打算在这里实现脚本。
node.js - 有没有办法使用 FFMPEG 以可变比特率确保 mp3 持续时间的准确性？
在我们的应用程序中，我们使用 ffmpeg 处理音频文件。具体来说，我们使用 NodeJS 库fluent-ffmpeg( npm link )。
我们的音频文件是从各种文本到语音提供商生成的。我们最近注意到，当我们使用 ssml 转换音频以向生成的音频添加暂停时，文件上的持续时间不再正确。经过进一步调查，我们注意到标准音频也不正确，由于数据更一致，总体上更准确。当我们在音频开始处暂停时，估计是最差的，超出了很大的幅度（例如，25 秒的音频剪辑会读为 3 分钟长，但播放超过 25 秒时会跳到结尾.
我对 MP3 文件的结构进行了一些搜索和研究，对我来说，问题似乎是因为各种音频播放器估计了持续时间。Windows 媒体播放器就是一个例子，但 Firefox 的网络播放器似乎也能做到这一点。我尝试将 ffmpeg 命令从 using .audioQuality(0)（将 ffmpeg 设置为使用 VBR）更改为.audioBitrate(320)，它告诉 ffmpeg 使用恒定比特率。作为参考，我们使用的是 libmp3lame，运行的完整命令如下，分别用于 VBR 和 CBR 情况：
对于 VBR（中断持续时间）：ffmpeg -i <URL> -acodec libmp3lame -aq 0 -f mp3 pipe:1
对于 CBR（正确持续时间）：ffmpeg -i <URL> -acodec libmp3lame -b:a 320k -f mp3 pipe:1
注意：在发送适当的文件头后，我们将输出通过管道传输到请求的客户端应用程序，因此是 pipe:1 输出。输入为源文件所在的云存储url
这解决了我们有正确持续时间的问题，如果问题是因为这些播放器/音频消费者中的一些正在估计持续时间，我为什么会解决它是有道理的。但是，这是以文件大小明显变大为代价的，这对我来说也很有意义。在测试中我们发现，与 WAV 中的相同文件相比，VBR mp3 大约是 WAV 文件大小的 10%，而 CBR mp3 仍然是 WAV 文件大小的 50%。这实际上违背了为我们的用例支持 mp3 格式的目的，它是大型 WAV 文件的较小但略有损耗的替代方案。
在研究过程中，我发现在 mp3 文件开头的一个块中可以有 ID3 标签，为音频的消费者指定信息，以便在可能处理整个文件之前知道持续时间。但是，我也发现似乎没有一个标准，至少在持续时间上是这样。更多信息，如歌曲名称、专辑、艺术家等。
我的问题是，有没有办法在 mp3 文件上获得适当的持续时间，最好是通过一些 ffmpeg 机制，同时仍然使用 VBR？谢谢！