この文書は“BMS extensions proposed by Sonorous”を非公式に日本語に翻訳したものです。この翻訳の正確さは保証されません。この翻訳は二次著作物であり、原著作権は原著作物に帰属するものです。
Kang Seonghoon, 2013-11-13
これはBMSに可能な拡張に関する覚え書きです。Sonorous（現在開発中のBMSプレイヤーですが、常に一方的に遅れる可能性があります）において、著者はこれらの拡張のほとんどを実装するつもりです。フィードバックや提案を歓迎します。連絡先はhttps://mearie.org/about/contactを参照してください。
BMSフォーマットのための専門用語は、AngolmoisのINTERNALS.mdに基づいています: https://github.com/lifthrasiir/angolmois/blob/master/INTERNALS.md#glossary
「しなければならない（してはならない）」「するべきである（するべきでない）」を含む、要件定義のための専門用語は、RFC 2119から借用されています: https://tools.ietf.org/html/rfc2119
追伸。さて、私はこれは不要だと思ったけれど、言及しておくべきでした: この文書はコメントの要請であり、そのようにみなすべきです。（そしてこれはRFCとイコールではなく、単にインターネット標準に対する類義語です。）特定の提案が、ナンセンス、使いづらい、実装が困難と思われたら、この文書を公開する主目的のとおり、ご自由に発言してください。ご検討いただき、ありがとうございます。
#nnn7x-8x）#TITLEyy, #BMPxxyy etc.）#CANVAS）#LANES）各提案は次の状態のひとつを持ちます:
その問題は認識されますが、提案されていません。
提案の草案バージョンは存在しますが、更なる綿密さが必要です。ときには提案自身が撤回されるかもしれません。
容易に実装可能な提案のバージョンが存在します。この段階における提案は、実装者のフィードバックを除いて変更されません。
Sonorousは特にこの提案を実装します。コマンドはベンダー接頭辞#SNRS:の使用が要求されるかもしれません。
少なくとも3つの別個の実装が存在します。
状態: 2013-11-13時点で実装済
BMSが日本から発信されている一方で、今日では多くのBMSファイルが日本国外で作られ、非ラテン文字を使用するうえで（いくつかの日本の文字さえ）多大な苦労を伴うようになっています。この提案は間違いなくBMS界で最も求められる標準です。
次のいずれかの条件が満たされたとき、BMSファイルはUTF-8モードで解析されます:
EF BB BF、つまりUTF-8 BOM（U+FEFF）で始まる。もしくは、そうでなければ実装は、BMSファイルの文字エンコーディングを検知するために、不特定の手順を用いても構いません。
インデントコマンド（先行する1個以上の空白類文字と、それらに後続する番号記号#）をサポートする実装は、U+FEFFも空白類文字としてサポートすることが要求されます。この勧告を除き、実装は主にASCIIのみのフォーマットとしてBMSファイルを扱い続けることができます。引数の区切り文字として全種類のUnicode空白類文字をサポートする必要はありません。
この提案におけるUTF-8は、RFC 3629にて指定された文字エンコーディングを参照します。この提案は、さらなる精巧なUnicode標準（たとえばUnicode正規化アルゴリズム）を実装することを要求しません。
Readerは、バイト列EF BB BFで始まるBMSファイルを、UTF-8モードで解析しなければなりません。
Readerは、UTF-8モードにおける、妥当なUTF-8の文字列および妥当でない7ビットASCIIの文字列のどちらが最初に来ようとも、BMSファイルの最初の行（最初の0Aバイトまで）もしくは先頭の1024バイトを解析しなければなりません。
UTF-8モードにおいて、コマンド（#）の前に先行する特定の種類の文字群をReaderが無視する場合、無視される文字群にU+FEFFが含まれるべきです。
UTF-8モードにおいて、Readerは妥当でないバイト列をU+FFFD “REPLACEMENT CHARACTER”として代替するべきです。置換文字の数は指定されませんが、少なくとも1であるべきです。
Writerは、最初の行（最初の0Aバイトが現れる前の1024バイト以内）を、バイト列EF BB BFを含んでいる、コマンドではない妥当なUTF-8の文字列として開始するべきです。Writerは、1024バイトを超過する最初の行を使用するべきではありません。
Writerは、妥当でないUTF-8のバイト列を、いかなる場所にも書くべきではありません。
（UTF-8モードの発火用に使用された）最初の行、および解析されない文字列引数を持つコマンドを除き、Writerは非ASCIIの文字列を使用するべきではありません。特に、たとえば#WAVxxや#BMPxxなどのパス引数を持つコマンドにおいて、非ASCIIの文字列を使用するべきではありません。
あらゆる場合にUTF-8を強制するのが最善ですが、BMSフォーマットの深い資産がこの選択を禁止します。そこで私たちは、旧来の文字エンコーディングのBMSファイルから区別することを念頭に、UTF-8エンコーディングを宣言するべきです。さらに結局は、すべての新しいBMSファイルが、旧来の文字エンコーディングではなくUTF-8で符号化されることが、大いに望まれます。
ruv-it!の#CHARSET UTF-8提案（後に撤回されました）は、旧来の文字エンコーディング（EUC-KRとSHIFT-JIS）の使用を許可します。両者ともに著しい変形があることにも注意してください（たとえばEUC-KRに対するCP949 aka UHC、Shift_JISに対するJIS X 0213）。WHATWGのEncoding standardはこの点で遥かに完全ですが、サポートされた文字エンコーディングのほとんどは決して使われず、実装の負担になるでしょう。
あるいは、前述の#CHARSET UTF-8と等価でありながらUTF-8のみを宣言するコマンド、たとえば#ISUTF8について考えることができます。実装はUTF-8のあらゆる行より先にそのような指令を検知する必要があるので、そのような指令は最初のコマンドでなければなりません。この種の制限は、他のあらゆるBMSコマンドがこの方法で動作しないように強制することが困難ですが、もっと重要なことに、全角空白（U+3000）によるインデントをサポートするいくつかの実装と互換性がありません。必然的に、私たちはいかなる新しいコマンドの導入も避けるべきです。
一方、UTF-8 BOMシーケンスはいくつかの実装に既にサポートされており、それは事実上あらゆる旧来の文字エンコーディングにおいて非常に稀、もしくは無効です。しかしバイトオーダーマーク（U+FEFF）は空白類文字ですから、エディタや前処理が誤って予告なく削除する危険性があります。したがって、UTF-8の発火シーケンスを明白にする第二の選択肢: 最初の行は、明確に非ASCIIたるべく最上位ビット・セットに少なくとも1バイトを備えた、妥当なUTF-8の文字列であるべきです。（1024バイトの制限は気まぐれではなく、無制限な先読みを回避するためにあります。）これはIE8以前のバグのための応急処置だったUnicode雪だるまに触発されました。旧来の文字エンコーディングで符号化された文字のいくつかは、UTF-8として誤解釈される可能性がありますが、BMSファイルの最初の行は一般に非コマンドもしくは#PLAYERコマンドのどちらかなので（BMSEのおかげで）、この危険性は十分に無視できる程度に小さいものです。
いくつかの小さな懸念:
歴史的にUTF-8の正しくない実装が多かったので、私たちはUTF-8が何であるのかを明示的に指定する必要があります。（単純ながら正確な例については“Flexible and Economical UTF-8 Decoder”を参照。）
妥当でないUTF-8のシーケンスをU+FFFDに変換することは今や当たり前で、詳細な説明を必要としません。しかしながら、妥当でないUTF-8のための戦略が異なれば、U+FFFDを生成する数も異なるかもしれないので、提案は最小の必要条件だけを提供します。
提案は、複雑すぎて正しく実装することが難しいものとして、さらなるUnicode標準を回避します。これはまた、私たちが今のところ、Unicode双方向アルゴリズムを必要とする「右から左への記述」をサポートしていないことを意味します。
ファイルシステムのエンコーディングは、ファイルの文字エンコーディングよりもはるかに困難です。あるファイルシステムにおいて妥当ないくつかのファイル名が、他のファイルシステムにおいて無効であることがありえます（両ファイルシステムがUnicodeを用いる場合でさえ！）。そのような問題のあるファイル名を回避することが最良です。
状態: 執筆中
今のところ、BMSの様々な場所で普遍的に使用される2文字の英数字キーは、1296項目（36×36）に制限されています。それはBGAオーバーレイのような複合効果の使用を深刻に制限し、結局BMSにおいて直接の動画ファイルの導入を主導しました。長期的には、この制限を打破することが望まれます。
英数字キーは括弧英数字キーによって置き換えることができます。それは(で始まり、(と)を除く0個以上の文字を含み、)で終わります。括弧英数字キーは、英数字キーと同じ名前空間を共有します。それらの意味は…
00は()と等価（データ区間）、または(00)と等価（非データのコマンド）。01は(01)と等価。ZZは(ZZ)と等価。括弧英数字キーは、英数字キーと同様で、大文字・小文字を区別しません。
この構文は、データ区間に限らず、#EXRANKxx, #TEXTxx, #BPMxx, #STOPxx, #LNOBJ, #CHANGE, #WAVxx, #BMPxx, #BGAxx, #ARGBxxなどを含めた、英数字キーをサポートするあらゆる場所に適用可能です。この提案は、データ区間内ではコロン（:）の後の英数字キーにのみ、適用可能です。
構文は、括弧内において任意の非括弧文字を許可しますが、0個以上の英数字（0-9およびA-Z）以外のあらゆるキーは将来の拡張のために予約されます。中身がない括弧英数字キー()は、データ区間の外部で予約されます。
Readerは、キーが予約されているか否かを問わず、各行の内容に合わせた行長制限内にある妥当な括弧英数字キーを、解析することができなければなりません。Readerは、データ区間における予約された括弧英数字キーを、実際に()または00と等価なものとみなし、無視するべきです。Readerは、予約された括弧英数字キーを含んでいる非データのコマンドを無視するべきです。
Readerは、括弧英数字キーを36進数ではなく固定長文字列として扱わなければなりません。したがって、(1)と(01)と(001)は別個のキーです。
Readerは、終了しなかった括弧英数字キーを解析してはなりません。つまり、括弧開き(で始まり、しかしその行の中に（あるいは各行の内容に合わせた行長制限によって切り詰められた行の中に）括弧閉じ)がないキーを、解析してはなりません。Readerは、そのようなキーがある行を無視するべきです。
Readerは、データ区間において、不完全な（つまり1文字の）英数字キーが先行した括弧英数字キーを解析してはなりません。たとえば#00101:は#00101:と等価ですが、#00101:は無効です。Readerは、そのようなキーがある行を無視するべきです。
Readerは、名前空間ごとに、括弧英数字キー全体を一意に限定しても構いません。ただしそのような制限は、名前空間ごとに少なくとも1296個のキーであるべきです。
Readerは、名前空間ごとに、一意の括弧英数字キーの総数に制限を設けても構いません。ただしそのような制限は、名前空間ごとに1296キー以上であるべきです。
Readerは、非データのコマンドにおいて、括弧英数字キーの周囲の空白類文字を無視してはなりません。特に、#FOOxx 42#FOO 42#FOO(xx) 42#FOOxx 42#FOO (xx) 42#FOO(xx)42
Writerは、2文字の括弧英数字キーの代わりに、通常の英数字キーを使用するべきです。Writerは、#LNOBJコマンドにおいて、互換性の理由のために、通常の英数字キーを大文字にして使用するべきです。
項目数が1295未満の場合、先頭の1295項目のための（あるいは全ての項目のための）01からZZまでの通常の英数字キーを、Writerは使用するべきです。Writerは、互換性がある領域の中に重要な項目を含めることを目的にして、項目の順序を整えても構いません。
互換性の理由のために、Writerは()を使用するべきではありません。データ区間におけるプレースホルダは、従来のように00として書かれるべきです。
1つのBMSファイルが1200以上のサウンドを必要とすることは、一般的ではありません。（1つのBMSファイルが1200以上のイメージを必要とすることは、かつては一般的でしたが、動画BGAの最近の傾向はこれを希少にします。）したがって、この提案の影響は非常に限られており、実際には1296以上のリソースを実装がサポートする必要は全くありません。
この提案の主な意図は将来上に位置します: イメージのようなエフェクト、およびサウンドのようなエフェクトを、無制限に使用することを可能にします。イメージのようなエフェクトの主要な例は#BGAです。それは実際のイメージではありませんが、イメージのように使用することができるのです。しかしながら、#BGAの枚数は英数字キー空間によって過酷に制限され、他の理由も相まって、#BGAは広く普及しませんでした。この種のいくつかの最近の拡張は、別のチャンネルを以ってこの問題を相殺します。たとえばnanasi#SWBGA拡張は、理想的にはイメージのようなエフェクトと結合したサウンドであるべきでした。しかし、それはそうする代わりに専用チャンネルを使用し、#SWBGAリソースは将来においてエフェクトを適用するためにレーンを含んでいます（したがって、1本のチャンネルだけが必要です）。これは合理的ですが、まったくスケールしません: もし7-KEY DP BMS（つまり16のレーン）がすべてのレーンに対して100組のアニメーションスプライトを適用すれば、それは1600の#SWBGAリソースを必要とするでしょう。
この提案も、多数の可能な拡張の先駆けです。たとえば括弧英数字キー(04 x=15 y=15)(-)は、#LNOBJの代わりにロングノートの終了を示せるかもしれません（またもや今のところ無効です）。現在の提案は簡単な実装のためにそれらを避けていますが、このような拡張はこの提案の枠組みにおいて確かに可能です。
約物(および)の選択は今のところ恣意的であり（私の見解では、それは外観をより自然にしますが）、DTXManiaが#BGAコマンドの中で括弧を区切り文字に使用しているようなので、変更するかもしれません。
状態: 提案済
さまざまなBMSプレイヤーが、ロングノートオブジェクト用のさまざまな判定ルールを持っています。いくつかのプレイヤーはそれらを2個のノートとして数えます（開始時および終了時）。いくつかのプレイヤーはそれらを1個のノートとして数えます。いくつかのプレイヤー（とりわけruv-it!）は「数が長さに比例する、複数の中間ノート」としてそれらを数えます。ノートの数は判定ルールとスコアに大幅に影響するので、中間ノートを指定する能力は一貫したゲームプレイのために決定的に重要です。
今のところまったく未使用であるチャンネル7xおよび8xが、ティックオブジェクトに任命されます。ロングノートオブジェクトが、対応するティックオブジェクト（ロングノートの終了点と一致しても構いません）を持つ場合、これらのティックオブジェクトはBMSプレイヤーの既定の判定ルールとコンボカウントを無視し、ゲージはティックオブジェクト到達時にのみ影響を受けます。
たとえば次のBMSファイルには、6個のティックオブジェクトを含んでいる1個のロングノートオブジェクトがあります。ロングノートは終端に1個のティックオブジェクトを含んでいます。
#00151:AA0000000000BB00#00171:0033445566778800
ロングノートの始まりがティックオブジェクトと一致しないので、最初のティックオブジェクト（33）に到達するまでは、コンボカウントは増加しません。もしプレイヤーがティックオブジェクト66と77の間で鍵盤押下を中断すれば、コンボカウントはリセットされ、最初の4個のティックオブジェクトだけがカウントされます。もしプレイヤーがロングノートを適切に終えることができたならば、コンボカウントは6だけ増加するべきです。
実際のルールは、ロングノートの始めか終わりでティックオブジェクトを扱うために、もう少しだけ精巧に作られます:
ロングノートの開始がティックオブジェクトと一致する場合は、そのティックオブジェクトはプレイヤーが鍵盤を押し始める時にカウントします。そのティックオブジェクト用のキー音は、ロングノート用の本来のキー音と共に演奏されます。
ロングノートの終了がティックオブジェクトと一致する場合は、そのティックオブジェクトはプレイヤーがロングノート全体を完了して鍵盤押下を中断する特にカウントします。したがってこのティックオブジェクトは、見かけ上のロングノートが完遂される前に演奏される場合がありえます。もしBMSプレイヤーがロングノート終点の明示的なキー音をサポートするなら（これは他の提案の主題です）、このティックオブジェクト用のキー音は、本来のロングノート終了用のキー音と共に演奏されます。
他のティックオブジェクトはコンボカウントへ加算されますが、ティックオブジェクト到達時にプレイヤーが鍵盤を押していなければ演奏されません。譜面制作者は、ティックオブジェクトの間に十分な間隔を与えるか、あるいは重要なキー音の欠落を避けるためにgenericなキー音をティックオブジェクト用に使用することが推奨されます。
寛大な判定によって、複数のティックオブジェクトが同時にコンボカウントへ加算される場合、コンボカウントが2個以上増加しうることに注意してください。これは、複数のティックオブジェクトのキー音を、私たちが演奏しない理由でもあります。
ロングノートはティックオブジェクトを少なくとも1個含んでいるはずです。ロングノートがティックオブジェクトを含んでいない場合、BMSプレイヤーはティックオブジェクトを追加するために独自の判断を自由に行使することができます。もっとも、これは異常な場所にティックオブジェクトを持つこともできてしまいますが。たとえば超長いノートの頭にティックオブジェクト1個だけを置くことができてしまいます。それはプレイヤーにさらなるコンボカウントを与えずに、鍵盤を押し続けさせます。
ロングノートの外側のティックオブジェクトは予約されます。また、サポートされていないどのようなティックオブジェクトも廃棄されるべきです（BGMに変換されるのではなく）。
Readerは、ティックオブジェクトをゲームプレイに関連させるようにする手段（たとえばコンボカウントかボーナススコアを増加させることによって）を持つべきです。Readerは、ティックオブジェクトがロングノートの開始もしくは終了と一致しても一致しなくても、ティックオブジェクトを視覚的にはっきり区別するべきです。Readerは、ティックオブジェクトからのコンボカウントあるいはスコアを、通常のオブジェクトよりも低くなるように比較検討しても構いません。
Readerは、ロングノートの外側のティックオブジェクトをすべて無視しなければなりません。Readerは、任意の大量のデータコマンドにおいて、配置されたティックオブジェクトを処理できなければなりません。Readerは、オーバーラップするティックオブジェクト（つまり、同一の小節および同一のチャンネルを持つ複数のデータコマンドにおいて、同一の位置に配置されたティックオブジェクト）を処理できなければなりません。その際、Readerはクラッシュしてはなりません。またReaderは、同一の位置で2つを超えるティックオブジェクト（それはたとえば、一致するティックオブジェクトのうち、1つ以外のすべてを無視するかもしれません）を加えるべきではありません。
Readerは、あらゆるティックオブジェクトが欠如した状態に対して適用するための、既定のティックオブジェクトポリシー（たとえば1つの四分音符当たり1個のティックオブジェクト）を持つべきです。
ティックオブジェクトを持つロングノートの開始が判定され、ロングノートの残りの部分が近い将来において判定されることになったとき、Readerは、現在位置に至るまでのティックオブジェクトすべてを適用しなければなりません。このときReaderは、ティックオブジェクトに関連づけられているあらゆるキー音を再生するべきではありません。
ロングノートが判定されているとき、Readerは、現在位置に到達するティックオブジェクトを適用しなければなりません。プレイヤーが以前に鍵盤を押し続けることに失敗したものとしてロングノートが判定されていないとき、Readerは、現在位置に到達するティックオブジェクトを適用してはなりません。Readerは、取り逃がしたティックオブジェクトに対して付加的なペナルティを適用しても構いません。Readerは、ティックオブジェクトに対して関連づけられているキー音がもし存在するなら、それを再生するべきです。
ティックオブジェクトを持つロングノートの終了が判定されるとき、Readerは、ロングノートの終了位置を含む、現在位置から終了に至るまでのすべてのティックオブジェクトを適用しなければなりません。このときReaderは、ティックオブジェクトに関連づけられているあらゆるキー音を再生するべきではありません。もしReaderが、ロングノートの終了位置でティックオブジェクトに関連づけられたキー音を「ひとつ」認識することができるなら、Readerはそれを再生しなければなりません。
Writerは、ロングノートの外側のティックオブジェクトを書くべきではありません。そうでなければ、データコマンドに対し、すべての標準Writer要件が適用されます。
この提案の主な意図は明らかに、BMSに対するロングノートを更に適切にすることです。この傾向は、ロングノートを備えた多くの商用ミュージック・ビデオ・ゲームにおいても顕著であり、いくつかのゲームはさらに、ゲージ減少に対してこの原理を適用します（その結果ロングノートを逃すことははるかに致命的です）。 この提案はしかしながら、ロングノートのコンボに集中します。as it is enough for making long notes important and unique game systems should be respected.
チャンネル7xおよび8xが選ばれています。これらは従来のBMSフォーマットの中で使用されておらず（DTXは使用しているようですが）、ゲーム・プレイと得点採点法に甚大な影響を持たないからです。元来は、ロングノート（チャンネル5xと6x）にオーバーラップする可視オブジェクト（チャンネル1xと2x）が、ティックオブジェクトの変形であるように考えられます。しかし、多くの（大多数ではないにしても）ロングノートの実装が、そのようなオーバーラップするノート上で不正に動作したために、それは放棄されました。
「BMSファイルの全体にわたるロングノートコンボ」のグローバルな速度を固定することは可能ですが、それはあまりにも暗黙的すぎ（たとえばノートの数は計算するのが難しい）、カスタマイズするのが困難です（たとえば速度はBPMや時間に依存すべきか？）。明示的なティックオブジェクトはすべてを明白にし、さらにオプションのティックサウンドさえ考慮に入れます。
状態: 研究中
...
状態: 執筆中
BMSフォーマットは多数の言語のためには設計されていません。しかし、言語に応じてBMSファイルの複数のバージョンを備える例は増加しつつあります。言語ごとに個別のBMSファイルを持つことは、様々な理由から望ましくありません（たとえば、BMSハッシュを介するインターネット・ランキングは完全に台無しにされます）。またほとんどの場合、いくつかの資産および文字列だけはローカライズされる必要があります。
#TITLEのようなメタデータコマンド、および#BMP01のような資産コマンドは、コマンドに直接に続く英数字キーを持つかもしれません（たとえば#TITLEKOおよび#BMP01KO）。それはISO 639-1 Alpha-2言語コードとして解釈されます。これがISO 3166-1 Alpha-2国コードとは区別されることに注意してください。韓国語はKRの代わりにKOであるべきです。日本語はJPの代わりにJAであるべきです。中国語はCNまたはTWの代わりにZHであるべきです。
影響を受けるコマンドが挙げられますが、これらに制限されません:
#STAGEFILE, #BANNER, #BACKBMP, #CHARFILE, #BMPxx, #EXBMPxx, #BGAxx, #@BGAxx, #SWBGAxx, #ARGBxx, #VIDEOFILE#WAVxx, #EXWAVxx#TEXTxx, #SONGxx#TITLE, #SUBTITLE, #ARTIST, #SUBARTIST, #MAKER, #GENRE, #COMMENT基本的には、実際の譜面に影響を与えないすべてのコマンドはローカライズすることができます。異なる資産を備えた1枚の譜面（分岐処理後）だけがあるので、このアプローチはローカライズされたBMSファイルを効率的に取り扱うことができます。
言語用の英数字キーに空白類文字が先行するべきではありません。空白類文字は後続するべきです。資産コマンド（たとえば#BMP01 a.bmp）に適用されたとき、言語はターゲット英数字キーの後に追加されるべきです（たとえば#BMP01KO a.bmp）。
この提案は、必要というわけではありませんが、いくつかの主要なターゲット言語をサポートするために、括弧英数字キーを推奨します（たとえばzh-cnからzh-twを分離するために）。この場合、通常の英数字キーは対応する括弧英数字キーと等価であり、それはISO 639言語コードのスーパーセットであるIETF言語タグとして解釈されます。
Readerは、言語の優先順位を持っているべきであり、言語の優先順位はユーザによって設定可能であっても構いません。Readerは、相対的な優先順位によって、複数の「優先する言語」をオーダーしても構いません。
Readerは、...べきです。
括弧英数字キーをサポートするReaderは、IETF言語タグの、制限された部分集合を解析することができるべきです。すなわち言語コード（ISO 639-1 Alpha-2）、および任意の選択によって後続しうるハイフンと国コード（ISO 3166-1 Alpha-2）。
Readerは、言語あるいは言語タグと正確に（大文字・小文字を区別しない方法で）一致することができなければなりません。もしReaderが言語タグをサポートしているなら、Readerはさらに、「優先する言語」よりも、厳密に特定の言語タグと一致するべきです（たとえばBMSにおいてKO-KRのとき、KOが優先されます）。
...
状態: 提案済
歴史上、BMSのBGAキャンバスは256×256のピクセルに制限されていました。これは、しかしながら、多くの場合において不十分であると証明されます。また、多くのBMSプレイヤーが、より大きなスクリーンのためにこの制限を引き上げました。まだ、いくつかの未解決の曖昧な表現が残っています。
明示的なキャンバスの寸法のためのコマンド、#CANVASSIZEが導入されます。それは2つの引数を持ちます（幅のためのひとつ、および高さのためのひとつ）。幅と高さの両方は正の数であるべきです。
指定されたキャンバスの寸法は、BGAに対する旧来の制限（256×256）を、指定された値に置き換えます。これはさらに、BMSにおけるいくつかの場所を、暗黙の256×256平面から変更します: キャンバスの寸法よりも小さなBGAは、通常通りに透明な黒にパディングされ、#BGAコマンドはキャンバス平面にクロップします。
Readerは#CANVASSIZE <w> <h>の形式を備えたコマンドを認識しなければなりません。ここで空白は1個以上の認識された空白類文字を表わし、<w>と<h>は1桁から4桁の10進数を表わします。Readerは、妥当でない構文を備えた#CANVASSIZEコマンドを無視するべきです。Readerは、妥当な#CANVASSIZEが複数存在するなら、最後のそれをキャンバスの寸法として使用しなければなりません。Readerは、BMSファイルを前にして、暗黙的な#CANVASSIZE 256 256を仮定しても構いません。
#CANVASコマンドが存在する状態において、Readerは、内部のキャンバスを、指定されたキャンバスの寸法へ伸張しなければなりません（あるいは伸張をシミュレートする内部計算を行わなければなりません）。Readerは、本来のイメージが左上隅に固定される位置で、指定されたキャンバス平面に対するBGAとして使用されるイメージファイルに、パディングするかクロップするべきです（あるいはパディングとクロッピングをシミュレートする内部計算を行うべきです）。パディングまたはクロッピングが生じたとき、パディング領域は透明な黒に満たされるべきです。Readerは、指定されたキャンバスの寸法に対するBGAとして使用される動画ファイルが存在するなら、それらを伸張するべきです。キャンバスの寸法がBGA領域を超過する場合、Readerは、固有のBGA領域に対する結果として生じるイメージを、再び拡大縮小しても構いません。このような再スケーリングが生じる場合、Readerはキャンバスの寸法の縦横比を維持するべきです。（これはBMSプレイヤーをクラッシュさせる悪意あるBMSファイルを禁止するためです。この提案は、BMSプレイヤーに対し、本来のイメージファイルよりも多くのメモリを割り当てることを要求しません。本来のイメージに対するポインタ、ならびにクロッピング情報もしくはストレッチング情報を持つことによって、クロッピングおよびストレッチングがシミュレートされるかもしれないからです。）
#CANVASコマンドが存在する状態において、キャンバスの寸法によって影響を受けるコマンドは（#BGA, #@BGA, および旧来の#ExtChrを含みますが、これらに限らず）、指定されたキャンバスの寸法を尊重するべきです。とりわけ#BGAおよび#@BGAコマンドは、指定されたキャンバスの寸法に対して与えられた座標を、クロップするべきです。
キャンバスの寸法が256×256ピクセルである場合さえ、もしBGAが存在するなら、Writerは#CANVASSIZEコマンドを書くべきです。
状態: 執筆中
BMSに由来した多数のフォーマットがあります。そのうちのいくつかは十分にメジャーですが、他のものはマイナーであり、それをサポートする実装は通常ひとつだけです。それでもなお、それらのうちの多数は同じゲーム・プレイを共有しており、単にレーンの順序および外観だけが異なります。最近の#OPTION拡張の方法において、与えられたBMSファイルが期待するレーンの順序および外観を明示的に指定することは、有用でしょう。
この提案はひとつのコマンド#LANESを加えます。レーンとチャンネルとの関連付け、およびレーンの順序と外観を指定します。構文は次のとおりです:
#LANES <channel> <spec> <channel> <spec> ...<channel>は、可視オブジェクト・チャンネル（10から2Z）用の2文字の英数字キーであり、<spec>はそのレーンについて記述する、いかなる空白類文字も伴わない文字列です。<channel>はさらに00でありえます。それはレーンの外側に仕様があることを意味します。（これはさらに、チャンネル00が復活するのを禁止します。）
<spec>はさらに_文字によって区切られます。_によって区切られた最初の部分は必須箇所であり、後続の部分は最初の部分に対してヒントを与えます。たとえばkeykeyと、2個のヒントblueおよびevenを含んでいます。必須の仕様が無視される場合は、関連づけられたヒントも無視されるべきです。<spec> is an opaque string besides from _, 衝突の可能性を最小化するために、:で終わるベンダー接頭辞を使用することが実装には推奨されます。
レーン仕様は、推奨されたレーン外観および振る舞いの簡潔な記述です。このコマンドは必須ではないので、実装は完全にこのコマンドを無視するかもしれませんが、
#LANESコマンドに現われたチャンネルの外部にあるすべてのオブジェクトが、BGMに変換されることが推奨されます。また、この提案はさらに、下記の標準レーン仕様およびレーンの外側の仕様を定義します。実装はそれらを自由に無視できますが、それでもなお、それらに従うことが推奨されます。
key包括的なon/
odd奇数位置の鍵盤。音楽のキーボードの外観の模倣。奇数位置の鍵盤用のレーンはオーバーラップするようには意図されません。
even偶数位置の鍵盤。偶数位置の鍵盤用レーンが、それら自身ではなく、奇数位置の鍵盤にオーバーラップすることがありえます。（たとえば、odd, even, odd, odd, even, even, oddヒントを備えた7個の鍵盤がある場合、2番目のeven鍵盤は1番目と3番目のodd鍵盤にオーバーラップするかもしれませんが、5番目と6番目のeven鍵盤は互いにオーバーラップしません。）
scratch時計回り・反時計回りの両方の運動を備えた包括的なスクラッチ。鍵盤よりも大きな視覚的な手がかりを持っているように意図されます。
pedal包括的なペダル。鍵盤よりも大きな視覚的な手がかりを持っているように意図されます。
gap（レーンの外側）レーン間の隔たり。間隔の大きさは実装依存であり、無視することができます。おもにダブルプレイ・モードにおいて、視覚的な手がかりとして2セットのレーンのために使用されます。
下記は既存のゲーム・モードを備えた#LANESコマンドの例です。（インデントが仕様の一部ではないことに注意してください。）
#LANES 11 key_odd 12 key_even 13 key_odd 14 key_even 15 key_odd 16 scratch
#LANES 11 key_odd 12 key_even 13 key_odd 14 key_even 15 key_odd 16 scratch 17 bm98:
#LANES 16 scratch 11 key_odd 12 key_even 13 key_odd 14 key_even 15 key_odd 18 key_even 19 key_odd 00 gap 21 key_odd 22 key_even 23 key_odd 24 key_even 25 key_odd 28 key_even 29 key_odd 26 scratch
#OCT/FPコマンドのシミュレート）#LANES 21 pedal 16 scratch 11 key_odd 12 key_even 13 key_odd 14 key_even 15 key_odd 18 key_even 19 key_odd 22 key_even 23 key_odd 24 key_even 25 key_odd 28 key_even 29 key_odd 26 scratch
#LANES 11 key_odd
レーン仕様が#PLAYERコマンドの役割を大幅に縮小するので、#LANESコマンドは常に#PLAYERコマンドをオーバーライドします。
...
...
既存のチャンネルに関する詳細情報についてはhttps://hitkey.nekokan.dyndns.info/cmds.htmを参照してください。
000102030405#SEEKコマンドに使用]060708090A0B-0E0F-0Z10-1Z20-2Z#LNOBJコマンドでロングノートを含む30-3Z40-4Z50-5Z60-6Z70-7Z80-8Z90-969798999A-9ZA0A1-A4A5A6A7-AZB0-BZC0-CZD0-DZE0-EZF0-FZG0G1-G8G9#STOPコマンドを非活性化する?GA-GZH0-HZI0-IZJ0-JZZ0-ZZベンダーキー: