FinaleユーザコミュのMusicXML

最近Finaleユーザの投稿が少ないようですね。
MusicXMLに関する投稿はないようなのでトピックを立てました。

MusicXMLは .mus、.musx　ファイルなどFinaleネイティブのファイルとは別の
オープンなフォーマットで作られた楽譜用フォーマット（ファイル）です。
おかげで musescore

Finale などの楽譜変換や、ScoreMakerなどで楽譜認識をした結果を
Finaleに取り込むことができるようになりました。
ご利益はそれだけでなくオープンフォーマットということで、一般の人がMusicXMLファイルを取り込んで情報解析したり、音の加工をしたりすることができるようになったことです。
そこで手始めとして２つのファイルの差分を表示するツールを作ろうと思い現在奮闘中です。
そのときに得られた情報などお伝えしたいと思います。
Finaleユーザで興味がある人がいればうれしいです。

コメント(16)

最初
全て
最新の40件

[2] mixiユーザー 07月14日 11:29

●musxファイルとMusicXMLの情報量の違い
MusicXMLはFinaleの開発元のMakeMusicで開発されたのですが、情報量の違いはあります。FinaleでMusicXML出力したものを再入力すると特殊な記号などが消えたりします。つまり両者ともに共通するところもあれば、片方だけが持つ情報もあるということです。共通する部分は記譜の基本的な表現や個々のソフトに依存しない部分です。
私はバッハの特殊な装飾音記号をFinaleのアーティキュレーションツールで一生懸命つくりましたが、そういうのはMusicXMLにしたとき、すっぽり消えてしまいました。
なのでオリジナルフォーマットは常に保存しておいた方がよいです。MusicXMLで加工したときもオリジナルと加工ファイルを同時に開き、加工部分をコピーすれば情報を失わずに済みます。

[3] mixiユーザー 07月21日 21:42

●MusicXMLの構造
以下のURLにMusicXMLの最初の例が説明されてます。
https://www.w3.org/2021/06/musicxml40/tutorial/hello-world/
最初の２要素はXML定番の表現ですが、encoding="UTF-8"が重要です。Finaleを含む一般的なMusicXMLはUTF８で出来てます。UTF8はASCIIが1バイト、漢字が3バイトですが、一般的に日本語のアプリ内ではSJIS、またはUTF-16LEなので英語圏のソフトはよく文字化けを起こします。
<score-partwise>が実際の音符情報のRootになります。<score-timewise>もありますが、実際に使われているのは<score-partwise>で、これより一つ中に<measure>(小節）があり、<measure>の中に<note>（音符）があるという構造になってます。
最初の<measure>(小節）は音部記号や調、拍子が必ずあり通常の小節より複雑です。
この例ではMusicXMLの構造を説明するのが主眼ですが、MusicXMLの核心を理解するには<note>（音符）についての例を学習しないとなりません。

[4] mixiユーザー 08月02日 04:47

●Measureエレメント
https://www.w3.org/2021/06/musicxml40/tutorial/notation-basics/
上記のサンプル2行目に
<measure number="1">
という行があります。ここは第１小節を記述していて、拍子記号や調号、ｎｏｔｅ（音符や休符）情報をを含みます。この number は、楽譜表示用のユーザー定義の小節番号で必ず１から始まるわけではありません。Ｆｉｎａｌｅにも小節番号には表示用と絶対番号の2種類あって、編集/環境設定/表示　で小節番号の表示方法を選択できます。
複数の楽章をひとまとめにした楽譜だと、number="1"が複数回出現することもあります。そのため小節を指定するには絶対小節番号が必要になりますがＭｕｓｉcＸＭＬにはその情報は入ってません。
なのでファイルを読み込んだ時などに、最初から順番に絶対小節番号を付け加える作業が必要になります。
出版譜などの小節番号は弱起などは数えないなどのルールで振られていますが、出版社ごとにルールが違い、複数の出版社のパート譜でアンサンブルしたときに困ったこともあるのではないでしょうか。
第一小節目には <divisions> という4分音符あたりにいくつの分割を使用するを示す数があります。これ以降 <dulation> という音価を表す基準となるので、とても大事な数になります。

[5] mixiユーザー 08月02日 09:15

>>[4]
誤：dulation
正：duration

[6] mixiユーザー 08月02日 13:47

>>[5] 失礼しました。訂正ありがとうございます。

[7] mixiユーザー 08月08日 15:54

●noteエレメント
https://www.w3.org/2021/06/musicxml40/tutorial/notation-basics/
note エレメントは,音符や休符を表すもので、measure（小節）エレメント内に存在します。
noteの音程はstep（音名）、alter（変化記号による差分）、octave(音名のoctave位置）の組み合わせで表現されます。これは調号による#♭の影響も含まれています。なので調号をしらべなくても単独で音程がわかります。
通常の音符と同様、note エレメントは音価を表す情報（duration）はありますが、小節内のどの拍に置かれるかの情報はありません。拍位置を計算するためには、出現順にdurationを累積させます。ただ和音（chord）場合は累積させません。音符がなくても拍位置を前進させるforwardエレメントや、後退させるbackupエレメントもあります。通常声部１（voice1）から順番に並べ、voiceの交代時には先頭に戻るbackupエレメントがつかわれます。
measureエレメントには通常拍数分のnoteが格納されていますが、これを超える音符があってもFinale MusicXMLは許容しているようです。

[9] mixiユーザー 08月11日 09:49

>>[8] ドラム系の音は<unpitched>扱いで通常の音と扱いが違います。そのあたりがうまくいってないのかも。私はデジタルパーフォーマ持ってないのですが、ドラム譜のPDFとmusicXMLデータがあれば、原因を探せると思いますよ。

[10] mixiユーザー 08月13日 04:06

●musicxmlライブラリ　libmusicxml
libmusicxmlはC++で作られたmusicXMLのライブラリです。
https://github.com/grame-cncm/libmusicxml
私も最初はこれに手を付けて、musicXMLの感触を得ました。STLに影響された作りで見た目は美しいソースコードです。作者はlilypond系のソフトに興味があったようで、musicXMLからの変換サンプルがついてます。
MIDIへの変換サンプルもありますが、現実のSMFをつくるのではなく、「MIDIのイベントを出力するので実際にSMFを作りたければ自分で改造してね。」というサンプルです。ただMIDIはmusicXMLみたいな繰り返し処理はないので実際の演奏順にunrollする手法が書かれて参考になります。
情報収集するのにvisitorパターンというものを使っています。visitorパターンというのは自分で情報を探すのではなくイベント（コールバック）に反応して状態を変えていく方法です。まあ、WindowsGUIのプログラムみたいなものです。
私はこれを visual studio community2022 でビルドして動かしてみました。
でもFinaleの出力を読ませてみると、straight、swing エレメントに対応してなくて、ソースコードの改造が必要でした。他にも　smartpointer.h 118行目にバグがあり、visual studio 2022では動作エラー（プログラムが終わらなくなる）を起こします。コンパイラによっては動作する場合もあるバグなので、他のコンパイラでは動作していたのでしょう。
あとは、日本語をつかった場合、文字が化けます。なんとか動くようにしましたが、treeiteratorというXMLの木をアクセスする方法に限界を感じ、結局現在は別のやりかたに取り組んでます。

[11] mixiユーザー 08月18日 11:29

●自作musicXMLライブラリ
libmusicXMLライブラリが満足できないとなると、より一般的なXMLパーサライブラリをつかうことになります。多くのXMLパーサは木構造まで生成してくれますが、今回は扱いなれた自作の木構造ライブラリを使いたいのでXMLのパーサだけで木構造は自分でつくるタイプのlibExpatを採用しました。自作の木構造ライブラリでUNICODE対応されているので日本語に対しても苦労することはありません。
MusicXMLの木構造を全部読み込んだ後、Part,Measure,Noteのクラスで解析します。
音符の比較は2つのMusicXMLに対して、Measure単位で行い、内部のNoteオブジェクトを拍や音の高さに並べ替えた後に行います。比較結果はCSVファイルに出力しエクセルで確認します。次回はその例を紹介します。

[12] mixiユーザー 08月24日 21:29

●2つのMusicXMLファイルの差分例
musescore にある Mozart Violin sonata No21のスコアを２種類取得し
今回作成した差分検出ソフトでピアノパートの差分を検出してみました。差分が見つかったのは７２か所でした。

１７８小節目の例ではエクセルには以下のように書かれています。
項目１：小節番号、項目2：FILE１の音符情報、項目2：FILE2の音符情報のように記述されます。
178, beat2+18/24 Voice1 F#5(66.0) duration6, beat2+54/72 Voice1 G5(67.0)duration18
beat2+18/24 は2＋3/4拍めを意味します。Voiceは声部、F#5は音名、66.0はMIDInote番号、durationは音価です。画像の左側をみると2＋3/4拍めの音が2度違っているのがわかります。

298小節の例では、２つの音が検出されて
298,beat3+0/24 Voice1 B5(71.0)duration24 chord, beat3+0/72 Voice1 B5(71.0)duration72 -tie start
298,beat3+0/24 Voice1 B4(59.0)duration24, 　　　beat3+0/72 Voice2 B4(59.0)duration72 -tie start
タイの違いが検出されています。ソフトの仕様上和音と声部の差は無視されています。
目ではなかなかチェックするのは大変ですが、ソフトならあっという間に検出されます。

[13] mixiユーザー 09月01日 20:58

●Finaleで2つのMusicXMLファイルの差分表示

前回紹介した差分では、エクセルファイルに文字で出力されるものでした。
そのため、実際の楽譜ではどこが違うのか文字情報から探す必要があります。
今回の改良版では、MusicXMLの差分がある場所にSMuFLフォントで作ったアーティキュレーションでマーキングしてみました。
SMuFLフォントはUNICODEのユーザページに楽譜用のフォントを割り当てたものです。SMuFLフォントは世界共通のフォントなので,どのソフトメーカでも同じフォントを指定することができます。ただしまだSMuFLフォント対応は進行中ですべてのソフトで扱えるわけではありません。
画像では相違点のある場所に　♡＋↓　のような記号を振ってみました。（現在のDoricoではこの記号を読み込んでくれませんでした。）
かなり分かりやすくなっています。エクセル出力と併せて使えばなお効果的です。

[14] mixiユーザー 10月02日 11:11

MusicXMLファイルの差分検出については、ほぼ目的通りに動作してるので開発は一旦終了としました。しかし、差分検出開発中にFinale開発終了のアナウンスがあって困惑しています。
Doricoへの移行のためにFinaleのMusicXMLファイルを読ませると、無視される記号や正しい解釈ができていないのもたくさんあります。例をあげるとcresc. や dim. は強弱記号ではなく単なるテキストとして解釈されます。そのため、FinaleのMusicXMLをdorico向けに直すツールを作ろうかと考えていますが、doricoのMusicXMLに対する挙動を調べるのに手間がかかってます。ある程度調査がまとまったらまたご報告したいと思います。

[15] mixiユーザー 10月19日 10:12

上記の件ヤマハに問い合わせてみました。

お問い合わせ内容：
Finaleからの移行者です。Finaleで作った楽譜をMusicXMLで読ませると、cresc. や dim. が強弱記号でなくテキストアイテムとして解釈されます。これを一括で強弱記号に変更するにはどうしたらいいでしょうか？

回答：
お問い合わせの件、テキストアイテムを一括で強弱記号に変更する方法はございません。
現在、MusicXMLファイルの読み込み精度を調整中でございます。
恐れ入りますが、しばらくお待ちいただきますよう、お願い申し上げます。

困ったもんです。スクリプト作って一括変換する方法を期待してたんですが、データの移行はすこし待ったほうがいいかもしれませんね。

[16] mixiユーザー 10月25日 11:34

MusicXML小節属性チェッカー
使用する音楽ソフトが増えるとソフト間のデータ移行にMusicXMLが活躍します。
今回、データ移行時の問題を事前に回避するためのMusicXML小節属性チェッカーを作成しました。
一番多いトラブルは既定の拍以上に音符が存在する場合です。これは本来連符なのに連符処理がなされていないために起こることが多いです。
Doricoの場合は読み込み時に拍がずれて完全に破綻します。Finaleの場合はMusicXML読み込みは成功しますが、その後のデータコピーで拍ずれすることがあります。既定の拍より少ない場合は、ほとんどのソフトで弱起として処理されます。本ツールはどちらの場合も該当小節を表示します。
ほかにもパート間で拍子記号や実音での調が違う場合もチェックしてくれます。SCOREMAKERはパート間で実音での調が違ってもなんの警告もありません。
添付画像は、1小節目が弱起、２３小節目が連符処理ミス、２４小節目が調号ミスをしたMusicXMLのチェック結果です。
エラーがあった場合は、MusicXMLを生成したソフト側で修正するのが効率的です。

ログインすると、残り2件のコメントが見れるよ