mediaPlayer.getCurrentPosition（）> mediaPlayer.getDuration（）播放MP3文件末尾

我正在播放從我的應用程序中的網絡流式傳輸的mp3文件，一些mp3文件有奇怪的行爲：mediaPlayer.getCurrentPosition()大於mediaPlayer.getDuration()最後，約3秒鐘。mediaPlayer.getCurrentPosition（）> mediaPlayer.getDuration（）播放MP3文件末尾

mp3文件編碼爲CBR。

這可能是什麼原因？

2017-04-24 wong2

當你從網絡流時，getDuration（）可以是-1，請參閱本 https://developer.android.com/reference/android/media/MediaPlayer.html#getDuration（） –

@ArunShankar在我的情況下，'getDuration（）'不是'-1'，它是正確的值 – wong2

@ wong2：發佈您的歌曲的代碼和網址 –

最後通過轉換MP3文件解決了這個問題，這是我使用的命令：

lame --mp3input -t -m s -b 128 --cbr input.mp3 output.mp3

2017-05-05 09:08:41 wong2

有幾個原因可以得到這種行爲。

首先看起來人們使用mp3文件時的確切結果爲44100Hz，因爲MediaPlayer類顯然是假設此值並相應地縮放時間，從而爲不使用此採樣的文件創建奇怪的值。

您還需要檢查您的頻道模式，並嘗試使用聯合立體聲或強制左/右立體聲。聯合應該是默認的，但你的文件可能以前編碼不好，所以值得嘗試。有意思的是，強制L/R立體聲可能會失去與聯合相同比特率的質量。

這也將是有益的檢查soxi其輸出是sox包的一部分（也可以用的ffmpeg做到這一點），這將使你的頻道的頻道數，採樣率，比特率和數量。

此外，如果您使用任何應用程序對導出期間可能插入的垃圾xml內容進行了某些處理，您可能需要檢查mp3文件的原始內容。

如果你有可能修改你正在流式傳輸的mp3文件（這聽起來像你做的，因爲你可以告訴比特率），這些都是我首先會嘗試的。如果它更像用戶上傳的東西，也許你應該看看另一個解決方案，比如ExoPlayer，它有幾千顆星和積極的開發。它包裝MediaPlayer api仍然，但值得一試。

你也必須考慮到，這可能是一個線程問題，玩家會停止播放，但計時器實際上會繼續運行，在這個結果優於歌曲的實際持續時間的情況下給出這個結果。 3秒似乎有點太多解釋它，但這只是一個想法。

2017-05-04 02:11:33

感謝您的回答無論如何 – wong2

通過使用'lame'的'-b'選項，您更改了明顯錯誤的文件的編碼並將其修復爲有效的。我的回答涵蓋了這部分，即使它沒有提供確切的命令來輸入，因爲問題可能還有很多其他的東西，並留給你去弄清楚（你也可以使用軟件等系統限制）。「無論如何」在這裏並不是正確的詞。 –

真正解決我問題的是'-m s'選項。 – wong2

回答