我正在编写一个 Android 应用程序，该应用程序需要能够以高精度查找大型 mp3 音频文件(约 90 分钟)中的特定点。
目前，我正在使用带有 URI 数据源的音频播放器对象的 OpenSL 方法，该 URI 数据源指定 mp3 文件和 MIME 信息。
为了测试这一点，我使用播放器上的 SLSeekITF 接口(interface)来寻找特定点(以毫秒为单位)。但是，我发现搜索性能很差且不一致。通常，音频与应有的位置相差 1-10 秒。有时领先，有时落后。使用较短的 mp3 文件时性能稍好一些，但还远远不够接近。
Seek 模式(“准确”和“快速”)似乎对 SLSeekITF 没有任何影响。
在其他平台上，我可以让搜索位置非常准确 < 50 毫秒，这几乎看不到，所以我知道这是可能的。
- 有谁知道如何从 OpenSL 音频播放器中获得更好的准确性？
- 此实现是否存在已知问题？
- 是否有其他 mp3 解码器可以提供更好的性能？
谢谢
最佳答案
我还在 Google NDK Group 上发布了这个问题:
https://groups.google.com/forum/#!topic/android-ndk/rzVr3A0DjBs
虽然我从未从 Google 的任何人那里得到官方答复，但我收到的反馈似乎表明媒体播放器和/或使用 OpenSL ES 从 URI 播放音频是有问题的。
我最终通过使用具有搜索能力的第 3 方 mp3 解码器和 OpenSL ES 中的 Buffer Queue Audio Player 对象来播放音频样本来解决这个问题。
很难做到，但它确实有效。
关于android - OpenSL - 音频播放器对象搜索不佳，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18390857/