doubledepth

VMware Workstation Playerをversion 14.0.0にupdateしたら、いくつかのvirtual machinesがprotection errorを発して起動しなくなった

なんでじゃ。前日には普通に起動してたでしょ。

VMware Workstation 14.0.0 Playerをuninstallして、類似Q&Aの通りに残留物を削除し、再度installしてみたけど、症状は改善せず。手動で削除する前の残留物の更新日時はのままだった。つまり14.0.0にupdateしたにもかかわらず、VMware Kernel Driverおよびその他いくつかのfilesは12.5のものが使われていた。再install後、それらのtimestampはのものに更新された。ということは、Kernel部分とかは特に内容が変わってはいなかったということだろうか。

困ったことにGuest OSをsafe modeでしか起動できない。その状態ではCD-ROM driveも認識されず、VMware Toolsもinstallできない。玄人ならこの状態からでもどうにか対処するのだろうけど、私は一時間粘って無理だったので諦めた。……と日記を書いているうちにどうにかできそうな方法を思いついたので、明日はそれを試そう。新しいCPUでGuest OSとして実行可能なWindows OSはWindows 10のみになるらしいし、今のうちからHyper-VやVirtualBoxに移行しておくべきかもしれない。

[追記] 問題を無事に解決できた。ついでに調べたところ、Windows 10のHyper-VはWindows Vista以前のWindows OSをsupportしていないことが判明した。私の目的を達成できそうな仮想環境はVirtualBoxしかなさそうだ。

BmsONE 0.2.1のencodingに関する罠

Windows x64版です。以下の現象はbugや不具合にはあたらないけど、噛み合わせが悪い感じ。

  1. 変換対象BMS fileのencodingが「BOMつきUTF-8|16|32」のとき、BmsONEの“Text encoding”選択肢“Default”は、sample text areaにUnicode文字列を表示します。
  2. 選択肢“default”を選択すると、Unicodeのbyte sequenceがSystem Localeに準じて復号されます。つまりsample textとは無関係の、まったく異なる内容として解釈されます。
  3. 誤って変換された状態の図表を、誤変換に気づかないまま「保存」すると、BMSON形式であるにもかかわらず、図表はUTF-8ではなくSystem Localeで符号化されます。

「System Localeが表現できない文字」を用いたBMS図表をBMSON形式に変換するなら、いまのところ以下の手順が安全と思われます。

  1. 変換対象BMS fileを、図表著者が意図したであろうencodingで「開く」（これはWindowsメモ帳とかでは無理です。wxMEditやMeryなどの「encoding変更機能を持つtext-editor」が必要です）。「図表著者が意図したであろうencoding」に関しては、変換者自身が推測しなければなりません。
  2. 適切らしきencodingで開かれた変換対象BMS fileを、UTF-8 encodingを指定して別名保存する。
  3. UTF-8符号化BMS fileをBmsONEにdropし、encoding選択肢で“UTF-8”を選択する。BOMの有無を問わず、必ず“UTF-8”を選択しなければなりません（“Default”や“Shift-JIS”ではなく）。

raindrop 0.600

いわゆる緑数字（“Green Number”と書いてあって驚く）や、#DEFEXRANKなどが実装されました。

私の環境では、log.txt内にCP932とUTF-8が混在し、その結果として必ず文字化けします。

(8): スピーカー (Realtek High Definition Audio) // CodePage 932 byte sequence:
28 38 29 3A 20 83 58 83 73 81 5B 83 4A 81 5B 20 28 52 65 61 6C 74 65 6B 20 48 69 67 68 20 44 65 66 69 6E 69 74 69 6F 6E 20 41 75 64 69 6F 29
(10): スピーカー (Realtek High Definition Audio) // UTF-8 byte sequence:
28 31 30 29 3A 20 E3 82 B9 E3 83 94 E3 83 BC E3 82 AB E3 83 BC 20 28 52 65 61 6C 74 65 6B 20 48 69 67 68 20 44 65 66 69 6E 69 74 69 6F 6E 20 41 75 64 69 6F 29

raindropやAngolmois 2.0a3以降などの最近のBMS関連applicationsが用いるlibpng 1.6.x以降は、妥当でないPNG chunksに対して厳しめに警告を出力します。私の環境ではraindropを起動しただけで、

libpng warning: iCCP: known incorrect sRGB profile

などと怒られるし（GameData\Skins\default\Global\）、何かの図表を終えただけで、

libpng warning: iCCP: cHRM chunk does not match sRGB

などと警告されます（GameData\Skins\default\Evaluation\）。特に実害はないようですが……

BmsONE 0.2.1をもう少し触ってみる

Antivirus softwareの許しを得たので、BmsONE 0.2.1をもう少し触ってみる。

古い32-bit版directoryと、その設定（C:\Users\<USER>\AppData\Local\BmsONE\Settings.ini）を残したままWindows 64-bit版を起動したところ、設定項目の一部が表示されなかったり、【表示 → 表示モード → キーボード24鍵盤】が選択肢に現れなかったり、いろいろ困った。古い版とその設定を消し、再度BmsONEの設定を行った。*.bmson filesへの関連付けもやり直した。

BMS import機能に関して、最初の「テキストエンコーディング」がいきなり難問。基本的には文字化けしない項目を選べば問題ないが、図表fileのencodingとSystem Localeのencodingが一致しない状況ではうまくいかない。日本語環境のWindowsの場合、簡体字中国語の図表や、韓国語の図表（BMS no.070）や、filenameのみ韓国語の図表などは、文字化け不可避。他のtext-editorsとの併用が必要。

  • 最初の項目“Default”は、Windowsの場合はSystem Localeが適用される。Byte-Order-Mark（BOM）が検出された場合は、UTF-8|16|32として解釈される……ように見えて、じつは無理やりにSystem Localeで復号されてしまう。しかもこのまま保存すると、BMSONであるにもかかわらず、UTF-8でなくSystem Localeで符号化されてしまう。「BOMつきGB18030」は解釈されない。

  • 二つ目の項目“Shift-JIS”は、Windowsが拡張したCodePage 932（Windows-31J）ではなく、純粋な（あるいは狭義の）Shift_JIS。なので、半角カナなどのいわゆる機種依存文字は文字化けする。たとえば、“#GENRE FINAL FANTASY Ⅷ”のRoman numeralsや、“#TITLE _(：3 」∠ )_”の左足。

    [追記] なんか、後日あらためて確認したら半角カナも「∠」も普通に表示された……。いい加減なことを書いてしまい申し訳ございません。

  • 三つ目の項目は、「BOMなしUTF-8」専用という感じ。冗長表現への対策も問題なかった。

μBMSC 3.2.1 + Pulsus 0.5.2

μBMSCの改修とともに、Pulsus同梱版もreleaseされました。uBMplayをWindows 10に導入できない方は、このμBMSC+Pulsusを試されるとよいでしょう。

PulsusはuBMplayよりも導入が簡単であるだけでなく、uBMplayよりもsensitiveなので、図表の基礎的な互換性を検証する目的でも役に立ちます。たとえばPulsusは、#xxx[1-6]7（FREEZONE）に出くわすと強制終了します。

PulsusはDouble Playなどのmaniacなmodeをsupportしていないので、それらの拡張的な図表をpreviewするならPulsus以外のviewerが必要です。私はuBMplayとの併用をおすすめします。

PulsusはBMSON用のviewerとしても役立ちます。0.5.2ではLayered Notesが実装されました。

BmsONE beta 0.2.1

BMS形式の図表fileをdropすると、BMSON形式に変換してくれるようになりました。複雑すぎるrhythmを変換すると、応答なし状態に陥る場合もありますが、「BMSEが扱えるrhythm」を変換する限りでは問題は発生しません。BMSON形式に変換された図表は、以下のような利点を享受できます。

  • 新たなpartにKEY音の役割を担わせたくなったときに、図表著者は音声を裁断する必要がありません。（もちろん従来型BMSの方法の通りに実際に音声fileを丁寧に切っても構いません。）
  • 同時押しに説得力を与えたくなったときに、図表著者は音声を実際に合成する必要がありません。（BMSON形式は、図表上で複数の音声をまとめるLayered Noteという仕組みを持っているので。）
  • 新たな音声や映像を追加したくなったときに、図表著者は定義数を気にする必要がありません。
  • 「分岐（＝実行時まで確定できない内容）が存在しないこと」が仕様によって保証されるので、実装次第ではBMSON図表の読み込み時間はBMS形式よりも高速化されうる……かもしれません。
  • #999を超過するような長い図表も表現できます。小節線を撤去するのも簡単です。
  • 「文字符号化方式の差異による文字化け」が無くなります。

一方、BMSON形式に変換することによる不利益をあえて挙げるなら、

  • BMSON図表はLR2では遊べません。十年前のsoftwareといえど、IRはまだ代替がありません。
  • 「複雑なrhythm」の表現精度は、BMS形式よりもやや劣ります（とはいえ実用上問題なさそうではあります）。座標や分解能の上限（Unsigned Long）が撤廃されれば無制限に精度を確保できますが、BmsONEやbeatorajaはその道を選ばないでしょう。
  • BmsONEは音楽的な意味でのscore editorという性質が強く、糞みたいなscrollingを操れるstage editorではありません。そのようなgimmickはBMSE/iBMSC/μBMSCのほうが得意です。
  • #RANDOM分岐・不可視notes・地雷もないので、それらを使いたいならBMS形式を選びましょう。
  • LAYER画像の仕様が多少変わります。BMS形式とBMSON形式で同じresourcesを使いまわし、尚且つ両形式で同じように描画させたい図表著者は、ちょっとややこしい工夫を求められる場合があります。
以下、気がついた点。
  • BMS fileのMAIN DATA FIELD以降を小文字にしてからBmsONEに投げると、変換結果が変わります。
  • "keyboard-24k-double"を編集しようとして気がついたのですが、KEY lanesを画面内に収容しきれない場合、水平方向へのscrollingができないようです。（いまのところ当環境ではBmsONE 0.2.1が未知のsoftwareとしてAntivirus Softwareにblockされている状態なので、10分間ほどしか試行錯誤できていません。もしかするとscrollするための方法が用意されていて、それを私が見落としているかもしれません。）

BMSONのfile pathに関する仕様を誤解していた事を懺悔する

初見で誤読したまま今日まで勘違いを引き摺っていた。いつもながら私は阿呆そのものだった。

  • The sound files may live in subdirectories relative to bmson file.
    • Path may be separated using backslash (\) or forward slash (/), the implementation should normalize them.
    • The implementation must protect from malicious paths:
      • Absolute path: C:\password.txt or /etc/passwd
      • Reference to parent directory: ../../../var/www/html/config.php
      • Null characters (\0)
    • Example: { name: "intro\\drum" }

普通に考えれば「『BMS/BMSON図表が置かれたfolder』から外部への参照を一切許さない」という制限が最も安全なので、引用箇所は「絶対pathも親directoryへの参照も受け入れてはならない」と解釈するのが自然だ。私はなぜだか、もっと面倒くさい実装を想像してしまっていた。

前述の引用はsound filesに関する規定だが、特に言及がないpicture filesの"name"に関しても、同様の制約が課せられるものと思われる。外部への参照を仕様違反として却下できるなら、file pathに関して私が面倒に感じていた問題は9割がた消えてなくなる。

UNC pathその他の備忘録

UNCといえば、Nekokan ServerがWebDAVに対応しているらしい。私のaccountのpasswordを思い出すか変更する機運が高まり次第、また試してみます。（Password promptに敗北奴〜）

BMSのresource欄にUNC pathを定義する必要性がいまいちわからない。ちらっと思うことがあって検索すると、やはり「攻撃経路としてのWebDAVの悪用」という話も可能性としてはあるようだ。私の素人codingでは複雑なfilepathに対処しきれないことを思い知ったので、「filepathが期待される値」の先頭が“\\”や“//”なら一律で諦めることにした。“\\?\”はこれを知った今ではむしろ推奨したいくらいだけど、BMSとはご縁がなかったということで。ほぼ十日かけていろいろ調べた結論がこれかぁ……

BMSE非公式Helpを今週中に更新したい。“BGAのススメ”移転・uBMplay20170913・μBMSCなど。[追記] に更新しました。

Networkの向こうのresourcesを参照するBMSについて

以下のBMSをvirtual machine越しにnanasigrooveで再生できた。接頭辞とは何だったのか……

#TITLE UNC test
#BPM 120
#WAV01 \\vmware-host\Shared Folders\shared-bms\testbms\kick.wav
#WAV02 //vmware-host/Shared Folders/shared-bms/testbms/undefined/../kick.wav
#WAV03 \\?\UNC\vmware-host\Shared Folders\shared-bms\testbms\kick.wav
#WAV04 //vmware-host//Shared Folders//shared-bms//kick.wav
#00111:01020304

“[MS-DTYP]: Windows Data Types — 2.2.57 UNC”によれば、“\\vmware-host”はhost-nameに相当し、“\Shared Folders”はshare-nameに相当する。host-nameは[RFC3986]に従うとされている。[RFC3986]によれば、英数字と"-" / "." / "_" / "~"だけが使用を許されている。

にもかかわらずWindows 10では日本語のPC名を付与できたり、System Localeが日本語でありながらHangulのPC名さえ付与できたりする。

英数字と"-" / "." / "_" / "~"だけが使用を許されている（迫真）「投手無双」や「감사」がPC名として許されて「🈧🈐🈚🈒」（四角囲み文字「投」「手」「無」「双」）が許されない理由は不明。

“#WAV01 D:kick.wav”について

まるで“D:\kick.wav”のtypoのように見えるこの定義を、nanasigrooveやbeatorajaは妥当なrelative pathとして解釈する。「図表fileが存在するfolder」がCurrent Directory（cd）として設定される。この#WAV01は、図表がDrive D:\上のどこかに存在する場合に限り、参照されうる。

システムメンテナンスツール「CCleaner」が改竄の被害、ユーザー情報を外部送信

当該版はv5.33.6162 (32-bit)だそうです。私のvirtual machinesのうち一台に直撃していました……。Registory entry: HKEY_LOCAL_MACHINE\SOFTWARE\Piriform\Agomoが存在しないなら大丈夫かも？　当該entryにMUID, TCID, NIDの各keyが存在しないなら間一髪でsafeかも？　64-bit版なら問題ないかも？　などと噂されています。奇しくも痛恨の一撃を食らった直後の今回の出来事でした。一回の清掃でC:\の容量が全体の⅕ほど空くこともあって、私は未だに現役でお世話になっており、このsoftwareが使えないととても辛い。頑張ってほしい。悪意ある改竄者は惨たらしく爆発してください。

Lynx日本語版が十年ぶりに更新されていてのけぞった

JavaScriptやCSSをsupportしていないのでtext-based web browserでありながら「せっかくチートを貰って異世界に転移したんだから、好きなように生きてみたい」とか成人男性向け投稿小説さえ閲覧させてもらえないというGooglebotにも劣る悲しきbrowserですが、そうであるがゆえに日本語のWeb Accessibility確認用toolとしては最適という、一部の向きに猛烈に愛されるbrowserです。

十年前のLynx 2.8.6 rel.4TH日本語版はHTML5の<meta charset="utf-8">に対応していなかったので、古いLynxが文字化けしないようにするにはHTML4時代の<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">を指定するか、またはContent Headerからencodingを直接指定するしかありませんでした。今後はそのような不毛な作業から解放されます。

uBMplay更新

検証ありがとうございました！

実に3年ぶりにサイトを更新しましたー

http://ucn.tokonats.net/

みんな〜＞🦍🦍

先日の日記の訂正と追記

#WAV03     kick.wav. . .

この指定に関して訂正します。nanasigrooveほかいくつかの実装は、commandとvalueの分離符として「連続する空白類文字」を許容します。前述の指定は、nanasigrooveにとっては以下と等価です：

#WAV03 kick.wav. . .

そして、後者の指定ならnanasigrooveのみならずuBMplayでもLR2でも鳴ります。（ただしBMSEやbeatorajaでは鳴らないので、これはuBMplayやLR2の「拡張子部分を無視してfileを検索してみる機能」の効果かもしれません）

Windows APIは通常は「Path末尾の空白やFULL STOP」をtrimしますが、file-nameやfolder-nameの先頭側の空白はtrimしません。Command promptなどを経由すれば、名前の先頭側に空白やFULL STOPを挿入することができます。それらを以下のようにBMSから参照すると、普通に参照されます。

#WAV03 .\    space_x4\    kick.wav. . .

前述の実際のfolder nameは“ space_x4”、filenameは“ kick.wav”です。

一方、以下の指定は参照されません。実際の名前は先程の例と同じです。

#WAV03 .\    space_x4    \    kick.wav. . .

そもそもWindows環境では、fileやfolderの名前末尾に空白を挿入することはCommand promptなどを経由しても不可能のようでした。前述の例のように定義文字列中のfolder名末尾に空白がある場合、これはWindows環境ではありえない名前と判断できますから、application側で末尾側空白を削除しても構わないのでは？　と私は考えました。

私はWindows Pathの複雑怪奇な仕様を大雑把に把握できたと思います。Path文字列を正規化する際の方針が定まったので、ようやくcodeの続きが書けそうです。

Naming Files, Paths, and Namespaces (Windows)

自分用備忘録。Windows Pathの拡張として“\\?\”や“\\.\”という接頭辞が定義されている。脱線するけど、「drive名つき相対path」なる代物についても私は初めて知った。常識なのだろうか。

  • "C:tmp.txt" refers to a file named "tmp.txt" in the current directory on drive C.
  • "C:tempdir\tmp.txt" refers to a file in a subdirectory to the current directory on drive C.

Relative paths can combine both example types, for example "C:..\tmp.txt".

  • Path文字列が“\\?\”から始まるなら、directory separatorとして"\"のみが許容され、"/"は禁止される。Directory componentとしてのU+002E ‘FULL STOP’も禁止される（"./"や"../"は不正）。さらに、「path末尾の空白やU+002E」などの「通常ならWindows APIに自動的に訂正される箇所」が、書かれている文字列の通りに解釈されるようになる。通常は許容され訂正される「directory separatorsの連続（"\\\"や"///"）」も禁止される。MAX_PATHに関する制限が取り払われ、UTF-16換算で32767文字までpath文字列が指定可能になる。Universal Naming Convention (UNC)と併用する場合は“\\?\UNC\”接頭辞を用いる。
  • Universal Naming Convention (UNC) is 何。Local networkなどで使うらしい。使ったことない。“\\?\”を伴わない場合のUNC pathは“\\PCname\sharedFolder\bms.bmp”とかになるらしい。
  • Path文字列が“\\.\”から始まるなら、Win32 file名前空間のかわりにWin32 device名前空間にaccessする。"\\.\COM10"とか。Win32 file名前空間側にも、device名のaliasが存在する（CON, PRN, AUX, NUL, CLOCK$, COM[1-9], LPT[1-9]）。COM0とLPT0は予約語ではないにもかかわらず、explorer上で件の名前に変更しようとすると「指定されたデバイス名は無効です。」と怒られてしまう。
  • "\??"は“DOS devices関連”らしい。Wikipediaにも例あり。日本語解説だとこのへん。

仮に“#BMP01 D:..\image\layer1.bmp”のような「drive名つき相対path」が指定されたとして、これはどのように解釈するのが妥当なんだろうか。BMS実行時のCurrent Directory (cd)、Windows日本語版の語彙における「作業フォルダー」とは、そもそもどこを指しているのか。たとえばLR2body.exeなどが存在する場所？　それとも対象の図表fileが存在する場所？

#TITLE nanasigroove understands everything
#BPM 120
#WAV01 kick.wav
#WAV02 KICK.WAV
#WAV03     kick.wav. . .
#WAV04 \\?\D:\kick.wav
#WAV05 D:\\\\foo.///bar\../..\\..///.\..\.\kick.wav
#00111:0102030405

前述の例はWindows上ではすべて同一のfileが参照されうるが（訂正：#WAV03は除く）、Unix系OS上ではすべて異なるfilesとして解釈されるはず。どうすべきか。Angolmois/SonorousはWindows OSとの互換性を保つために、filenameを明示的にcase-insensitiveで解釈していた。図表著者の期待通りに図表を再生するために大文字小文字の同一視を要求する、そんな図表はBMS形式が生まれた頃から大量に存在するので、大文字小文字の同一視はほぼ必須要件といっても過言ではない。しかし空白のtrimや末尾periodの削除は必要か？　もし必要ならどこまで許されるのか？

以前の日記で挙げた#BMPの多重定義例に関しても、前述のそれと同様の難しい判断が求められる。すくなくとも文字列の層だけで多重定義だと判定できる箇所に関しては、codeを修正しなければならない。Programmingにおいてfilepathは基本中の基本だと思うけど、いきなり躓いている……

後日記事に訂正と追記あり。

uBMplay triumphed over

透過 PNG の処理が全体的におかしかったので修正しました！

しかし ubm は半透明に対応できないので東方音弾遊戯7の方は若干残念な感じに・・・。

http://ucn.tokonats.net/imagedll_20170913.zip

（じつのところ、私はこの結果を半ば予想していました。東方音弾遊戯7のlogo素材を単独でpreviewすると、随所に透過指定のむらが見られ、当時から気になってはいました。これはもう、仕方ないと思います。）

すくなくとも私が試した限りでは完璧に動作していました！　東方音弾遊戯7のtext layersは元からえいやっと感が目立つ素材でしたし、透過されるべき箇所（RGB:0,0,0）は完璧に透過されていたので、「uBMplay上ではこの見え方が正常」と受け止めました。

BMS/BMSONにおいて、透過PNGの減色をためらう理由はもはやなくなりました。ありがとうございました！

Pulse, Fal’Cie, L’Cie, Purge, Cocoon

Techno BMS Event “B.T.S. -Brilliant Techno Square-”から“ABC”を変換すると、手元版ではこんな感じ。仕様に準拠するようにLAYER関連の定義や参照を変更したBMSON図表と、実行すると透過PNGに変換されるべき画像を選り分けるWSH JScriptが出力される。透過PNGへの変換は各自で行う形。

  • 現在は図表fileの同位にresourcesが存在する状況しか想定していない。Pathの階層とか自前で構文解析して上がったり下がったりするの？　やだぁ……　WSHならFileSystem関連関数で解決できる？
  • 「自前で」が面倒くさすぎる。oggdec.exe並に軽量な、command-lineから透過色を指定できて透過PNGに変換できるsoftwareがあれば多少はましだけど、ちょっと探した感じではImageMagickとかいかつい感じのやつしか出てこない……
  • 現在はWindows以外のOSを想定していない。Web Browsers上で完結できれば自動的に横断的にできるけど、Internet ExplorerやFirefoxでdirectory関連操作をsupportするのは私には難しすぎる。

う〜〜〜〜ん。階層文字列の解析は後でやるとして、画像の変換は各自でお願いします、でいいかな。定義名まで勝手に変えておいて放り投げるというのは行儀が悪すぎるけど。

PNG-8 (with alpha compositing) versus uBMplay

＞PNGをPNG-8形式に変換すると、uBMplayが強制終了します。

どうやら 2bpp の PNG ファイルを読み込んだときに強制終了していたようです。

修正版を作ってみたのですがいかがでしょうか。

問題なさそうならそのままサイトの方で公開しようかなと思います。

http://ucn.tokonats.net/imagedll_20170911.zip

ああ〜そうですね、PNG-8というよりBPPが原因だったようです。微妙に当てにならないmemoで申し訳ございません。そういえば、私が“Quotation”初公開版で犯人探しした当時の書庫を思い出して確認したところ、uBMplayを強制終了させる要因となっていた画像は一枚を除きすべて2 BPP（4 BPP?）でした。しかし現在配布されている版は、全画像が透過なし8 BPPに修正されていました。

BMSON形式を睨んだ画像の構成や検証がやりやすくなるということもあり、uBMplayが減色PNGに対応していただけるのはものすごくありがたいです！　修正版DLLを私が確認した限りでは、問題を二つ見つけました。

  • 減色済み透過PNGが正しく描画される場合もありますが、結構な頻度でどこかが変になります。これは私が使用した減色PNGに問題があるのかもしれませんが、私にはよくわかりませんでした。
  • これは元からだったかもしれませんが、東方音弾遊戯7のsample BMS（Web page下部『当素材を使用したBMSはこちら。』）の、動画へのLAYERが映像著者の期待通りには透過されないようです。

BMSON関連

BMSON "keyboard-24k"の仕様を探していて、「#RANDOM分岐やencoding変更にも対応する、BMSからBMSONへの真っ当な変換器」が実装されていたのを見つけました。分岐対応すごい。私のα版を使うのではなく、BmsONEの将来版を通してBmsONEに最適な形で変換することを強く推奨します。

変換や編集とは別の、もうすこしやくざっぽい目的を達成するために、拙作版も更新を継続中です：
  • BMSON仕様の“Edge Cases”に対処しました。
  • LongNote区間内に長さ0のnotesが紛れ込んでいた場合、変換器がそれらを削除します。
  • "y"座標を基準として、配列要素を昇順で並べるようにしました。

"c":false, "l":0, "x":0などのFalsyな値が省略可能になると、BMSON filesizeを更にminifyできて良いのではと思いました。いまのところ省略できないのはCircularRhythmだけだし、CircularRhythmは専用の図表しか認識しないので、事実上省略可能と考えてもよさそうではありますが。

beatorajaとμBMSCが更新されていたので私も便乗した

  • #RANDOM系には対応しません。分岐構造をBMSON形式で表現するのは難しそう。
  • “∂○ν○ゞ＜俺が衆議院に襲来だ！！！！”など、変換後BmsONEで編集できない図表もあります。
  • ↑の図表は#WAV01で未定義の番号を参照しています。変換後のBMSON code内を"name":""で検索して、"name":"undefined.wav"のように適当に架空の音声fileの名前を定義すれば、beatoraja 0.5でも期待通りに音声が再生されます。
  • “BlackCity”のように一部の画像がBASE部とLAYER部で共有される場合、本来は変換時に、①LAYER用にそれらを新たにcopyして、②copiesをPNGに変換し、③それらにalpha-channelを与え、④それらを新たな"id"に別名で定義し、⑤参照しなおす必要があります。(todo)
  • 長さを持つnotesに対して、beatoraja extension "t" keyを付与します。変換前のBMS図表に#LNMODEを指定すれば、変換後のBMSON図表もLong notesの種類が一括指定されます。
  • 不可視notesや地雷に関しても、構文解析して選り分けるところまでは一応やっています。

[以下、2017年9月9日追記]

  • 不可視や地雷を含む図表の変換に失敗していたのを修正。
  • #TOTAL 450FLANの値を取得できていなかったのを修正。これはcharatbeatHDX拡張の「Float型を明示するoption」を実装しようとしてやめた名残でした。
  • 座標の最小間隔がPulse単位量1を下回らないように、縮小率の下限を再設定しました。今までもそのようにしていたつもりでしたがそうなっておらず、結果として前述の450FLAN図表などを変換した際に"duration"の意図せざる重なりが発生していました。

BMSONの"bga"に関して

画像によるanimationを、BMS図表とBMSON図表で同じように表示させるのは、予想外に難しいようです。BMSON形式に変換した“BlackCity [7EXTRA]”をPulsus 0.5.1で再生した結果は以下の通り。

BMSON仕様はalpha-channel以外の透過処理をもはや規定しません。BMS形式の図表だけをBMSONに変換しても、#xxx07（LAYER）は著者の期待通りには描画されないかもしれません。Pulsusやraindropは、「BMS形式の“BlackCity”」であればLR2やbeatorajaと同じように映像を表示します。つまり前述の動画の表示例は、Pulsusが各書式仕様に準拠した結果ともいえます。

余談。このBMSON図表をBmsONEで編集する際、拡大率が変なら最初にCtrl+0を実行するとうまくいきます。拍分解能を24000以下に抑えた図表ならBmsONEが扱える可能性がありますが、“∂○ν○ゞ＜俺が衆議院に襲来だ！！！！”は"resolution":14512まで肌理（きめ）を粗くしても無理でした。

LAYER用の画像はすべてPNG化したうえでalpha-channelを指定する必要があります。しかしそれだけではまだうまくいかないかもしれません。たとえば当頁下部「二次配布BMS」から、“PARTY TIME IN MY DREAM”をBMSON化して検証した際に発生した現象がこちらです。

んんｗｗｗｗｗ　BMS形式ではLAYERの透過部分によって覆われていた「再生機種の生のskin部分」が、BMSON仕様に従うと露出してしまいます。これは、#xxx04（BGA BASE）に表示される一部の画像の高さが、Canvas sizeに満たないためです。

[追記] これは“beatoraja default” skin特有の現象で、BMSONとは無関係でした。元のBMS図表とBMP画像の組み合わせでも同じ表示になりました。すみません。

表示内容の互換性について最善を尽くすなら、BGA基底部やPOOR部に用いられる画像のsizeも均す（ならす）必要があります。他にもBMSON仕様にはさらっと怖いことが書かれていて、

If there is the same value in one file, player may issue a warning, taking posterior one.

「あるpicture fileが複数の"id"を持つ場合、playerは後方の"id"を採用し、警告してもよい」。

#BMP00 40_MiB.webm
#BMP01 40_MiB.webm
#BMP02 40_MiB.webm
#BMP03 40_MiB.webm
#BMP04 40_MiB.webm
#00104:01
#01604:02
#03204:03

Resourcesを無駄に読み込みうる書き方はmobile激おこ、ということかも。この状況で#BMP00–03を無視されても困るので、変換器にはBMSE Conversion Wizard的な定義整理が求められるでしょう。

あと、暗転用の未定義#BMPはBMSON仕様では禁止されているし、未定義の"id"を参照するBMSON図表はbeatorajaを強制終了させます。前述の透過処理に関する仕様も考慮すると、

  • #xxx04および#xxx06から参照される「未定義の#BMP番号」は、ひとつに集約されなければならない。その番号に対して、「暗転用の画像（alpha-channelなし）」をあてがう必要がある。
  • #xxx07から参照される「未定義の#BMP番号」は、ひとつに集約されなければならない。その番号は#xxx04・06用のそれとは別でなければならない。集約される番号に対して、「暗転用の画像（alpha-channelあり）」をあてがう必要がある。

という感じなので、特にこだわりがないなら動画に変換するのが面倒がなくてよいと思います。[日本語が格別に不自由だったので微修正および追記] 複数枚の画像によるanimation形式を維持したまま見栄えをBMSON図表に移植するには、これまで述べたような多少込み入った手間と注意深さが要求されます。複数枚の画像によって映像を構成することに関して著者が特にこだわる理由を持たないなら、変換対象たるBMS図表の映像は事前に一本の動画にまとめておくのが手軽でよいと私は思います。

[さらに追記] 「未定義"id"の参照がBMSON仕様で禁止されている」と書きましたが、それは私の勘違いでした。しかし、未定義"id"の参照によってbeatorajaが強制終了するという事実は変わりません（すくなくともversion 0.5時点では）。

備忘録

  • 透過PNG作成さんなどでfolderと色番号を指定すれば、画像素材は透過PNG形式に一括変換できます。しかしLAYER以外の画像まで透過すると、環境次第では悲しい見栄えになります。
  • 透過部分や透過率を任意に指定したい場合は、もう一手間（ひとてま）必要です。
  • PNGをPNG-8形式に変換すると、uBMplayが強制終了します。[追記] 20170911版以降のuBMplayは強制終了しません。今後は減色された透過PNGもがんがん使っていけます。
  • PNGを過度に最適化すると、描画がうまくいかなくなる場合があります。
  • JPEG & PNG Stripperなどで余計なPNG Chunksを一括削除すると、互換性がやや向上します。
  • “PARTY TIME IN MY DREAM”の#xxx17（FREEZONE channel）によってPulsus 0.5.1は死ぬ。
// sound note
dictionary Note {
    any x;           // lane
    unsigned long y; // pulse number
    unsigned long l; // length (0: normal note; greater than zero (length in pulses): long note)
    boolean c;       // continuation flag
}

BMSON仕様によれば"x"はany型なので、FREEZONEを"x":-1や"x":"FREEZONE"などに隔離しても問題ないはずですが、実際に-1に変換するとやっぱりPulsusが強制終了します。

BMSONの巨大な座標に関して

“∂○ν○ゞ＜俺が衆議院に襲来だ！！！！”のBeginner図表（syugiin_89_B.bms）を、scrolling関連要素のみBMSON形式に変換してみました。試行錯誤する過程で得た知見をmemoしておきます。[2017年9月3日追記] 書庫も含め訂正があります。

1. 複雑なrhythm

#084–#106、および#122は、いわゆる「BMSEで編集できないrhythm」を含んでいます。
小節拍小節を何等分するか小節内分解能
#0844/4[1,4,8,16,43,192]8256
#0854/4[1,7,35,57,114,175,181,192]115550400
#0864/4[1,92,117,119,151,179,192]553950057024
#0874/4[1,31,53,59,103,106,160,173,179,186,192]296822738051520
#0884/4[1,83,122,166,181,188,192]8269620672
#0894/4[1,53,72,105,134,144,164,171,189,192]167301529920
#0904/4[1,149,154,164,180,187,192]23030441280
#0914/4[1,79,184,191,192]66633024
#0924/4[1,3,24,48,88,123,152,176,192]1645248
#0934/4[1,139,155,161,167,176,187,192]20798484020160
#0944/4[1,32,80,83,110,160,163,177,183,192]514175597760
#0954/4[1,73,90,169,180,185,190,192]24977983680
#0964/4[1,2,120,171,173,179,180,182,189,192]462602387520
#0974/4[1,130,174,180,187,192]203037120
#0984/4[1,21,60,81,129,160,175,178,192]3471854400
#0994/4[1,7,19,95,133,163,177,192]1227898560
#1004/4[1,124,147,152,178,192]493176768
#1014/4[1,20,113,129,134,173,176,192]594746264640
#1024/4[1,89,106,159,180,185,192]502643520
#1034/4[1,8,128,165,169,179,190,191,192]2318572164480
#1044/4[1,21,50,105,131,142,173,175,180,192]162194558400
#1054/4[1,25,45,141,145,179,190,192]66752107200
#106¹⁵⁄₆₄[1,5,43,45] // → lcm(64,192,2752)8256
#1224/4[1,3,6,8,12,24,48,96,128,192]384

BMSON型の大域分解能方式ではなく、小節単位で座標をparseしていく方式の場合は、#087の296822738051520を処理できる精度があれば良さそうです。そうでない場合は次節を参照。

2. 大きすぎる数値（BMSON仕様違反）

拍分解能
649204422624492997583698071949318733307465961776128654502095560800
総小節長
125.984375
最大座標
327158453726330439969834847132959809166131128112557833828149781670650

小節分解能と総小節長の積を、BMSON図表内"y"座標の最大値と仮定しています。野球君さんのこの図表におけるそれは約3.2715845372633043e68（三無量大数）、仕様違反です。しかし現時点でもBemuseとraindropに限っては、倍精度浮動小数点型の座標を受け入れてくれるようです。

1.7e±308 ?:
Bemuse, raindrop
0–4294967295 ?:
BananaBeats, beatoraja, BmsONE, CircularRhythm, Pulsus, raindrop, woseq

[追記] #STOP01 40000を完全に忘れていました……。正しくは以下の通り、「最後の小節線の座標」よりも停止時間のほうが大きくなります。約五無量大数です。

拍分解能
649204422624492997583698071949318733307465961776128654502095560800
総小節長
125.984375
最大座標
327158453726330439969834847132959809166131128112557833828149781670650
停止時間
541003685520410831319748393291098944422888301480107212085079634000000

後述のいくつかの誤りは、停止時間のpulse換算値を考慮していなかったのが原因でした。

3. 引用符で括られた数値（BMSON仕様違反）

JavaScriptは大きすぎる整数を正しく扱えません。数値型のままだと入出力の際に誤差が生じうるので、私は暫定的に数値を文字列化して出力しています。しかし、型が異なる値は仕様違反です。

Tolerate "Number":
BananaBeats, beatoraja, Bemuse
Strict Number:
BmsONE, CircularRhythm, Pulsus, raindrop, woseq

4. BMSON仕様に準拠する図表が期待通りに再生されるとは限らない

Chart-editorsが巨大な座標を管理するのは、見るからに難しそうです。仕様に準拠する図表が正しく再生されない状況は他にもあります。前述の書庫内の最小の図表は、元の座標を59桁shiftして、さらに4で割って丸めたものです。59桁shiftするだけでは、beatorajaでは再生されませんでした[Note]。[追記] これは、桁shift時に前述の停止時間が4294967295を超えていたこと（それを私が見落としていたこと）が原因だったようです。beatorajaは仕様通りでした。むしろPulsusが桁移動するだけで再生された件が謎。[さらに追記] そんな事実はなく、Pulsusも仕様通りでした。私が寝ぼけていただけでした。お騒がせしました。

4294967295 or ↑:
beatoraja[Note], Bemuse, Pulsus, raindrop
2147483647 or ↓:
bananaBeats, beatoraja, BmsONE, CircularRhythm, woseq
24000 or ↓:
BmsONE

実装ごとに許容される座標の上限が異なるので、gimmickyなBMS図表の完全移植は諦めるしかなさそうです。巨大な数値も引用符で括られた数値も受け入れてくれるBemuseに私は賭けたい。[追記] 普通に仕様に従って4294967295を上限とすれば、「だいたい合ってる」水準までは達成できそう。

  • [さらに追記] beatoraja 0.4.3において、上限は4294967295ではなく、2147483647でした[Note]。
  • [さらに追記] BananaBeatsも、座標2147483648を読むと、result画面が出なくなります。
  • [さらに追記] CircularRhythmはPromise関連のerrorが出ていますが、よくわかりません。

5. その他

座標を縮めた結果、#106の"stop_events"の予期せぬ合体が発生しています（"y":695189736と"y":697353751が複数ある）。縮小による改竄を避けたいけれど、よい方法を思いつきません。[追記] これは私が座標算出時に小節長を考慮し忘れていたからでした。直しました。そもそも縮小によるmoiréを抑えるようにcodeを書いたはずなので、こんな現象が発生する時点で他の原因を疑うべきでした。

あと、変換された"bpm_events"を眺めていて疑問に思ったことがあります。値が変わらないBPM変更eventsを192分音符単位で敷き詰める方法には、何か意味があるんでしょうか？　charatbeatHDXのようにBPM変更を視覚化する機種において、図表を彩るとか、そういう発想かしら。

日記

BMS関連

拙作BMS
bubble / hitkey
二次配布BMS
ノイズの海と鯨 / moka
PARTY TIME IN MY DREAM / HAIJI
BMSE非公式ヘルプ
Lite
Lite-online
Full
Full-online
buglist
iBMSC
Web (Japanese version)
issues
BMS差分
a­nal­gam
boléro
Ketch­up
quovadis
SELF
yellows
Do not use non-ascii filenames
雑多なメモ
bmsplayer data
bms benchmark
Secrets - Feeling Pomu 2nd
grid2sec
bmx2xxx
BMx Outliner
BMS command memo
BMS command memo (Japanese version)
BMS EVENT LITE
#RANDOM BMS list
BMS #OPTION command
BMS Bitmap test
Extended BPM
STOP Sequence
BMS Edge Cases
BMS extensions proposed by Sonorous (unofficial Japanese version)
BMS 2.0 (unofficial Japanese version)
BMS Editors
Do not use non-ascii filenames
BM98 Kikuchan Version 3.30 Revision #4.2
BMSON Checker

その他

HTML関連メモ
Dakuten on HTML
nest1000
EVS
Nervous Cascading
Source Han Sans test
User-Agent String
CSS Logical Properties