MP3文件格式
（摘自freex64加壳工具的博客，尚未完整完成）
如果你通过某种途径得到一首歌曲的MP3文件，那么大多数情况下它应该由三部分组成（其实很多时候不是），这三部分分别是头部、中间部、尾部。其实按照更严紧的说法这三部分应该是ID3V2、音频帧部分，ID3V1。
构成MP3文件的三部分中，只有音频帧部分包含了真正可以播放的音频数据。不管有没有ID3V2和ID3V1，只要MP3文件中包含音频帧，它就可以正确无误地播放音频。到了1996年，有个叫Eric Kemp （也叫 NamkraD） 的家伙想要在MP3文件里附加一些比如歌曲名称、作者名字等等的简单信息，于是他首先把ID3V1附加在了MP3文件的最后面。这是一个聪明的做法，因为1996年之前写成的软件大都认为MP3文件中只包含音频帧，把任何东西放到音频帧的前面都会引起这些软件的失效。这种只在音频帧后面附加ID3V1的MP3文件到现在仍然正确合法。
ID3V1的大小固定为128个字节，前后两个版本，后一个版本在不改变ID3V1结构大小的情况下做了一点微小的调整。下面是第一个版本的ID3V1结构：
| 字段名 |
占用空间 |
偏移位置 |
用途 |
| Header |
3字节 |
0-2 |
所存内容必须是“TAG”，用于判断此结构是否存在。 |
| Title |
30字节 |
3-32 |
存储歌曲名称 |
| Artist |
30字节 |
33-62 |
存储艺术家名称 |
| Album |
30字节 |
63-92 |
存储专辑名称 |
| Year |
4字节 |
93-96 |
存储年份 |
| Comment |
30字节 |
97-126 |
存储注释 |
| Genre |
1字节 |
127 |
存储流派 |
早版的ID3V1共7个字段。除Genre外其余字段全部是以文本形式存储的信息。就比如Year字段，如果要存储2005年，就那把2005这四个阿拉伯数字对应的ASIIC码0x32、0x30、0x30、0x35依次填入Year字段的存储空间即可。Title、Artist、Album、Comment字段内容是以ISO-8859-1格式存储的文本，如果某内容不足30个字节，就要在文本内容后面用0x00填充，使它完全充满30个字节的空间。有两点需要注意。一点，某些软件可能以空格0x20来填充字段里不足30个字节的部分，如果把空格看作文本的一部分这样做似乎也合规。另一点，假如要存储汉字内容，采用汉字国标GB2312/GBK即可。最后的Genre是唯一个数字字段，它只占用一个字节的存储空间。Genre用于存储歌曲的流派，它的取值范围从0x00到0x4F，共80种可能，下表是Eric Kemp给出的每种可能所对应的具体流派名称。
| 0 |
'Blues' |
20 |
'Alternative' |
40 |
'AlternRock' |
60 |
'Top 40' |
| 1 |
'Classic Rock' |
21 |
'Ska' |
41 |
'Bass' |
61 |
'Christian Rap' |
| 2 |
'Country' |
22 |
'Death Metal' |
42 |
'Soul' |
62 |
'Pop/Funk' |
| 3 |
'Dance' |
23 |
'Pranks' |
43 |
'Punk' |
63 |
'Jungle' |
| 4 |
'Disco' |
24 |
'Soundtrack' |
44 |
'Space' |
64 |
'Native American' |
| 5 |
'Funk' |
25 |
'Euro-Techno' |
45 |
'Meditative' |
65 |
'Cabaret' |
| 6 |
'Grunge' |
26 |
'Ambient' |
46 |
'Instrumental Pop' |
66 |
'New Wave' |
| 7 |
'Hip-Hop' |
27 |
'Trip-Hop' |
47 |
'Instrumental Rock' |
67 |
'Psychadelic' |
| 8 |
'Jazz' |
28 |
'Vocal' |
48 |
'Ethnic' |
68 |
'Rave' |
| 9 |
'Metal' |
29 |
'Jazz+Funk' |
49 |
'Gothic' |
69 |
'Showtunes' |
| 10 |
'New Age' |
30 |
'Fusion' |
50 |
'Darkwave' |
70 |
'Trailer' |
| 11 |
'Oldies' |
31 |
'Trance' |
51 |
'Techno-Industrial' |
71 |
'Lo-Fi' |
| 12 |
'Other' |
32 |
'Classical' |
52 |
'Electronic' |
72 |
'Tribal' |
| 13 |
'Pop' |
33 |
'Instrumental' |
53 |
'Pop-Folk' |
73 |
'Acid Punk' |
| 14 |
'R&B' |
34 |
'Acid' |
54 |
'Eurodance' |
74 |
'Acid Jazz' |
| 15 |
'Rap' |
35 |
'House' |
55 |
'Dream' |
75 |
'Polka' |
| 16 |
'Reggae' |
36 |
'Game' |
56 |
'Southern Rock' |
76 |
'Retro' |
| 17 |
'Rock' |
37 |
'Sound Clip' |
57 |
'Comedy' |
77 |
'Musical' |
| 18 |
'Techno' |
38 |
'Gospel' |
58 |
'Cult' |
78 |
'Rock & Roll' |
| 19 |
'Industrial' |
39 |
'Noise' |
59 |
'Gangsta' |
79 |
'Hard Rock' |
后来，为了标识歌曲来自CD的哪个轨道，人们需要ID3v1多拥有一个字段。但问题是ID3v1是在文件最尾部固定的128个字节，而且它也没有给未来新的字段预留存储空间。一个叫Michael Mutschler的家伙想到了办法，他给出的ID3v1.1结构如下：
| 字段名 |
占用空间 |
偏移位置 |
用途 |
| Header |
3字节 |
0-2 |
所存内容必须是“TAG”，用于判断此结构是否存在。 |
| Title |
30字节 |
3-32 |
存储歌曲名称 |
| Artist |
30字节 |
33-62 |
存储艺术家名称 |
| Album |
30字节 |
63-92 |
存储专辑名称 |
| Year |
4字节 |
93-96 |
存储年份 |
| Comment |
28字节 |
97-124 |
存储注释 |
| Reserve |
1字节 |
125 |
必须为0x00 |
| Track |
1字节 |
126 |
轨道 |
| Genre |
1字节 |
127 |
存储流派 |
ID3v1.1在原来结构的Comment字段中切出最后的两个字节空间来，用于存放新增的两个字段。这样Comment字段减少了两个字节，但却保持了ID3v1结构总的大小不变。新增字段Reserve占用切出来的首个字节，且规定这个字节只能存储0x00。新增字段Track使用切出的第二个字节，用于存储数字形式的轨道号，假如歌曲来自轨道号1，就在Track字段中存储0x01。
ID3v1.1很好地兼容了ID3v1。30个字节存储不了多少评论和介绍，所以Comment字段的用处并不太大。最主要ID3v1要求使用0x00来填充未使用到的字节，在这种情况下如果Comment文本不超过28个字节，那么Reserve和Track位置上一定都存储着0x00。在ID3v1.1中如果Track存储着0x00,那就表示它又退化成了ID3v1结构，于是不存在关于轨道号的信息。只有当Reserve为0x00且Track非0时，才表示ID3v1.1结构成立，Track中才存储着轨道号。
ID3V1结构并不必须出现在MP3文件里，判断它是否存在的方法就是先读取文件最尾部的128个字节，然后比较这128个字节中最前面的3个字节，也就是Header字段，看它是否依次存储着0x54、0x41、0x47(大字TAG的ASIIC码)，若是则说明此128字节是ID3V1，否则MP3文件并不包含ID3V1结构。
本节信息绝大部分都来自https://id3.org/ID3v1和http://www.ne.jp/asahi/techno/ostra/id3doc/ID3.htm网页
ID3v2
ID3V1的大小固定为128个字节，很难再放入新的标签信息，比如专辑的封面图片等，于是在1998年id3.org又给出了另一种更灵活的标签结构，这就是ID3v2。
到2000年ID3v2_4诞生为止，ID3V2一共有了4个版本,但现在只有第3版ID3v2_3现在仍在流行。ID3v2_3之前的版本已无软件支持，第4个版本ID3v2_4有点多余，因为它诞生至今20多年，一直没有哪个MP3文件会使用它。所以本节中的ID3v2是专指ID3v2_3而言的。
ID3v2在MP3文件里占据着文件最开始处一段连续存的储空间。比ID3V1要复杂得多，ID3v2结构最多由ID3v2头、ID3v2扩展头、标签数据和pading，共4部分组成。
ID3v2头占据着ID3v2结构最开始处一段连续存的储空间，下表是ID3v2头的结构：
| 字段名 |
占用空间 |
偏移 |
说明 |
| Header |
3字节 |
0-2 |
所存内容必须是“ID3”，用于判断此结构是否存在。 |
| Ver |
1字节 |
3 |
主版本号，0x03表示ID3v2_3 |
| Revision |
1字节 |
4 |
副版本号， |
| Flag |
1字节 |
5 |
标记位 |
| Size |
4字节 |
6-9 |
整个ID3v2结构在文件头部占用存储空间的字节大小，但不包含ID3v2头。 |
Header
ID3v2结构并不必须出现在MP3文件里。判断方法就是先检查文件最开始处的连续3个字节，如果ID3v2结构存在于文件中，这3个字节就恰是Header字段占用的存储空间，然后看这3个字节是否依次存储着0x49、0x44、0x33(大字ID3的ASIIC码)，若是则说明文件里最开始处的储空间已被ID3v2占用，否则MP3文件中并不包含ID3v2。
Ver
主版本号。对于ID3v2_3这里只能存储0x03。主版本号如果改变，就表示新版本结构无法与旧版本结构向后兼容了。那些ID3v2_3之前的旧版软件，如果遇到主版本号是0x3或者更大的数字，就应该认为ID3v2结构中不存在任何标签信息。这类软件应该利用Size字段跳过ID3v2结构直接去处理后面的音频数据。注意，主版本号不可以是0xFF。
Revision
副版本号。主版本号相同的情况下，所有新的副版本号的改变都表示新结构与旧新结构可以向后兼容。注意，副版本号也不可以是0xFF。
Flag
标记位字段虽然占用了一个字节，但这个字节只有最高3个二进制位被使用，剩余的5个二进制位必须保持为0，以便将来使用。为方便说明，Flag字节的这8个二进制位被表示为“abc00000”的
形式，其中a代表最高位，b代表次高位，c代表次次高位，其余5位全部为0。
a
按照MPEG的规定，每个音频帧必须始于字节边界，而且其二进制流的最初11个二进制位必须为1，作为同步信号。ID3v2之前产生的软件会认为在MP3文件的最开始处读到的就是音频数据帧。这些软件遇到无法识别的帧，可以通过搜索同步信号，跳跃播放后续的音频。为了尽可能兼容这些旧软件，ID3v2引入了unsynchronisation方案。同步信号的二进制模式是“11111111 111xxxxx”，其中最前面的11位全部为二进制1，字节对齐情况下还有5位是不属于同步信号的，用5个x表示对它们的忽略。如果ID3v2的标签中碰巧有数据符合了这个模式，旧有软件就会错误的把它当成同步信号，其实它不是，所以称其为“伪同步”。为了消除伪同步，unsynchronisation方案规定，将伪同步替换为“11111111 00000000 111xxxxx”，也就是在两个字节之间再插入一个全0字节，5个x位保持原值不变。这样一来，旧有软件就不会在ID3v2的标签中找到同步信号了，但是支持ID3v2的软件应该知道标签中的“11111111 00000000 111xxxxx”其实是“11111111 111xxxxx”才对。所以用Flag字段的a位置1来通知新软件读取标签数据之前应把“11111111 00000000 111xxxxx”替换回“11111111 111xxxxx”。反过来，如果ID3v2的标签中压根不存伪同步，那就把Flag字段的a位置0。
b
如果Flag字段的b位被置1，那就表示ID3v2头后面紧临的一小块空间被用来存储“ID3v2扩展头”，此时“ID3v2扩展头”的位置被夹在ID3v2头和标签数据之间。如果Flag字段的b位被置0，那表示ID3v2头后面的存储空间直接存储着标签数据。
c
测试位。如果此ID3v2结构为测试版，那么Flag字段的c位被置1，否则被置0。鉴于ID3v2_4都已诞生了20多年，ID3v2_3中怕是遇不到c位置1的情况了。
Size
Size字段存储着整个ID3v2，除ID3v2头以外，在MP3文件中占用了多少存储空间。所以整个ID3v2在文件中占用的字节数是Size字段的值再加上10（十六进制的0x0A）。虽然Size字段占用4个字节，但它并不是以大端或小端格式存储的32位整数。Size字段的4个字节，每个字节的最高位都抛弃不用且必须保持为0,余下每个字节7位，共4个字节组成一个28位的整数。其中首个字节的7位组成整数的最高7位，次个字节的7位组成整数的次高7位，最末字节的7位组成整数的最低7位。因此ID3v2结构的最大空间不会超过256M+10个字节。
ID3v2扩展头
只有ID3v2头的Flag字段b位被置1，“ID3v2扩展头”才会占用ID3v2头后面的存储空间，否则ID3v2并不拥有扩展头。若ID3v2头的Flag字段a位也被置1，那么软件处理ID3v2扩展头的时候就必须先考虑unsynchronisation方案的影响。ID3v2扩展头有如下结构：
| 字段名 |
占用空间 |
偏移 |
说明 |
| Extended header size |
4个字节 |
0-3 |
ID3v2扩展头大小，但不包括此字段本身。 |
| Extended Flags |
2个字节 |
4-5 |
|
| Size of padding |
4个字节 |
6-9 |
|
Extended header size
以大端优先的方式存储着一个32位整数，也就是ID3v2扩展头的大小，占4个字节的存储空间。其中的首个字节存储着整数的最高8位，次个字节存储着整数的次高8位，最末字节存储着整数的最低8位。与“ID3v2头”结构的Size字段不同，“Extended header size”字段每个字节的全部8位都被使用。但是注意，“Extended header size”字段存储的大小并不包含“Extended header size”字段本身在内。通过上表可以发现，ID3v2扩展头的大小应该是10个字节，所以此字段存储的值应该是10-4=6。但有时这里存储的值也可能是14-4=10，具体原因参见本下面对“Extended Flags”字段的说明。
Extended Flags（对哪部分CRC）
此字段虽然占用两个字节，但是除了首个字节的最高位，其余各位都不使用，且必须为0。如果首字节的最高位被置1，那么ID3v2扩展头在上表给出的三字段后面还另外拥有第四个字段，CRC32数据。CRC32是一种循环冗余校验技术，为了发现标签数据在传输或存储过程中可能出现的错误，使用CRC32算法先对标签数据进行一个次运算，这次运算得出的结果是32个二进制位。如果标签数据在传输或存储过程中保持原样不变，在这32个二进制位的参与下对数据再次进行运算结果一定会是32个二进制0。若32位结果中任何一位不是0，则说明数据在传输或存储的某个环节中已经出现了差错。这里所说的CRC32数据指的就是传输或存储之前对数据运算所得的32个二进制位，显然它必须占用4个字节的存储空间，此时的ID3v2扩展头大小也就变成了14个字节。因此前面所提“Extended header size”字段在这种情况存储的值也就变成了14-4=10。需要注意的是，对标签数据的CRC32运算应该在unsynchronisation方案应用于标签数据之前进行。
Size of padding
在MP3文件中，ID3v2占据了文件的头部，ID3v2后面才是音频帧数据。如果ID3v2需要扩大以容纳更多的标签数据，那么音频帧数据也需在文件中向后搬移。为了避免这种情况频繁发生，ID3v2在其结构尾部预留了一定的存储空间，如果ID3v2的扩大没有超出这些预留空间，那就不需要向后移动音频帧的位置了。这些预留的存储空间被称为pading，由于在ID3v2需要扩大之前padding空间并未存储有意义的数据，所以padding空间中的每个字节都存储着0x00。padding空间不参与CRC校验运算。
“Size of padding”字段占用4个字节，以大端优先的方式存储着一个32位整数——存储着padding空间的字节大小。大端优先方式请参见“Extended Flags”字段的说明，不再重复。
Total frame CRC
这是一个上表中没有出现的字段，只有“Extended Flags”字段首字节最高位为1时，此字段才会占用存储空间。此字段占用4个字节，首个字节存储着CRC32数据的首8位，次字节存储着CRC32数据的的次8位，末字节存储着CRC32数据的末8位。CRC校验仅限于标签数据本身，ID3v2头和ID3v2扩展头都不参与其中，padding数据也不参与CRC校验。
标签数据
再强调一次，ID3v2结构是MP3文件最开始处的一段存储空间，这段空间由ID3v2头、ID3v2扩展头（如果Flag字段b位被置1）、标签数据和pading共4部分组成。
在ID3v2结构中，标签数据和pading占用了ID3v2头后面所有的存储空间。当然如果有ID3v2扩展头，那么标签数据和pading则只能占用扩展头后面剩余的空间。提前说一下，pading位于ID3v2结构的最后面，而且它不包含任何有意义的信息。标签数据被分割成若干个“帧”，一个标签帧的后面紧随着另一个标签帧，帧与帧中间没有空间间隔。如果ID3v2结构中存储完所有的标签帧仍有剩余空间的话，则剩余空间被称为pading。标签数据中每一个标签帧都包含着独立的内容，如歌曲名、歌曲作者等。标签帧在存储空间中的前后位置并不重要，哪帧在前，哪帧在后，都可以。
每个标签帧的开始位置上都存被标签帧的帧头占用，由于ID3v2结构中只包含这种构成标签数据的“帧”，所以本节也把标签帧的帧头称为ID3v2帧头。ID3v2帧头后面的存储空间，则根据标签类型使用对应的格式存储着各自的标签内容。下表先介绍ID3v2帧头的格式：
| 字段名 |
占用空间 |
偏移 |
说明 |
| Frame ID |
4个字节 |
0-3 |
用于指出标签类型 |
| Size |
4个字节 |
4-7 |
当前标签占用存储空间的大小，但不包含ID3v2帧头在内。 |
| Flags |
2个字节 |
8-9 |
|
Frame ID
这个4个字节用于顺序存储4个字符，这4个字符的内容给出了标签的用途和类型。例如“COMM”表示注释，对应ID3V1结构中Comment字段的功能。又如“TIT2”表示标题，对应ID3V1结构中Title字段的功能。ID3v2规定，这4个字符只能在26个大写英文字母A-Z中，或者是阿拉伯数字0-9中的进行选择。但如果这4个字符是以字母“X”、“Y”、“Z”开始，那么拥有这些Frame ID的帧是保留给实验使用的。ID3v2不允许别人随便定义Frame ID的内容，因此除了“COMM”、“TIT2”这样在文档中有规定的内容，其它在文档中没有提到的内容也是被ID3v2保留不允别人定义的。ID3v2还规定，如果Frame ID内容是AENC、ETCO、EQUA、MLLT、POSS、SYLT、SYTC、RVAD、TENC、TLEN、TSIZ其中的之一，那么如果MP3文件发生改变则这些帧会被丢弃（从ID3v2结构中删除），但如果只是标签帧被改变这些帧则可以留下来。
Size
这是一个以大端格式存储的32位整数。这个整数的值是减去ID3v2帧头大小以后，标签帧占用存储空间的字节大小。由此可以计算出下一个标签帧的开始位置。
Flags
这个字段占用两个字节的存储空间。但是每个字节都只使用了它们二进制的最高3位，那此未被使用的二进制位都必须保持为0。其中第一个字节用于存储状态信息，最高3位分别使用a、b、c表示，其二进制形式为“abc00000”。第二个字节用于存储与编码有关的信息,最高3位分别使用i、j、k表示，其二进制形式为“ijk00000”。
a
有些软件可能需要改变整个标签数据，这种改变包含了对文件中的标签帧的重新排列，甚至也包含添加pading。此时，如果软件并不了解某个标签帧的内容，比如不知道“BLFS”这样的Frame ID是哪一类标签等，那么Flags字段的a位则用于告诉软件该如何处理这个标签帧。a位为0，表示当前标签帧应该被保留在文件里；a位为1，表示当前标签帧应该被丢弃。
b
有些软件可能需要局部修改文件中的音频数据。此时，如果软件并不了解某个标签帧的内容，例如不知道“XCHG”这样的Frame ID是哪一类标签等，那么Flags字段的b位则用于告诉软件该如何处理这个标签帧。b位为0，表示当前标签帧应该被保留在文件里；b位为1，表示当前标签帧应该被丢弃。但是如果文件中的音频被其它音频完全替换则不在此列，列如把一段黄梅戏替换成一段平戏。
c
只读位。如果Flags字段的c位为1，那就表示当前标签帧不希望被修改。对此帧的修改可能破坏某些内容，例如数字签名等。如果对此帧的修改是必须的，而且找不出当初将此帧标记为只读的理由，修改后也没有采取适当的补偿方法（例如重新计算签名等），那就应该把Flags字段的c位清0。
i
压缩位。如果Flags字段的i位为1，那就表示当前标签内容已被zlib压缩。这种情况下，紧随ID3v2帧头后面的4个字节空间，以整数大端格式存储着压缩之前原始标签内容的字节大小。zlib是由Jean-loup Gailly与Mark Adler所开发开源压缩库，其压缩算法公开，已是事实上的业界标准。而如果Flags字段的i位为0.那就表示当前标签内容未经压缩。这种情况下，紧随ID3v2帧头后面的空间直接用于存储未压缩的原始标签内容。
j
加密位。如果Flags字段的j位为1，表示当前标签内容已被加密。这种情况下，紧随ID3v2帧头后面的1个字节空间用于存储加密的具体方法，称为“扩展字节”。事实上，只使用一个字节无法真正容纳这些加密信息，这个字节的作用只是在软件寻找加密信息的过程中提供关键的帮助。ID3v2规定如果Frame ID字段存储的内容是“ENCR”，那么这个标签帧就是一个提供具体加密方法的ENCR帧。ID3v2的标签数据中可以有多个ENCR帧，但每个ENCR帧必须描述不同的加密方法。当Flags字段的j位为1时，利用帧头后面扩展的这1个字节，可以唯一的选择到一个ENCR帧，从而选择了一个具体的加密方法。后面还会具体介绍ENCR帧的格式和选择它的方法。如果Flags字段的j位为0，则表示当前标签内容未被加密。这种情况下，“扩展字节”不在存储空间中出现，紧随ID3v2帧头后面的空间直接用于存储正式的标签内容，而且标签内容未被加密。
k
分组位。如果Flags字段的k位为1，表示当前标签帧与另外的一些标签帧属于同一个分组。这种情况下，紧随ID3v2帧头后面的1个字节空间用于存储“分组ID”。同一文件中，“分组ID”相同的所有帧都属于同一个分组。如果Flags字段的k位为0，表示当前标签帧不参与任何分组。这种情况下，紧随ID3v2帧头后面的空间直接用于存储标签内容。
标签帧类型详解
（https://id3.org/id3v2.3.0）
在标签帧中，Frame ID的内容给出了标签的用途和类型。相同类型的标签拥有相同的存储格式，
文本信息帧
文本信息帧是指遵循本小节所讲存储格式的标签帧。文本信息帧的用途是给出“艺术家”、“专辑名”等众多信息。每一种用途的文本信息帧其Frame ID都与其它文本信息帧不同。例如给出“专辑名”的文本信息帧其Frame ID是TALB，而“演唱者”帧的Frame ID则是TOPE。但在ID3v2文档中有个规律，即所有文本信息帧的Frame ID总是以字母“T”开端。文档说每种用途的文本信息帧在ID3v2结构中可能只出现一次，那么如果MP3播放软件的作者在解码ID3v2结构的过程中发现了两个冲突的“灌录年份”会怎样？——至少还不至于影响到播放吧。
所有标签帧，包括文本信息帧，它们的帧头，即ID3v2帧头，格式前面已经详细给出过了，标签内容数据直接跟随在ID3v2帧头的后面，中间没有空间间隔。所以后面每一种标签帧的介绍都省去了完全相同的帧头格式，直接给出标签内容数据的格式。
Text encoding
对文本信息帧来说，紧随ID3v2帧头之后的首个字节存储的是文本的编码方式，称其为文本编码字节。文本信息帧中携带的有效内容当然是文本信息，ID3v2规定，如果其携带的文本信息采用ISO-8859-1字符集编码，那么这个文本编码字节存储的值必须是0x00。这种情况下文本信息的结尾处要存放一个值为0x00的字节做为结束符。另一种情况，如果文本信息采用Unicode字符集编码，那么文本编码字节内必须存放0x01,此时文本信息结尾处的结束符是连续两个字节的0x00。
Information
紧随文本编码字节后面是本帧携带的有效文本信息。需要注意，文本信息帧中的所有文本都不包含回车换行信息。对于Unicode编码的字符，ID3v2使用16位宽字符存储，就是说每个字符占用两个字节。这就牵扯到字节的大端优先还是小端优先存储的问题，故此ID3v2约定Unicode文本内容的前面，若是大端优先则必先插入一个0XFEFF字符，若是小端优先就先插入一个0XFFFE字符，以方便区分。
对采用ISO-8859-1字符集编码的空文本，只需要一个0x00字节做结束符就可以。但是对采用Unicode字符集编码的空文本则必须包含区分大小端的0xFEFF或0xFFFE，还有做为结束符的0x0000，连续两个字符。
TALB 专辑名
TBPM
拍子。这是一个“数字字符串”，ID3v2约定“数字字符串”和URLs（超链接）都采用ISO-8859-1字符集编码，所以此文本信息帧的文本编码字节内应存放0x00。
TCOM 作曲家
TCON 音乐类型
TCOP 版权信息
The 'Copyright message' frame, which must begin with a year and a space character (making five characters), is intended for the copyright holder of the original sound, not the audio file itself. The absence of this frame means only that the copyright information is unavailable or has been removed, and must not be interpreted to mean that the sound is public domain. Every time this field is displayed the field must be preceded with "Copyright © ".
TDAT 灌录日期
TDLY 播放延时
TENC 编码者
TEXT 填词人
TFLT 文件类型
TIME 灌录时间
TIT1 内容组别
TIT2 歌名
TIT3 歌名副标题
TKEY 音调
TLAN 语言
TLEN 音频长度
TMED 媒体类型
TOAL 原唱片集
TOFN 原文件名
TOLY 原歌词
TOPE 原艺术家/演唱者
TORY 原发行年份
TOWN 文件的所有者
TPE1 主唱
TPE2 乐队/管弦乐队/伴奏
TPE3 指挥家
TPE4 翻唱/混音/改编
TPOS 片段来源
TPUB 出版商
TRCK 音轨号
TRDA 灌录时期
TRSN 网络电台名
TRSO 网络电台所有者
TSIZ 音频长度
TSRC 国际灌录编码标准
TSSE 软硬编码
TYER 灌录年份
APIC帧（Attached picture）
| 字段名 |
占用空间 |
偏移 |
说明 |
| Frame ID |
4个字节 |
0-3 |
APIC |
| Size |
4个字节 |
4-7 |
0X00023A96 |
| Flags |
2个字节 |
8-9 |
0X0000 |
0X00 -------------采用ISO-8859-1字符集编码
image/jpg\0------------MIME type
0x00-------------------------Picture type
\0---------------------------Description
PNG0D0A----------------------Picture data
（学习MP3文件格式，结果只接触到标签格式，就好比向小姐调情结果却只和丫鬟勾搭在一起）