それでも、ちょっと長めの曲(Full版とか)はちょっと読み込みに時間が掛かる模様。
調べてみると、SoundDecoder.dllが提供する各Open()で時間が掛かっている。 フォーマット違いのOpen()の時は一瞬で終了するのに対して、フォーマットがあっていると (例えばoggに対してoggOpen()すると)、処理に2～3秒掛かっている。
いったい中で何が行われているのだろうか・・？？
from 正直ほとんど覚えていませんが、
確か、Open() 内で一度データを全部デコードしてたと思います。で、ため込んだPCMデータを、再生中に Decode() で少しずつかっぱらってくるという見事な似非ストリーミング再生。
ただし、ogg だけは本当のストリーミングをしている（xaもだったかな？）ので、Open() 内でのデコードは行ってません。
例えば、私が昔作った Ys2 OP の PREVIEW サウンドは長い（フル版が最初から最後まで流れる）ですけど、ogg 形式なので、選曲画面で選択するとすぐにプレビュー再生が始まると思います。他のフォーマットだと、全部デコードするまでプレビュー再生が始まらない上に、デコードが終わるまでフリーズするはずです。
……たぶん、そんな感じだったのではないかと。（汗
Open()の処理時間が分かるようにしたログを添付しました。
どうやらoggもOpen()でフルデコードしているっぽいですね。冷静に考えれば、Open()時点ではオンメモリ再生させるかストリーミング再生させるかを決めていないのだから、こういう実装になりそうではあります。
from ふーむ。
でも ogg がストリーム化してあるのは間違いないですよ。
Ys2 OP のプレビューはその実験だったんですから。
となると、libogg の方で全体サイズ測るとか何かしてる可能性はありますね。
ぬー。そうですか・・・。
ちょっと気になりましたので、vorbisfile.c の ov_fopen() を簡単に読み込んでみました。
オープンのついでに全てのBOS(Beginning Of Stream)ページをフェッチしてますが、 件のoggファイルはどれも1個ずつしかBOSを持っていませんでしたので、そんなに時間が掛かると思えず。
参考) http://www12.ocn.ne.jp/~dante98/text/rfc3533j.txt
まあ今回はここに注力するつもりはないので、一旦このチケットはクローズします。今よりもっと高速化したくなったときに、SoundDecoder.dllの作り直し含めて再検討します。
これ、いいですね
キビキビ動いてる感がすごくいいです
チケット趣旨とはずれますが、個人的にはリザルト画面のフェードアウトも削ってみると体感がどうなるか興味があります
・リザルト画面→フェードアウト（これ）→フェードイン→選択画面。
あまりキビキビしすぎると安っぽく見えるからあえてクッション処理を置く手法があるのはわかってるつもりですが、今回のは私はありだと思います。
私はプログレスバー出す前にまず待ち時間短縮派ですので・・・。
さて、リザルト画面のフェードアウトを削った試作品も作ってみました。092に上書きして下さい。
tp://yyagi.com/DTXMania_27787_test.zip (そろそろチケット添付の200k制限を超えて色々面倒になってきたので、外部リンクにします。そろそろ一旦093として出しておくべきか・・・)
実は個人的に最後のフェードアウトがあった方がいいと思っていたクチですが、実際に試してみると、これはこれでアリかなと思いました。(でもやっぱり演奏の余韻は半減しますね)
ありがとうございます。試してみましたが悪くないと思いました。
リザルト画面になっても音楽が続く譜面もあり、それはいきなり音楽が切れる印象が少々増える感じかもしれませんね。個人的にはフェードアウト処理を挟んでもそういうのは少々残念ですが（苦ｗ）
強引かもしれませんが余韻を楽しみたい方はあえてリザルトで待機してもらうことも出来るかな･･･と思うので他の方で反対がなければ実装を検討お願いできないでしょうか。
それでは、リザルトからのフェードアウトを削るか残すかは、他の方のご意見を待ちたいと思います。
1週間経って、特にコメントがなさそうですので、このまま(フェードアウトカットのまま)として、このチケットは完了とさせていただきます。
Fork
選曲時に発生する「選曲画面のフェードアウト」と「NowLoading画面のフェードイン」を省略することで、演奏開始までの体感待ち時間を短縮する。
フェードアウト・フェードインで1秒ずつ使っているので、計2秒の短縮となる。