バグ情報 の最近のブログ記事

多難なFinale 2014日本語版の船出
　去年(2013年)の11月、本家アメリカで２年ぶりのバージョンアップ版2014がリリースされ、その日本語版は３ヶ月後の今年(2014年)２月にリリースされた。これまでは日本語版が発売されるまでには、ローカライズ作業のために半年近いタイムラグが発生していたことを考えると、輸入代理店のMI7も今回はよく健闘したと言えよう。
　ところが、その日本語版2014がリリースされるやいなや、ネット上のあちこちから早速購入したユーザーからの悲鳴が上がり始める。「旧バージョンのファイルが開かない」といったものから、「保存したはずファイルが消滅した！」という悲痛な叫びまで......。実際、明日レコーディングというスコアが消滅してしまい、レコーディングに穴を空けてしまったという話や、ほぼ書き終えていた卒業作品をリリースされたばかりの2014を使って仕上げていたところ、ファイルが突然開けなくなり、作品提出期限に間に合わず留年を余儀なくされたという音大作曲科学生の悲劇もあった。
　ユーザーがこうした不利益を被った場合、ソフトメーカーに責任を問いたくなるのはやまやまだが、大抵のソフトにはインストール時に表示される約款に「ソフトのバグによるユーザーの損害についてメーカーは一切の責を負わない」旨が明記されていて、Finaleも例外ではない。それに同意してインストールを行っている以上、法的にはメーカーに責任は問えないことになっているのだ。一見理不尽に思えるが、なぜそういうことになっているかについては、「ソフトウェア、製造物責任法(PL法)」などをキーワードに検索していただきたい。
　とはいえ、「ファイルが開かない」、「保存したファイルが消滅する」などというバグは、ソフトウェアとしては商品価値を失うレベルの致命的な欠陥であり、これが一般製品ならリコール対象になっても不思議はない。いくらバグについてはメーカーに法的に責任がないとはいえ、このような欠陥ソフトを販売することには道義的な責任が生じるだろうし、結果的にメーカー自身が評判を落とすことになる。

　MI7も４月になってようやくこの問題に対する暫定的な対応策を自身のサイトのFAQで発表するに至ったが、根本的な解決には、プログラムを開発している本家MakeMusic社(以下MM)からのアップデートを待つよりなかった。2014は他にも多くの重大なバグを抱えていたようで、そうこうしているうちに、MMからは2014b(英語版)のアップデータのアナウンスがあり、それは6月3日にリリースされた。
　2014bには前バージョンのアップデート版2012cのような目新しい新機能はなく、アップデート内容はバグフィックスがほとんどだったが、その2014bに対しても早速ユーザーから問題点が次々に指摘され、約１ヶ月後の7月7日、矢継ぎ早に2014cのアップデータをリリースした。一方、国内代理店のMI7は、当初日本語版のアップデータについては2014bを７月中にリリースするとアナウンスしていたが、それに先んじて本家で2014cが出たため、結局2014bを飛ばした2014cのアップデータという形で７月末ギリギリでのリリースとなった。
　結果論だが、ここまで重篤な問題があったことを考えれば、日本語版2014はもう少しじっくりと動作の検証をした上で、問題をクリアできた時点でリリースすべきだったかも知れない。リリースを急いだことがかえって仇となってしまった格好だ。

　さて、「保存したファイルが消滅する」というトラブルは本家のフォーラムでも報告されており、日本語版固有の問題というわけではなかったのだが、「ファイルが開かない」というトラブルは、文字発想記号に日本語フォントを使っている場合に発生することが判明しており、こちらは日本語版固有のトラブルである。Finaleが日本語のフォント名を正しく認識できないことが原因で、この問題そのものは以前のバージョンから存在していた。

　この日本語フォントの誤認識によってファイルが開かなくなるトラブルについては、当初MMから「あまりにプログラムの根幹部分にかかわる問題なので、2014のアップデートでは対応できない」旨の回答があったようだが(MI7の当該FAQの下部参照)、MI7は５月に主宰したFinaleユーザーの集いの場にMM社の営業担当者を招き、ユーザーの面前でこの問題の2014のアップデートでの解決を確約させたという。営業担当者としては大勢のユーザーの面前で自社製品のネガティブな発言はしにくいわけで、この演出がMI7とMMとの馴れ合いによるものかどうかは第三者の私には知るよしもないが、MI7もなかなか知謀を巡らせたものである。

未解決の日本語版の問題点
　というわけで、日本語フォントの誤認識の問題については晴れて2014cで解決が図られたわけだが、今回のアップデートで日本語処理に関する問題が一挙に解決されたわけではない。少なくともMac版2014cでは、今なお以下のような問題を抱えている(Windows版については検証できないので、以下の問題点は発生しないかも知れないし、全く別の問題が発生している可能性もある)。

①セットアップ・ウィザード１ページ目において、日本語表記が含まれる楽器編成を削除すると大抵クラッシュする(英数文字のみの編成名だと問題ない)。クラッシュしないケースでも、その際に出るアラートの楽器編成名が文字化けする。

②「五線ツール」、「ステップ入力ツール」、「高速ステップ入力ツール」を選択した状態では、ことえりやATOKなどのインプットメソッドが機能しない。すなわち、この３つのツールを選択している間は、「ファイル情報」でのタイトルなどの入力、文字列の検索、各種ファイルの保存などの際に日本語が一切タイプできない。いずれも他のツールを選択しなおせば解決するが、「五線ツール」を選択しないと操作できない「楽譜スタイル名」や「グループ名」の入力には対応できない。
　いずれのケースもコピー＆ぺーストによる日本語入力は可能なので、これらに日本語を使いたい場合は、あらかじめ別の場所(外部テキストエディタでも可)でタイプしたものをコピー＆ぺーストすることで対応するしかない。これはFinale 2014cで新たに発生した問題。

③発想記号のカテゴリ用表示セットのセット名に日本語をタイプしても、最初の２〜３文字しか表示されず、それ以上の文字をタイプするとクラッシュする。

④発想記号の「五線別に割り付け」、反復記号の「五線別表示リスト」に日本語の名称を付けると文字化けしてしまう。2011以前にここに日本語名を付けたファイルを開いた場合も文字化けを起こすので要注意だ。

⑤Mac版では、オーディオファイルの書き出し時に、ファイル名や保存場所のパス名に日本語が含まれているとファイルが生成されない。この問題についてはMI7のFAQにも書かれている。

　①、③、④は2012から発生しだしたバグであり、このバージョンからは、おそらく日本語にローカライズすると文字化けを起こしてしまうためか、英語のまま表示されるダイアログやアラートが散見されるようになった。2012といえばユニコードに対応したバージョンだが、それに伴うプログラムの変更が行われた結果、これらの新たな問題が発生したと考えられる。

　じつは、2012からは「組段の間隔調整」というプラグインがバンドルされているのだが、Mac版についてはこの文字化けの問題が未解決らしく、それから２年以上も経った2014cにおいてもなおバンドルされていない。一応Mac版についてもマニュアルは準備されているが、ダイアログは英語のままであり、マニュアルのプラグイン・メニュー項目からも外されている状態だ。

なぜ日本語に関するトラブルはなくならないのか？
　Finaleの日本語に関するトラブルは昨日今日に始まったことではない。なぜ、日本語に関するトラブルは根絶できないのか？

　Finaleほどの多機能なソフトになると、機能ごとにプログラマーが開発を分担するのが一般的である。そうした場合、各プログラマーが勝手にプログラムを作ると全体の整合性がとれなくなるので、ソフト開発全体を俯瞰し統括するマネージメントが必要となってくる。しかし、Finaleを操作していると、そのマネージメントが適切に行われているのか疑問視される箇所がいくつも散見される。
　その一例がマクロの登録方法だ。発想記号では、2009の改訂時に記号の選択画面を表示させたまま続けて別のマクロキーを登録できるように改良された。ならば、アーティキュレーションなど他のツールでのマクロの登録も同様に改良されているかと思いきや、こちらは新たなマクロキーを登録するたびに一旦ダイアログを閉じて楽譜に戻らなければならないという従来のインターフェイスのままだ。同じような編集に対し、ツールによって異なる操作を求められるこのようなインターフェイスはユーザーを混乱させ、習熟を妨げるだけである。
　同様のことが日本語処理についても言える。上記で指摘した③と④は、ユーザーが登録した名称がリストに現れるというものだが、「カテゴリ用表示セット」では入力欄、リスト表示とも日本語で表示されるものの、入力時にクラッシュを引き起こし、「五線別に割り付け」ではクラッシュこそ起きないものの、入力した日本語は入力欄、リスト表示とも文字化けを起こす。「五線別表示リスト」では入力欄の文字化けは起こらないが、リスト表示は文字化けを起こすといったように挙動が三者三様である。ちなみに、同様の処理を行う発想記号の「カテゴリ名」や「付箋の編集」では日本語は問題なく表示されている。

　こういった一貫性のなさは、各プログラマーが自分の担当部分のみに恣意的なプログラミングを行っている証左である。このような問題は、「共通した処理は共通したプログラムを組む」という基本を徹底させておけば防げることであり、これが見通しのよいプログラムを作る鉄則なのだが、それをおろそかにすると、ひとたび問題が起こった場合に、その原因の究明が困難になり、その場しのぎの対応をした結果、さらなる問題が発生するという悪循環に陥ることになる。
　ご存じとは思うが、Finaleの日本語版のローカライズは日本語版の登場以来ずっと国内代理店が行っており、本家MMは直接ローカライズにはタッチしていない。したがって、本家MMは日本語環境下での動作チェックを積極的に行っているわけではなく、日本語版固有のトラブルが起こる度に、国内代理店からの報告を受けてプログラムの修正に応じているに過ぎない。MMはこれまでさんざん日本語に関するトラブルの報告を受けてきたはずだが、今もなおそのトラブルが一向に根絶できないことを鑑みるに、MMは日本語処理に関するトラブルについてはその場しのぎの対応しかせず、そこにプログラムの根本的な見直しを行おうという姿勢は全く感じられない。上記MI7のFAQにある、発想記号に日本語を使った際のトラブルに対する当初のMMの回答がまさにそれを物語っている。

　日本語に関するトラブルが根絶できないもうひとつの理由は、日本語版ユーザーが圧倒的なマイノリティであるということにもありそうだ。
　公式な数値が出ているわけではないが、以前、輸入代理店の人から聞いた話では、Finaleの世界全体のシェアに対する日本語版ユーザーの割合は１割にも満たないという。私は２割くらいはいるのではと思っていたので、この数字は正直意外だった。
　Finaleは各国語にローカライズされているが、漢字を含む２バイト圏の日本語版以外はすべて英数文字からなる１バイト圏のヨーロッパ言語版だ。例えば、もし我々日本人が作ったソフトに対して、文字を右から左に向かって書くアラビア語圏のユーザーから「文字がちゃんと打てない」というクレームが届いたら、「そんな環境のことなんか知らないよ」となるだろう。MMの開発者からすれば、日本語に関するクレームに対する感覚はこれに似たものではないだろうか。
　今回の2014cのアップデートでの改善項目は、Windows版が約60項目、Mac版については約100項目に及んでいる。その項目の多さには驚かされるが、その筋の人の話によれば、Finaleクラスの規模のソフトでは、つねにその10倍近い未解決のバグや潜在的なバグを抱えているという。次バージョンの開発や膨大な数のバグ修正に追われる中で、１割にも満たないマイノリティユーザーのためだけに、根本的なプログラム修正を行っている余裕などないというのが正直なところかも知れない。

　先日、MM社がスポーツトレーニングのサポートソフトを開発しているPeaksware社の傘下に入ったという発表があった。なんでも、MM社のもうひとつの主力製品である伴奏アシスタントソフト、SmartMusicとの連形を模索するという。このことが今後のFinaleの開発にどう影響するのかは未知数だが、我々としては、より良い開発環境の構築に結びついてくれることをただただ願うばかりである。

※ 13/6/22に「問題点３」を追記

　「レガシー」と聞くと、真っ先に車のブランド名を思い浮かべる方も多いかもしれない(正式なブランド表記は「レガシィ」)。「レガシー」とは「過去の遺産」の意味だが、ことITの世界では「レガシー・デバイス」や「レガシー・システム」といったように、もっぱら「時代遅れなもの」というネガティブな意味合いで使われる言葉である。80年代後半に産声を上げたFinaleには、その当時の設計思想に基づく「レガシー」な部分がまだあちこちに残っている。今回はそんな中の１つである「弱起」についてスポットを当ててみることにする。

　2000年代初頭までのFinaleの弱起は、「バグの巣窟」と言われるほど多くの問題を抱えていた。パート譜に書き出すと弱起小節内の連符がご破算されて音符が消滅するとか、「Allegro」等の発想記号が１拍目より左に移動できず、拍子記号に揃えることができない等々......。当時のユーザーの間では「Finaleの弱起機能は使うな」が共通認識だった。その後、そうしたバグは少しずつ修正されて現在に至っているのだが、弱起そのものの根本的な設計が脆弱なため、今もなおいくつかの問題を残している。

問題点１：曲頭にリピートで戻ると、余計なカウントが入ってしまう
　Finaleの弱起は特殊な構造になっている。「ライブコピー・ツール」を選択すると、弱起小節に見慣れない図形が表示されていることに気付くだろう。これは「空白時間の挿入」が行われている小節を示すアイコンである。では、その「空白時間の挿入」とは何ぞや？

　「空白時間の挿入」機能とは、例えば４拍子の曲で３拍の不完全小節を作りたい場合、小節の頭に１拍の「空白時間」を挿入し、表記上はその部分を詰めることで見かけ上の不完全小節を表現するというしくみである(詳しくはマニュアルをご覧いただきたい)。初期のFinaleでは、弱起を含む不完全小節は「空白時間の挿入」を用いて表記するのが標準的な方法だった。ただ、読んで字のごとく、プレイバックを行うとまさに「空白時間」、すなわち空カウントが挿入され、記譜通りのプレイバックにはならない。次の譜例のように曲頭に戻るリピートを作成した場合、曲頭に戻った際に余計なカウントが挿入されてしまう。

問題点２：記譜上の誤り
　2011以前のFinaleでは、弱起小節のデフォルトの休符は全休符のままだった。これが原因で、オーケストラのリハーサル現場が混乱した光景を私は幾度も見ている(もちろん、私自身はそんなヘマをしたことはないが)。2011になってやっとデフォルトの休符は正しい音価で表示されるようになったのだが、これまで全休符で表示されていたものをそれぞれの音価の休符に置き換えただけで、位置は依然小節にセンタリングして配置されている。弱起部分が短い場合は気付きにくいが、下の譜例のように弱起部分にスペースを必要とする場合には、その奇妙な配置にすぐに気が付くだろう。これは記譜としては明らかな誤りである。
　この配置を正しくするためには、デフォルトの休符が表示されている部分に改めて休符を入力するという、じつにナンセンスな作業をする必要がある。

　楽典では弱拍とそれに続く強拍の休符をまとめてはならないというルールがある。しかし、Finaleの弱起のデフォルトの休符は１つの休符でしか表現できないため、本来まとめてはならない休符がまとまった状態で表示される。以下の譜例の弱起部分の休符の表記はいずれも楽典的には誤りである。これを正しい表記にするには、やはり実際に休符を入力しなければならない。

　別の問題もある。
　セットアップ・ウィザードから新規作成する場合、セットアップ・ウィザード上では１つの音符で表現可能な音価の弱起しか扱えないため、それ以外の音価、例えば下記の譜例のような弱起を表現できない。

　なお、Finaleの名誉のために断っておくが、上記のような弱起はあくまでセットアップ・ウィザードでは設定できないのであって、書類メニューの「弱起の設定」を使えば不可能ではない。ここではパレットによる音価の指定の他に、音価を直接数値で指定することもでき、上記の譜例では弱起は８分音符５つ分なので、８分音符の長さである512EDU×5＝2560EDUを直接指定すればよいことになる。惜しむらくは、音価を表すEDUという単位はあまり馴染みがなく、もっと直感的な指定ができるようにして欲しいところではあるが。

　ところが、Finaleの弱起小節のデフォルトの休符は１つの休符でしか表現できないという設計上、８分音符５つ分という音価の休符を表現することはできず、代わりに近似値の音価の休符が表示される。この状態のままパート譜を作ってしまうと演奏者の混乱は必至なので要注意だ。結局この場合も正しい休符をユーザーの責任において入力しなければならない。

　弱起小節に相応の休符が自動的に表示されるようになったことは、つねに全休符で表示されていた2011以前よりは一歩前進と言えるかもしれないが、実際に休符を入力しなければ正しい表記にならないという点では2011以前と何ら変わりがない。そもそも弱起小節の休符が１つの休符でしか表せないという設計自体に無理がある。早急な改善を望みたいところである。
　なぜこんな事を口やかましく言うかというと、2011の弱起の改訂以降、デフォルトの休符のまま出版されている楽譜を目にすることが多くなったからである。この原因はFinaleの不完全な仕様にあることは論を俟たないが、少なくとも出版社たるもの、プロとして正しい楽譜表記についての見識を持つべきである。

問題点３：「スラッシュ表記」でのバグ　※ 13/6/22に追記
　10年以上前にCoda社(MakeMusicの当時の社名)に送ったバグや要望をまとめた報告書を改めて読み直していたところ、弱起部分で「スラッシュ表記」を行うと、本来の拍子(４拍子なら４拍分)のスラッシュが表示されてしまうという記述を見つけた。この件について改めてFinale 2012で検証してみたところ、余計なスラッシュこそ表示されなくなっているものの、まだ問題を残していることが分かった。以下にその問題点を示してみる。

　ドラムパートの弱起部分をスラッシュ表記にするために「五線ツール」で小節を選択する。弱起小節全体を選択しているはずだが、すでに選択域がおかしい。

　楽譜スタイルの「スラッシュ表記」を適用したところ。後半に片寄って表示されている。スペーシングをかけ直しても変化なし。

　弱起小節の他のパートに音符を入力すると、スペーシングは正常に戻った(厳密には完全ではないのだが)。

　......と思いきや、ドラムパートをパート譜表示にしてみると、依然、片寄ったまま。

　音符(休符)を入力すればスペーシングは直りそうなので、とりあえず休符を入力してみる。

　楽譜スタイルの「スラッシュ表記」を適用すると、今度は不必要にスペーシングが広がり、しかも、休符のゴーストまで現れる。このゴースト、スクロール表示では最上段パートの拍子記号の直後に、ページ表示ではページの下端に現れる。弱起小節に入力した音符/休符がゴーストとして現れるようだが、元の音符/休符を非表示にしてもゴーストは消えない。

そもそも現行の弱起設定は必要か？
　弱起は曲頭で生じるとは限らない。弱起で始まる曲は、曲中の段落部分や繰り返し部分も弱起表記になることが多い。また、テーマが弱起で開始される変奏曲は、基本的に各変奏も弱起で開始される。さらには、最近のFinaleでは、ファイルの統合機能が設けられたり、曲の途中でも楽器名をフルネーム表示できるようになるなど、複数の曲を１ファイルに入れることを想定した設計になってきている。すなわち、弱起は１つのファイル中のあらゆる部分に出現する可能性がある。

　Finaleのマニュアルの「不完全小節」の項目を見ると、曲頭以外の弱起を含む不完全小節は、拍子記号設定の「表示専用に別の拍子記号を使う」方式で作成せよと書かれている。また、プラグインを使って小節の途中に反復記号を挿入した際などに生じる不完全小節にも、こちらの方式が用いられている。そもそも、Finaleの弱起がバグだらけだった頃は、冒頭の弱起についてもこちらの方式で表現することがユーザーの間でも推奨されていたくらいである。

　現在のFinaleで「空白時間の挿入」機能を必要とするシチュエーションはどこにあるだろうか？　すべての不完全小節を「表示専用に別の拍子記号を使う」方式で表現できる現在、あえて上記のような問題が生じる「空白時間の挿入」機能を冒頭の弱起のみに利用する必然性はどこにも見当たらない。
　開発側は「古いファイルとの互換性を保つために必要」と主張するかもしれない。それならいっそのこと「空白時間の挿入」機能なんぞ廃止して、その機能で書かれている小節については、「表示専用に別の拍子記号を使う」方式に自動的にコンバートしてしまってもかまわないのではないか？　セットアップ・ウィザードや書類メニューにある「弱起の設定」も「表示専用に別の拍子記号を使う」方式で表現すればすむ話である。さらに言えば、「表示専用に別の拍子記号を使う」という設定も決して分かりやすいインターフェイスではないので、書類メニューの「弱起の設定」を曲頭の弱起に限定せず、曲中のあらゆる不完全小節に利用できるようにしてもよいのではないか。

　そろそろ、こういったレガシーな機能をキッパリと切り捨てる勇気も必要ではないかと思う。

　普段我々が使っているソフトウェアのアップデータが公開される際に付属するバグフィックス項目を読むと、普段使わない機能なので気付かない部分にも多くのバグがあったことを改めて知らされることがある。大規模なソフトになればなるほどそういったバグは多岐に及び、ことFinaleのバグに関してはいろいろ情報を集め把握しているつもりの私でさえも、「こんなバグがあったのか」と驚かされることが多い。
　Finaleの本家のフォーラムにはユーザーからのバグ報告や機能改善の要望が多く寄せられているが、「我々もその問題はすでに把握しているが、先に解決しなければならない問題が他にたくさんあるんだ」と開発スタッフに釈明され、先送りされている問題点も多い。
　今回取り上げるのは、そんなバグの１つである。

　音符が転調部分を挟んでタイでつながっているというシーンはよくあることだ。また、転調は音楽の段落である場合が多いので、転調部分で改行というのは楽譜のレイアウトの上では極めて自然の成り行きである。ところが、Finaleには「移調楽器」、「転調部分を挟んだタイ」、「転調が改行部分で行われている」の３つの条件が重なった時、段頭のタイが消えてしまうというバグがある。不思議なのは、つねに消えるわけではなく、消えるケースと消えないケースがあったりするのだから少々厄介だ。

　さらに不思議なのは、和音の構成やポジションによっても、タイがかかったりかからなかったりするのだ。

　転調部分が段の途中であれば、タイは見た目ではつながっているのだが、「フレーム編集」でチェックしてみれば、データ上はつながっていないことが確認できる。実際にプレイバックしてみれば、そこで音が打ち直されることが分かる。

　どの条件の時にタイが消えるのか法則でも見いだしてやろうかとも思ったが、仮に分かったところでこちらでそのバグを直せるわけでもなし、その規則性を得意満面になって開発元に報告したところで、「そんなことは分かっている」と言われるのがオチなので、これ以上の詮索はあきらめた(「酸っぱい葡萄」の法則)。この法則性についてお気付きの方、あるいは何か情報をお持ちの方がいらっしゃれば、ぜひごお知らせいただきたいところである。

　じつはこの消滅したタイ、一旦書類メニューから「移調楽器を実音で表示」モードにし、その小節に対して高速ステップ入力編集枠を表示させて抜ける操作を行えば復活し、その状態で「移調楽器を実音で表示」モードを解除すれば表示が保持される。しかし、ひとたび移調表記の状態で高速ステップ入力編集枠を表示させた瞬間に再びタイは消えてしまう。
　上記の対処法では、うっかり編集枠を表示させてしまい、知らぬ間にタイが消えてしまうという事故を起こしかねない。これは楽譜の管理という観点からは決して好ましい状態ではないので、もっと堅実な処置を行っておきたいものである。当座のところ、消えてしまったタイについては、スラーを加工して貼り付けて対応するくらいしかなさそうだ。コツとしては、変形図形メニューから「小節に割り付け」を選択し、Shiftキーを押しながらドラッグすることで簡単に水平なスラーを描くことができる。

　注意しなければならないのはリンクしたパート譜との整合性である。スコア、パート譜とも転調部分が改行部分であれば問題ないが、どちらかが段の途中になった場合、貼り付けたスラーはもはやゴミでしかない。この場合はスラーのリンクを一旦外し、不必要なほうのスラーをコンテクストメニューから「表示」のチェックを外して隠しておけばよい。

　このバグ、じつに90年代のバージョンからずっと引き継がれてきているもので、移調楽器を扱うユーザーの間ではそれなりに認知されている。このバグについては相当以前より改善の要求があったはずだが、10年以上解決されないということは、案外根が深い問題なのかもしれない。

　私を含め、楽譜の版下製作に携わっている者は他人の作成したFinaleデータを編集する機会が非常に多い。Finaleによる版下製作はDTPとの連携の良さからほぼ100% Macintosh上で行われているのが現状だが、世の中全体から見ればFinaleユーザーはWindowsユーザーのほうがはるかに多く、版下製作の現場でも必然的に彼らのデータも扱うことになる。
　Finaleでは同じバージョンのファイルであれば、OS間の互換性は完全に保たれているはずなのだが、フォントなどのシステムに依存する部分に表現の差異があり、とりわけ日本語環境下でのOS間のファイル交換時には、これまでもいろいろなトラブルが発生していた。

　最近、Windows版Finaleで作成されたファイルをFinale 2011で開き、発想記号を貼り付けようと楽譜上をクリックした瞬間にFinaleが強制終了してしまうというトラブルをしばしば耳にすることがあり、実際、私も体験した。
　これについていろいろ原因を調べてみたところ、発想記号カテゴリに日本語名の新たなカテゴリが追加されている場合に発生しやすいことが判明した。どうやら、このカテゴリ名をコンバートした際に文字コード変換ミスが発生してしまうようで、発想記号カテゴリ名のリストが表示されるダイアログであれば、「発想記号の選択」の他にも「発想記号カテゴリの設計」ダイアログを開こうとした場合にも強制終了してしまう。ためしに、変換ミスが発生したカテゴリの発想記号をコンテクストメニューから開いてみると、カテゴリ名が文字化けしていることが分かる。

　この症状が発生した場合は、「プログラム・オプション - 開く」内の、「テキストのコンバート：他のOSからのファイルの欧文特殊文字を自動的にコンバート」のチェックを外そう。この設定でファイルを開き直せば強制終了は発生しなくなる。

　このオプションは、Windows版で作成されたファイルのテキストに含まれる「ö」や「ù」等のアクセント付き文字を正しくコンバートするために設けられたものだが、一方で発想記号の注釈や楽譜スタイル名が文字化けしてしまうという副作用も発生する(これはFinale 2012では解消されている)。元のファイルにドイツ語やフランス語などのテキストが大量に含まれているというケースでもなければ、ここのオプションは基本的にオフにしておいたほうが良さそうだ。

　今回の記事はMac版2011のみに発生するトラブルということで、すでに2012がリリースされて半年近く経つ現時点の記事としては少々旬を外している感もあるのだが、楽譜版下製作の現場では未だに2011が多く使われており、じつは先日もネット上でこのトラブルが話題になったくらいである。イーフロンティアの旧FAQやMI7のFAQにもこのトラブルの情報は上がっていないようなので、この記事が同じトラブルに遭遇したユーザーの手助けになれば幸いである。