奉献一份MIDI档**手稿

3万 · 2008-12-31 19:27

midifan.com ：MIDI文件格式分析——理论篇




MIDI文件属于二进制文件，这种文件一般都有如下基本结构: 文件头+数据描述文件头一般包括文件的类型，因为Midi文件仅以.mid为扩展名的就有0类和1类两种，而大家熟悉的位图文件的格式就更多了，所以才会出现文件头这种东西。而数据描述部份是主体，我们现在来一起分析它的结构: 在每个Midi文件的开头都有如下内容，它们的十六进制代码为:“4d 54 68 64 00 00 00 06 ff ff nn nn dd dd”。前四个是ASCII字符“MThd”是用来鉴别是否Midi文件，而随后的四个字节是指明文件头描述部分的字节数，它总是6，所以一定是“00 00 00 06”，以下是剩余部分的含义：以上就是MIDI文件头了，后面的所有内容都是真正做事的，我们先来看看它的构成。 MIDI的数据是由若干个格式相同的子数据构成的，这些子数据在多音轨的格式中记录了一个轨道的所有信息。多加一个音轨，就简单地把数据追加在前一音轨的后面就可以了，不过不要忘记更改文件头中的nn nn(轨道数)。先看全局音轨。全局音轨包括歌曲的附加信息(比如标题和版权)、歌曲速度和系统码(Sysx)等内容。不管是全局音轨还是含有音符的音轨，都以“4D 54 72 6B”开头，它其实是ASCII字符“MTrk”，其后跟着一个4个字节的整数，它标志了该轨道的字节数，这不包括前面的4个字节和本身的4个字节。这一点，我们可以在后面的例子中去理解。接着就是记录数据的地方了，每一个数据有着相同的结构:时间差+事件。所谓时间差，指的是前一个事件到该事件的时间数，它的单位是tick(MIDI的最小时间单位)。它的构成比较特殊，这里要用二进制来说明。一个字节有8位，如果仅使用7位，它可以表示0~127这128个数，而剩下的一位，则用来作为标志。如果要表示的数在以上范围，则这个标志为0，这时，一个7位的字节可以表示0~127tick。如果要表示的数超出了这个范围(比如240)，则把标志设置成1，然后记录下高7位，剩下的留给下一个字节，在该例中240可以分解成1281+112，这里的1就是第一个字节要记录的，加上标志位，应该为10000001，即十六进制的81；而112是下一个字节记录的，它的十六进制为70:所以要表示240这个时间，要写成81 70。同理，如果要表示65535tick，则可以先计算出65535=128²3+128¹127+128⁰127，然后得出结果:83 FF 7F。由此，我们反过来也可以知道如何确定时间差:只要标志位为0，则表示结束读取时间差。比如82 C0 03表示128²2+128¹64+128⁰3=40963，如果基本时间为120，则有341:043个四分音符。以这种方式记录整数的字节称为动态字节*，它根据记录的整数改变自身的长度，这在后面还要用到，所以必须熟练计算。看完了这么麻烦的东西，我们再来看个更麻烦的东西:事件。在这些标准的解释后面，我们会通过一些例子来进一步掌握这些内容。事件大体上可以分为音符、控制器和系统信息这几个种类。对于这些事件，都有统一的表达结构:种类+参数。对于一个音符，由于它的有效范围是0~127，所以直接用00~7F作为“种类”，可以认为是个音符，比如3C表示中央C。而一个音符的最重要的参数是力度(也叫速度:velocity)。比如，3C 64 表示一个力度为十进制100的中央C音符。因为一个字节有8位，所以剩余的一位如果置1，再联合其他的7位，则可以表示各种信息。我们暂且无视一个音轨到底是全局的还是用于记录音符的。它们归根结底都是用来记录各种事件的，只不过有些应出现在全局音轨比较合乎逻辑而已。既然这样，我们就可以从下面的表来看事件: 下表中，x表示音轨0~F，比如81表示松开第二轨的音符。下表详细地列出了FF的详细情况，对于字节数由数据决定的情况，表中以“--”表示。这些就是MIDI结构的全部内容，在下一讲，我们将通过一个实例来分析。

midifan.com ：MIDI文件格式分析——实践篇



	[/url]
要书写二进制(十六进制)文件，应该准备好一些工具，比如我自己用的是VC++，因为学习MIDI格式无非是想写它的软件，既然VC++可以编辑二进制文件，就将就着用吧。其次，应该找个可以编辑和播放MIDI文件的软件，比如Cakewalk，这样就可以开始了。首先书写文件头“4d 54 68 64 00 00 00 06”，我们直接写同步多音轨的格式，先写1个音轨，并以120为一个音符的基本时间。这样，随后的字节是:“00 01 00 01 00 78”。现在，如果用Cakewalk打开会失败，因为我们指定的音轨数为1，但是并没有书写任何音轨，如果改成“00 01 00 00 00 78”再打开，就不会出问题了。所以，今后如果更改了音轨数，千万不要忘记向“上头”汇报。把轨道数改回01，继续我们的实验。先写音轨的头信息：“4D 54 72 6B”（MTrk），因为我们还不能确定后面有多少字节，所以先把它假设成“00 00 00 00”，以后再回来改。我们先尝试设置歌曲的速度和节拍等基本信息。假设一个四分音符的时间是半秒，即0.5106微秒。它的十六进制数是07A120,再看事件表，设置速度是51,但是在其前面必须是FF，然后它须要3个字节作为参数，因此字节数为03，参数为“07 A1 20”，也就是“FF 51 03 07 A1 20”。这是事件部分，不要忘记在其之前有个参数——时间差。这是一开始就应该设置的参数，因此时间差为00。所以，完整的事件应该是“00 FF 51 03 07 A1 20”，我们把这一段追加在Midi文件末尾。这时先不要急着用Cakewalk验证，因为我们还没有向“上级”报告，没错，把前面表示字节数的“00 00 00 00”改成“00 00 00 07”，如果用VC++作为二进制文件的编辑器，选择了事件后，可以在状态栏看到选择的字节长。保存后，再用Cakewalk打开，就可以看见速度是120。我们再来设置节拍和调号，因为一般用Cakewalk新建一个Midi会默认地设置成4/4，C大调，我们就改设成6/8，A大调。查阅事件表知道，58和59是分别用来设置节拍和调号的。虽然设置节拍的参数很多，但在现在的系统中，后两个参数是被忽略的，而且Cakewalk还会对其进行修正。因此，我们只要设置好实际有用的就可以了。分子是6，分母是8，所以第一个参数是06，第二个参数是03(2³=8)。最后，补上前面的时间差和后面的两个被忽略的参数，它应该是“00 FF 58 04 06 03 00 00”；再看调号，A调有3个升号，因此可以这样的事件可以表示为“00 FF 59 02 03 00”。事实上，大小调是个被忽略的参数。我们统计一下至今为止事件的字节数，然后更改前面的参数，即把“00 00 00 07”改成“00 00 00 15”。保存后用Cakewalk打开，再进入五线谱窗口，就可以马上验证了。细心的你可能已经发现，进入五线谱窗口前和平常有些延迟，这是因为我们并没有设置好那些可以忽略的字节，而Cakewalk就是在对其进行重新验证，这一点，我们以后再讨论。用同样的方法，您可以很容易地设置歌曲的标题和版权，这作为一个练习，在这里就不多写了。我们现在学习写一个含有音符的轨道。首先您应该知道要做哪些事：1、写新音轨的信息头；2、向上级汇报多了一个音轨。接下来，我们开始写入一个简单的音符。假设向第一拍写一个中音A，这里可能要先说明一下，音符是从C0开始一起向上数的，数到中央C(C5)是十六进制的3C，则中音A应该为45，在附件中有详细的计算方法。我们知道在音乐中一个音符通常有三个属性：音高、力度和时值。可是我们在事件表中并没有看见有什么可以直接设置音符时值的标志。不错，事实上，音符的时值是由按下的时间和松开的时间决定的。我们假设要写入一个八分音符。它的Tick数是四分音符的一半，即60，十六进制表示成3C。我们先来看看与音符有关的标志。在事件表中，9x是用来打开一个音符，我们这里假设使用第7个通道(注意到MIDI有16个通道(Channel)，而第10个被默认地用作打击乐，所以，我们在这个阶段(没有学习Sysx之前)，先不要使用第10个通道)*，则9x中的x是6；再看它的参数，一个是音符，这里我们写入45，第二个是力度，我们用70，因为是一开始就触发的，所以前面的时间差还是00。这样我们就在第5个通道以力度112按下了一个中音A。对应的字节描述是“00 96 45 70”。它的时值不用想都知道一定是0，这取决于什么时候把它松开。特别地，如果一个音符的力度为0，则MIDI认为用户想松开这个键，因为9x已经打开了通道，所以我们直接写入一个带00力度的同一音符就可以决定这个音符的时值了。根据前面的分析，这个时间差应该是3C，所以我们在写入3C后写上音符45和它的力度00，即“3C 45 00”。统计好字节数并向这一轨的头信息中更新，然后保存到磁盘，用Cakewalk打开并进入事件列表窗口便可以验证了。在这个基础上，我们再尝试在A的后面增加一个四分音符中音#G。因为96已经打开了通道，我们没有必要每次都使用9x，只要输入事件信息即可。对于中音#G，它的十六进制是44，相对刚才输入00力度的A来说时间差为00，因此可以表示成“00 44 64”，这里我们已经假设力度为100；然后是松开它，因为是四分音符，所以时间差是78H，别忘记力度是00，它的字节应表示成“78 44 00”，做好后面的工作，然后验证看对不对。我们再做个稍微复杂一点的实验：在原来的基础上，在同一轨的第一拍加上一个附点四分中音D。这里就不能再使用追加的方法了，因为前面的事件已经过了3个八分音符的时间，无论再加上什么，都只会发生在后面，所以我们要在前面插入一些字节。 9x已经打开了通道，我们直接在9x按下的音符后加上一个音符事件“00 3E 64”，这里的00显然是个时间差，3E是中音D，64是力度，也就是说，在按下中音A的同时按下了中音D。我们又按下一个键了，要在什么时候，在哪里松开才能保证输入的是个附点八分音符呢？首先，它的时值是3个八分音符，即180，这里还有一点要注意，180是个大于128的数，它的动态字节就应该表示成“81 34”，在哪里输入才好呢？如果你觉得在按下D后输入，或者在任何什么地方输入这个时间差，然后再写上“3E 00”可以表示松开的话就完全误解了时间差的概念。其实，我们只要简单地在松开#G的时候松开D就可以了，所以应该在末尾补上“00 3E 00”。统计好字节数后到Cakewalk中去验证验证吧。[url=http://www.midifan.com/iarticle/seerxillion/note.mid]这里附有我们目前写下的Midi文件样本。到目前为此，我们应该可以输入任何形式的音符了，不过MIDI除了音符以外，还可以包括各种控制器和系统码，它们的地位不亚于音符，我们现在马上学习如何使用控制器。控制器比音符要简单多了，我们尝试在#G前加入相位控制(Pan)，它的十进制代码是10，十六进制是0A，我们将参数设置成111，即十六进制的6F。首先查得控制器是Bx，这里的x和上面一样，也是6。接下来写入控制器号0A，然后是参数6F，别忘了前面的时间差是00。所以这段字节是“00 B6 0A 6F”，它应放在松开#G的事件之前，与按下#G同时。不过，一旦使用了非音符，而后面还有音符事件时，则必须重新通知打开音符，这说起来复杂，做起来还是比较容易的，我们只要稍微改写下一个音符事件即可：原本是“时间差+音符+力度”，我们加入一个打开音符的标志，成为“时间差+9x+音符+力度”即可。校验过头信息后，去Cakewalk中进行更进一步的检验便知它的可行。其实，时间差为00的控制事件如果出现的时间也是00，则在Cakewalk中会尽可能地把它们放在轨道信息中，而不在事件列表中重复。我们可以利用这一点给音轨设置初始乐器和音量，这就作为一个练习，在此就不再说明了。至于其他的诸如触后键等与控制器类似的格式在此就不多说了。在这里有必要提醒的是滑音。滑音的乐理范围是-8192~8191，但是在使用时参数是个正数，比如要设置成0，则应该是0-(-8192)=8192，它才是参数。8192的7位双字节表示成“8192 mod 128=00H；8192 div 128=40H”。如果时间差是00，则应表示成“00 E6 00 40” 最后我们看看系统码。系统码的构成本来是“F0 厂家ID 设备号码格式代码传送命令具体参数 F7”，而在文件中，则不以开头的“F0”为系统码，而字节数也仅记录剩余的系统码，比如XG的复位码是“F0 43 10 4C 00 00 7E 00 F7”，则在文件中应写成“00 F0 08 43 10 4C 00 00 7E 00 F7”，其中第一个00是时间差，F0是系统码标志，08是后面的字节数。有一点要注意的是，几个系统码不可以写在一起，比如“00 F0 0D 43 10 4C 00 00 7E 00 F7 F0 AA BB CC F7”或“00 F0 0C 43 10 4C 00 00 7E 00 F7 AA BB CC F7”都是不好的写法。如果存在以上系统码集，可以分成两个事件:“00 F0 08 43 10 4C 00 00 7E 00 F7 00 F0 04 AA BB CC F7” 当然系统码可以写在任何音轨，不过一般我们会考虑把歌曲播放前发送的系统码写在全局音轨中，并把时间差设成00。作为一个参考，这里再附上一个MIDI样本。虽然我们只讨论了同步多音轨的格式，其实对于其他两种，比如较常见的单音轨格式，所有的事件只写在一个音轨中，即只要存在一个“MTrk”就足够了。而相对地，用于记录音轨数的两个字节也永远为“00 01”，连续事件如果出现的通道不同，也必须重新指定通道(8x~Ex)。在此不详细讨论了。到目前为此，我们应该可以构造出任何MIDI音乐了，作为一些辅助性的参考，可以查阅下一篇连载《MIDI文件格式分析——附件篇》。另外，对于扩展名为.rmi的格式，可以参阅下下篇连载《MIDI文件格式分析——RMI篇》。

midifan.com ：MIDI文件格式分析——附件篇


	[/url]
	[url=http://www.midifan.com/]
该文档是前两编的补充，主要讲述以下内容：音符十六进制的计算关于乐器选择 RPN和NRPN 在MIDI中，中央C是C5，最低音是C0，最高音是G5，要计算任何一个音符对应的十六进制，可以使用这个公式：假设音符是NO，表示第O八度的音名N，比如G2中，N为G，O为2，则它的十进制为O12+N，N的值为了简便起见，用下表给出：这样G2的十进制值为212+7=31，十六进制为1F。若知道音符的十六进制，也可以很容易求出音符，比如64₍₁₆₎=100₍₁₀₎，而100 div 12=8，100 mod 12=4，对应音符为E8。写成公式就是： N=B mod 12；O=B div 12；(设B为表示音符的字节的十进制数) 乐器是MIDI中比较重要的因素，要选择所有的乐器不仅仅只是使用Cx号标志就能完成的，还必须结合BankSelect(乐队选择)，而BankSelect其实是由0号控制器和32号控制器完成的，它们的十六进制代码分别是00和20.比如要选择出XG标准中的Slow Violin，它在第08H个乐队中的第28H号乐器中，所以它的完整代码应为“00 B0 00 00 00 20 08 00 C0 28”。我们来分析它的构成：这里我们假设时间差为00，所有信息都发给通道00，所以第一个00是时间差，B0是打开控制器的标志，并指定发送到通道00，接下来的00 00，是由控制器号00和控制器参数00构成的，它事实上是表示0号控制器的参数为0，即BankSelect-MSB的参数为0，然后是下一个事件，它是“00 20 08”，即时间差是00，使用20H号控制器，参数为08H，即BankSelect-LSB的参数是08H，这样就指定了Bank(乐队)。再下来就是“00 C0 28”，就是所谓的Patch Change事件了，它的时间差为00，参数是28H。这样就完成了标准的乐器选择。事实上，它是由三个事件共同完成的，如果某次选择乐器和上次的乐器有共同的参数，可以不必重复使用相关的操作。在本例中，您可能发现了一点，当连续使用同类操作时可以不必每次指定操作种类，比如这里的连续再次使用控制器，所以第二个控制器并没有使用B0作为标志，而是直接使用控制器号码和它的参数。这一点和音符是一样的。其实，如果连续使用Patch Change事件(我是说如果)，则也可不必每次都写Cx，打开了一次就可以了；不过就Patch Change事件而言，连续地更换乐器的结果是仅最后一个有效而已。在前面的文档中并没有提及RPN和NRPN，其实它们是由四个连续的控制器来实现的。我们假设要使用RPN事件的Coarse Turning，它的参数假设是4096，则它的字节是“00 B0 65 00 00 64 02 00 06 20 00 26 00”，我们来分析这段字节：首先我们先看看RPN是由哪四个控制器组成的——首先设置RPN-MSB和RPN-LSB，分别对应的控制器是65H和64H，Coarse Turning的RPN码是2，所以MSB为0，LSB为2；然后是设置Data Entry MSB和Data Entry LSB，对应的控制器是06H和26H，而4096 div 128=32，4096 mod 128=0，对应的十六进制数分别是20H和00H。因此就构成了上面的字节。而NRPN和RPN原理是一样的，只不过不用RPN-MSB和RPN-LSB，而改用NRPN-MSB和NRPN-LSB而已，它们对应的十六进制数分别为63H和62H。

midifan.com ：MIDI文件格式分析——RMI篇



	[url=http://www.midifan.com/][/url]
MIDI文件除了有常用的以.mid为扩展名的格式以外，还有一种以.rmi为扩展名的。这种格式与.mid不同的是它在.mid格式的前面增加了一个文件头，后面的部分几乎和.mid的一样。即.rmi=RMI格式文件头+.mid文件。这个文件头可以描述成以下这种形式： 52 49 46 46 LL LL LL LL 52 4D 49 44 64 61 47 61 SS SS SS SS 和.mid文件格式类似，这个文件头的前四个字节是“RIFF”，接下来的是一个四个字节的整数，它表示从最后一个LL起到文件结束的字节数。假设这个数是100，则这四个字节就是“64 00 00 00”。然后紧接着的八个字节又是文字标识，不过这次是“RMIDdata”，最后的四个字节SS，表示MIDI文件的字节数，如果MIDI文件长度为139，则这四个字节就是“8B 00 00 00”。文件头后就是和MIDI文件一样的内容了，这些内容的长度就是SS的值。

例子:

3万 · 2008-12-31 19:28

http://www.myfaq.com.cn/A/2001-12-20/8449.html

MIDI 文件结构

Chunks

MIDI 文件由 chunks 组成：
每个chunk 的组成：

类型	长度	数据
4 字节	4 字节	（前面规定的）长度

A 4-字节 chunk 类型 (ASCII)
A 4-byte 长度(32 位, msb first)
（前面规定的）长度数据

有两种类型的 chunks ：
Header Chunks
有一个chunk标志“MThd”
Track Chunks
有一个chunk标志“MTrk”
一个 MIDI文件由一个header chunk和紧接的一个或多个track chunks组成。
在chunks结构中，自长度区以后是严格规定好的。它可能容纳的chunks除了“MThd”或“MTrk”其它的将被忽略。MIDI说明书要求软件能够处理意想不到的chunk，并忽略掉整个chunk。

	<---Chunk--->
	类型	长度	数据
MIDI 文件 :	MThd	6	<格式>	<tracks>	<division>
MTrk	<长度>	<delta_time> <event> ...
:
MTrk	<长度>	<delta_time> <event> ...

数值表示法

在MIDI 文件中，除了基本的MIDI数据，还有一个变化的数据（类型）。如： delta-times 和 meta-events。
这里有一些关于这样的数的一些资料，它们有通常有下面1~2种格式：

二进制数

二进制数的存贮：

每个字节8位
MSB first (最左方的字节权（或数位）大)

（除非其它的描述）

可变长度数

这个可变长度数是为了方便表示任意大的整数，而不必创建固定宽度的整数。
一个可变长度数被表示为连续的7位数据。从最高位到最低位，最后一个字节bit7等于0，前面的字节bit7等于1。
例：

数	可变长度数
十进制	十六进制	二进制	二进制	十六进制
-	abcd	aaaabbbbccccdddd	100000aa 1aabbbbc 0cccdddd	-
0 : 127	00 : 7F	0000 0000 : 0111 1111	0000 0000 : 0111 1111	00 : 7F
128 : 16383	80 : 3FFF	00000000 10000000 : 00111111 11111111	10000001 00000000 : 11111111 01111111	81 00 : FF 7F
1000	03E8	11 1110 1000	10000111 01101000	87 68
100000	0F4240	1111 0100 0010 0100 0000	10111101 10000100 01000000	BD 84 40

如此，你可以从上面的例子发现：小的数（0~127）可以用一个字节表示。而（比较）大的数也可以表示出来。
在MIDI 文件中，最大的数是0FFF,FFFF。这个规定了可变长度数允许利用32位整数。

Header Chunks

Header chunk 数据部分包括3个16位（数据）区。这个区域描述：（ MIDI 文件）格式、track 的数量和 MIDI 的时间设置。
Header chunk的长度是6个字节。无论如何软件必须遵循这个原则。即使它大于预期的，任何意料外的数据被忽略。

Header Chunk
Chunk 类型	长度	数据
4 字节（ASCII）	4 字节（32位二进制数）	<-- 长度(= 6字节) -->
16位	16位	16位
MThd	<长度>	<格式>	<tracks>	<division>

<长度>
Chunk数据部分的长度。
这是一个32位二进制数, MSB first.
这在 MIDI 1.0文件说明书中规定为6。不过，考虑到将来的扩充，（希望）任何MIDI文件的作者能够应付大的Header chunks。
<格式>
MIDI 文件的格式。
这是一个16位二进制数， MSB first。
有效的格式是： 0、 1 和 2 。
<tracks>
MIDI 文件中track chunk的数量。
这是一个16位二进制数， MSB first。
<division>
这个定义在MIDI 文件中（一个）单位的 delta-time数。
这是一个16位二进制数， MSB first。
有下列两者之一的的格式，依赖于最高位值。

位:	15	14 ... 8	7 ... 0
*<division>*	0	1/4音符tick数
1	-帧/秒	ticks / 帧

bit 15 = 0:
bits 0-14
每个1/4音符的 delta-time 数。
bit 15 = 1:
bits 0-7
每个 SMTPE 帧的 delta-time 数。
bits 8-14
负数，表示每秒中SMTPE 帧的数量。有效数应符合MTC Quarter Frame消息。

   -24 = 24 帧/秒

   -25 = 25 帧/秒

   -29 = 30 帧/秒, drop frame

   -30 = 30 帧/秒, non-drop frame

MIDI File Formats

MIDI 文件有3种变化：

格式 0
…容纳单一的Track。
格式1
…容纳一个和多个同步的Track（所有的Track同时播放）。
格式2
…容纳一个和多个独立的Track（所有的Track独立播放）。

MIDI 文件格式 0

格式0 MIDI 文件包括一个Header-Chunk 和一个 Track-Chunk。
这个 Track-Chunk 包括所有的音符和节拍消息。

MIDI 文件格式 1

格式1 MIDI 文件包括一个Header-Chunk 和多个 Track-Chunk，所有的Track同时播放。
格式1 中第一个Track是专用的。它看成“Tempo Map”。它包括所有的 meta-event ：拍子记号、拍子、音序/Track 名称、音序号、标记、SMTPE偏移量。在格式1中（这些）将放入在第一个 track 中。

MIDI 文件格式 2

格式2 MIDI 文件包括一个Header-Chunk 和多个 Track-Chunk，每个Track表现出独立的次序。

Track Chunks

Track chunk 的数据部分由一对和多对 <delta-time> <event> 组成。 <delta-time>是必须的，0是有效的 delta-time。

Track Chunk
类型	长度	数据
4 字节 (ASCII)	4 字节 (32位二进制数)	<-- 长度--> (二进制数)
MTrk	<长度>	<delta-time> <event> ...

<delta-time>
相对于前一个事件的“tick”，是一个可变长度数。
<event>
下列之一：
·   <midi   事件>
·   <sysex 事件>
·   <meta 事件>

事件

注意：在 <delta-time> 和 <event>之间，没有明确的分隔符。这个是因为 delta-times 和event有一个长度定义。

Delta-time 定义最后一个字节的最高位等于0。
MIDI Channel 消息有一个长度定义。
Sysex-events 和 meta-events 有一个清楚的长度区。

3万 · 2008-12-31 19:29

看了这份资料,想信你一定会找到MIDI档的大门,哈哈,十几年前俺为之费尽心思,特地刨出来晒一下,以饷各位MIDI玩家.

2万 · 2008-12-31 19:35

3万 · 2008-12-31 19:38

只看该作者 · 2008-12-31 21:38

太长了，有兴趣...记号。

只看该作者 · 2009-1-1 08:16

同楼上，做个记号

只看该作者 · 2009-11-7 15:29

本帖最后由 st-wzr 于 2009-11-7 15:35 编辑

好贴,学习中

只看该作者 · 2009-11-7 16:06

像这种规范，标准之类的东西我一直很困惑，为什么公开得到的渠道那么难呢？懂的大侠说说。

2万 · 2009-11-8 17:40

midi的标准并不统一，就像基于IE开发的网页，有的对标准W3C偏离了很多，导致FireFox显示混乱
我也做过老T叔的那个手工分析的工作，不过俺不是做害人的**，还是助人学习的字典机，呵呵

2万 · 2009-11-8 17:42

老T叔有个地方非常值得我辈学习--------------技术的积累和分享
我是经常一个案子OK了，很多东西就丢了，除非确定下个案子还继续用

3万 · 2013-9-1 09:33

95年那时存储器还很贵,MIDI文件6K能放60秒音乐,很有价值,现在RAM很便宜了,MIDI也只能作为一些乐器的输出信息来玩玩了.哈哈

只看该作者 · 2015-8-2 15:59

谢谢

奉献一份MIDI档**手稿

midifan.com ：MIDI文件格式分析——理论篇

midifan.com ：MIDI文件格式分析——实践篇

midifan.com ：MIDI文件格式分析——附件篇

midifan.com ：MIDI文件格式分析——RMI篇

相关下载

相关帖子

MIDI 文件结构

MIDI 文件结构

Chunks

数值表示法

二进制数

可变长度数

Header Chunks

MIDI File Formats

MIDI 文件格式 0

MIDI 文件格式 1

MIDI 文件格式 2

Track Chunks

事件

奉献一份MIDI档**手稿

沙发

厉害啊

太长了~~

佩服

十世金身

终身成就奖章

坚毅之洋流

技术领袖奖章

无冕之王奖章

湍急之河流

七世轮回

核心会员奖章

技术导师奖章