となっており、カードリーダなどで書き込んだデータは公式には 正常に再生されないデータと見なされています。 しかし、いくつか実験をしてみたところ、 原理的には、カードリーダでSDカードに 書き込んだMP3もExrougeで問題なく再生できる ことがわかりました。 以下では、「原理的に再生可能」であることの延長として、とりあえずファイルを 書き込んで再生する「あくまで第一段階」 だけを実験してみます。

/　…ルート H2.PL　…曲順記憶ファイル < INFO > 　…曲情報格納フォルダ 　TRACK001.MP3 　TRACK002.MP3 　TRACK003.MP3 　　： < MUSIC > 　…曲データ(MP3)格納フォルダ 　TRACK001.MP3 　TRACK002.MP3 　TRACK003.MP3 　　：

右に記したのが、Exrougeで使用されるSDカードに書き込まれている情報の格納形式です。 ルートフォルダにはH2.PLというファイル(おそらくHyperHyde.ProgramListの略)があり、 この中にはテキストで、1行目に曲数、2行目からは曲ファイル名が曲の数だけ 1行ごとに書かれています。 < INFO > のフォルダには曲情報を納めたファイルがあります。.MP3というファイル名 ではあるものの、1つあたりわずか1KBのファイルで、曲の情報(タイトル名、アーティスト名、 アルバム名など、情報量的にはID3のようなもの)だけが格納されています。 最後に< MUSIC > フォルダには、MP3データ本体が納められており、 この< MUSIC > フォルダにあるMP3に対応した曲情報データが、同じファイル名で < INFO > フォルダのほうにも無いとその曲は再生されません。 以上が大体の構成です。

さて、H2.PLは改行コードが0Aだけ(普通Windowsのテキストは0D,0Aの2バイト)ということだけ 気をつければ、あとはただのテキストファイルですので、扱いは簡単です。 < MUSIC > フォルダのほうにあるMP3データも、ごく普通のMP3です。 問題なのは< INFO > フォルダの内容で、ここにある拡張子MP3の曲情報データの 解析はちょっと手間が掛かりそうです。バイナリエディタで覗いてみると、 タイトル名、アーティスト名、アルバム名くらいは簡単に変更できそうなのですが、 ちゃんとExrougeのデータとして正しく書き込むには、やはりちゃんとした解析が必要でしょう。 ここではとりあえず、そんな面倒な解析は避け、 手っ取り早くSDカードリーダなどでデータを書き込む方法 を考えます。どういうことかと言いますと、

という強引な方法をとるのですが、 それでもExrougeは、液晶表示に間違った曲名を表示すること以外は正しく動作してくれます。

上にも少し書きましたが、とりあえずExrougeに転送したMP3が正しく再生されるには、 以下の条件がちゃんと満たされていなければなりません。

1. H2.PLの中に曲数と、その数だけ曲ファイル名が記されている。
2. H2.PLに記されたファイル名がちゃんと< INFO > にも< MUSIC > にもある。

ここまで判れば、とりあえずSDカードリーダでファイルを直接書き込むことが できそうです。たとえば以下ような手順になります。

1. < MUSIC > の中にMP3ファイルを書き込んで、TRACKxxx.MP3(xxxは数字)のような ファイル名に変更する。ファイル名はTRACKxxxでなくても、ASCII文字で8文字以内 であれば何でも構いませんが、< INFO > 側も同じ名前のファイルを用意する必要があり、 あまり独自の名前にしない方が面倒臭くないでしょう。
2. < INFO > にも< MUSIC > と同じ名前のファイルを用意する。 ファイルはちゃんとExrougeで認識する情報ファイルでなければなりません。 元々HyperHydeManagerで普通にMP3を転送したときに作成される情報ファイルを、 複製＆リネームで増やしたりすればOKです。ファイルが沢山有りすぎても 害になることはありません。TRACK001〜TRACK030くらいまで作っておくと あとで楽です(笑)
3. H2.PLに曲数と曲順を書き込む。

「第一段階」はとりあえずQuickHackということでここまでで終了。 < INFO > フォルダのほうのデータも、そんなにクセの有りそうな感じでもないですので、 腕に覚えるある方でしたらすぐに解析できそうですね。 カードリーダで書き込むためのフリーウェア (HyperHydeManagerと同じように、MP3をドラッグ＆ドロップ、曲順変更、 カードリーダのドライブを指定して「転送」すると、 H2.PL、< INFO > 、< MUSIC > を適切に書き込んでくれるソフト) が登場したら凄く嬉しいです♪ （私はソフト開発の経験が浅いですので実際にモノを作るのは無理です…）。 →さなさん、なんとさん、みらげさんが実際に作ってくださいました。 詳細はこちら

ところで効果のほどは？？
自宅で実験した結果は以下の通りです。Exrouge付属の64MB MMCカードに、 テストデータ11曲（55MB＝57,704,900byte）を書き込みました。 つまり、64MBのカードを持っている場合の大まかな目安になる実験ですが、 USBケーブル経由でMMCカードに転送した場合10分近く掛かっていたものが、 ノートPCのPCカードスロットにアダプタを挿してMMCに書き込むとわずか2分で書き込めてしまいます。

追記ですが、128MBのSDカードで試したところ、さらに高速に書き込めました。 次のテストは、HDBENCH 2.610を使い、MMC 64MBとSD 128MBの2枚をそれぞれ USBのSDカードライタとPCMCIAのSDカードアダプタを使って書き込み速度を測定したものです。 Exrouge用のデータを書き込んだテストではありませんが、 そもそも直接書き込む際の速度はどれくらいのポテンシャルがあるのか、 という参考になると思います。これを見ると、SD 128MB は MMC 64MB と比べて 40%くらい高速です。また、USBのSDカードライタよりも、ノートPCのPCカードスロットに PCMCIAのSDカードアダプタを挿して書き込んだほうがさらに40%くらい高速です （ちなみにPCMCIAのSDカードアダプタをUSBのPCカードライタに挿したら元の木阿弥です・笑） もちろんPC環境やメディアのメーカーなどによって結果は大幅に異なると思われます。

メディアと書き込み方法によって、得られる効果が大幅に違うのが お判りいただけると思います。それにしても、標準のHyperHydeManager経由の転送速度(100KB/秒) に比べれは、いずれも大幅な速度向上が見込めるでしょう。

また今後、書き込み速度の向上が図られているという大容量(256MB,512MB)SDカード が登場すると、さらに高速に転送できることが期待できます。一方の正式なUSBケーブル経由 の転送はというと、IO.DATAは「省電力を優先し、本体に低速なCPUを搭載した」ために 書き込み速度がこれ以上向上しないことをほのめかしており、 差は開く一方？という可能性も大いにあり得ます。 私は512MBのSDカードが手に入る状況になったら直ぐに購入する予定ですので、 その結果もまた報告する予定でいます。

図１：情報データの中の前半部分(000h〜1FFh)

図１は前半部分(000h〜1FFh)のデータです。解明された部分だけ説明すると、 まず004h(〜005h ?)には液晶表示データの長さが格納されています。液晶表示データが何かという ことについては後ほどご説明します。 次に、008h〜009hの2バイトには、リアルビットレート(ファイルサイズ÷曲の長さ(秒))が 格納されています。この例のファイルは5,960,630バイトで、秒数は298でしたので、 5960630÷298は切り捨てで20002、つまり4E22hです。 続いて00Ahからの４バイトには、曲の長さが秒数で格納されています。 この例の曲は4分58秒でしたので、298秒=012Ahがその値です。 040h〜042hの３バイトにある「01 03 02」はデータの形式を示しており、 MPEG1、AudioLayer3のステレオを意味しています。 044hからの４バイトは「44100」つまりサンプリング周波数を示しており、 続く048hからの４バイトは「160000」でMP3のビットレートを示しています。 こちらはエンコード時の目標ビットレートです。この目標ビットレートは HyperHydeManager上で曲のプロパティを見たときに表示される情報としてしか 使用しません。一方、前記のリアルビットレートは、実際に演奏時に タイム表示をするための指標として使われますので、変な値を設定すると 演奏時のタイム表示がおかしくなります。

なお、000h〜003hの「00 01 00 00」と、006h〜007hの「10 00」は不明ですが、 常に固定値が出力されているようです。前者は付属ソフト(HyperHydeManager)あるいは 本体ファームウェアのバージョン番号、 後者は液晶表示の縦ライン数(16固定)と解釈することもできます。 （みらげさん、情報ありがとうございます♪）

0C0hからの5行分(80バイト)は曲名がシフトJISでそのまま入っています。 これでいくと曲名などのデータは全角80文字まで、半角40文字まで入ることになりますね。 同じく110hからはアーティスト名、160hからはアルバム名が、 1B0hからはコメントデータが入っています。 このあたりのデータは見たままで非常に簡単です。

ところが、この曲名やアーティスト名を書き換えても、Exrougeの液晶表示は 全く変化がありません（！）。これには当初驚きました。よくよく調べてみたところ、 液晶表示のデータは、曲名などのテキストデータとは別に、ビットマップデータとして 直接、後半部分に格納されていることが判明しました。

図２：情報データの中の後半部分(200h〜3FFh)

図２は情報データの後半部分です。 ここに、液晶に表示するデータの中身が格納されています。 先ほど、004hに液晶表示の長さ("C6h")が格納されていると書きましたが、 この後半部分には長さC6hのデータが２つ格納され、それ以降はゴミデータ（余り）になっています。 もし004hに格納されているのが "FFh" だとしたら、長さFFhのデータが２つ格納され、 ゴミデータ（余り）はわずか2バイト、ということになります。

さて、実際のデータの中身についてご説明します。 図３は液晶表示された曲名やアーティスト名の例です。

図３：液晶表示された曲名やアーティスト名の例

この表示データを、白("0")と黒("1")の２進数に見立ててデータを保存しています。 どのようになっているかと言いますと、上半分(8ビット)、下半分(8ビット)に分け、 左端から順々にビットデータを保存します。判りやすいように縦にして拡大したのが 図４です。

まずは上半分（図４で言えば右半分）のデータです。黒い部分を１、白い部分を０として ２進数→１６進数に変換します。一番上の行は黒い部分がありませんので 「0000 0000」＝「00h」になります。２行目は左から３番目だけが黒いですから、 「0010 0000」＝「20h」です。この要領で上半分（右半分）をずっとデータ化していき、 指定された長さ（ここではC6h）までいったところで、今度は下半分（左半分）に続きます。

図４：液晶表示とデータの対応

このような調子で、最大16×256の長さで白黒のビットデータを格納することで、 Exrougeはその画像を液晶に表示するのです。なお、16×256と言いましたが、 16ラインのうち上下1ラインずつは、他の表示（電池残量表示など）と共用になっており、 通常は使用しません。この部分に表示をすると、他の表示を一時的に邪魔したり、 スクロールをした際に黒いゴミが残ったりします。そのため、実質的には14ラインと 考えた方がよいでしょう。

ココに記した解析情報だけでも、データを直接SDカードに書き込むためのフリーウェアを 作るにはだいたい事足りるように思います。 ただ、MP3のID3情報を取り出すなどのスキルが別に必要なこと、 液晶表示のビットマップデータを作るためにはフォントデータから自力でビットマップを作る 必要があることなど、ある程度のプログラムスキルが必要になります(私は挫折しています…)。