h.morinoの日記： 最初の中間発表にはなにも動いていませんでした 6
日記 by
h.morino
研究を始めた当初はまず点字楽譜ってなんですかそれというところから勉強し既存の論文を読むわけです。
研究室配属2ヶ月弱で中間発表があるのでそこまでに何をできるかというと点字の勉強程度。あと方針説明です。
自分にとって、手でゴリゴリ書くのが無理だということは既存研究ではっきりしているわけですが、最初の数ヶ月はそれでもチャレンジしていたような記憶が…
コンパイラ書くなら読んでおきなさいと渡されたドラゴンの絵の本（確か「コンパイラ その技法と原理 I II」）はさっぱり理解できないし。いきなり弱り果てました。
そこで人工的な言語ならコンパイラを作るツールで簡単に解析できるんじゃないですかね、と最初にいったのは誰だったか記憶にないのですが、おそらく電情の田村先生じゃないかと踏んでおります。後藤先生が言い出したのかどうか記憶にないです。もう8年ぐらい前なので。
すいませんちょっと調べなおしてもう一回書きます。
人工的な言語 (スコア:1)
例：
楽器の種類や基準となる音等を最初に記述
ド
レ
ミ
・
・
・
このようなもので何か不具合があったのかが知りたいです（スラーとかが問題になるのかな。対象となるものに名前（番号等）を付けることが出来るようにすればあまり問題にならないような気がする）。
これならばコンパイラがかなり簡単に記述出来ると思いますが、そのあたりはどうだったのでしょう。（エラーが出ないように記述するのが非常に面倒そうですが、俺俺コンパイラなら説明書さえ書いておけば問題ないような気がする）
Re:人工的な言語 (スコア:1)
新たに人工言語を作って練習してもしょうがないでしょう。
＃昔、点字楽譜の自動解析やってました。
Re:人工的な言語 (スコア:2)
まず、記述時や保存時に点字である必要性が皆無であることです。
既存の点字楽譜データを保存する目的であれば、そのままの形式で良いでしょうし、印刷時に何等かのコンバータを通せば問題ないでしょう。
しかし、実際に手作業で入力することを考えると楽譜の入力って健常者（目に障碍の無い人）が行うのでは？
点字で入力して保存で良いのなら、現状でそれほど問題になるとは思えませんし。余分なデータ領域が存在するのであれですが、6bitを8bitに格納したりが問題になるとは思えませんし、むしろフラグ等をつけれるのであえてそうするのもありかなと思ったりもします。（どんなものにするのかは適当に決めて良いでしょう）
最近はMIDI等で保存されているものが多そうだけど、その場合は変換コンバータを使えば良いと思います。
そうではなく、実際に印刷や手書きの楽譜からデータを打ち込むのであれば、健常者（目に障碍の無い人）が打ち込みやすいものを追求すべきだと思います。
パソコン用の五線譜に音符等を書き込んでいくタイプのソフトウェアと同様のことが出来れば問題無いのではないでしょうか。そういう意味でもドレミと書いて保存等もかなり有効だと思います。
すでにフォーマットが定められているものから、フォーマットが定められているものには、データを格納出来ない形式を含んでいた場合は変換不能ですが、同等の機能を実現しているのであれば、格納出来ると考えて差し支えないのではないでしょうか。
例えばjpegとpngはどちらも同じように画像を保存出来ますが、双方で保存出来ない情報が存在します。しかし、画像を保存するという本来の目的は達成出来ているのです。
つまり、楽譜に戻すに足る情報を格納出来ているのであれば何も問題は無いわけです。
点字楽譜自体も音符に直せるという点で、普通の楽譜と同等のものであると考えられますが、違うものとして扱っていますよね？
私はデータを保存する方法は開発者（オープンにするならメンテナとかも含む）が理解していれば何でも良いと考えています。
実際に、パソコン上にデータがあっても意味は無いのです。それを読ませたい（この場合、見せたいは変かな？）人に読ませたい方法で表示なり印刷なり出来れば何も問題がないと思います。
データがしっかりしていれば、何か問題があるとすればプログラム部分のみですし、その逆もそうだと思います。
＃言いたいのは、
＃やる気があるのなら、ここにいる人達で助言が出来そうだからやってみないか。
＃ということです。
＃保存にはxmlとか使うって手もありそうですね。とかね。
Re:人工的な言語 (スコア:1)
まず最初に、私はやる気がありません。残念ながら。
過去の研究の経緯をまとめているのです。電子情報通信学会の論文誌にのった論文や、修士論文では奇麗事過ぎて伝わらなかった事を細かく残すことで、後に続く人が誰か興味を持ってくれたり他山の石としてくれればよいなと思っているだけです。
あと、うすうす感じられているようですが、はっきりいっておきますとこの点字楽譜の問題全般は
「研究として成果を出すという枠を捨てて膨大な金と時間と手間をかけちゃえば解決しそう」
なことがとても多いです。点訳ボランティアを1万倍ぐらいに増やしたり法令で楽譜出版時に点字楽譜も強制出版したりすりゃ研究するまでもない。ヤマハやローランドのソフト部隊がかかれば、簡単な点字楽譜で良ければ1ヶ月でできるかも。永遠にできない可能性もありますが。
＞記述時や保存時に点字である必要性
そりゃないのですが、最終目標を見据えれば、それよりよい方法がまったくもってないのです。やってみてごらんなさいませ。
あと6bitをテキスト4文字に展開しようが8bitで表そうがおっしゃる通りそんなのは問題じゃない。
でも元が6bitじゃなくて8bitフルに使っているのです。でも本来の意味としては6bitなのです。
どうせ展開する必要があるので「8bit -> 6bit」の変換を書いて変換結果が正しいかどうか心配するよりは「8bit -> 研究者に可読性の高い4文字のテキスト」にしたという、理想ではなくて現実のこまかい実装の話をしています。
＞楽譜の入力って健常者
「どうせ入力するのは健常者だろ。」その割り切ったアプローチは現実に即してはいますが世界の半分を切り捨てています。
点字楽譜は視覚障害者の作曲家も点字ディスプレイを読みながら実際に入力します。そして点字楽譜校正の手段が机上デバッグしかありません。彼らのためにも、点字楽譜コンパイラ、点字楽譜デバッガが必要です。
＞MIDI（中略）変換コンバータ
今ちょっと4文字言葉を言いそうになりましたよ。そうですね、市販の楽譜印刷ソフトに良くある、smfから楽譜の再構築ができるタイプのエンジンが使えるとよいですね。そうですね。ソースでもらえるとよいですね！
自前で作ったらそれだけで学生研究の時間が終わっちゃいますよ。建物の写真からオクルージョンありで3D再構築するようなもんです。不可能じゃないし、既存ソフトもあるけど研究の準備としてさらっと自前で終わらせておくにはお金と時間と人手が無理。
＞健常者（目に障碍の無い人）が打ち込みやすいものを追求すべき
それで点字楽譜生成用のMMLなんて創作するのはひどく遠回りだと思います。それを覚えられるならダイレクトに点字楽譜かけますよ。無駄だとはいいません。おやりになるならとめません。
あと、やってみるとトークンを置き換えて文法を機械解釈しやすくした点字楽譜ができあがるだけだと思いますが、それ卒論とか修論になりますかね。
また、健常者によっての作りやすさの点については（私のアプローチでダメだったので）別途考え、現在の後藤研究室では「ほっといてもどんどん視覚障害と全く関係ないところで作られる」MusicXMLから点字楽譜を書き下す研究が進んでいますが、それもひどく難航しているようです。
墨字楽譜も点字楽譜もとてもではないですがコンピュータ技術者が思うような意味で「フォーマットが定められている」ものではありません。Midiが行うようには演奏を表現できません。逆にMidiは音楽を表現できません。楽譜は音楽の鋳型、演奏指示情報でしかありません。演奏指示情報をデータとして確立した表現にする事に成功した人はいません。例えばMusicXMLは単なる2D-CAD情報です。
＞データがしっかりしていれば
データはしっかりしていないし、そのデータを見た人理解した人も計算機科学の学究領域ではいないと思います。音楽関連のソフト屋の人にはその世界を知っている人がいるかもしれません。音楽家は脳内にモデルを持っています（つまりギター部だった私も持っているはずです）が、それをデータ化できた人がまだいません。
＃昔、点字楽譜の自動解析やってました。
Re:人工的な言語 (スコア:2)
私が言っているのは、「健常者が使うのなら、健常者が使いやすいフォーマットで良いだろうし、点字で入力する人は点字のデータで保存すれば良いのでは？」ということです。
点字楽譜を作ろうとしていて、墨字楽譜を作ろうとしていないのなら、点字入力している人のデータまでわざわざ健常者と同一にする必要性が理解出来ません。まぁ健常者が入力し易いように墨字楽譜にも直せないと駄目だとは思いますが。。。
拡張子とかバージョン情報とかで簡単に区別付くようにすれば良いんじゃないかな。
つまり、相互に変換可能ならどんなフォーマットで保存していても問題は無いと思います。（これが一番重要）
midiやsmfで苦労するというのは、たぶん全て解析してリライトしようとしているからではないでしょうか。midiやsmfの場合はフォーマットが公開されていますので、そちらを参考にしてみてはどうでしょうか。
一応フリーでsmfとかを楽譜で作成するようなもののソースとかもどこかにあったような気がしますが・・・。
以前調べた時に気付いていましたが、墨字楽譜は結構作者独自の注釈とかが多くてフォーマットにはし辛いみたいですね。
MusicXMLは初めて聞きました。XMLで演奏フォーマットを定めたのかな。
最近のOSなら標準でXMLの取り込み機能とか使えるようになっている（Linuxとかでもインストール時に選択したら入れれそうな気がする）と思うのでかなり扱いが簡単そうですね。
MusicXMLで苦労しているというのを見てふと思ったけど、MusicXMLってWAVファイルみたいなデータだったりして。それなら楽譜に起こそうというのはやめたほが良いと思います。WAVやmp3等のデータからmidiや楽譜に変換だと全く違う研究をしていることになっちゃいます。ちなみにWAVとmidiの中間のデータ形式としてqcp等があります。
データがしっかりしていないというのは、midiとかでは演奏は不可能ということですね。まぁ演奏だけではなく注釈とかまでというのは少し面倒かな。やろうと思えば簡単そうですが、例外項目が何かを全て書き出していくとどこまで許容出来るのかとかが出るのかもしれません。
私は学校以外では楽器を演奏することが無かったので、音楽とかに関しては結構無知なのですが、学内で見たことのある墨字楽譜程度で良いのなら、それほど難しいとは思えないです。たぶんこのあたりがmidi等で実現出来ている範囲のような気がしますが。
付加したい情報があるのならそれらを指定出来るような柔軟性や拡張性のあるフォーマットを考えれば良いだけです。拡張性等を全く考えないというのはハードウェアやソフトウェアの限界に到達してからで良いと思います。
とりあえず、現状で点字楽譜で表せるものに限界があるのならそれにあわせたら良いのではないでしょうか。（上の一番重要というところをもう1度見てみましょう）
点字楽譜で表せれるものに限界が無いのであれば、何故無いのかを考察すると保存するときのフォーマットとかが決まりますよ。
現実的に考えると、点字楽譜で表せれるもの以上のものを作るのなら、それこそ墨字と点字で表せれる全く新しい楽譜を考えなければならないと思います。それらをしようとしていなかったみたいなので今までの発言があるわけです。
＞あと、やってみるとトークンを置き換えて文法を機械解釈しやすくした点字楽譜ができあがるだけだと思いますが、それ卒論とか修論になりますかね。
コンピュータの世界ではまさにそれで論文を書いているのですが・・・。
例えば点字楽譜に近いものとして、動画や音声のcodec。初心者が最初に動画を再生しようとして困った時に、まっさきに「動画や音声を再生するだけだろ！」とか考えると思いますが、やっぱり最初はこれほどいっぱいcodecがあるのが不思議に思えることでしょう。これと似たようなことをしているので、動画について書かれている論文と同様の論文を書くことが出来ると思います。
点字楽譜の性質みたいな論文が書きやすいかな。何が出来て何が出来ないのかをしっかり検証してまとめるだけでも立派な論文だと思いますが。
とりあえず、本当にやる気がないみたいですね。
何を言っても無駄のような気がしてきました。
もうため息しか出ない (スコア:1)
えー、その程度の認識で今まで散々突っ込みを入れられていたのでしょうか。
それでは今のあなたに何を言っても理解してもらえないでしょうね。
そんなもん研究初期に把握してます。確かにここには書いていませんでしたが。
midiでできること、点字楽譜でできること、墨字楽譜でできることを把握して研究の入り口に立てるんです。推測でガタガタいうのはおやめください。
midi→楽譜の変換には、たとえばカエルの歌の16輪唱を1トラック1チャネルに混在させて格納したsmfを旋律別に分割できたり、ギターの名曲「禁じられた遊び」のギター一本での演奏を主旋律とその他のアルペジオに分割できたりするような解析能力が必要です。その難しさを理解していない人にコメントしても私の時間が無駄です。
＃昔、点字楽譜の自動解析やってました。