我有一个Java应用程序，允许用户上传用户录制的MP3文件，然后将版权声明合并到文件的开头。如果没有对文件进行编码和解码，这就是一件苦差事（我避免了解码/编码，因为：1。我真的想避免处理开销2.不是在运行时使用dll /共享库的复杂性的大粉丝不同的平台，即LAME）
我的解决方案是读取上传文件的采样频率，比特率和单声道/立体声特性，并选择与这些特征相匹配的相应版权介绍，然后通过阅读介绍中将其附加到文件的前面，用户录制为FileInputStream，并将介绍和用户文件写入FileOutputStream。
回放是事情变得有趣的地方。根据操作系统/浏览器和已安装的播放器，在网页中将显示文件的长度为35秒（介绍长度），或者在文件下载到播放器时将逐渐增加播放持续时间（约45分钟）长度）。我假设文件的持续时间由不同的播放器和浏览器以不同的方式处理。 Win7上的Safari和Firefox似乎采用了“渐进式”路线，其中Win7上的Chrome和IE9仅显示35秒的介绍长度，尽管整个45分钟的合并录音确实可以播放。
最后，在iOS上，Safari只显示NaN / NaN持续时间，并且只播放15分钟，无论合并录制的总长度如何。
所以，我得出的结论是“合并”仍然导致了这个问题。问题是：我可以在不采用更复杂的解码/编码路由的情况下解决这个问题吗？我删除了两个文件的ID3标签，然后使用来自mp3agic的jar将标签添加回合并文件。我能想到的是，有些玩家只读取介绍的帧，然后在遇到录音的用户部分时因某种原因停止。我不知道为什么会发生这种情况，除非必须有一些我错过的MP3框架的特性导致玩家认为它已经到达文件的末尾（即使它继续播放超过前35秒）据我所知，MP3的整个持续时间都没有存储的地方。这是玩家留下来计算文件的播放持续时间。
我应该寻找什么？我保留了合并前和合并后的文件，当我比较比特率，采样频率和单声道/立体声特性时，它们是相同的。合并所谓相同的文件应该有效。但是框架中有一些不同的东西（我假设）会在一些OS /浏览器/播放器组合中阻碍玩家的持续时间计算。我错过了什么？