MP3 ID3v1 & ID3v2 &APEv2 标准总结-CSDN博客

本文链接：https://blog.csdn.net/thomasyuan8/article/details/81571362

MP3是現在相當流行的一種音樂格式，全名為Moving Picture Experts Group Audio Layer III(MPEG-1 Audio Layer 3)。MP3使用失真壓縮的方式大幅降低儲存音訊資料所需的空間，大大增加它的可攜性。不過，雖然MP3採用失真壓縮，它還是保留了一定程度的音質，因此相當受大眾歡迎。然而，MP3的音訊編碼訊息，並沒有包含額外的文字資訊，我們只能從中得知MP3音訊的音訊格式(從MP3標頭中讀取)以及壓縮過後的聲音訊號。如果我們想要儲存或是讀取更詳細的訊息，例如MP3的歌曲名稱、專輯名稱甚至是專輯圖片，那就只能依靠安插在MP3資料前後的標籤訊息了!

MP3的標籤格式非常多樣，其中最常見的是ID3和APE兩種，而這兩種也是大部分的音樂播放器能支援標籤格式。雖然這些標籤格式都是用於內嵌在MP3的標籤格式，但它們的結構卻頗有差異，本文將在之後分別詳細介紹各標籤的結構。

ID3

ID3可說是每個音樂播放器都必須要支援的標籤格式，它較APE還更為流行。我們常聽到「MP3的ID3訊息」，就是在指ID3標籤訊息，它就好比數位相片幾乎都會使用的EXIF訊息，ID3簡直就是每個MP3檔案都應該具備的基本識別證!

ID3目前主要分為兩個版本，ID3v1與ID3v2，它們兩個雖然都是ID3，但結構幾乎完全不同。ID3v2較ID3v1有著更良好的擴展性，因為它的大小是可延展的，不像ID3v1為固定的128bytes，超過長度的訊息只能捨棄掉。因此ID3v2的重要性又比ID3v1 還大得多，是每個音樂播放器都應該支援的ID3版本。

以下，將分別介紹ID3v1與ID3v2。

ID3v1

ID3v1的起源

前面提到過MP3的音訊編碼訊息(Audio Data)並沒有辦法儲存有關這MP3檔案的文字訊息，因此在1996年的時候，有個名叫Eric Kemp alias NamkraD的人，他提出了一個名為Studio3的解決方案來處理這個問題。這方案執行起來十分簡單，就是在MP3檔案的結尾再添加一段很小的數據資料，而這段添加進去的資料儲存了對這個MP3檔案的一些基本訊息，如前面提過的歌曲名稱、專輯名稱等等，方便使用者進行辨識。這就是ID3v1標籤，現在由id3.org組織進行制訂與維護。

原始的ID3v1僅能儲存歌曲標題(Title)、演出者(Artist)、專輯名稱(Album)、年份(Year)、注釋(Comment)與風格(Genre)。後來由於CD逐漸流行且CD上的音樂大多會採用分割音軌(Track)的方式來區別曲目，讓使用者能快速選擇要聽第幾首的關係，因此ID3v1後來又衍生出能夠儲存音軌(Track)訊息的版本，即為ID3v1_1。

基本上ID3v1_1可向下相容於ID3v1，因此在實作程式上，僅需完成ID3v1_1就好。不過，在此還是會逐一演示ID3v1和ID3v1_1的結構。

ID3v1的結構

以上為ID3v1的結構，標頭(Header)用來提供給程式識別MP3檔案的尾端是否有ID3v1標籤存在。至於其他的欄位，除了Genre和Year外，皆是直接儲存文字資訊，且採用ISO-8859-1格式進行編碼(但有很多人會無視這項規定，用別的編碼方式，因此常常出現亂碼)，如果編碼後的文字長度超過30 bytes，則必定會有部分文字無法儲存進去；未滿30 bytes則補0進去。Year欄位儲存四位數字，如西元2013年就儲存{'2','0','1','3'}進去。Genre欄位可儲存0~255的數值，每個數值分別對應一種不同的風格類型，列表如下：

ID3v1_1的結構

ID3v1_1的結構和ID3v1僅差在Comment欄位後又切出兩個bytes出來，如下：

經切割後Comment欄位剩下28 bytes，其後多出了1 byte的Reserve和Track欄位。Track欄位儲存音軌資訊，直接以數值來表示，如第一軌道就存1。另外，在此的Reserve欄位扮演著重要的角色，如果Reserve欄位的值為0，表示說Comment欄位中的資訊並未超過28 bytes，後面擁有的空間是儲存Track訊息，而不是Comment訊息，此時的Reserve欄位可說是一個分隔字元，區分開Comment和Track欄位，使它們不會被混雜在一起。前面有提到說ID3v1_1向下相容於ID3v1，其實就是當 Comment長度不超過28 bytes時，原本Comment的30 bytes欄位的最後兩個bytes即變成Reserve和Track欄位用以額外存取Track的訊息，增進空間使用率。然而，當Comment有超過28 bytes的資料時，很顯然的，這時候Reserve欄位的位置存放的資料就絕對不會是0，此時的Comment欄位就可以有30 bytes的空間來儲存完整的訊息，故在這個時候的標籤結構就如同ID3v1。當然，還是會有一種情況是「Comment的訊息超過28 bytes，且還有Track訊息需要存入」，一般來說，這時後應該要優先考量Track訊息使其能儲存進去，只保留Comment前面的28 bytes。

ID3v2

ID3v2的起源

由於ID3v1的固定長度設計實在是令人詬病，於是在1998年id3.org的一群貢獻者又商討出另一種標籤格式來解決這個問題，於是ID3v2就誕生了！ID3v2的制定速度頗快，從1998年的ID3v2(ID3v2_2)到現在位居主流的ID3v2_3格式只花了一年的時間。然而，事實上ID3v2的最新版本早在2000年就已經提升到ID3v2_4，但經過了10年的時間卻依然沒有許多的軟體能支援ID3v2_4，其中的原因筆者認為是ID3v2_4實作起來較為困難，且ID3v2_3已經足以應付大部分的狀況，因此沒必要再花功夫去支援ID3v2_4。