create_extm3u

kbwsr.kpi の動作確認用に名前が Z で始まる某サイトの曲データを入手しましたが、
曲番号ごとに個別に m3u が入っていて、このままだと KbMedia Player では開けない
ので１つにまとめるツールを作りました。

https://kobarin.sakura.ne.jp/kpi/create_extm3u_20240427.7z

某サイトとか、何のことだか分からない人はダウンロードしても無意味です。

コマンドラインで複数の wsr ファイルを渡すことが出来ます。
コマンドプロンプトを起動してエクスプローラからファイル名をドロップする感じで
やれば良いかと思います。

フォルダ名を渡して一括で処理することも考えましたがやめておきました。

スキルのある人なら簡単にバッチファイルを作れてしまうのかもしれません。


以下、readme.txt より

【概要】

サイト名がZで始まる某サイトにある WonderSwan の曲データに含まれている NEZplug
拡張m3uファイル群を１つにまとめるツールです。

例えば foo.wsr をダウンロードするとアーカイブに複数の m3u ファイルが以下のよう
な感じで含まれています。

01 title1.m3u
foo.wsr::WSR,1,title1,length1,loop1,fade1,loopcount1

02 title2.m3u
foo.wsr::WSR,2,title2,length2,loop2,fade2,loopcount2

03 title3.m3u
foo.wsr::WSR,3,title3,length3,loop3,fade3,loopcount3

このままだと KbMedia Player で foo.wsr を開いても曲長やタイトルを取得することが
出来ません。

この場合に

foo.m3u (foo.wsr と同じ名前で拡張子が m3u)を作成して

foo.wsr::WSR,1,title1,length1,loop1,fade1,loopcount1
foo.wsr::WSR,2,title2,length2,loop2,fade2,loopcount2
foo.wsr::WSR,3,title3,length3,loop3,fade3,loopcount3

のように１つにまとめるツールです。
これにより、KbMedia Player で foo.wsr を開いたときに曲長やタイトルを取得出来る
ようになり、不要な番号の曲が表示されなくなります。

【使い方】

コマンドラインに .wsr ファイル名をフルパスで渡します。
パス名に空白を含む場合、パス名は "" で括る必要があります。
複数のファイル名を渡すことも出来ます。

例1：create_extm3u.exe "C:\wsr data\foo\aaa.wsr"
例2：create_extm3u.exe "C:\wsr data\foo\aaa.wsr" "C:\wsr data\bar\bbb.wsr"

例1 を実行すると aaa.wsr と同じフォルダに aaa.m3u を作成します。
aaa.wsr と同じフォルダに m3u ファイルが存在しない場合は何もしません。
同じフォルダに m3u が存在すれば、既に aaa.m3u が存在していても確認することなく
上書きされます。

本ツールでは元の m3u ファイルは削除しません。不要なら手動で削除して下さい。

例2 のように複数のファイル名を渡すことも出来ます。コマンドプロンプトを起動して
エクスプローラからファイル名をドロップすると簡単です。あまりたくさん渡すとコマ
ンドラインの長さの制限に引っかかる可能性があるのでほどほどの数にして下さい。

【文字コード】

某サイトにある m3u ファイルには、Shift-JIS では正しく表示されない文字が含まれて
いるもの(Copyright のマーク(0xa9)とか ,(0x2c) に似た記号(0x82)とか)が多いです。
その為、本ツールでは m3u ファイルをコードページ1252として読み込み、aaa.m3u は
BOM 付 UTF-8 で保存します。

, に似た記号(0x82)を含む場合、作成された m3u を秀丸エディタで開いて編集すると、
区切り文字としての ,(0x2c) に置換されてしまう場合があります。そうするとタイトル
や曲長等の情報が正しく取得出来なくなります。

タイトルに , を使う為にこの記号(0x82)を使ってるみたいですが、その場合は \, と書
けば良いです。


本ツールで作成した m3u は

KbMedia Player v3.12以降
foobar2000(x64) + foo_input_wsr v0.30
Winamp + in_wsr.dll

で正しい曲情報を取得出来ることを確認しています。
Winamp では in_wsr が Unicode に対応していないからなのか、元データで半角カタカ
ナのウと表示される文字(Copyright の C のマーク)が ? と表示されたりします。

https://kobarin.sakura.ne.jp/test/kbmed313_beta3.exe
https://kobarin.sakura.ne.jp/test/kbmed313_beta3.7z

.exe と .7z はどちらも中身は同じです。
.7z の展開の仕方が分からない方は .exe をダウンロードして下さい。

.exe だと Microsoft Edge でブロックされる方は .7z をダウンロードして下さい。
Microsoft Edge にブロックされる方は安全だと報告してくれると助かります。

起動時にエラーメッセージが表示されてプラグインが認識されない場合は
Microsoft Visual C++ 2022 再頒布可能パッケージが必要です。
https://visualstudio.microsoft.com/ja/downloads/#other-ja-family
x64 版ランタイムファイル直リンク
https://aka.ms/vs/17/release/VC_redist.x64.exe
x86 版ランタイムファイル直リンク
https://aka.ms/vs/17/release/VC_redist.x86.exe
(x64 版の動作には vc_redist.x64.exe と vc_redist.x86.exe の両方が必要です)

VS2019 のランタイムでも動作はするようですが、念のため VS2022 の
ランタイムを入れて下さい。

β版は Windows XP のサポートを打ち切りました。XP 環境だと一部のプラグインが
動作しません。Windows XP で使いたい方は正式版をお使い下さい。


v3.13beta3 での変更点

・kbwsr.kpi に関する以下の修正
　・ベースを foo_input_wsr v0.30 に変更
　・foo_input_wsr に準じた設定に対応
　　・エミュレーションコアを選択出来るようになった
　　　(mednafen/oswan/in_wsr)
　　・エミュレーションコアごとに再生周波数と音量を設定出来るようにした
　　・ChannelMuting に対応(各コア共通)
　・wsr_player_mednafen.dll と wsr_player_oswan.dll に対する以下の修正
　　・再生時に落ちるデータがあったのを修正
　　・名探偵コナン 西の名探偵最大の危機！(SWJ-BAN027.wsr)
　・wsr_player_mednafen.dll と wsr_player_oswan.dll で音が鳴らない曲データを確
　　認
　　・With you～みつめていたい～(SWJ-SHLC01.wsr)
　　・修正は出来ていない
　　・wsr_player_in_wsr.dll では音が鳴る
・kbvgm.kpi に関する以下の修正
　・libvgm を 2024/04/24 の版に更新(Resampler.c)
・kbunarc.kpi に関する以下の修正
　・unrarsrc を 7.0.8(2024/04/25) に更新
・kbungca.kpi に関する以下の修正
　・kbungca.dll の IGca の呼び出し規約を __cdecl から __stdcall に変更
・「ツール」=>「PLS/TAGファイル作成」の「NEZplug 拡張 M3U/PLS を TAG に変換」を
　実行すると落ちるのを修正(M3U を開いたとき)
　・レジストリを書き換えないと機能が使えないので誰も気づいてないだろうけど

特に問題なければ次を正式版にしようと思います。
ゴールデンウイークが終わる前にそうしてしまうかもしれません。

本当はこの版を正式版にしてしまおうかとも思いましたが kbwsr.kpi がとても大きな
修正だったので一応β版にしておきました。

https://kobarin.sakura.ne.jp/test/kbmed313_beta2.exe
https://kobarin.sakura.ne.jp/test/kbmed313_beta2.7z

.exe と .7z はどちらも中身は同じです。
.7z の展開の仕方が分からない方は .exe をダウンロードして下さい。

.exe だと Microsoft Edge でブロックされる方は .7z をダウンロードして下さい。
Microsoft Edge にブロックされる方は安全だと報告してくれると助かります。

起動時にエラーメッセージが表示されてプラグインが認識されない場合は
Microsoft Visual C++ 2022 再頒布可能パッケージが必要です。
https://visualstudio.microsoft.com/ja/downloads/#other-ja-family
x64 版ランタイムファイル直リンク
https://aka.ms/vs/17/release/VC_redist.x64.exe
x86 版ランタイムファイル直リンク
https://aka.ms/vs/17/release/VC_redist.x86.exe
(x64 版の動作には vc_redist.x64.exe と vc_redist.x86.exe の両方が必要です)

VS2019 のランタイムでも動作はするようですが、念のため VS2022 の
ランタイムを入れて下さい。

β版は Windows XP のサポートを打ち切りました。XP 環境だと一部のプラグインが
動作しません。Windows XP で使いたい方は正式版をお使い下さい。


v3.13beta2 での変更点

・各種プラグイン/DLL の開発環境を VS2022 17.9.6 に更新
・kbGuru2SMF.kpi に関する以下の修正
　・以下、GuruGuruSMF4.dll に関する修正
　・リズムパートの SysEx を使用する曲データが正常に再生されないのを改善
　　・ピアノになってしまうことがある曲データ
　　・チャンネルボリュームが利かないことがある曲データ
　　・最初の発音までの時間の進み方が遅くなった(MIDI イベントによっては送信前後
　　　にウェイトを置く為)
　　・根本的な原因(ピアノになるデータとならないデータの違い、チャンネルボリュー
　　　ムが利くデータと利かないデータの違い)が分からず、対症療法的な措置
　・冒頭の空白をスキップ、シークに関する以下の修正
　　・リズムパートの SysEx を使う曲データで正常に再生されなくなることがあるのを
　　　改善(冒頭の空白をスキップ、シークをしなければ正常に再生出来るデータ)
　・たまに再生がおかしくなるデータはまだ存在するがその確率は低くなった
　・演奏スレッドと同じスレッド内で処理するようにした
　・処理に時間がかかるようになった
　　・MIDI イベントによっては送信前後にウェイトを置く為
　　・特に冒頭付近が時間かかるので曲データによっては冒頭の空白スキップがあまり
　　　機能しなくなった
　　・処理中は進捗状況に応じた位置を返すようにした
　・以下の SysEx を無視するようにした
　　・テキスト表示、ドット絵、PatchName、XG のSysEx(マスターボリュームはチャン
　　　ネルボリュームに置換)
　・非ループ曲(CC111 を含まない曲)でリセットを含む曲データのループ時は先頭に戻
　　ったときにリセットを送信するようにした
　　・非ループ曲の2周目以降が不自然になる曲データの改善
　　・「非ループ曲のループ再生」を true にするデメリットが少なくなった
　　・リセットを含まない曲データでは2週目以降が不自然になる可能性があるが、
　　　GuruGuruSMF の仕様に合わせて敢えてリセットは送信しない
・kbmac.kpi に関する以下の修正
　・Monkey's Audio SDK 10.71(2024/04/19) に更新
・kbmpg123.kpi に関する以下の修正
　・libmpg123 を 1.32.6(2024/04/04) に更新
・kbopus.kpi に関する以下の修正
　・libopus を 1.5.2(2024/04/12) に更新


GuruGuruSMF でリズムパートの SysEx を使うデータを正常に再生出来ないことがある不具合が
改善しましたがまだ完全ではありません。

根本的にはどう対処したら良いか分かりません。SysEx の送信前に(送信後ではない)少し待てば
改善するデータがありますが、いくら待っても全く改善されないデータもあります。

確認出来たデータでは大分改善されましたが、まだ10回に1回程度の割合で演奏がおかしくなる
ものがあります。

You さんのテストプログラム相当の処理を KbMedia Player 本体に組み込んで実験してみました。

SetProcessInformation を使わない場合、最小化時にタイマーの精度が悪くなっていることは
確認出来ましたが、デバイスを開いている間は問題ないようです。

> Windows 11以降、ウィンドウ所有プロセスがエンド ユーザーに完全に隠された、最小化された、またはその他の方法で目に見えない、
> または聞き取れなくなる場合、Windows は既定のシステム解像度よりも高い解像度を保証しません。

デバイスを開いていると「聞き取れなくなる場合」に該当しなくなるのでしょう。
うまく出来ていますね。

ただし、例えば 64bit 版で 32bit 版のデバイスプラグインや演奏プラグインを使う場合、本体とは
別プロセスでデバイスを開くことになる為、最小化時にタイマーの精度が低くなることが確認出来ます。

ですが、最小化時においてもタイマーの精度が高くないと困るのはデバイスプラグイン/演奏プラグイン
が実際に動作しているプロセス内においてであって、本体は困りません。

したがって本体が常時タイマーの精度を高くしておく必要はなさそうです。
kbrunkpi.exe の方も、デバイスを開いている間は精度が保証されるのであればやはり
SetProcessInformation を呼び出す必要はなさそうです。

> 本体でも同じことをしておけば kbrunkpi.exe の方では何もしなくても良さそうです。

これは勘違いですね。
Win10 2004 以降では kbrunkpi.exe の方でも timeBeginPeriod は必要ですね。

You さんのテストプログラムのおかげで SetProcessInformation の使い方が簡単に理解出来た
のでとても助かりました。結果的に必要がないことが分かりましたが。

すみません。実行後に表示されるダイアログの意味を勘違いしていました。

私の環境でも同じような感じになりました。

最小化するとタイマーの精度が保証されなくなるが SetProcessInformation で
それを回避することも出来るということですね。

本体でも同じことをしておけば kbrunkpi.exe の方では何もしなくても良さそうです。
本体が動作中、タイマーの精度を常時高くするのは行儀が悪いのかもしれませんが
音楽の再生を目的とするソフトなのですからやむを得ないですよね。

対処無しでもタイマー精度が落ちない、と言うのは謎ですね。

こちらの環境では、テストAPPを再起動せずにオプションを色々変更して実行していると、
SetProcessInformation をコールしなくてもタイマー精度が落ちなくなることが有りました。
その場合でもテストAPP再起動のみでまた再現するようになります。


テスト環境での動作結果を貼っておきます。
全て、1回実行するごとにテストAPPを再起動しています。

・①②③ ウィンドウを最小化した時のみタイマー精度が落ちる
・④⑤ timeBeginPeriod(1) のコールは必須
・⑥ SetProcessInformation と timeBeginPeriod(1) をコールすると最小化してもタイマー精度が落ちない

> GuruGuruSMF は何だか良いオモチャになっているようですね。

DirectMusic でここまで MIDI をきちんと再生出来ると思ってなかったので
とても面白かったです。

そろそろやることがなくなって来ていますがここへ来て行き詰っています。

> Win10 2004 以降では timeBeginPeriod がプロセス内に限定されるのは知りませんでした。

フェードアウト時間を長めにしたとき、64bit版の本体で実行するとフェードアウトが
終わるまで設定時間より長くかかることに気づいて調べてたら timeBeginPeriod が
関係してることが分かりました。

フェードにかかる時間はタイマーの精度が低くても問題なく動作するように出来ました
がフェード中のモタりは精度が低いと発生する可能性があります。

> ウィンドウ最小化時にタイマー精度が15ms程度に戻るようです。
> ウィンドウを持たないプロセスだと設定した精度が維持されていたので、
> kbrunkpi.exe 経由で実行されるプラグインは問題が起きないと思いますが、

kbrunkpi.exe 自体はウィンドウを作成しませんが、GuruGuruSMF4.dll は内部で
隠しウィンドウを作成します。

改造版 GuruGuruSMF はフェードアウト時のモタリ以外はタイマーの精度の影響は
少ないです。公式版だとモタり以外にフェードにかかる時間にも影響します。

本体の midiOut での MIDI 再生時は Sleep(1) を多用しているので、
最小化時にタイマーの精度が下がったら影響が大きいです。

> 一応この現象のテストAPPのソースを添付しておきます。

わざわざありがとうございます。

私の環境だと最小化しても 1ms の精度で動作しているみたいです。v3.13beta を
公開前、timeBeginPeriod の実験の為に色々試していたら、何かの拍子に OS を
再起動するまで 1ms の精度のままになってしまうことがあるようでした。

なので一度再起動してみましたが結果は変わりませんでした。

GuruGuruSMF は何だか良いオモチャになっているようですね。

Win10 2004 以降では timeBeginPeriod がプロセス内に限定されるのは知りませんでした。
確かにドキュメントに明記されてましたが、こんな簡単なAPIのドキュメントは今更見ないし…

timeBeginPeriod のドキュメントにはこんな記述も有りますね。
> Windows 11以降、ウィンドウ所有プロセスがエンド ユーザーに完全に隠された、最小化された、またはその他の方法で目に見えない、
> または聞き取れなくなる場合、Windows は既定のシステム解像度よりも高い解像度を保証しません。
> この動作の詳細については、「 SetProcessInformation 」を参照してください。

実際に試してみましたが、確かにWin11だと timeBeginPeriod(1) をコールしても
ウィンドウ最小化時にタイマー精度が15ms程度に戻るようです。
ウィンドウを持たないプロセスだと設定した精度が維持されていたので、
kbrunkpi.exe 経由で実行されるプラグインは問題が起きないと思いますが、
32bit版の本体から直接実行される kbGuru2SMF.kpi は、本体を最小化した時に影響が出るかもしれません。

一応この現象のテストAPPのソースを添付しておきます。
※2024/04/13 22:26 : 添付ファイル内の誤記を修正

(70KB)

https://kobarin.sakura.ne.jp/test/kbmed313_beta.exe
https://kobarin.sakura.ne.jp/test/kbmed313_beta.7z

.exe と .7z はどちらも中身は同じです。
.7z の展開の仕方が分からない方は .exe をダウンロードして下さい。

.exe だと Microsoft Edge でブロックされる方は .7z をダウンロードして下さい。
Microsoft Edge にブロックされる方は安全だと報告してくれると助かります。

起動時にエラーメッセージが表示されてプラグインが認識されない場合は
Microsoft Visual C++ 2022 再頒布可能パッケージが必要です。
https://visualstudio.microsoft.com/ja/downloads/#other-ja-family
x64 版ランタイムファイル直リンク
https://aka.ms/vs/17/release/VC_redist.x64.exe
x86 版ランタイムファイル直リンク
https://aka.ms/vs/17/release/VC_redist.x86.exe
(x64 版の動作には vc_redist.x64.exe と vc_redist.x86.exe の両方が必要です)

VS2019 のランタイムでも動作はするようですが、念のため VS2022 の
ランタイムを入れて下さい。

β版は Windows XP のサポートを打ち切りました。XP 環境だと一部のプラグインが
動作しません。Windows XP で使いたい方は正式版をお使い下さい。


v3.13beta での変更点

・本体の開発環境を C++Builder 12 v29.0.51961.7529 に更新
・kbGuru2SMF.kpi に関する以下の修正
　・「同梱の GuruGuruSMF4.dll を使う」設定を追加
　　・true のときは「GuruGuruSMF4.dll のパス」を無視
　　・公式版を使いたいときにパスを設定し直すのを省ける
　・キーシフトの設定に対応
　　・GuruGuruSMF4.dll の機能の動作確認用。通常は 0 にする
　・マスターピッチの設定に対応(playopt のと名前が被るので表示は「ピッチ」)
　　・GuruGuruSMF4.dll の機能の動作確認用。通常は 0 にする
　・フェードインの設定に対応
　　・GuruGuruSMF4.dll の機能の動作確認用。通常は 0 にする
　・フェードアウトの設定に対応
　　・0 以外にすると本体の演奏停止ボタン押下時及び「演奏」メニューの「フェード
　　　アウト」時に指定時間かけてフェードアウトさせる
　　・現在の演奏プラグインの仕様では「演奏メニュー」の「フェードアウト」時だけ
　　　フェードアウトさせることが出来ない(その為の API が存在しない)
　・GuruGuruSMF4.dll に関する以下の修正(DirectMusic 使用時)
　　・複数ポート(メタイベント0x21)に対応
　　　・最大4ポート
　　・フェードイン/フェードアウト(以下フェード)中にモタるのを修正
　　　・フェード中はポーリングの Sleep 時間を短くした(5ms => 1ms)
　　・フェードの終了までかかる時間が不正確なのを修正
　　　・Sleep の回数で判定していたのを実際の経過時間で判定
　　・フェードアウト中にフェードアウトが呼ばれても無視するようにした
　　　(最初のフェードアウトが続行されるのみ)
　　・フェードイン中にフェードアウトが呼ばれた場合は同時に進行するようにした
　　　(フェードインしてる分だけ直ぐには音量が下がらず、音量が下がり始めるのが
　　　遅くなるがフェードアウトが終わるのは呼ばれてから指定時間経過後)
・kbrunkpi.exe に関する以下の修正
　・Windows 10 バージョン 2004 以降の環境でタイマーの精度が低かったのを修正
　　(Sleep 等の API を使用するプラグインの動作改善)


本体の開発環境を更新しましたがまだ XP でも動作するようです。
本バージョンからβ版は XP のサポートを打ち切ったので本バージョンでは関係ありませんが。


GuruGuruSMF で複数ポートに対応出来ました。かなり広範囲に渡って修正が必要でした。

複数ポートに対応した関係で今まで未対応だった GuruGuruSMF の機能の動作確認が必要に
なったため設定項目を増やしました。常用するべきものでないものも含みますが、お遊び
程度には面白くて良いのではないかと思います。

フェードイン/フェードアウトのモタりは DLL の呼び出し元アプリが timeBeginPeriod で
それなりの精度(出来れば1ms)に設定しておかないと解決出来ない可能性があります。

なので kbGuru2SMF.kpi に同梱の GuruGuruSMF4.dll を他のアプリで使っても、モタり
は改善してないかもしれません。公式サイトのテストプレイヤーしか対応アプリを知り
ませんが、それも含めて動作確認はしていません。

> XPでの動作確認の結果を。

ありがとうございます。想定通りの動作で安心しました。

プラットフォームツールセットが最新だと 64bit 版は XP 64bit版では
全てのプラグインが動作しないのですね。

あとはプラグイン置き場のプラグインを今後どうやって配布するかですね…。

GuruGuruSMF は複数ポートの MIDI (メタイベント0x21) にも対応出来そうです。