分解能とか
その前に忘れてた事を
- WAV フォーマット対応
- 24bit 32bit とかサンプリング周波数 192kまで対応とか？
- どこまで必要なのか判らん。正直16bit 44k 2ch じゃ駄目なの？とは思うが。
- BMSの音量調査で 32bit 欲しいとか言ってたような
- 分解能はPCのリソースに限界がある以上どこかになんらかの上限は出てしまう
- 具体的に言うと 32bit Windows だと 2^32≒4億 とか。
- 今の BMX2WAV は全ての小節で同じ分解能にするようにしてるので、極端に高い分解能はメモリが足り無くなる
- これは BMX2WAV で作った BMS 編集ライブラリで編集する際にこっちの方が良いと思った為だったような
- この方式だと、大抵の場合何も無い部分を表すデータで占められてしまうので効率は悪い
- BMSON みたいな形式だとノードに「どの位置か」という情報を持たせるので無駄は少ない
- そういう形式だと（他アプリ等の）編集とかの事には使いにくい
- じゃあ BMX2WAV で使ってるライブラリが他で使われたんですかって言うとね
- なので、中で持つデータ構造は BMX2WAV に向いてるデータ構造にするべし
- BMSON 形式でも 558 桁は流石に流石に
- 不可能じゃないけど労力に見合わないかと（コンピュータで巨大数を扱うのは面倒なのよ）
- というか通常 44k 高品質でも 192k の wav に丸めるのでそれ以上は意味が無いかと
- Alcubierre Driveがどういう方法でアレを実現してるのかはまだ不明だけど、変換出来れば良いので何か良い方法で対処したいかな
- 結局の所、内部データをどう持つかがそのまま実装に繋がるのでそのデータ構造の骨子を考えて決めないとね
- 第一候補は BMSON 形式そのまま
- 分解能限界は400万ぐらいかな？
- 第二候補は旧バージョンと一緒
- メモリ次第だけど数万が良いところか。
- 第三候補は小節毎に異なる分解能を持つやりかた
- 分解能は1小節で億単位で行けると思うが
- 変換で問題が無い形式を考えれるのかどうか
分解能については以下適当に箇条書き
