前にみたようにWaveUpConverterディザなしとFuseデフォルトのの場合には、両者にはほとんど違いがないようである。個人的にはオリジナルのビットレートが小さいものはディザありWaveUpConverterでアップコンバートを、高いものまたはアコースティック、自然系などはFUSEと使いわけたりもするが、ほとんど気分でかもしれないが、ただその場合、最終的にエンコード後のファイルサイズに違いが出てくるのでメモしておく。
下のファイルには上からオリジナル16bit44.1khzのwavファイル、FUSEによるデフォルトの24bit176.4khzのwavファイル、WaveUpConverterのディザあり24bit176.4khzのwavファイルが並んでいる。wavファイルのサイズに関しては、そのフォーマット上、ディザありなしにもかかわらずサイズは同じ368MBになる。
その下の後半３つはWavPackでロスレスエンコードしたものであるが、5番目のFUSEと6番目のWaveUpConvertでは40MBものサイズの違いが出てくる。割合でいうとオリジナルに対して12%前後ものサイズ差が出てくる。
これにはWavPackのエンコードアルゴリズムが影響しているであろうが、つもりつもればライブラリの総容量に大きな影響を与えるので、この視点でどちらでアップコンバートするかを選択してもいいだろう。
またサイズの話でいうと、アップコンバート中にどちらもオリジナルのWAVファイルをコピーして、それを元に巨大な一時ファイルを作成する。その処理中はガリガリガリと、HDをおもいっきり使っている音がでっぱなしとなる。
それが作られる場所はFUSE+Lilithは、Lilithの出力先で指定したところになるが、WaveUpConverterではデフォルトでは下のプログラム本体の下に作られるフォルダになる。
ところでバッチで何十曲もアップコンバートする場合には何時間も、場合によっては10時間以上もかかり、しかもその間ガリガリHDが唸り続けるわけで、これをなんとかしたい、もっと速くしたいとおもうものである。
そうなるとハードディスクを使わないオンメモリ上で動かしたいとなり、RAMディスクを使おうとなる。WaveUpConverterの場合には、プログラム本体があるディレクトリに wuc_settings.iniという設定ファイルがあり、そこでガリガリの行われる一時ファイルの場所を指定できるので、メモリあまっている方で、ディザなしでアップサンプリングする場合には、RAMディスクを作ってWaveUpConverterを使うのがよいとおもう。
下のファイルには上からオリジナル16bit44.1khzのwavファイル、FUSEによるデフォルトの24bit176.4khzのwavファイル、WaveUpConverterのディザあり24bit176.4khzのwavファイルが並んでいる。wavファイルのサイズに関しては、そのフォーマット上、ディザありなしにもかかわらずサイズは同じ368MBになる。
その下の後半３つはWavPackでロスレスエンコードしたものであるが、5番目のFUSEと6番目のWaveUpConvertでは40MBものサイズの違いが出てくる。割合でいうとオリジナルに対して12%前後ものサイズ差が出てくる。
これにはWavPackのエンコードアルゴリズムが影響しているであろうが、つもりつもればライブラリの総容量に大きな影響を与えるので、この視点でどちらでアップコンバートするかを選択してもいいだろう。
またサイズの話でいうと、アップコンバート中にどちらもオリジナルのWAVファイルをコピーして、それを元に巨大な一時ファイルを作成する。その処理中はガリガリガリと、HDをおもいっきり使っている音がでっぱなしとなる。
それが作られる場所はFUSE+Lilithは、Lilithの出力先で指定したところになるが、WaveUpConverterではデフォルトでは下のプログラム本体の下に作られるフォルダになる。
ところでバッチで何十曲もアップコンバートする場合には何時間も、場合によっては10時間以上もかかり、しかもその間ガリガリHDが唸り続けるわけで、これをなんとかしたい、もっと速くしたいとおもうものである。
そうなるとハードディスクを使わないオンメモリ上で動かしたいとなり、RAMディスクを使おうとなる。WaveUpConverterの場合には、プログラム本体があるディレクトリに wuc_settings.iniという設定ファイルがあり、そこでガリガリの行われる一時ファイルの場所を指定できるので、メモリあまっている方で、ディザなしでアップサンプリングする場合には、RAMディスクを作ってWaveUpConverterを使うのがよいとおもう。
