Broadband Watch logo
バックナンバー

その116「DLNAの仕組み」
[2007/03/26]
その115「ドメインとActive Directory」
[2007/03/19]
その114「ワークグループができること」
[2007/03/12]
その113「WPSの仕組み」
[2007/03/05]
その112「Gopherの生い立ちと現在」
[2007/02/26]
その111「Wikiの使われ方」
[2007/02/19]
その110「文字コードとは」
[2007/02/05]
その109「IISの生い立ち」
[2007/01/29]
その108「NASの登場と一般への普及」
[2007/01/22]
その107「HomePNAのいろいろ」
[2007/01/15]
その106「Ogg Vorbisの成り立ち」
[2006/12/25]
その105「MIDIの原理とSMFの構造」
[2006/12/18]
その104「AIFFの構造」
[2006/12/11]
その103「WAVの構造と現状」
[2006/12/04]
その102「WMAの歴史」
[2006/11/27]
その101「AACの特徴」
[2006/11/20]
その100「MP3/MPEG Audioの仕組み」
[2006/11/13]
その99「HSDPAの仕組み」
[2006/11/06]
その98「H.264・MPEG-4 AVCの特徴」
[2006/10/30]
その97「IEEE 802.16e(モバイルWiMAX)の特徴」
[2006/10/23]
その96「TIFFの特徴」
[2006/10/16]
その95「PNGの現状と今後」
[2006/10/02]
その94「GIFの構造」
[2006/09/25]
その93「10GBASEの種類(2)」
[2006/09/11]
その92「10GBASEの種類」
[2006/09/04]
その91「GbEのいろいろ」
[2006/08/28]
その90「JPEGの特徴」
[2006/08/21]
その89「DivXの広がり」
[2006/08/07]
その88「MPEGの仕組み」
[2006/07/31]
その87「WMVのこれまで」
[2006/07/24]
その86「AVIの生い立ちとそのコーデック」
[2006/07/10]
その85「QuickTimeの変遷」
[2006/07/03]
その84「Realのこれまでと今後」
[2006/06/26]
その83「ShareとWinny」
[2006/06/19]
その82「DOCSISの仕組み」
[2006/06/12]
その81「SQLインジェクションの流れ」
[2006/06/05]
その80「RSSの動作」
[2006/05/29]
その79「Skypeの仕組み」
[2006/05/22]
その78「BitTorrentの特徴と今後」
[2006/05/15]
その77「Winnyの仕組みと現状」
[2006/05/08]
その76「WinMXの特徴」
[2006/04/24]
その75「Gnutellaの歴史と構造」
[2006/04/17]
その74「Napsterの歴史」
[2006/04/10]
その73「P2Pのいろいろ」
[2006/04/03]
その72「IEEE 802.11nの動向」
[2006/03/27]
その71「ActiveX Scriptingの動作」
[2006/03/20]
その70「Ajaxの仕組み」
[2006/03/13]
その69「DHTMLの動作」
[2006/03/06]
その68「Scriptの定義」
[2006/02/27]
その67「JavaScriptの仕組み」
[2006/02/20]
その66「Javaの動作」
[2006/02/13]
その65「RFCのプロセス」
[2006/02/06]
その64「ActiveX DocumentとActiveX Controlの違いと共通点」
[2006/01/30]
その63「ActiveX Controlの機能」
[2006/01/23]
その62「ActiveXを構成するもの」
[2006/01/16]
その61「Cookieの仕組みと用途」
[2005/12/26]
その60「malwareとその分類」
[2005/12/19]
その59「rootkitの動作」
[2005/12/12]
その58「CSSの役割」
[2005/12/05]
その57「HTMLの変遷」
[2005/11/28]
その56「PONとその種類」
[2005/11/21]
その55「FWAの仕組み」
[2005/11/14]
その54「DoSとDDoS」
[2005/11/07]
その53「SNMPとMIBの動作」
[2005/10/03]
その52「Jumbo Frameとフレームサイズ」
[2005/09/12]
その51「WPA2の仕組み」
[2005/09/05]
その50「WPAとWPA-PSKの違い」
[2005/08/29]
その49「WPAの仕組み」
[2005/08/22]
その48「WebDAVの動作」
[2005/08/08]
その47「OFDMAの仕組みとOFDMとの違い」
[2005/08/01]
その46「OFDMの仕組み」
[2005/07/25]
その45「WiMAXの特徴」
[2005/07/11]
その44「Wi-Fiの役割」
[2005/07/04]
その43「FTPの目的と動作」
[2005/06/27]
その42「UPnPの動作」
[2005/06/20]
その41「ネットマスクの仕組み」
[2005/06/13]
その40「ARPの機能」
[2005/06/06]
その39「DNSの原理」
[2005/05/30]
その38「デフォルトゲートウェイの役割」
[2005/05/23]
その37「MACアドレスの仕組み」
[2005/05/16]
その36「スイッチとその進化」
[2005/05/09]
その35「ルータによるメリット」
[2005/04/25]
その34「ブリッジの原理」
[2005/04/18]
その33「リピータの機能」
[2005/04/11]
その32「IPアドレスのクラス」
[2005/04/04]
その31「ブロードキャスト/マルチキャスト/ユニキャスト」
[2005/03/28]
その30「SMTP AUTHと認証の種類」
[2005/03/14]
その29「Submissionポートとスパムメール対策」
[2005/03/07]
その28「Outbound Port25 Blockingとは」
[2005/02/28]
その27「PGPの仕組み」
[2005/02/21]
その26「PKIと認証局」
[2005/02/14]
その25「公開鍵暗号方式とは」
[2005/02/07]
その24「共通鍵暗号とは」
[2005/01/31]
その23「SSHの仕組みと応用」
[2005/01/24]
その22「SSLの役割」
[2005/01/17]
その21「POP3とIMAP4の違い」
[2004/12/27]
その20「POP3の役割と機能」
[2004/12/20]
その19「SMTPの機能と問題点」
[2004/12/13]
その18「SPIとパケットフィルタリング」
[2004/12/06]
その17「LANの概念とその広がり」
[2004/11/29]
その16「SIPの役割」
[2004/11/15]
その15「プロキシの利用」
[2004/11/08]
その14「VoIPの仕組み」
[2004/11/01]
その13「イーサネットとは」
[2004/10/25]
その12「IP/TCP/UDP/ICMPとは」
[2004/10/18]
その11「DHCPの役割」
[2004/10/04]
その10「MIMOとは」
[2004/09/27]
その9「DMZとその効果」
[2004/09/13]
その8「ファイアウォールとは」
[2004/09/06]
その7「NATとNAPTの違いとIPマスカレード」
[2004/08/30]
その6「VPNとVPNパススルーの仕組み」
[2004/08/23]
その5「無線LANの問題とWEP」
[2004/08/09]
その4「IEEE 802.11a/b/gって何を意味しているの?」
[2004/08/02]
その3「ダイナミックDNSって?」
[2004/07/26]
その2「グローバルIPアドレスとプライベートIPアドレス」
[2004/07/12]
その1「PPPoEって何だろう?」
[2004/07/05]

その105「MIDIの原理とSMFの構造」


MIDIって何?

 MIDIは「Musical Instrument Digital Interface」の略で、もともとは電子楽器同士のデータ交換のために定められた規格です。この規格を定めたのは「JMSD(MIDI規格協議会、現在のAMEI:社団法人音楽電子事業協会)」と「MMA(MIDI Manufactureres Association)」という2つの組織です。中核企業は国内ではヤマハやローランド、カワイ楽器、コルグで、海外ではOberheim、Sequential circuit(現Sequential)といった電子楽器(というか、シンセサイザ)メーカーでした。

 端的に言えば、MIDIは異なるメーカーの楽器であっても、同一のインターフェイスで接続して連動できるようにしよう、というものです。Specificationは、MMAから「Complete MIDI 1.0 Detailed Specification」として入手できます。最新版は2001年11月にまとめられた「Version 96.1 Second Edition」で、良くぞここまで改定したというべきか、名前の付け方を変えた方が良かったんじゃないかと、いろいろ考えさせられます。

 MIDI自体は、5pinのDIN端子を使い、31.25kbpsの速度で演奏データを転送するものです。MIDI Specificationでは、物理的なケーブルの形状や通信方式、実際の演奏データフォーマットなどをすべて網羅したものになっています。

 さて、MIDI自体はインターネットとあまり関係がありません。もともとMIDIは、スタジオや(大きくても)コンサートホールレベルのエリアに配される、シンセサイザなどの機器を接続するための規格です。もっとも最近は接続すべき機器類が非常に多くなり、接続も段々難しくなってきたため、「MIDI over LAN」や「ipMIDI」というようにTCP/IPの上にMIDIプロトコルを通すなんて方式も次第に広まってきました。しかし、流石にこれでインターネットを介するというのは技術的にはともかく、実際はあまり意味はありません。

 では、インターネットに関係するものはというと、MIDI規格のうち、「SMF(Standard MIDI File)」と呼ばれるものがあてはまります。SMF自体はもともと、Opcode System社が提唱したMIDIデータを格納するための規格です。もちろん、これも当初はPCにMIDI機器を接続して演奏したり、逆に演奏データをPCに格納したりするためのものでしたが、音楽データをMIDIフォーマットで交換するという用途でも当然使用されています。加えて、インターネット上においてMP3などに比べればややシェアは低いものの、それなりに使われているのが現状です。


MIDIの原理とSMFの構造

図1:MIDI Message
 さて、MIDI自体に関してですが、ものすごい単純な書き方をすれば、「譜面をデータ化したもの」ということになります。譜面は端的に言えば五線譜に音符を並べて、音の高さ、長さを記したもので、さらに書き込みなどで強弱や速度、音色などの情報が加えられていくわけですが、MIDIもこれと同じです。

 最初に音色とか速度などのデータを送った後は、音符同様に音程や音のオン・オフがシーケンシャルに送られ、MIDI機器はこれを元に内蔵する音源の音色を使って再生(演奏)を行なう形になります。具体的に言えば、MIDIでは「MIDI Message」と呼ばれるデータを連続して送る形になります。どんなMessageが用意されているかをまとめたのが図1ですが、この中で1番頻繁に使うのが上の2つ、「Note On」と「Note Off」というイベントです。

 例えば、「ドレミファソラシド」を演奏させたい場合に、MIDIでは図2のようなメッセージ列を送る形になります。Note Onというのはピアノで言えばキーを押す指定、Note Offはキーを離す指定になります。それぞれ待ち時間がその後に入っているので、これを調整することで「ドッレッミッファッソッラッシッドッ!」にも、「ド〜レ〜ミ〜フ〜ァ〜ソ〜ラ〜シ〜ド〜」にも調整できるわけです。本稿の意図はMIDIのフォーマットの詳細を説明するものではないので、このあたりで説明はやめておきますが、譜面では感覚的に表現するような項目も、MIDIではデータとして表現するというわけです。


図2:ドレミファソラシドのメッセージ例

 SMFは、このMIDIメッセージ列の頭にヘッダをつけるだけの構造です。厳密に言えばメッセージ列のことをMIDIでは「トラック」というのですが、図3のように簡単な「ヘッダ(Header Chunk)」の後ろに、ずらずらと「トラック(Track Chunk)」が繋がるという構造です。何故、Track Chunkが複数あるのかという話ですが、MIDIでは1つのTrackで1度に発音できる音は1つだけになるからです。

 従って、「ドミソ」を同時に発声させたければ、3トラック必要になるというわけです。何か無駄のように感じるかもしれませんが、例えば長い曲の1カ所だけが和音というケースではTrack Chunk #1にメロディを入れ、Track Chunk #2以降は和音の前後は全休符にしておけば良いので、それほど無駄が多いというわけではなかったりします。


図3:SMFの構造

MIDIの長所・短所と発展形

 なぜ、MIDIがインターネット上で使われるかという理由は2つほどあります。まず、他の音声フォーマットに比べて劣化が少なく(というべきかどうか微妙ですが)、しかも圧倒的にデータ量が少ない点です。端的に言えば、他の音声フォーマット(MP3/WAVなど)はいずれも演奏時間に比例してデータ量が増えるのですが、MIDIは音声の変化に比例するため、ゆっくり演奏する曲であれば変化量自体はそれほど多くありません。

 また、音声データにしても、例えば図2のドレミファソラシドの場合、メッセージ列そのものは78バイト(Note On/Offが各3バイト、待ち時間指定が各2バイト)で済みます。実際には「Header Chunk(14バイト)」と「Track Chunk Header/Track Length(8バイト)」、それにTrackの最後に「EOT(End Of Track)の宣言(4バイト)」を追加するために104バイトほどになりますが、それでもたったの104バイトです。22KHz/16bit MonoのWAVだと0.002秒分、64kbpsのMP3でも0.013秒分にしかならないデータ量でこれだけの曲を表現できるのですから、その効率の良さは圧倒的といってよいでしょう。

 もう1つのメリットは、非常に広い範囲でサポートされている点です。PC(Windows/Macintosh/Linuxを問わず)のメディアプレーヤーでMIDI(というか、SMF)をサポートしていないものは数えるほどですし、電子楽器の大半は当然サポートしています。メディアプレーヤーどころか、Webブラウザレベルでサポートしているものもあるほどなので、曲の配布などをするときに相手の環境にあまり悩まずに済みます。


 では短所はというと、実はこれも何点か存在します。まず最大の問題は、音声をサポートしていないこと。何しろ譜面ですから、これを使って会議の録音などをするわけにはいきません。あくまでサポートしているのは“曲”、それも西洋音階に従った曲のみであり、ボーカルパートなども記録や再生はできません。

 次の問題は「音色」。MIDIには標準的な128種類の音色が定められており、これに従えば同じ音が出るハズなのですが、例えば音色の1番のグランドピアノにしても、どこのメーカーのどんなグランドピアノも全部同じ音がするかと言えば、そんなことはないわけです。もっと悪いことに、MIDIでは音色1番は単に「グランドピアノ」と決められているだけで、その音色が具体的に定まっているリファレンスがあるわけではありません。結果、MIDIを作る側と再生する側で異なる音色が割り当てられる場合もあり、MIDIでは“曲が一緒”であることは保証されますが、“音が一緒”とは誰も保証して(できて)いません。

 3つ目の問題は、再生側の環境で音が変わってしまうことが多々あることです。最近はPCのハードウェア性能が向上し、「HDA(High Definition Audio)」と呼ばれる規格に準拠したものが増えました。しかし、少し前では「AC97(Audio Codec 97)」と呼ばれる規格に準拠したものが多く、こちらでは同時に32音まで、また、酷いものになると16音までしか発音できないなんてものが平気で流通していました。

 ドレミファソラシド程度なら16音でもお釣りがきますが、オーケストラクラスとまではいかなくても、ちょっとしたバンドの演奏程度で簡単に16音は越えてしまいます。越えた場合どうなるかというと、単に無視されて音が出ないわけで、結果として妙にすかすかした演奏になってしまいます。この同時発音数の問題は、ソフトウェアMIDIプレーヤーを使っていると、今も出会うケースがあります。

 結果として、ちょっとしたBGMの再生などにはともかく、生音声の記録や配布には向いていないのがMIDIフォーマットというわけです。筆者がインターネット上で良く見かける使い方は、曲そのものを説明するときに、いろいろ書くよりは聞いたほうが早いというパターンです。

 例えばクラシック曲の場合、曲自体は著作権が切れていますが、オーケストラなどが演奏したものは演奏者の著作権もありますし、CDであればCD発売元の権利もありますから、勝手に配布はできません。しかし、自分で譜面からMIDIを起こせば著作権の心配もなく配布できるというわけです。また、自分のページでBGMを流したい、というケースにもデータが小さいこともあり、手軽に利用されているようです。MIDI自体は、演奏やカラオケなどで非常に広く利用されていますが、インターネットに絡むところでは今一歩という感じでしょうか?

 ところでこのMIDIを拡張したものの1つが「SMAF」です。着メロなどにもMIDIの持つ特性は非常に向いており、こうした形でのMIDIの応用は今後も続いていくと思われます。


【12月18日17時35分追記】
 掲載後にいくつかご指摘をいただいたので、ちょっと補足説明をしておきます。
(1)和音について

 本文では、「MIDIでは1つのTrackで1度に発音できる音は1つだけになります。」と書きましたが、これの意味があやふやな部分がありました。MIDIで和音を作る場合、以下の2種類の方法があります。

・待ち時間0で音を重ねる
・複数トラックで同時に音を出す

 後者は上で説明した通りなので、前者について少し補足しておきます。例えば、「ドミソ」の和音を鳴らしたいときに、以下のようなメッセージ列を送ったとします。

「ド」のNote On event
待ち時間=0
「ミ」のNote On event
待ち時間=0
「ソ」のNote On event
待ち時間=いくらか
「ド」のNote Off event
待ち時間=0
「ミ」のNote Off event
待ち時間=0
「ソ」のNote Off event

 この場合、耳で聴く限り、「ドミソ」の和音がいきなり鳴らされたかのように聴こえます。この意味においては、シングルトラックでも“事実上は”和音が作れます。ただ、厳密に言えば、微妙なタイムラグはあります。この例で言えば、「ド」の音が発生してから「ソ」の音が重なるまでの間に、4つのMIDI命令を解釈する必要があります。

 解釈自体の時間は非常に短いので、ある程度まともなシンセサイザーであれば気が付かないないでしょうが、例えば和音の数が非常に多いケースや、いい加減な作りのソフトウェアシンセサイザーで再生した場合には、タイムラグが知覚できてしまったりします。

 ファイルなどから読み込むSMFではこうした問題はあまり問題になりにくいのですが、オリジナルのMIDIケーブル経由で接続していると、何しろ通信速度は31.25kbps(=4000Bytes/sec)ですから、環境次第では結構シビアになります。

 こうした場合でも確実に和音が和音として再生されるための唯一の方法は、複数トラック構成ということになります。そういうわけで冒頭の表現、正確には「MIDIでは1つのTrackで1度に操作できる音は1つだけになります。」となります。むしろ、わかりにくくなった気はするのですが、正確さを優先するということで、お詫びして訂正いたします。

(2)16音でお釣りがくる

 「ドレミファソラシド程度なら16音でもお釣りが来ます」という表現の意味がわからない、というメールをいただいたので補足を。特に深い意味はなく、単に該当部分の説明のような単調な音(その例が「ドレミファソラシド」という意味です)だけを再生するのであれば、同時発声数が16程度の環境であっても、なんら不自由はない、というだけの意味です。言葉足らずをお詫びいたします。


2006/12/18 10:58

槻ノ木 隆
 国内某メーカーのネットワーク関係「エンジニア」から「元エンジニア」に限りなく近いところに流れてきてしまった。ここ2年ほどは、企画とか教育、営業に近いことばかりやっており、まもなく肩書きは「退役エンジニア」になると思われる。(イラスト:Mikebow)
Broadband Watch ホームページ
Copyright (c) 2006 Impress Watch Corporation, an Impress Group company. All rights reserved.