uLilith

公式サイト:http://www.project9k.jp/
バイナリを一致させる方法:WASAPI排他モード,ASIO

概要

音楽再生に特化したプレーヤーがまだ殆ど無い頃,国産の音質重視設計プレーヤーとして名をはせたのがLilithです。ここ数年は海外製のソフトの勢いに押されてあまり元気がありませんでしたが,最近になってUnicode版のuLilithという新しいタイプのプレーヤーをリリースしました。

特徴(ベクターより引用)

(旧 Lilith にはない新しい特徴は ★ で示してあります)
★MP3, Ogg Vorbis, Flac, OggFlac, Windows Media, Monkey’s Audio, Tak,RIFF-WAVE の再生/デコードに対応
・DirectShow フィルタにより、上記のほかにもさまざまな形式を再生/デコード可能
・OggVorbis, Flac, OggFlac, Windows Media Audio, Monkey’s Audio へのエンコードに対応
・MP3 から Ogg Vorbis、Flac から WMA など、タグ引継ぎありでのフォーマット変換に対応
・外部コマンドラインプログラムを使用した、CLI エンコードに対応
・内部 64bit Float 処理パイプラインによる精度の高い DSP 処理が可能
・18 バンドイコライザ / 音程変更 / 周波数変更 / 速度変更などの DSP を搭載
★VST エフェクトプラグインを追加することにより、その他多数のエフェクトを使用可能
・ASIO へのネイティブ対応により、カーネルミキサなどによるバイナリ改変を回避可能
★Uniocde ベースアプリケーションにすることで、Unicode 特有文字を完全に扱うことが可能
★実行時言語判断により、多言語対応可能
★国産音楽プレイヤー初のレイヤードウィンドウ対応により、より高度な表現の UIを実現
★全体の半透明度を設定するだけでなく、一部分だけ完全透明あるいは半透明にするなどが可能
★ウィンドウ自体がレイヤなので、不定形ウィンドウなどで滑らかなアンチエイリアスが可能
★フェイス定義にあった多くの制約が解放され、より自由度の高く、イメージどおりのフェイスを製作可能

設定

多機能かつ設定が非常に細やかなのはよいのですが,設定できる項目が多岐にわたりすぎてかなり訳がわからない状況になっている設定項目を,作者さんのコメント@サポートBBSを元に解説してみます。
設定→サウンド関連→サウンド出力,の部分についてみていきましょう。

出力デバイス

出力プラグインで,ASIO(with Mixer)かWASAPIを選択します。
仕様デバイスはASIOまたはWASAPI排他モード対応のデバイスを選択します。

Q. with Mixerってなんですか?

(with Mixer) は、その名のとおり、ミキサーを搭載しているバージョンです。
(Project9k) (※えるえむ注:旧バージョンは2種類のASIOプラグインがありました。)の方は、ミキサーを搭載していないので、一度に1つの音しか出せません。このため、部分的に2つ同時に再生する、クロスフェード再生ができません。
最近のバージョンでついた、『停止時にフェードアウト』を使用した場合も、フェードアウトが完全に終わるまでは、次を再生できません。(with Mixer) の方は、ミキサーを内蔵しており、サンプリングレートが同じなら、いくつの音でも同時に再生できます。サンプリングレートが異なる2つの音は再生できませんが、Lilith 本体の方で、『リサンプリングを許可する』のオプションが有効な場合、自動的に他の音とサンプリングレートを合わせますので、特に意識しなくても普通に再生できます。Lilith 単体で使用している場合には、DirectSound を使用しているときと、ほぼ同等の機能を得られます。制限があるのは、DirectSound エフェクトが使えないことだけです。
ただし、内蔵のミキサーは、多重起動した他の Lilith の音や、その他のアプリケーションの音まではミックスできないので、再生中は他のLilith や、その他のアプリケーションは、音を出すことができなくなります。

デバイスの詳細設定(ASIOを有効にした場合のみ設定可能)

チャンネルシフト:音が出れば特に変更する必要なし
占有チャンネル数:ステレオ再生なら2に変更しましょう。

Q. 占有チャンネル数は、デフォルト8のままでいいでしょうか?

必要なければ、減らした方がよいです。ステレオファイルの再生のみで、5.1ch とかは使わないのであれば、2 に。減らしたぶん、ch の処理が減るので、誤差程度ですが高速になり、音切れなどが起こりにくくなります。

バッファサイズ:最低2~最大16です。音が途切れなければ問題ないでしょう。

Q. ASIO出力設定のバッファサイズと再生バッファサイズの違いはなんですか?

Lilithのサウンド出力…にある再生バッファは、DirectSound利用時のDirectSoundのバッファサイズです。それ以外の出力プラグインを選択した際も、DirectSoundと同様に扱える形でプラグイン化しているため、プラグインの中と外の間でやり取りする際のバッファサイズということになります。
再生バッファサイズの1/2の時間、CPU負荷過多などで、Lilithが続きのデータをデコードしてプラグインに渡せない場合、処理落ちとしてバッファサイズ分の音源のループが起きます。
ASIOのバッファサイズはデバイスとそれを使うアプリの間のバッファですので、この再生バッファとは基本的に関係のないものです。わかりやすく書くと、
【デバイス】⇔【ASIOバッファ】⇔【ASIOプラグイン】⇔【再生バッファ】⇔【Lilith】
このような関係になっております。直接的な因果関係はないので、整数倍などにこだわる必要はまったくありません。

使用サンプルレートの制限設定:特に変更する必要はありません。

Q. サウンドデバイスに任意のサンプリング周波数に固定することが出来る項目があるのですが、これは最高の値(例:96kHz)に固定しておいた方が良いのでしょうか?

原則としては固定はしない方がよいです。固定すると、その周波数へリサンプルされながら再生することになります。多くの音源は44.1kHzでしょうから、96kHzへのリサンプルが行われます。原則として、44.1kHzのものは44.1kHzのまま再生するのが最適ですので、これは好ましくありません。またリサンプル処理により、再生負荷が高くなります。
一部の向きでは、高い周波数へとプレイヤー側でリサンプル(アップサンプル)してからデバイスへ渡して再生することにより、音がよくなるという考えがあります。サウンドデバイスの中で勝手にリサンプルされる場合もありますし(プロオーディオ向けデバイスでは基本的にこれはありえませんが)、少なくとも厳密には、1bitDACを利用しているのでない限り、DACのアナログ変換処理の中でアップサンプリングが行われています。
一般的に、高次のアップサンプリングを行うDACほど音がよいという認識ですので、それならソフトウェアでアップサンプリングしてから渡せば、更に音が良くなるという原理なのでしょう。効果のほどは疑問系になりますが、これは好みの問題になります。アップサンプリングによって音質の向上を実感できない限りは、オリジナルの周波数で再生するようにした方がよいです。
なお、サウンドデバイスはサポートしているが、DACがサポートしていない周波数がある場合、
その録音周波数のファイルを再生すると、音が出ないという状況になってしまいます。
これを回避するには、…該当する周波数のチェックを外し、その周波数を利用しないように設定すると回避できます。
#該当する周波数のファイルを再生するときには、
#利用可能な最大の周波数へリサンプルされるようになります。

コントロールパネルの表示:サウンドデバイスの簡易設定が出来ます。

再生バッファ

他のソフトと同様で,短すぎるとCPU負荷が上がります。値は自由に入力できますが,最小値は200msのようです。ちょっと変わっているのは,9999999msまで自由に設定することが出来,この場合事実上再生したいファイルを完全にメモリに展開する使い方が可能だという点です(ただし当たり前ですが再生開始まで結構時間がかかります)。

Q. ASIO出力設定のバッファサイズ[2]の場合、再生バッファ[600~1000]でいいですか?

ASIO プラグインのバッファサイズと、サウンド出力タブの再生バッファには、直接的な因果関係はありません。したがって、連動させて変化する必要はありません。
ASIO プラグインのバッファサイズは、主にデバイスのサンプルフォーマットへの先行変換用のバッファです。再生バッファの方は、先行デコード用のバッファです。 再生バッファは、CPU が十分に高速かつ、余力がある状態なら、(Core2Duo などで、CPU負荷80%↑なってない状態)400ms もあれば十分かと思います。CD-DA をノンストップ再生する際は、1000ms くらいあったほうがよいかもしれません。

Q. Lilithでは出力バッファサイズが200ms以下にはならないように制限がかかっているようですが、どういう理由からでしょうか?

DirectSoundの最低バッファサイズが200msだからです。それ未満で作成しようとすると失敗します。ASIOプラグインなどではそれ以下のサ イズでも作成できますが、音源のデコード時間を吸収するバッファでもあるので、そのような極端に小さいサイズだと恐らく実用に耐えません。

Q. 最適なバッファサイズはありますか?

再生するデータ形式にもよるが、デコードの最低単位2回分以上を行うだけのCPU時間が確実に回ってくるだけのサイズが必要。
最近の高性能PCでは、500ms以下でも十分動作可能だが、小さくすることにあまり意味はない。イコライザの設定変更反映が早くなる程度の効果。小さくするとノンストップ再生で音飛びする可能性が高い。あまり大きくすると、再生開始までの時間が長くなる。
ASIOプラグインとの因果関係としては、ASIO(Project9k)ではASIOバッファサイズの4倍程度あれば十分動作可能。ASIO(with Mixer)ではASIOバッファサイズxプラグイン設定のバッファ数x2程度のサイズが必要。

プラグインへの出力ビット深度

Integer(固定)8bit~32bit,Floating Point(浮動小数点)32bit~64bitが一応選択可能ですが,全て選択できるのはASIOの場合のみで,WASAPIの場合はIntegerから選択する必要があるようです(警告ダイアログがでて再生不能)。

ASIO プラグインを使う場合には、64bit(float) に設定するのがベストです。
ASIO プラグインが、内部で最終段階で、デバイスの対応ビット数に自動で落としますので、ソフトボリューム (Lilith 内で設定できるボリューム)を使用する場合を考えると、先に 24bit(int) に落としてから渡すよりも精度がよくなります。

Q. 出力ビット深度は、周波数と同じく再生するファイルのビット数と同じ深度に設定するのが最適なのでしょうか?それとも、これに限っては64bit(float)でも構わないのでしょうか?

64bit(float)は、ASIO出力の時にしか使えませんが、全体としてまとめると、ソースが8/16/24bit(int)の場合には32bit(float)、32bit(int)の場合には64bit(float)で、ソースの内容を完全に保持できます。
従って、デバイスが対応しているのであれば、32bit(float)を利用するのが最適です。
(32bit(int)のために64bit(float)を選択したいところですが、ASIO出力以外ではサポートされていないはずです)ASIO出力のときには、64bit(float)を利用するのが最善です。

なお、ASIOの場合には、出力プラグインへ引き渡す際のビット深度であり、デバイスへ渡すビット深度ではないことに注意してください。プラグイン内部でデバイスのサポートしているビット深度へ自動変換されます。
デバイスによってどの深度をサポートしているのかは変わりますが、64bit(float)であれば、ASIOで定義されているどの深度でも完全に表すことができるので、プラグインへ引き渡す際には64bit(float)を利用するのが最善となります。

サンプリングレート変換

音が問題無く出るようなら基本的にチェックしないで良いでしょう。

DAC または ASIO ドライバで対応していないサンプリングレートのファイルを再生する可能性がある場合には、『リサンプルを許可』(※えるえむ注:uLilithでは『必要なときサンプリングレートの変換を許可する』)を ON にしてください。ON になっていても、そのまま再生できるファイルはリサンプルしませんので、音質には影響ありません。

その他作者さんの見解で参考になるもの

Q. Lilithで調整可能なメインボリュームのことですが、このボリュームを100%未満にした場合、音質の劣化は当然あるかと思いますが、どの程度の劣化なのでしょうか?

ボリュームを何分の一にしたかで、シグナル/ノイズ比は変わってしまいます。
以下、元の音量の50%(1/2) にしたときの例で話をします。

ソフトウェアボリュームが使用されている場合では(ASIO/ASIO with Mixer/WaveOut プラグイン使用時)誤差(劣化)は、最大で下位1bit分に相当します。
#なぜ下位1bitなのかというと、
#値を 1/2 にすることによって、1bit分の桁落ちが発生するからです。

16bit(int) 出力時には、1/32767=0.003%の計算になります。誤差はサンプルごとにランダムに近い形で発生するため、最大振幅の0.003%のノイズが発生するのと同じようなものです。
#これを量子化ノイズと呼びます、多分。計算すると、-90.3dB 相当のノイズが発生することになります。

24bit(int)以上(float含む)での出力時で、DAC が24bit対応なら、1/8388607=0.0000119%で、-138.5dBのノイズに相当します。
どちらにせよ、聴覚上まずわかることはないと思います。8bit 出力のときには、-42dB程度になるので、これは聞こえてしまうと思われます。
なお、さらに音量を半分(25%,1/4) にした場合には、誤差が2倍、さらに半分(12.5%, 1/8)にした場合には、さらに誤差が2倍、といった感じで、倍倍に増えていきます。25%なら、16bitで-84dB、12.5%なら-78dBの計算になります。

音質傾向

旧タイプのLilithから引き続き,伝統的にクリアネス,S/N感,解像感に優れるのがLilithシリーズの特徴です。

反面,旧タイプは特に力感にやや欠ける嫌いがあるので,楽曲によって得手不得手がありました。アコースティック系や打ち込み系のスピード感を重視する方にはかなりお薦め出来ますが,RockやJazzを腰の据わった音で聴きたいという方にはお薦め出来ません(そういうのはfoobarのほうが向いています)。また,スピード感は非常に良好である反面中低域の厚みもやや不足気味で,密度感にもやや欠ける印象です。

uLilithはこれに対して低域の押し出しが改善されており,ボーカル帯域が薄めになっているのはかわらないのですが,わかりやすくくっきりはっきりした音です(最近のはやりの表現でいうと弱ドンシャリ?)。
データを全てメモリに展開すると,奥行き方向の音場感に乏しいのと音像が平面的になるので個人的にはあまり好きではないですが,バッファサイズを200ms前後に設定するとバランスが取れて個人的には好ましいです。やや箱庭的表現ではありますが,ボーカル音像の周りの空気感も感じられて良いですね。

※ この項目は ビットパーフェクト(バイナリ一致)環境での試聴ですので,音質が変化する主要因としてはソフトウェア処理によるジッターとGND経由のノイズ流入が一応考えられます。ただし,私個人の感想ですので,客観的な音質評価とは言い難く,この点でソフトウェア作者様に問い合わせをされないようお願いいたします。