Image.png
by OptiPNG (0.7 or later)"D:\optipng\optipng.exe" -strip all "D:\bms\Virtual_ogg\Image.png"
The latest libpng was released :
UPDATE : The latest released versions are libpng-1.5.17 and libpng-1.6.8
Avoid un anchored hovers
:E.g.: [id='W']:checked ~ dl .tbody > dl:hover { background: #CFC; }
Since browsers evaluate selectors from right-to-left, “dl:hover
” is parsed by IE7. Therefore, in spite of not applying this CSS rule to IE7, this CSS rule degrades IE7.
On Windows XPcharatbeatHDX.exe
says “Entry Point Not Found”:
プロシージャ エントリ ポイント GetTouchInputInfo
がダイナミック リンク ライブラリ USER32.dll
から見つかりませんでした。
Vitrual_ex.bms
is not using any commands which change BPM, that implements a scroll effect just like BPM change. This is a noteworthy trick.#049
-#064
, #STOP
commands are performing pseudo-BPM-change.This BMS is also a new historic test case about the scroll granularity of BMS application.
#LNOBJ
is not supported), Sonorous, Technical#049
), RDM, WAview & in_bm2 (too quick), GALLI, ruv-it! (too quick), nazoZZ (too quick), fgt# (too late), pomu2, PMSee-V (crash in #057
), nanasi, AngolmoisThe license requires one Mac Computer and one Mac OS X Server 10.6 (Snow Leopard) at least:
(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using OS X Server; or (d) personal, non-commercial use.
[Firefox 28 ()] “Support multi-line flexbox (bug 939901).”
flex-wrap
and flex-flow
in “display:flex
”.ロングノートの隣接は是か非か:
#00151:1111
#00152:2222
#00151:11001100
#00152:00002222
是非の判断はユーザに任せて、検出器は粛々と検出するのが望ましいかな
備忘録、ラインハーフ対応ソフトウェアにおいて、是非はさておき、全押しロングノートが問題なく表示できるか否か:
#00151:1111
#00152:2222
#00153:3333
#00154:4444
#00155:5555
ロングノートとラインハーフの両方をサポートするソフトウェアはLR2, nanasi, nazo, fgt++のみ(のはず)。 nazoは怪しい。昔のforgetaliaはたしか黒鍵が表示されなかったはず。
備忘録その二・#EXWAV
フォールバック:
#WAV01 kick.wav
#EXWAV01 pvf 2000 -300 88200 kick.wav
bms[i].playData
を直接比較してみたところ、小節長変更によって1ミリ秒の誤差が発生しうることが分かった。許容誤差に0
[ms]を指定して小節長変更差分を比較すると、問題ないはずの箇所が誤検出される場合がある。yellows10.bms
に私が修正するべき誤りは存在しない。 yellows10ez.bms
は#034
先頭の不可視ノートが一個多い以外はyellows10.bms
と同一なので、こちらも誤りは存在しない。譜面として手直ししたい箇所はあるけど、まあ今はいいや。#20002
が“Dissolution:1/0.5714285714285714
”と表示されます……?先日の補足です。 foon_5n.bms
のコピーをテキストエディタで開き、以下のコードを追加:
#00103:9A
#00102:1.1
#00202:1.1
#00302:1.1
#00402:1.1
これはBMSC, GDAC2, iBMSCでは問題なく読み書きできますが、BMSEで開くと丸め誤差が発生します。
0.015625
の整数倍として表現することができない小節長1.1
を、BMSEは正しく扱えません。1/58.18181818181818
を、BMSEは正しく扱えません。BMSEで開くとリズムが変わる(ずれる)小節:
0.015625
で割ると余りが出る小節0.015625
より小さい小節16
より大きい小節いまのところdiff toolは、「最大分解能が192
より大きいかどうか」でBMSEへの警告を出しているので、その近辺に適当に条件文を足してみたんですけど、
if ([1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 192].indexOf(maxDisso) === -1) {
とか、
if (!bms[i].playData.every(function (v) {
return v.lane !== "02" ? true :
v.note % 0.015625 === 0 &&
v.note >= 0.015625 &&
v.note <= 16;
})) {
ele.innerHTML = "<b style="color:red">BMSEェ…</b>";
}
とか、うまくいくはずなのにうまくいかない……
maxDisso
に限らず全小節長を調べる必要があるのか。いけないわw#xxx[51-69]
, #LNOBJ
).test.pms
:Yes, we can
:
最大分解能表示、小節ごとの分解能(※)表示を追加
※小節内に存在するすべてのレーン分解能の最小公倍数分の一
8
から10000
までの任意の整数値を指定できる。つまり長さ1
の小節(4/4拍子の小節)を一万までの任意の音符で等分できる。理論上は長さ0.1
の小節を千等分できるし、実際に長さ10
の小節を十万等分できる。#xxx02:0.1
を千等分する譜面は、iBMSCで開いた時点で丸め誤差が発生する(浮動小数のスケーリングの問題?)。この長さの小節において正しく表現できるリズムは999等分まで(≈9999分音符)。0.015625
を、iBMSCは156等分できる。157等分だとiBMSCで開いた時点で丸め誤差が発生する(長さ0.015625
の小節に音符157個を収めるためには、分解能10048が必要)。00
を削除した例。このリズムをiBMSCは正しく読み書きできる。しかしサンプルの#00113:
を#00111:
に変更すると、iBMSCで譜面を開いた時点で丸め誤差が発生する(191分リズムと192分リズムを同一レーン上で正しく表現するためには、分解能36672が必要)。ということはつまり、現在最高精度のiBMSCで“Disable vertical moves”を有効にして譜面を編集する場合でも、複雑なリズムはノートの水平移動によって改竄されうる。サンプルの場合、同一レーン上に水平移動したノートのリズムは保存時に改竄される。BGM
などの「描画されない世界」では問題にならないかもしれない。しかし図表として描画される世界では、元譜面との差異が視覚的に認識されうる。そしてBMSはリズムを抽象的に記述する書式なので、ノートはタイムライン上にparseされなければならない。この工程が不可欠である限り、誤差をゼロにすることは事実上不可能だ。なにせBMSフォーマットにおいて、著者は素粒子レベルの分解能を要請する譜面を簡単に書けてしまうのだ。たとえば、分解能2800733を要求するBMS:
#TITLE LCM(13,17,19,23,29) = 2800733
#00111:00000000000000000000000013
#00111:0000000000000000000000000000000017
#00111:00000000000000000000000000000000000019
#00111:0000000000000000000000000000000000000000000023
#00111:0000000000000000000000000000000000000000000000000000000029
13分音符、17分音符、19分音符、23分音符、29分音符を同一レーン上に指定している。この段階で既に、最大分解能192000のuBMplayですら正確に再生することができなくなっている。このような譜面の差分作成にBMSCやGDAC2やbeditorやBMSEやiBMSCを使用すると、譜面を開いた時点で必ず改竄が発生する。
16
以下の、0.015625
の倍数のみ。小節長の基準が64分音符。0.015625
の小節をBMSE上で二等分することはできない。192分音符によって三等分することはできる。15.984375
などの長さは「拍子」タブからは指定できないが、正しく読み書きできる。#xxx02:0.01
などの百分率小節長は、BMSEで開いた時点で丸め誤差が発生する。 “人間の盾”ぐらい派手にずれてくれるなら逆に発見しやすいが、「割り切れない小節長」の大半は2006年版の“Ether dive”のように目立たない形で使用されているため、従来はこれらに対する差分譜面の暗黙的な改竄を黙認するしかなかった。しかしtoolがある今、もはや「割り切れない小節長」の発見はたやすい。16
を超える長さは16
に丸められる。例: “yellows” + yellows10.bms
(#034
)±170.666...
を超える長さは強制終了する。例: Toy Musical 2 \ メキシコ \ 03_mexico_ex.pms
#RANDOM
によって保護するのを止めると、すべてのデータチャンネル行が削除される。 #RANDOM
による保護があってもなくても、%URL
, %EMAIL
, #WAV00
は必ず削除される。yellows.bms
とyellows10.bms
を秒数で比較すべく、先日のようにbms[i].playData
を覗いたところ、差分側の全ノートのms
が比較元と異なっていて、最初のノートが約21秒地点にあることにされていたりして困惑。#xxx02:1
だろうと#xxx02:1E-10
だろうとGUI上での表示は同じなので、普通に192等分間隔でノートを配置することができてしまう。分解能192によって表現できないリズムは丸められる。たとえば小節を5等分するリズムなら、
#00111:1122334455
#00111:110000000000000000000000000000000000000000000000000000000000000000000000000022000000000000000000000000000000000000000000000000000000000000000000000000000033000000000000000000000000000000000000000000000000000000000000000000000000004400000000000000000000000000000000000000000000000000000000000000000000000000005500000000000000000000000000000000000000000000000000000000000000000000000000
「BMSEが割り切れる小節長」が指定されていない場合は、BMSEも同じ結果になることに注意されたい。
最大分解能:1/1344 BMSEで開くとずれます。iBMSCを使ってください。
oggdropXPd V.1.9.1 updated on .
boleroDP updated on .
bolero.bms
and bolero131.bms
were corrected.boleroLN.bml
had were corrected. 3052 differences which still remain are by design of this appendix chart file.About diff--.htm:
It seems that the following CSS rule does not work in Internet Explorer 9-11. Why?
tbody tr { display: none; }
[value='HIDE']:not(:checked) ~ blockquote tbody tr { display: table-row; }
Of course, this rule works in Chrome, Opera (Presto and Blink), Safari, and Firefox.
I gave “harmless
” class to hidable 802 tr
elements, and changed the CSS rule.
[value='HIDE']:checked ~ blockquote .harmless { display: none; }
Firefox Error Console:
gBrowser.addProgressListener
was called with a second argument, which is not supported.secureLogin.just_installed
” in about:config
2
etc., I should reset this value比較のベースとするBMSファイルが壊れていたため、再度DLし比較したところ同じ結果となりました。
小節長変更の計算がバグっていたため修正しておそらくこれで正しいと言える状態にまで戻しております。
ついでに音の定義が同じものは表示を変えました。
ご指摘ありがとうございました。
#xxx31-49
不可視ノートや、#xxx51-69
のロングノートの終端側も計上されるので、譜面作成者はノートを水平移動する以外の一切の行動が許されなくなります。まさしく'user strict';
ズレや抜けが無いのにオブジェクト総数が一致しないなら、どこかに重複オブジェクトが存在するはずなので、
diffResult.appendChild(document.createElement("br"));
}
diffResult.appendChild(document.createTextNode(bms[i].playData.length.toString() + " Objects"));
diffResult.appendChild(document.createElement("br"));
}
bms[i].playData.sort(function (o1, o2) {
if (o1.ms === o2.ms) {return o1.note < o2.note ? -1 : 1; }
return o1.ms - o2.ms;
});
var pre = document.createElement("pre");
diffResult.appendChild(pre);
pre.appendChild(document.createTextNode(
JSON.stringify(bms[i].playData, ["note", "measure"], 2)
));
diffResult.appendChild(document.createTextNode(bms[i].playData.length.toString() + " Objects"));
とかやって、結果を別のテキストにコピーしてRekisaで比較するという低知能な方法で重複を検出しました。よく考えたらラジオボタンのチェックマークを逆にして再比較すれば済む話でした。私はプログラムを書くべきではありません。
検証方法に違いがあるか、未知のバグがありそうです。僕が比較した結果ではズレ抜けありませんでした。
(もしかしてズレ抜けがないのが間違いですか?)
https://
stairway .sakura .ne .jp /smalltools /minibmsplay /diff _result .htm
a383449a1dcc388767a749657a102677
)註: 更新
時点のdiff toolであれば、bolero131.bmsはズレ抜けなしとなるかと思います。
ちなみに時点で計算精度の改善もしております。
double
の積算誤差がわりと無視できない量になっていたので。
ここ数日間たいへんお世話になっております! さきほど試したところ659個の差異が検出されまして、
精度の改善と引き換えに、何か別の誤りが発生しているようです。(版と版の各結果を抜粋・比較)
WAV
定義変更に関しては、ファイル名比較を行ってしまうと#WAV01 1.wav #WAV02 1.wav #00001:01 #00001:02
を
#WAV01 1.wav #00001:01 #00001:01
に改変しても抜けがないということになってしまうため、現状の比較方法とファイル名比較を両方実装するのが理想的かなと思います。
もしくはファイル名ごとに重複して鳴っている音をカウントして、それも含めて比較することが必要になるかと考えます。
ので、の日記におけるnormal.bms
とanother.bms
を同一視できるように、手元で改造中
diffMain()
のbms[i].wavData
が、「定義番号[01-09]
や[0-9A-Z][A-Z]
」を漏らす以下の箇所がその原因っぽい([]
でなく{}
が正しいような気がする)
function BmsResource() {
this.registFiles = [];
this.bmsdata = [];
this.headerData = [];
this.stopData = [];
this.bpmData = [];
this.wavData = [];
this.bgaData = [];
これは私の誤解でした。さらに、「WAV
番号違いの同ファイルを無視する」非推奨のオプションが、既に実装されています。
In old Androidlabel
element which is possible to tap, we should add empty onclick to the HTML label
element. Quoted from “Advanced Checkbox Hack”:
<label for="button" onclick></label>
_人人人人_
> onclick <
 ̄^Y^Y^Y^ ̄
ヘ(^o^)ヘ
|∧
/
bmview.exe
) is goneFortunately BMS Viewer is wayback-able, and redistributable. Quoted from bmsview.htm
:
再配布は特に禁止しませんが、その場合は本ドキュメントと共に配布してください。
また、著作権を侵害するかもしれないデータとともに配布するのはご容赦願います。
#MIDIFILE
and FREE-ZONE are also supported. The number of maximums of reproducable musical measure is #512
.At least in “RETRO BMS EVENT”, RAR5 is permitted. Quoted from “BMS rule”:
容量は圧縮して5MBまでとし、圧縮に使用する形式に制限はありません。
This is a golden opportunity to spread the outstanding compression format.
UTF-8
(meet the requirements of Sonorous' proposal), UTF-8 may spread in the BMS world. We already have ruv-it! (the BMS driver which supports UTF-8), iBMSC (the BMS editor which supports UTF-8), and Sonorous (the BMS driver which can be used as BMS viewer and which supports UTF-8).Added support for Firefox, and Internet Explorer (version 10 or later). thanks a lot!
The label
element will make this tool easy-to-use by clickable text.
<label><input type="checkbox" name="nosound">無音ノーツも比較する</label><br>
label {display: block; }
”:If possible, it will be convenient if type="radio"
are also wrapped with label
elements.
_人人人人人人人人人_
> わりとどうでもいい <
 ̄^Y^
[] Labels were wrapped with label
elements.
This tool detects the mistake by which original song is altered according to the carelessness of noter which creates appendix note-chart.
This tool operates on Google Chrome (version 13 21 or later: webkitGetAsEntry()
) and Opera (version 15 or later).
readAsArrayBuffer()
), and Safari (version 6 or later).diff
to multiple BMS files completely. Although it was my misunderstanding, supposing GUI chart editor can do diff
, it will be ideal. bms diff tool approaches the ideal.Usage:
Note:
#RANDOM
command nor #LNOBJ
longnote.As a matter of fact, the target of this tool is not audio files but notes on BMS.
normal.bms | another.bms |
---|---|
|
|
Although above-mentioned two BMS codes reproduce the same song, this tool will detect four differences. Users should be careful.
kbmed251_beta5\Plugins\Mamiya\kpibmse\bmse.kpi
, KbMedia Player can reproduce BMS.On Windows XP SP3,
◇bmsオブジェクト重複定義時の動作を変更。(対G7仕様)
I investigated “G7” and, probably found the answer.
#TITLE G.7 "Final Attack Mix"
#ARTIST cranky / Blue_Manbow
via http://www.geocities.jp/ray_of_illumination/bmslist.txt
CAUTION: “[V:I-Worm.Hybris.B]” including malware !!
In g7.bms
, lines 522-523:
#02302:0.5
#02302:0.5
Or, lines 627-629:
#03407:7E7F7E807E7F7E80
#03406:f3
#03407:01
I never got BM98 (version 3.18 or earlier which were made by Urao Yane). Furthermore, I do not even have having seen FM TOWNS. Therefore, I cannot know about how old BM98 and BM386 parse above-mentioned codes. However, general BMS applications parse as follows:
// overlapped large line
#02302:0.5
#03406:f3
#03407:017F7E807E7F7E80
そういやベンチマーク集の差分へのリンクですが大体Internet Archiveが保存してないのばっかりなので意味無いような…
Some features which I should keep in mind:
#200
measures is performed only up to #200
measures#PLAYER 4
(BATTLE PLAY)#MIDIFILE midiFileName
[version 2.00δ ()] supported VFAT (filenames up to 255 bytes)
Note: It was 8.3 filename before version 2.00δ
#GENRE
All BMS players become the Gorilla. Gorillas using Gorilla
I do not necessarily know in detail about impossible keypress. In my guess, it is the meanings following probably: In arcade style 9-buttons device, for example, 1+5+9 is impossible.
Whether impossible keypresses are welcomed or not, it is convenient if we can detect them.
This software can be called like viewers from BMSE or iBMSC. For example:
Key | Value |
---|---|
Player Name | PMS ImpChk |
Path | viewer\PmsImpChk\PmsImpChk.exe |
Argument of "Play All" | <filename> |
Argument of "Play" | <filename> |
Argument of "Stop" | <filename> |
Key | Value |
---|---|
Path | <apppath>\..\bmse\viewer\PmsImpChk\PmsImpChk.exe |
Play from beginning | "<filename>" |
Play from current measure | "<filename>" |
Stop | "<filename>" |
If this software is called from a note-chart editor, this software will consider that the file under present edit is PMS. Then, this software will enumerate PMS impossible keypresses in note-chart under present edit. For example:
D:\bms\yamajet_is_sugoi\___bmse_temp.bms
小節:1 ポジション:0 無理押し:159
This means: Measure: #001
, Position: 0/192
, Impossible Keypress: 1+5+9
You can double-click this executable file and input the path of target PMS file.
PMSのファイル名を入力してください:D:\bms\yamajet_is_sugoi\test.pms
小節:1 ポジション:0 無理押し:159
The method of copying the full path of a target PMS file, and choosing “Paste” from the context menu on the title bar of a command prompt is easy.
This software may also be able to be set to “無理皿チェッカー”.
[無理皿] Impossible DP-Scratch:
For example, in 14keys (double play) mode, a one player cannot process simultaneously the turntable (#xxx16
) and the key No. 7 (#xxx19
) on the left-hand side by its left hand only. A one player cannot also process simultaneously the turntable (#xxx26
) and the key No. 1 (#xxx21
) on the right-hand side by its right hand only.
It is difficult to process S+4 simultaneously, for players whose hands are not so large. If the distance of a turntable and keys is S+4 or more, we may consider that players are unable to process them simultaneously. These may be able to be detected. (Although 10keys-DP is more troublesome.)
Key | Value |
---|---|
"Play All" | <filename> -9 |
"Play" | <filename> -10 |
"Stop" | <filename> -14 |
This software does not support long notes. It seems to be actually difficult.
[] Supported long notes. See another article.
#RANDOM
.Note-chart Editor's arguments example:
Key | Value |
---|---|
Player Name | RepeatChk |
Path | viewer\RepeatChk\RepeatChk.exe |
Argument of "Play All" | <filename> 0 -N0 |
Argument of "Play" | <filename> <measure> |
Argument of "Stop" | <filename> |
Key | Value |
---|---|
Path | <apppath>\..\bmse\viewer\RepeatChk\RepeatChk.exe |
Play from beginning | "<filename>" 0 -N0 |
Play from current measure | "<filename>" <measure> |
Stop | "<filename>" |
If this software is called from a note-chart editor, this software asks to you the interval of targeted Button-Mashing Note. (1
corresponds to 1/192
of the measure)
D:\bms\yamajet_is_sugoi\___bmse_temp.bms
開始小節:0
終了小節:999
検出する縦連の間隔を入力してください(1-48 12分=16 16分=12 24分=8 32分=6):12
D:\bms\yamajet_is_sugoi\___bmse_temp.bms
小節:5 ポジション:36 縦連間隔:12(16分) (bms):1P4鍵 (pms):4
This means: Measure: #005
, Position: 36/192
, Interval of Button-Mashing Note: 12/192 (corresponds to sixteenth note)
, Lane: 1P-side Key 4 (as BMS), Button 4 (as PMS)
You can double-click this executable file, and ...
1
corresponds to 1/192
of the measure)ファイル名を入力してください:D:\bms\yamajet_is_sugoi\test.pms
開始小節を入力してください(0-999):0
終了小節を入力してください(0-999):70
検出する縦連の間隔を入力してください(1-48 12分=16 16分=12 24分=8 32分=6):12
D:\bms\yamajet_is_sugoi\test.pms
小節:5 ポジション:36 縦連間隔:12(16分) (bms):1P4鍵 (pms):4
Solution 1: body {word-wrap: break-word; }
overflow-wrap
”: Internet Explorer and Firefox have not supported this yet.<body>
, it may not work in Internet Explorer etc. as expected.Solution 2: <wbr />
element
Technical<wbr />Groove
)Tech<wbr />ni<wbr />cal
” may not be “Technical
” any longer. It may be “Tech ni cal
” which looks like “Technical
”.Solution 3: U+00AD 'SOFT HYPHEN'
su­ per­ cal­ ifrag­ ilis­ tic­ ex­ pi­ ali­ do­ cious
su?per?cal?ifrag?ilis?tic?ex?pi?ali?do?cious
”Solution 4: CSS Text Module Level 3 - Hyphenation
body {
-webkit-hyphens: auto;
-moz-hyphens: auto;
-ms-hyphens: auto;
-o-hyphens: auto;
hyphens: auto;
}
<span lang="en">supercalifragilisticexpialidocious</span>
lang
attribute value is set appropriately, and if web-browsers have a hyphenation dictionary which is specified language, a hyphenation will be applied automatically.auto
” yet. However, this is the most peaceful solution at the moment probably. Although there is probably no Sindarin dictionary.Groove
”. When I want to give the further line-break opportunity to this English word, what should I do? I hardly know about English ...en
”).When the following code is parsed, #TITLE
is set to “C
”:
#TITLE A
#TITLEen B
#TITLEen C
When the following code is parsed, what is #TITLE
?:
#TITLEen B
#TITLEen C
#TITLE A
Probably writer should not write such an ambiguous code.
Hi, this is lifthrasiir. This time I think English is better for communication ;)
- HTML authors are not expected to annotate every possible data, since it's impossible or not useful. (e.g. "mithril" is technically not an English word but rather a Sindarin word coined by J. R. R. Tolkien. So should it be sjn-Latn
? :S) Authors can, and in fact should select the varying level of annotation supported by HTML. For example, <time></time>
is annotated well, but so is <span class="date"></span>
, and if you don't need a machine-readable data,
is just fine. HTML5 makes some annotation easier than ever (e.g. <time>
) but doesn't force you to annotate everything.
- Simple Localization proposal is not designed to be a silver bullet. It supports exactly one particular use case well: BMS makers have one preferred language (#TITLE
) that is also used as a fallback and zero or more other languages (#TITLEen
etc). Other use cases would need much more research and trial-and-error.
Hi, thank you for your English comment. In this diary, English language makes markup easier than Japanese language.
Before translation (ja ) | After translation (en ) |
---|---|
2013年11月21日 |
|
2013 年 11 月 21 日 |
2013 Year 11 Moon 21 Day |
Japanese language does not have a custom which divides words by whitespace. But the Latin font which adjoins CJK fonts is generally ugly. (e.g. Alphabet鬱鬱葱葱)
This problem must be solved by CSS. However, CSS Text level 4 text-spacing
is not ready for implementation. Therefore, I am allowed only the following methods at present:
.Latin { font-family: Verdana, sans-serif; }
.Latin-open { margin-left: 0.4em; }
.Latin-close { margin-right: 0.4em; }
:lang(ja)
scope):<span class="Latin Latin-close" translate="no"
>Sonorous</span
>がいつのまにか<span class="Latin Latin-open Latin-close"
>1</span
>万<span class="Latin Latin-open Latin-close"
>line</span
>を超過しましたね。
It is easy to add lang
attributes to these span
elements. Of course, this is just “<span lang="en-JP">bad know-how</span>
” (Round Tuit). But I do not have other methods.
:3
Yes, nobody forces me to annotate everything. (This is important indication. I am made aphasia by myself.) But supposing I want to annotate like an encyclopedia, I will be happy to do that.
<i lang="sjn-Latn">mithril</i>
<i lang="mis-Kana-x-nadsat" data-latin="tolchock">トルチョック</i>
... However, when applying lang
attributes in each word level, the education which is equal to an encyclopedia is required of HTML authors. I should have remembered that I did not have such education, before trying paranoiac-annotation.
!? ... Possibly I misunderstood Simple Localization proposal, because my too poor English.
#TITLE
(without language tag) is used as fallback.#TITLE
(without language tag). (??)I further had misunderstanding. In conclusion, I understood that the following code is valid:
// BMS maker's "preferred language",
#TITLE 豊穣の都プロウシア
// and zero or more other languages
#TITLEen Prussia, the city of fertility
// If user's "preferred language" is not "en",
// the first #TITLE (without language tag) will be used
Almost all BMS users should be able to read and write English language well rather than me. I expect their comments.
lang
makes me aphasia豊穣の都プロウジア
” to “豊穣の都プロウシア
”“プロウシア
” is scripted as Katakana, but this is not Japanese language. I do not know to which language this proper noun belongs.
Language | Codes | Script |
---|---|---|
English | en | Prussia |
German | de | Preußen |
Latin | la | Borussia, Prutenia |
Latvian | lv | Prūsija |
Lithuanian | lt | Prūsija |
Polish | pl | Prusy |
Old Prussian | prg | Prūsa |
Danish | da | Prøjsen |
Russian | ru | Пру́ссия |
Although I cannot know the “right infallible history” about etymology, the (X)HTML lang
attribute requires that I should determine a political position.
If we assume that this word is Old Prussian, we can mark as follows:
<cite title="Prussia, the city of fertility">
<span lang="ja-Jpan" >豊穣の都</span>
<span lang="prg-Kana">プロウシア</span>
</cite>
“FOON
” in “BMS OF FOON” is scripted as the Latin alphabet, but this is Japanese language.
<a href="http://www.geocities.jp/rf_mirai/bms/event/02/bofoon2006.html">
<abbr title="Be-Music Source file">BMS</abbr>
OF
<span lang="ja-Latn">FOON</span>
2006
</a>
“GBK
” is described as the Latin alphabet, but this is an abbreviation in Chinese language.
However, since (X)HTML lang
attribute is inapplicable to content of attribute values, the following description is not valid:
<abbr title="Guojia Biaozhun (国家标准) Kuozhan (扩展)" lang="zh-Latn">GBK</abbr>
If the part which is zh-Hans
is separated from a title
attribute value, it will become the markup which is probably consistent.
<abbr title="Guojia Biaozhun Kuozhan" lang="zh-Latn">GBK</abbr>
(
<span lang="zh-Hans">国家标准扩展</span>
)
We have some cases where we would like to distinguish the Latin alphabets and the CJK characters. For example, it is a case where we would like to apply “font-style: normal;
” to the CJK characters without italic. But it will not be so easy for CSS :lang()
Selector to extract them.
Even if it assumes that all the lang
attribute values have a SCRIPT token, neither Netscape Navigator (de facto standard in ) nor Internet Explorer 6 (de facto standard in ) is supporting CSS :lang()
Selector. In order to solve this problem, we can use class="CJK"
throughout life, or can unuse any CJK characters. Probably the latter is recommended. In , HTML was not internationalized yet, and the CJK characters were non-standard in ISO-8859-1
.
<cite title="Prussia, the city of fertility">
<span lang="ja-Jpan" >豊穣の都</span>
<span lang="prg-Kana">プロウシア</span>
</cite>
ÿ
is not valid):<cite title="Prussia, the city of fertility">
<span lang="ja-Jpan" >豊穣の都</span>
<span lang="prg-Kana">プロウシア</span>
</cite>
Note: <cite>
: HTML 1.0 or later, <div>
: HTML 3.0 or later, <span>
: HTML 4.0 or later
<cite>Prussia, the city of fertility</cite>
Note: This list-item is 90% joke. However, we are still put to the violence of de facto standards. For example, for the foolish mobile browsers which misunderstand numeric character reference or BMS DATA sections as telephone numbers, we must describe as follows:
<meta name="format-detection" content="telephone=no">
I remember <meta http-equiv="imagetoolbar" content="no">
.
In practice, this is one of new Control Flow Statements.
BMS code | Equivalent pseudo code |
---|---|
|
|
Since this specification does not have negative syntax, we cannot describe as follows:
#TITLE 豊穣の都プロウシア
#TITLE!ja Prussia, the city of fertility
If we describe as follows, a result is equal to the above:
#TITLE Prussia, the city of fertility
#TITLEja 豊穣の都プロウシア
It may be a burden for Japanese authors that a default #TITLE
cannot be described in Japanese language. But since Japanese language is not a de facto standard, this may be a matter of course.
Moreover, it will become less “Simple” if this specification has negative syntax.
In order to hold the fairness in a score system probably, this specification is not applied to a data section. Therefore, it may be hard to describe some conditional effects. However, it is cost required for fairness.
// the vocal-lyrics in English language are displayed on video
#BMP01 lyrics-en.mpg
// whatever the language, data sections for telops must be described
#00199:01
// telop content
#TEXT01en ""
#TEXT01ja "歌詞"
#TEXT01ko "가사"
It seems to be rather difficult to realize “telops optimized for each language”. (However, probably, there is almost no user troubled by that. )
What is called “added locales” is accompanied by change of MD5 of BMS. Probably, “Simple Localization” is not the specification for solving such a problem.
#BMP01 lyrics.mpg
#00104:01
Fixed several loading errors.
#BMP
and #BGA
namespaces are now distinct and #BGA
works for movies. (There is a known issue with #BMP
s larger than 256×256.)
#BMP01
and #BGA01
do not collide any longer.#BGA
can already apply cropping (trimming) to video files.SQLite has been added as a dependency and MD5 calculation has been added for the use with it.
sqlite-5baa75b8f28ffaad-0.1.dll
こんにちは、lifthrasiirです。時間がないから短く書きます。
- snapshot...この出てきたんですよ。すみませんorz
- / snapshotの変更は大略次の通りです: Couple Playの誤謬に関する修正、Long Note形変更(Sonorousのgrading lineが本来は画面の真下にいてプレーに邪魔になったのに、一緒に改築されました。)、文字エンコード、重複
#BMP
/#BGA
key処理変更、曲終了後にある#xxx02
に対する処理、一文字alphanumeric key処理("One digit problem")- GBK自動エンコード認識は、
GBK
/Shift_JIS
が過度に類似して、統計的な処理が難しいです。もちろん-E gbk
を使うわけにもいます。(実はrust-encodingはもうほとんどの主要エンコードをサポートします。)- 最近目標とする主要機能: local BMS database (MD5が入った主な理由です)、skin system (インターフェース実験をもっとやすいように)、sound system (いつかは修正しなければなりました)。それぞれ数週間ずつかかるようです。orz
- Sonorousがいつのまにか1万lineを超過しましたね。ひょっとしたらRust compiler、Servoの次に大きいRustプロジェクトかも…?
U+0085
and U+FEFF
might be supported.In TechnicalGroove, U+200B
and U+FEFF
are indentable. My test was wrong:
U+200B
: E2 80 8B E2 80 8B 23 49 46 20 31
: PassedU+200B
: E2 80 8B E2 80 8B 23 49 46 E2 80 8B 31
: Of course, failedGrading line now appears on the playing screen and the appearance of long notes have been changed.
Automatic character encoding detection.
Quote from src/format/bms/encoding.rs
:
/// Tries to guess the encoding of the stream and reads it accordingly. /// Any error would be substituted with U+FFFD. /// Returns a guessed encoding and confidence (probability) in addition to the decoded string. /// Currently recognizes `ASCII`, `UTF_8`, `WINDOWS_949` and `WINDOWS_31J` encodings.
[Note] The file is encoded in the legacy CJK encodings. Their continued use is discouraged.
Big5
? GB18030
? GB2312
?Codepoint | Unicode name | iBMSC | TG | SNRS | Memo |
---|---|---|---|---|---|
U+0009 | CHARACTER TABULATION | Yes | Yes | Yes | +HDX |
U+000B | LINE TABULATION | Yes | Yes | Yes | |
U+000C | FORM FEED (FF) | Yes | Yes | Yes | |
U+0020 | SPACE | Yes | Yes | Yes | +HDX |
U+0085 | NEXT LINE (NEL) | Yes | Yes |
Yes | |
U+00A0 | NO-BREAK SPACE | Yes | Yes | Yes | |
U+1680 | OGHAM SPACE MARK | Yes | Yes | Yes | |
U+180E | MONGOLIAN VOWEL SEPARATOR | No | Yes | Yes | [.NET 4+] isWhiteSpace() |
U+2000 | EN QUAD | Yes | Yes | Yes | |
U+2001 | EM QUAD | Yes | Yes | Yes | |
U+2002 | EN SPACE | Yes | Yes | Yes | |
U+2003 | EM SPACE | Yes | Yes | Yes | |
U+2004 | THREE-PER-EM SPACE | Yes | Yes | Yes | |
U+2005 | FOUR-PER-EM SPACE | Yes | Yes | Yes | |
U+2006 | SIX-PER-EM SPACE | Yes | Yes | Yes | |
U+2007 | FIGURE SPACE | Yes | Yes | Yes | |
U+2008 | PUNCTUATION SPACE | Yes | Yes | Yes | |
U+2009 | THIN SPACE | Yes | Yes | Yes | |
U+200A | HAIR SPACE | Yes | Yes | Yes | |
U+200B | ZERO WIDTH SPACE | Yes |
Yes | No | [.NET 4+] !isWhiteSpace() |
U+2028 | LINE SEPARATOR | Yes | Yes | Yes | |
U+2029 | PARAGRAPH SEPARATOR | Yes | Yes | Yes | |
U+202F | NARROW NO-BREAK SPACE | No | Yes | Yes | [.NET 4+] isWhiteSpace() |
U+205F | MEDIUM MATHEMATICAL SPACE | No | Yes | Yes | [.NET 4+] isWhiteSpace() |
U+3000 | IDEOGRAPHIC SPACE | Yes | Yes | Yes | +HDX |
U+FEFF | ZERO WIDTH NO-BREAK SPACE | Yes |
Yes |
Yes | [.NET 4+] !isWhiteSpace() |
In the UTF-8 mode, if the reader ignores the preceding letters of the particular kind before the command, U+FEFF
should be included in the ignored letters.
I thought that the following description was allowed:
BMS code: <BOM><BOM>#IF 1
Byte sequence: EF BB BF EF BB BF 23 49 46 20 31
BMS V2 Project.odt
” directly at any cost; the private unofficial Japanese version by me cannot guarantee quality.<table>
is best.ニライカナイ / tierlily
” to “ニライカナイ / tigerlily
”Get the latest version. It seems that it was updated on .
(Although I did not notice till today. I do not know what was improved.)
Does the BGAEncAdvance operate normally? Operation verification:
Unzip “yamajet_is_sugoi.rar”, and check that “yamajet_is_sugoi” directory configuration.
yamajet_is_sugoi\
classic\
cyc-kami.bms
kami.bms
@cyc-readme.txt
_5keys.lr
_banner.bmp
title.bmp
xxx.wav
(8 files)cyc-yyy_nnnnn.bmp
(122 files)foon_5n.bms
foon_10n.bms
foon_readme.txt
Don't change above-mentioned directory configuration.
Drag-and-Drop “yamajet_is_sugoi\foon_5n.bms
” to BGAEncAdv.exe
.
(Or specify BMS path directly to BGAEncAdv.exe
via CUI.)
BGAEncAdv\out.avi
.When not working, BMS may have a cause. For example, when “yamajet_is_sugoi\classic\cyc-kami.bms
” is dropped to BGAEncAdv.exe
, loading images “is not found”.
BMS code | is equivalent to: |
---|---|
|
|
If that hierarchy one level goes up, “yamajet_is_sugoi\cyc-kami.bms
” will be able to convert correctly.
If you have any problems, please let Mr.Bluvel know what environment you are using.
#TITLE
of BMS)