這個MP3文件為什麼忽長忽短？它到底有多長？

01-21

同一個音頻文件，在屬性里顯示1小時46分鐘，QQ影音打開1小時32分鐘，拷到MP3上3小時46分鐘。重新下了一個軟體（酷狗），89分鐘。有圖有真相。

===========================分割線長這樣嗎？==============================
在知乎的第一個問題就有人回答，很開心。
音頻內容是某次缺課之後老師發來的課堂錄音。之所以糾結音頻的實際長度，是因為最初突變的時間（MP3和QQ影音）分別接近1節課和2節課。

用MP3邊聽邊做筆記時發現進度條會突變，也有大段大段的重複部分，實際長度1小時30分左右。
多謝。

謝邀。

估計文件里的元信息（Metadata）有錯誤吧。

MP3 的文件頭裡是有記錄了音頻數據的長度以及碼率的。實際上這是有冗餘信息的。因為音頻長度×碼率 = 文件大小，只需要其中兩項就能計算出另一項。所以這幾個元信息必須匹配。如果不匹配的話就可能出現不同的播放器顯示的信息不一致。比如有的播放器按音頻長度=文件大小/碼率來計算，而有的播放器則是直接讀取文件頭裡的長度信息。有的甚至可能直接認為錯誤而不能播放。

當然我對 MP3 格式了解並不多。我說的只是一種可能性。也可能是別的原因。

謝邀。

kanato其實回復的已經到位了。我再補充一下吧，造成這樣的原因有幾種。

首先有個背景是：

1、mp3分vbr和cbr。

2、對於這兩種的文件進行碼率計算方式是不一樣的。

3、對於cbr和vbr本身也有不同的處理演算法。當然，最靠譜的也是最粗暴的演算法是直接解碼後成wav後，來進行計算，最準確，但是是不現實的，因為客戶端沒必要為了顯示時間點，去做這麼複雜的工作。

其次談談一般的處理方式：

1、首先是最粗暴的，直接解碼求時長；

2、其次是跟進meta信息去解碼，vbr這種；

3、第三種是對於cbr這種其實可以去找head，根據有多少幀去計算，因為幀長是一定的；

4、就是最簡單的，直接用文件size去除以碼率。這種是模糊的，特別是對於vbr的時候，出錯的概率很大。（windows下文件的碼率和時長顯示應該就是這種處理方式）

5、其他非主流二逼處理方法，不一一舉例；

因此，基於以上幾種處理方法，其實是有誤差的。

程序本身會綜合各種因素考慮。看誰處理的細膩了，同時也要看程序綜合考慮了，非常細膩的也不一定是最好的。