doubledepth

頭痛と眩暈が酷い

CREATIONBMSON差分Layered Notesおよびbeatoraja独自拡張("ln_type"の個別指定、BackSpinScratchを含むLongNotes終点発音、"scroll_events")を使用する。でも小数値の"scroll_events"が効かなくて悲しかったので、BMS-on形式のBMSも同梱した。こちらはbeatoraja以外のBMS clientsでも遊べる(KEY音なし・LR2IR登録不可で構わないなら)。なんならBMSE上で音声裁断さえできる(BMS-on形式をsupportする変換器、たとえば拙作変換器を通すなら)。

風邪をひく

日本は本州にももうすぐ雪が降りそうな季節だが、数日前に乾季のHawaiiめいた夏日が訪れた。その日の夜、私は就寝中の体温調節に失敗し、盛大に寝汗をかいて毛布を蹴っ放ってそのまま臍を天に眠り続け、翌朝震えて目覚めた。

Boob me baby

███████の曲名をbeatoraja上で表示させたりQuadrupolarの小節線を消し去ったりして遊んでいた。“Quadrupolar”の図表制作技術力は卓越している。私の頭ではBGM列35–38列目のguideさえ満足に組めない。図表自体のscrolling速度も併せて考えるとQuintupolarとみなすこともできる?

われら こくどうたんけんぶんたい 恐怖のR425編の小節長は八分音符単位でNarrow化が進行する。小節線の明滅間隔を合わせたくてもこれは無理。BOF全曲が長尺になれえ〜

Xanadu VoIceがuserに促す行為は、図表の層構造の隠喩というか直喩かなあ。私は最初の図表と最後の図表だけを遊んだ自分の体験を「多少もったいないことをしたな〜」と悔いている。

純子先輩というか[3 COLORS / NO CHEESE / BMS DAWN]が最高にteam戦していて泣けた。


HARDCLEAR markやFULLCOMBO markが悪しきnudging(sludge)に感じられることは以前からたまにあった。SCOREだけが評価軸というのも寂しいし、あったほうが多面的にやりこめるんだろうけれども。

かつてなくBOFXVIが捗った日

寒いと手が動かないので明日も暖かいと嬉しい。

萌・生 ~GERMiNATE~のBackGround Illustrationは3500 × 3500 pixelsですごいおっきい。8K UHD時代への備えとして、静止画ならSVG形式とかが使えると嬉しいかもしれない。こんな感じ:

#BMP01 fallback_256x256.bmp
#BMP02 scalable_vector.svg
#00104:01
#00107:02

でもSVG parserを自力で書けと言われたら私は発狂してしまいそう。

BMSEはWMF形式の画像を描画できるようなことがreadme.txtに書かれている。先見の明がありすぎる。

#PREVIEW#RANDOMはたぶん働かない

beatoraja, BMX2WAV Searcherおよびraindropでは、分岐の有無を問わず最も後方側にある#PREVIEW行の内容が常に演奏される。Bemuseはserver上にtest用BMSをuploadして試してみないことには不明。

beatoraja上で#PREVIEWpreview(*).wav(ogg)が競合すると、#PREVIEWが勝つ。beatoraja上で#PREVIEWは繰り返し再生される。今日まで知らなかった。

Qwilightは#PREVIEWをsupportしていないが、選曲画面上で図表が照準される度にBMS parserが走り、適当な小節からpreviewが開始される。最近の版ではpreview用に読み込んだresourcesを演奏画面でもそのまま使い回すようになり、読み込み効率が高まったらしい。

LR2に関しても#PREVIEWに依らないpreviewが可能だが、previewを無効にするとmemory leakをそこそこ抑制できるという呟きも見つかる。もしかしてpreviewが有効だと、選曲画面上で通り過ぎた図表全部のresourcesを抱えたまま遊ぶことになるのか。それはLR2も強制終了しちゃうわね……

Fluteは固定運指

英語では録音機も縦笛も“recorder”で区別がつかないためfluteと表記したが、ここでは日本の義務教育課程で訓練させられる縦笛を指す。BMSに限らず「複数の鍵盤の同時押し状態が休みなく続くため、notesに割り当てられた音声が演奏者に認識されづらい図表」がままある。個々のKEY音を演奏者に示すことを重視しない図表に演奏感があるとすれば、それは複雑な運指の結果として音程ひとつのみを発音する縦笛の演奏感に近いかもしれない。

BMSON Layered notesの仕組みを考える。縦笛のような「同時押しが成功した場合のみ発音されるKEY音」が制度として用意されれば、切り分けられていない和音の波形一個を複数の同時押しnotesに分割して割り当てるような図表が書けるだろう。なんというか絶対に誰かが思いついていただろうが過度に面倒くさそうで破棄された発想という印象が強いが。これができるなら、長さ90秒の波形が一本あれば仮想裁断して適当に同時押しに分配した「有KEY音BMSON」が捏ち上げられそうだが。

話を戻す。打楽器の演奏感と鍵盤楽器の演奏感と縦笛の演奏感はそれぞれ異なるのではないだろうか。そして少なくとも日本においては、打楽器経験者よりも鍵盤経験者よりも縦笛経験者のほうが多いのではないだろうか。義務教育段階の器楽教育に関する調査によれば、

問2では,93%の学校が鍵盤ハーモニカを個人所有としているとの回答であった。それ以外の学校でも,「ホースのみ個人持ちで学校に備えてある」「保育園や幼稚園で購入し入学前に必ずもっている」との回答など,児童すべてにいきわたるようになっていた。ソプラノリコーダーは,ほぼ100%の学校で個人所有となっていた。カスタネットを個人所有としているのは19%,地域によってはアルトリコーダーを個人所有としている学校(3校)もあった。

十年後の現状に関する資料は見つけられなかったが、(打楽器を非固定運指の亜流とみなし、また縦笛を固定運指の一派と認めてもよいのなら、)ここ十年間のRhythm-action gameの素地として固定運指のほうが人口に膾炙していた可能性はある。PC Keyboard環境が入り口であれば尚更に。

などと仮説を立ててはみたが、“固定運指”で一応検索してみたら身も蓋もない理由が出てきた。

また北斗が忌避される理由は、低難易度の譜面を北斗で打っていると、力の入りやすい人差し指や中指のみで鍵盤をたたく癖がつき、高難易度になった時に他の指が使えずに実力が頭打ちになることが多いからです。

そっか〜それはそうだよな〜。私もToy Musical 3では既定のkeyconfigで5BUTTON/NORMAL/HYPERのFULLCOMBO未達成図表が合計20枚を切るところまではできたが、これ以上頑張るのは無理と感じる。まあこんなものだろう、ペーパーファンクNを北斗でSSSS狙うの楽しい〜、と私なら諦めもつくが、自分が劣っているように感じられる状況をそのままにしておけないというのは真っ当な反応だろう。

自分の環境にK-Lite Codec Packを導入していたことを思い出した

つまり、動画形式に関する私の調査まるで意味がなかった可能性が高い。意気消沈太郎

LAV FiltersインストールしてWin7DSFilterTweakerで32-bit decodersの方のH.264をLAV VideoにするとLR2でmp4再生できるゾ

という呟きを見かけた。それが本当なら動画はMP4ひとつだけで済みそう。お役立ち情報。

高画質動画について思うところを書きかけていたことも思い出した。

wholeheartedlyの高画質動画(2560 × 1080 pixels)は、4K解像度(3840 × 2160 pixels)環境下のBMS clientsに最適化されているように見える。8K解像度(7680 × 4320 pixels)のUHD時代になっても、この動画ならmosquito noiseなしに鑑賞できそう。BMS一作1 GiB時代の到来。

LAST PROPOZEの1680 × 1680 pixels画像も、大画面なら手描きの筆致まで鑑賞できそう。

このまま加速度だけが増し続けたらしばかれる顔の毛穴までくっきり見えそう

beatoraja 0.8 vs. HARDTEK DJMIX (monauralized)

Total
size
1st2nd
WAV1.31 GiB6.28 sec
48.77 sec
6.18 sec
5.84 sec
OGG112 MiB21.56 sec20.74 sec
FLAC493 MiB13.15 sec12.52 sec

先日の検証に続き、“HARDTEK DJMIX”の全音声をmonaural化したうえでbeatorajaに投げてみた。なぜかWAV形式の初回読み込み時間が爆速化したが、理由がさっぱりわからない。[追記] Wavosaurの一括処理を経て、Monauralized WAV filesがcacheされていたようだ。日を改めて計測した結果、むしろSTEREOの時より読み込み時間が増大した。おそらく考え無しに全音声をmonaural化したために随所で音割れが発生し、beatorajaのlimiterが余計な仕事をさせられたという経緯がありそうだ。

以下の節はすべて翌日追記分

事実上monauralであるstereo音源(註釈)のみをmonaural化したのち、再び同様の検証を行った。

Total
size
1st2nd
WAV2.60 GiB30.63 sec5.93 sec
OGG160 MiB33.56 sec33.38 sec
FLAC931 MiB16.19 sec16.34 sec
(註釈)

以下に列挙される音源は事実上monaural。

  • 2_fx2_001.wav
  • 4_sweep1_000.wav
  • 4_sweep1_001.wav
  • 4_sweep1_002.wav
  • 4_sweep2_000.wav
  • 4_sweep2_001.wav
  • 4_sweep2_002.wav
  • 4_wobble3_000.wav
  • 4_wobble3_001.wav
  • 4_wobble3_002.wav
  • 4_wobble3_003.wav
  • 6_subbass.wav

音声形式と読み込み時間の比較

beatoraja 0.8 vs. HARDTEK DJMIX
Total
size
1st2nd
WAV2.62 GiB33.85 sec5.66 sec
OGG204 MiB36.38 sec36.42 sec
FLAC931 MiB16.42 sec16.82 sec

Launch4jでEXE化したbeatoraja.exe(version 0.8, ModernChic skin使用)」のshortcut.lnkに引数-aを付与しておく。このshortcut iconに対し、現時点で最も巨大な音声resourcesを持つと思われる“HARDTEK DJMIX”のBMSON fileをDrag-and-Dropし、演奏画面のscrollingが開始されるまでの時間を雑に計測した。Computerに疎い私はこの結果が何を意味するのか理解していない。

  • WAV形式は2回目以降の読み込み時間が極端に短縮される。Buffer cacheというやつだろうか。
  • OGG形式は非可逆圧縮。圧縮率は高く、decodingは遅いようだ。
  • FLAC形式は可逆圧縮。圧縮率は普通だが、decodingは速いようだ。
  • RESULT画面で鍵盤7番を押し続けてRETRYすると、音声形式を問わず4秒弱で再演奏が開始された。

私は選曲画面をほぼ使わないので以下は当て推量だが、beatorajaの選曲画面が#PREVIEW用のresourceをmemoryに出し入れするtiming次第では、D3C3MB3Rのようなさりげない工夫にも効果があるかもしれない。この作品のOGG版は、preview用音源だけはWAV形式のまま同梱している。いま確認しようとしたところBOFXVI会場に全然繋がらなかったので、私の勘違いかもしれないが。

BOFXVIに登録されたBMSON作品について

可能ならsafe_stateCREATIONはbeatoraja/Pulsus/raindropで遊びたい。

  • beatorajaは全部遊べる
  • raindropもだいたい遊べるKEYBOARDMANIA系の図表や、1 GiBを超えるresourcesを除く)
  • Pulsusもだいたい遊べるKEYBOARDMANIA系の図表や、DoublePlay図表を除く)

BananaBeats/Bemuse/Qwilightもだいたい遊べる。たまにCOMBOが切れるはずがない箇所で切れたり、KEY音が一部しか鳴らなかったりするかもしれないが、作品の概要を把握するには充分かと。

(退屈な詳細)

safe_stateCREATIONLayered notesを持つ。beatoraja, BmsONE, Pulsus, raindropがこの特徴を実装している。(BananaBeats/Bemuse/Qwilight上で、Layered notesは“fusioned”されない。重ねられたnotesを素早く連打すれば別個に判定・発音されるが、どこにnotesが重ねられているかは演奏者には見分けられない。それはそれで楽しいが図表著者氏が意図された体験ではなさそう。)

“safe_state”初版は音声定義の拡張子部分を省いていたBananaBeats/Bemuse/BmsONE/raindropはこの特徴を実装していない。修正版のほうがtimestampが古いが、BMSON file以外は完全に同じ内容。

Nothing But Sevenは24 keys図表と48 keys図表を持つ。これらの図表形式をsupportする実装は今のところbeatoraja, BmsONEのみ。BananaBeatsはどちらも18 keys図表として解釈する。

Make MeはBMSON 9 keys図表を持つ。この図表形式をsupportする実装はBananaBeats, beatoraja, BmsONE, Pulsus, raindrop。BemuseはBMSON 9 keys図表を7 keys図表として解釈する。QwilightはPMS fileなら検出してくれるが、BMSON 9 keysは選曲画面に現れない。

IL-HEL-U初版はWindows full pathで音声を定義していた。修正版は全BMSON実装で遊べる。

“safe_state”, “CREATION”, “Make Me”, “IL-HEL-U”はWebM形式の動画を持つ。QwilightはWebMをsupportしていない。

beatoraja 0.8’s BPM graph

“beatoraja 0.8のBPM graphは偽ることができる。

前述の画像はbeatoraja 0.8から同梱されるようになったModernChic skinの、resources読み込み中に表示される情報。左半分はIL-HEL-UのBMSON図表、右半分はそれを手元で修正したもの。曲終了後の余分な小節線がBPM graphを引き伸ばしている。邪魔であれば余分を消せばよいし、graphを詐称したい場合は遠い座標に小節線を設置すればよい。この方法が今後も有効とは限らないが。

BMS形式の図表でも、曲が終わった後に無音声noteを置いている例がある。これによってresult画面に移行するtimingを調整したり、FULLCOMBO effectのtimingを調整したりできるようだ。

BOFXVIのpath定義

Teruyuki”, “untitled tr.01”, “BATHALA”, “Lumpiang Shanghai Deluxeがpathの定義を持つ。後者2作品のPOOR画像animationは、beatoraja, nanasigroove, Qwilightでは描画されない。

Bad:
#BMP04 \miss\mali_00.bmp
Good:
#BMP04 miss\mali_00.bmp

図表が修正されれば、前述の実装は問題なくPOOR画像animationを描画できる。

  • BananaBeatsはPOOR画像をsupportしない。動画定義の先頭に\を足すと動画は描画されない。
  • charatbeatHDXはPOOR画像をsupportしない。動画定義の先頭に\を足しても描画される。
  • PulsusはPOOR画像をsupportしない。図表が修正されれば、Pulsusはerrorsを発しなくなる。
  • QMS-playerは未修正版のPOOR画像を描画できるように見えるが、animationにならないようだ。
  • 以下の実装は未修正版のPOOR画像を描画できる: Angolmois, BGAEncAdvance, BMSE, LR2, mBMplay, nazobmplay, raindrop, ruv-it!, uBMplay, …

ここまで書いておいてなんだが、冒頭の\miss\mali_00.bmpがpathとしてvalidなのかinvalidなのか、私には分からない。/miss/mali_00.bmpはWebでは妥当なRoot pathだが。Webじゃないが。

びっくりするほど

1年越しに話題になった「リズムアクションゲームにおけるキー音の自動推定」論文において、参考文献として”BMS command memo (JP)”が載っているようです。([10])

https://www.art-science.org/journal/v18n1/v18n1pp10/artsci-v18n1pp10.pdf

ご紹介ありがとうございます、興味深いお話でした! この研究には続きがあり続きの続きでは「そこそこ遊べるKEY音つきBMS file」の自動生成まで既に到達されているようです。実用化される日がもし来るなら待ち遠しい! 各userが各client環境で自分好みのpatterning傾向と自分好みの難易度を学習させて自分好みのBMS fileを自動生成できるようになっちゃえ

最低難易度ではキー音でないBGMのオブジェクト数と比べてキー音であるオブジェクト数が大幅に少ないことから、キー音であるオブジェクトについてもfalseと判定されやすく、特にキー音における再現率が極端に低下するという問題が見られた。

—リズムアクションゲームにおけるキー音の自動推定

それは「演奏領域の密度を下げるために、phraseの音声断片のうち一部だけをBGMに移す手法」が原因なのでは。譜面作成時の手間を省き書庫容量を節約するための現実的な妥協ではあるが、KEY音の取捨選択判断のmodellingのとっかかりとしてはplugout4とかのほうが適切だったのでは。妥協の産物を最初から大量に学習した自動生成器、大丈夫なんだろうか。

ケモナーマイハウス

前者2つは"アンチエイリアスがかかってないといや+透過BMPはLR2がうまく読まない"、後者1つは"透過させる表現"で透過PNGを用いています

教えていただきようやく私もJet to 1990のAlpha blendingに気が付いた。後半、着色されたLAYERの向こう側にBGA基底部の雲が透けて見える。これを透過なしでやろうとするとりりりくろclock folderみたいなことになる。巨大なBMSを高圧縮したいsack_ma氏の記事

Y.L.Cafeの初版には32-bit透過BMP形式のLAYERが用いられていた。当時の当日記も言及していたので、これは私の記憶違いではないと思う。あるいは当時から私が勘違いしていたか。現在downloadできる版のLAYERは透過性を持たない。LR2でうまく描画されなかったことを受けて修正されたのかな。

ベートーヴェン: 交響曲第9番 二短調 Op.125 第4楽章LAYERへの言及に補足

あらすじ: 完全に黒一色で描かれていたLAYER指揮者くん

元から描画可能:
Angolmois, HDX/IIDXv, LR2, mBMplay, QMS, ruvit
PNGOUT.EXEを通せば描画可能になる [註釈]
beatoraja, BGAEncAdvance, nanasigroove, Qwilight, raindrop#BMP06のみ描画されず)
描画不可能:
BananaBeats, uBMplay 1.5.x

Alpha channelを解する現在到達可能なBMS clientsは前述の通りのはず。uBMplayのそれは部分的なsupportだったはずなので(“Jet to 1990とかめっちゃ色黒になる)、よくわからないのはBananaBeatsだけ。BananaBeatsはNeonfallJet to 1990のLAYERなら問題なく描画できる。

[註釈追記] 私は完全に勘違いしていた。実際はpngoutに通す前にLAYER画像をImageMagickでtextに変換し、color code “(0,0,0,(1,1,1,に全置換したtextを画像に再変換していた。前述のほぼ全ての実装が描画できる透過LAYER画像差分

内容なんてウチにはないよ……

ラーメン三銃士ネタ好きだったりするのかな…

内容と比べてどうでもよすぎる疑問失礼しました

BananaBeatsで遊ぶMirrorcle World (Hard Schedule Mix)みたいな画がとても好きです

透過領域と完全な黒色を併せ持つLAYERの実作例を思い出した

ベートーヴェン: 交響曲第9番 二短調 Op.125 第4楽章の終盤で荒ぶる指揮者がそれ。このLAYER画像には「完全に透過される完全な白色」と「透明度の濃淡によって人型に模られる完全な黒色」の二色しかない。指揮者自体がRGB(0,0,0)なのでbeatoraja上では透過され、不可視化する。このLAYERを指揮者として描画できる実装はAlpha compositingをsupportしているはずであり、事実としてこのBMSを遊んでいるuserには指揮者のwhite shirtが基底画像とblendされ青みがかって見えるだろう。

BOFXVI大容量三銃士

  1. Lustige Kartoffelは全音声が32-bits Float形式で、合計すると1 GiBを超える。
  2. Midnight Graveyardも全音声が32-bits Float形式で、合計すると855 MiBくらい。[追記] WAV版はOGG版に取って代わられた。書庫展開後の合計sizeは66.2 MiBまで縮小された。
  3. wholeheartedlyの高画質動画は2560x1080 pixelsのMP4形式で、filesizeは817 MiB。

こういった例外的なresourcesは私にとってはありがたい。

BMX2WAV v2.0.0に“Lustige Kartoffel”を放り込むと、短い無音WAVが生成される。「変なdataを食わされてもapplicationが強制終了しないこと」はとても凄い。32-bits Float形式の音声が部分的に使われた作例は過去にもいくつかあったが、全音声が32-bits Floatというのは貴重だ。

“wholeheartedly”の高画質動画を得た状態で、図表fileを適当にcopyしてメモ帳などで開き、#BMP01の拡張子部分を以下のように書き換えつつ、一行書き足す。

#BMP01 BGA.mp4
#BGA01 01 2304 824 2560 1080 0 0

書き換えた図表をBGAEncAdvanceで変換すると、高画質動画の右下隅256 pixels四方だけをcropした動画fileが生成される。私の環境では変換中にencoded frame too largeが大量に表示されたが、変換そのものは完遂されたのでとても凄い。


演奏画面の背景として演奏画面よりも高画質で再生される動画について思うところを以降に書こうとしていたが、傍らで走らせていたencoding処理が2時間半を経てもまだ終わらず、textを保存してHard Disk Driveを鳴らすのがとても怖いので、唐突に終了。

透過領域と完全な黒色を併せ持つLAYERのsample

先日に「透けるPNGの利点のひとつは完全な黒色をLAYERとして使えること」と書いたが、これは正しくなかったAngolmois/LR2/HDX/IIDXView2015/QMSは書いた通りに透過領域のみを透過するが、その他の実装は黒色領域も透過する。またPulsusはBMS parserとBMSON parserで解釈が異なる。

BMS LAYER imageが透過領域と完全な黒色を併せ持つとき、BMSON変換器はどうすべきか。べつにどうもする必要ないか。そんな特殊な状況なら拙作変換器由来の生成画像はごみ箱に捨てて、BMSON file上の文字列___alpha_layer_を空文字列に一括置換するだけでBMSONの"bga"仕様を満たすはずだし。

  • BananaBeats/Pulsus/raindropは「透けるPNG」の"layer_events"を描画できる。
  • beatorajaはBMSONの"layer_events"を実装していないように見える。
  • Bemuse/Qwilightは動画形式の"layer_events"なら描画してくれる。

というわけで、BMSONで互換性を重視するなら動画形式が有利、画像LAYERは不利。

BMSON図表における動画指定

結論から書くと私は以下の形が良いと思う。

  • MPEG1形式で動画を用意し、図表には拡張子mpgを直接定義する。
  • 必要なら更にMP4形式の動画も用意し、図表には拡張子mp4を直接定義する。

基底名を同じくするMPEG1とMP4を両方同梱し(たとえばVIDEO.mpgVIDEO.mp4、図表にmp4を定義しておけば、BananaBeatsではMPEG1動画が・それ以外ではMP4動画が再生される。MPEG1はBOFXVIのRulesに明記されるだけあって、fallbackとしては超優秀。

各BMSON実装がsupportする形式
WebMMP4WMVMPEG1
BananaBeatsYesNoYesYes
beatorajaYesYesYesYes
BemuseYesYesNoYes
PulsusYesYesYesYes
QwilightNoYesYesYes
raindropYesYesYesYes
  • 演奏機がWebM形式を実装することをBMSON仕様は期待しているが、実装を義務付けてはいない。
  • Error SectorのMPEG1動画は、私の環境では前述の全実装で描画された。
“Error Sector”のようにMPEG1とMP4が同位に存在し、図表がBGA.mpgを定義している場合:
  • Bemuse/raindropは、まず定義されたBGA.mpgを探し、存在しない場合は動画を再生しない。
  • Pulsus/Qwilightは、まず定義されたBGA.mpgを探し、存在しない場合はBGA.mp4を再生する。
  • beatorajaは、定義されたBGA.mpgよりも先にBGA.mp4を探しに行く。
MPEG1とMP4が同位に存在し、図表がBGA.mp4を定義している場合:
  • beatoraja/Bemuse/Pulsus/Qwilight/raindropは、定義通りにBGA.mp4を再生する。
  • BananaBeatsは、定義されたBGA.mp4を再生できないが、BGA.mpgを探してくれる。
“Error Sector”を「BMSON実装でうまいことやれるように」変換するなら、動画の定義部分は:
"bga": {
    "bga_header": [
        {"id": 1, "name": "BGA.mp4"},
        {"id": 2, "name": "miss layer.bmp"}
    ],
    "bga_events": [
        {"id": 1, "y": 960}
    ],
    "poor_events": [
        {"id": 2, "y": 2640}
    ]
},

"y"の値は分解能によって異なるので、勘で適当に合わせてね

BMS/BMSON LAYERs

BOFXVI登録作品群を調査中。一次登録分(No.1–443)のpackageにお世話になりました。

透過性を持つ画像LAYER

Neonfall”, “SUPER ANIMAL SCRATCH ROYALE”, “Jet to 1990のLAYER image filesが「透過性を持つPNG形式」だった。私はこの流れを歓迎する。

  • 最近のgroupに属する演奏機はほぼすべて、透けるPNGをLAYERとして描画できる。
  • ただしuBMplayはimage.dllが古い場合は強制終了しうる。nanasigroove2は不明。
  • やや古めのgroupで非対応なのは、Feeling Pomu Second, nazobm+Glasopal, PMSee-Vくらい。
  • 透けるPNGの利点のひとつは、LAYERとして完全な黒色を使えること[追記] そうとも限らない
  • もうひとつの利点は、BMS形式とBMSON形式で同一のLAYER image filesを共用できること。

PulsusがPNG8形式の画像に対して警告を発したことがある。これに関しては私の環境や変換指定の仕方が良くなかったのかもしれないが、この経験から拙作変換器は無難な方法としてPNG32形式の画像を生成している。しかし冒頭の3作品を見た感じでは、私の変換器よりもうまくやる方法がありそうだ。

(余談。“Neonfall”preview.oggを除く全音声が15500 Hzだった。私はそれを知らずにAngolmois 2.0a3にBMSをdropし、凄まじい雑音の直撃を受けた。)

基底部を欠く画像LAYER

La souvenirおよびRogue Gは、BGA列でなくLAYER列にのみ画像を配置している。
当該箇所のBMS code:
#BMP01 Rogue_G.png
#00007:01

#00004:01なら確実に描画される)

拙作変換器を経た、仕様に準拠するBMSON code:
"bga": {
    "bga_header": [
        {"id": 1, "name": "___undefined_black.png"},
        {"id": 2, "name": "___alpha_layer_Rogue_G.png"}
    ],
    "bga_events": [{"id": 1, "y": 0}],
    "layer_events": [{"id": 2, "y": 0}]
},

(この変換器はもうちょっと賢く対処するべきだ)

各実装が描画できるか
BMSBMSON
BananaBeatsYesYes
beatorajaYesNo
BemuseNoNo
PulsusNoYes
QwilightYesNo
raindropYesYes

LAYER列でなくBASE列に画像を置けば、この表のdata cellは全部“Yes”で埋まる。[追記] ごめんなさい、Bemuseは無理でした。BMSON形式なら"back_image"に定義した画像が背景に描画される。

基底部を欠く動画LAYER

Colors Out of Space”, “Tetrachromat”, “Mirrorcle World (Hard Schedule Mix)”, “Dragon's Blood Tree”, “浮灵, Samudra”, “Song of Four Coolness”, “Quantization”, “A Nameless Nova”, “眸古(Eyes to the Past)”, “Tian'Xuan”, “舞灭, Tandavaは、BGA列でなくLAYER列にのみ動画を配置している。

各実装が描画できるか
BMSBMSON
BananaBeatsYesStrange size
beatorajaYesNo
BemuseYesYes
PulsusNo1 frame
QwilightYesYes
raindropYesYes

動画は描画される形式なら融通が利くが、formatの非互換性が重くのしかかる。「全機種が描画できる動画形式」はおそらく存在しない。[追記] 動画を基底名から拡張子まで一字一句たがわずBMSON図表に定義できる状況なら、MPEG1形式は全実装で再生されうる。但しMPEG1形式にもCodecsの問題はある。

予約された動画LAYER

Stellariaは基底部に画像を配置し、LAYERに動画を配置する。ただし現時点では動画が存在しない。『後ほど追加でBGAの方をご用意させて頂く所存です』とある通り、後で追加されるかもしれない動画のために枠を確保しておくという、よく知られた工夫のひとつ。BMSのInternet Rankingは図表のfile hash値を用いるため、これを変更せずにうまいことやれるhacksがいくつか捻り出された。

#BMP02 stellaria.png
#BMP03 movie.mpg
#00004:02
#00007:03

当該箇所のBMS codeはこの通り。「存在しない画像だけを先に定義しておき、画像の拡張子挿げ替え検索で動画が引っ掛かることを期待する手法」も見かけたが、それは実装依存度が高そうだ。

[追記] 動画LAYERを予約する方法は、画像の挿げ替え検索に期待する方法よりは確実そうに見える。しかし「動画LAYERのRGB(0,0,0)領域を画像と同様に透過する実装」がもしも存在したなら、その環境で動画は製作者の期待通りには描画されないかもしれない。

今は楽しくやってるよ、トゥットゥルー

Xanadu VoIceの、に更新された版の、に更新された図表の、#010#025は、図表の誤りを持つかもしれない。それはさておき興味深い作品だった。

開催中のBOFXVIに関して、以下は図表の誤りかもしれない。いくつかは修正済みかもしれない。

以下は誤りとは言い切れないかもしれない。

wsh_count_bgm_lines.js

v0.0.2: #RANDOMが使われたBMSを除外
v0.0.2
  • #RANDOMが使われたBMSを除外
v0.0.1
  • 公開

このWindows用JScriptは、指定されたfolderを検索し、BMS filesのBGM行数を列挙する。

  1. Windows XP以降でこのtext fileを保存し、メモ帳などで開く。
  2. 21行目あたりと23行目あたりの変数の値を適宜書き換え、保存してメモ帳を閉じる。
  3. このtext fileの拡張子を.jsに変更して、左double-clickなどで実行する。
  • LIMIT_BGM_LINES_PER_MEASUREの値を32に変更すると、「BMSEで開いた時点でBGM情報が欠損するBMS」だけが列挙される。(「列挙されなかったBMSがBMSE safe」というわけではないので注意)
  • TARGET_FOLDERの値について、path区切り文字は/\\で記述する。

私はBMSEで編集できる図表はBMSEで編集したいので、BTS差分を組む前に全図表の大域分解能や使われたchannelsやBGM列数などを手早く調べるためにこれを書いた。回想 -Minimal Techno Mix-のANOTHER図表#024は俺じゃ見逃しちゃうね。このJScriptは入力値検証などを怠けており、BGM行の判定も雑なので、あまり信頼できるものではないが、当座をしのぐ役には立ってくれた。

J-un Kombat

FLAC形式は8-bit音源を扱えるが、公式repositoryの最新commitを反映した64-bit Windows用変換器はBMS appsほど寛容ではない。たとえばBoleroの各音源をFLACに一括変換すると幾つかの警告や誤りが発生し、beatoraja/mBMplay/Qwilightで演奏した際に最初のkickが鳴らないなどの不具合が生じる。なおXRECODE3“Bolero”の全音源をFLACに一括変換すると最初がGabber kickと化す

この問題は、元々の“Bolero”のWAV filesの一部に不明なchunksや巨大なmetadataが埋め込まれていることが原因。SoundEngineで上部Menuの「設定」→「タグ情報の保持」のcheckを外し、以下のSoundEngine scriptを実行すれば、各音源から余計な情報が剥ぎ取られる。

[Folder Open]
Text=処理するフォルダを選択してください。
[Folder Save]
Text=出力フォルダを選択してください。
Sec=None
Extension=wav
[Message Box]
Text=処理が終了しました。

このscriptは波形を一切変更しない。この処理の前後でBMX2WAV変換結果を比較すると完全一致する。この処理を経た“Bolero”の音源は正常にFLACに変換できる。「StudioOneから出力されたWAV file」をwoslicerが開けない場合も、この方法で解決できる可能性がある。

Oh TEAM TEAM

先日の泥臭い方法をAudio Bit Depthに応用すると「劣化なく8-bit化できる音声(8-bit量子化雑音を含んだ16-bit音声)」を検出できる。滅多に見かけないが。「信号の劣化なしに」という条件を「聴覚への影響を最小限に」まで緩めれば、Audio Sampling RateやAudio Bit Depthの最適化処理も自動化できそうではある。聴覚への影響を定量評価できるsoftwaresがあれば。WaveError……はちょっと違うか。GoldWaveWavosaurのBatch processingでうまいことやれると良いのだが、前者は無料ではないし、後者はやりたい処理が選べない。まあ「Monaural化したい音声filesを適当なfolderにまとめて一括Monaural化」などのよくある一括処理なら、WavosaurはSoundEngineよりも素早く完了する。非公式日本語化patchがありがたい。最近のGoldWaveは多言語切り替えができ、日本語も選択肢に含まれる。MenuのHelpが「助けて」になっているお察し品質だが、そんな翻訳でも私にはありがたい。

Stereo形式のMonaural波形を泥臭く探す

  1. 調査対象BMSをfolderごとcopyする。各folder nameは便宜上original, copy1, copy2とする。
  2. copy1 folderに対し、以下のSoundEngine script “Monauralized L”を実行:
    [Folder Open]
    Text=処理するフォルダを選択してください。
    [Silence]
    Selection=0,-0,1
    [Format Converter]
    Selection=0,-0,-1
    Channel=1
    Quality=3
    [Folder Save]
    Text=出力フォルダを選択してください。
    Sec=None
    Extension=wav
    [Message Box]
    Text=処理が終了しました。

    このscriptは、選択されたfolder内の全音声について、左側の波形のみを抽出しMonaural化する。

  3. copy2 folderに対し、以下のSoundEngine script “Monauralized R”を実行:
    [Folder Open]
    Text=処理するフォルダを選択してください。
    [Silence]
    Selection=0,-0,0
    [Format Converter]
    Selection=0,-0,-1
    Channel=1
    Quality=3
    [Folder Save]
    Text=出力フォルダを選択してください。
    Sec=None
    Extension=wav
    [Message Box]
    Text=処理が終了しました。

    このscriptは、選択されたfolder内の全音声について、右側の波形のみを抽出しMonaural化する。

  4. 処理されたfoldersをWinMergeなどで比較する。比較結果が同一になる音声は元々Monaural

    日本語環境Windows 10上で、WinMergePortable日本語版を使用し、System LocaleがCP932なら、Command Promptから以下のように処理を定型化できる。(自分用memo)

    "D:\WinMergePortable\App\WinMerge\WinMergeU.exe" "D:\BTS_Package\_bms_code-bts_L" "D:\BTS_Package\_bms_code-bts_R" -minimize -noninteractive -noprefs -cfg Settings/DirViewExpandSubdirs=1 -f *.wav -u -or %USERPROFILE%\Desktop\L_vs_R.txt

    さらに続けて以下のように:

    findstr "ファイルは同一です" %USERPROFILE%\Desktop\L_vs_R.txt > %USERPROFILE%\Desktop\1ch_wav.txt

    Desktop上に生成された1ch_wav.txtの内容は以下のような感じ:

    bass_01.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:15,* 2020/11/01 21:28:40,wav
    bass_02.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:16,* 2020/11/01 21:28:41,wav
    clap.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:25,* 2020/11/01 21:28:50,wav
    hat_01.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:27,* 2020/11/01 21:28:52,wav
    hat_02.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:28,* 2020/11/01 21:28:53,wav
    hat_03.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:29,* 2020/11/01 21:28:54,wav
    hat_04.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:30,* 2020/11/01 21:28:55,wav
    kick_01.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:44,* 2020/11/01 21:29:09,wav
    kick_02.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:45,* 2020/11/01 21:29:10,wav
    kick_03.wav,,バイナリ ファイルは同一です,  2020/11/01 21:26:46,* 2020/11/01 21:29:11,wav
    perc_01.wav,,バイナリ ファイルは同一です,  2020/11/01 21:27:14,* 2020/11/01 21:29:39,wav
    perc_02.wav,,バイナリ ファイルは同一です,  2020/11/01 21:27:15,* 2020/11/01 21:29:40,wav
    rimshot.wav,,バイナリ ファイルは同一です,  2020/11/01 21:27:18,* 2020/11/01 21:29:43,wav
    tom_01.wav,,バイナリ ファイルは同一です,  2020/11/01 21:27:38,* 2020/11/01 21:30:03,wav
    tom_02.wav,,バイナリ ファイルは同一です,  2020/11/01 21:27:39,* 2020/11/01 21:30:04,wav
    tom_03.wav,,バイナリ ファイルは同一です,  2020/11/01 21:27:40,* 2020/11/01 21:30:05,wav

    Code-B.T.S.に含まれる音声のうち、前述の16 filesはMonaural化しても聴覚上の影響が一切ない。実際にMonaural化の前後でBMX2WAV変換結果を比較して完全一致することを確認した。


  5. copy1 folderとcopy2 folderを削除し、必要ならoriginal folder内の音声をMonaural化する。

音声をOgg VorbisやFLACに変換する場合、Monaural化してもしなくても最終的なfilesizeは殆ど変わらない。BMSの音声をWAV形式のまま配布する場合や、usersが各自でWAVにdecodeすることを見越すなら、Monaural化を施しておくことには意味がないこともない。費用対効果はさておき。

日記

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
Brilliant Techno Square
雑多なメモ
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
_wsh_bms2bmson.js

その他

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