[讲稿]读书笔记：MIDI Tick、Meta-event、变长数表示法、区分MIDI文件中单个字节的含义

[讲稿]读笔记：MIDI Tick、Meta-event、变长数表示法、区分MIDI文件中单个字节的含义 读书笔记:MIDI Tick、Meta-event、变长数表示法、区分MIDI文件中单个字节的含义 读书笔记:MIDI Tick、Meta-event、变长数表示法、区分MIDI文件中单个字节的含义 MIDI Tick与TPQN: MIDI中常用的时间度量法是采用Midi Tick。Midi Tick是MIDI系统中最小的时间单位，MIDI系统的所有时间功能，如节拍的产生，都是基于Midi Tick的。MIDI系统中的设备，只需要对Tick计数，就可以获得曲子的时间信息。 TPQN是一个缩写，全称是“Ticks Per Quarter-Note”，即“每四分音符所具有的Tick数”。从字面就可以理解其含义。在一个MIDI文件的MThd chunk中，我们能找到这个参数。通常这个值可以取48-480(这个是准确值，原来那个帖子的60-480写错了，抱歉„„)之间。 每Tick的绝对时间长度是关联于曲子拍速(tempo)的。比如在一首4/4拍，tempo为60bpm的曲子中，一个四分音符为一拍，发音长度为1秒。我们将一个四分音符的音长规定为480 Ticks，则480 Ticks为1秒，单个Tick的时间长度就是(1/480)秒。如果MIDI文件中要播放一个四分音符，即一拍，只要在播放时对MIDI Tick计数，计满480个MIDITick后停下，就达到了目的。同理，八分音符就是240 Ticks，一个三连音中的每个连音就是160 Ticks。 具体的解释，请参考笔者曾经编辑的这个帖子: Meta-event事件: meta-event事件也 MIDI事件的一部分，但它并不会被发送出去。它只是代表了MIDI文件的一些特征，如速度、调号、拍号、版权信息、音轨名称等等。它的数据是: FF xx nn dd dd dd dd „„ FF代表了此数据类型为meta-event; xx代表了具体的meta-event事件类型，取值范围为00-7F; nn代表了其后的meta-event数据长度，用可变长度数来表示; dd dd dd则是具体的数据。 话说0xFF这个数据，既表示meta-event的标志，同时也是MIDI事件“系统复位”的指令码。如何区分这两个数据呢,我的理解是:系统复位事件属于系统实时信息，是不会出现在MIDI文件中的。所 以在MIDI文件中的0xFF，都是meta-event的标志，不会是属于系统实时信息的“系统复位”事件;而meta-event事件是不会被音序器发送出去的，所以MIDI系统中接收到的0xFF，只可能是系统复位事件，不会是meta-event。 变长数表示法: 举一个可变长度数的例子:81 70，那么这个delta-time实际表示的数为0xF0。怎么来的,0x81的二进制为10000001，后边还有数据;0x70的二进制为01110000，后面没有数据了，这个变长数表示完毕。把下划线部分的数组合起来，就变成了:000 0001111 0000，就是1111 0000，0xF0。 再举个例子:E3 9A B4 70，这个可变长度数实际上表示的是0xC669A70。这串数是这么变化的:0xE3 = 1110 0011，后面还有数据;0x9A = 10011010，后面还有数据;0xB4 = 1011 0100，后面还有数据;0x70 = 0111 0000，后面没有数据了，这个变长数表示完毕。把下划线部分的数组合起来，就变成了:1100 0110 0110 1001 1010 0111 0000 = 0xC669A70. 找到规律了吗,这种表示法，将每个字节的最高位，作为一个标志位，标志该字节是否是整个可变长度数的最后一字节。如果最高位为1，则表明此字节不是最末尾的字节;如果最高位为0，表明此字节为最后一字节，即可变长度数表示完成。剩下的七位则是实际要表示的数的数位。所以在把可变长度数改为普通整数时，就顺序阅读可 变长度数，并且判断当前字节的最高位，如果是1，说明下一个字节依然是这个可变长度数的下一部分;如果是0，就说明本字节已经是这个可变长度数的最后一字节了。然后只需要把每个字节的后七位取出来，按其所处各自字节的先后顺序，也顺序地拼在一起，就是它所代表的整数了。 如何区分MIDI文件中的某一个字节是做什么用的, 如果单独看MIDI文件中的某个字节，我们是看不出这个字节代表的含义的。所以在阅读MIDI文件时，最好是从Track Chunk头开始慢慢阅读，顺藤摸瓜，才能找到这个字节的具体含义。 MIDI文件读取的难度也正在此。因为一个MIDI文件中混杂着各种文件标志符(如有多少Track Chunk、MIDI Tick定义等等)、delta-time(而且还是以变长数表示法表示)、MIDI事件码(还包括可发送的事件和meta-event事件)、事件数据(而且不同事件的数据还不定长)，等等等等。各种标志和事件数据码大小不一，长短不齐，十分混乱。 所以说单纯地考察MIDI文件中某个字节的数据，其作用是什么，这很难考察出来。比如一个小于0x80的数，它可能是一个delta-time数据结构的最后一字节，也可能是某个Note-On事件的数据部分，还可能是设置MIDI Tick的TPQN。如果仅仅凭借上下文，也很难猜出 这个字节数据的作用，因为它的上下文也可能具有不同的含义，依然会造成歧义。 但实际上MIDI文件依然是有规律可循的。解析MIDI文件的线索就在于:MIDI文件中所的每种MIDI事件，或是每种MIDI文件标志符，其数据段长度都是规定好的，要么是中已经规定死的，要么是文件中具有指定其大小长度的标志。这是MIDI文件最重要的特点。知道了每个事件或者标志的长短，我们才能准确无误地从MIDI文件中提炼出内容。 一个MIDI文件中记录的内容，无非就是一些MIDI文件本身的标志符，和一些MIDI事件数据，还包括一些meta-event事件，还有delta-time结构，有时(或者说常常)具有省略MIDI事件指令码的缩略结构。 文件本身的标志符长度，通常是固定长度的(比如Header Chunk中的内容);MIDI事件和一部分meta-event都具有协议中规定的长度，如多数MIDI事件具有1-3个字节的长度，系统事件和一部分meta-event虽然长度不定，但这些事件中也都标明了各自的数据段长度;delta-time数据结构采用可变长度数，但因其只能存在于MIDI事件之前，或者说存在于两个事件之中，所以也能很容易地被读取，并且根据可变长度数的特征(最高位作为可变长度数结构是否结束的标志)，我们也能知道可变长度数的结构何时结束;对于缩略结构，因其只能适用于MIDI事件之中，所以在读取完delta-time结构后，就可以判断下一字节是否大于0x80，如果大于，则是另一个MIDI事件，如果小于，表明这是一个数据段，其事件类型和指令码依然是上一个指令的类型，数据段大小也和上一指令类型相同。 根据不同事件或标志的不同长度，以及各个MIDI事件和标志符之间位置的关系，还有事件指令码与数据段的大小差异，等等诸多MIDI文件的特点，我们还是能够比较容易地将各个MIDI事件与标志符一一分开的。 所以，在解析一个MIDI文件时，我们要从文件头开始，找到各个Chunk后，以Chunk为单位，慢慢地往下解析。Header Chunk的解析相对容易，Track Chunk在解析时注意区分delta-time数据结构，MIDI事件结构，还有缩略结构。 在以后的介绍中，笔者会用图的方式来解释MIDI文件的解析方法。