ラベル Foobar2000 の投稿を表示しています。 すべての投稿を表示
ラベル Foobar2000 の投稿を表示しています。 すべての投稿を表示

2014年2月21日金曜日

  

Walkmanのギャップレス再生を検証してみた。

WalkmanにNonstopMixなCDをLAME(V0)オプションでmp3にエンコードして聴いていたら、
明らかに曲間の欠落があるCDが有った。
プツっといった音は聴こえないが、数秒間の音が抜けた形でギャップレスになった感じに聴こえた。
SONY WALKMAN ウォークマン NW-F880 Part5
NW-F880のスレッドにはEAC+LAMEでエンコードしたファイルも
ギャップレス再生出来たとの書き込みがあって、
嘘をついている様な書き込みとも思えなかった。

そこで、LAMEでエンコードする時の設定で、
ギャップレス再生の有無が変わるのではないかと考え、検証をしてみる事とした。

そもそも、ATRACファイルのギャップレス再生は、すべての曲を同じ条件でエンコード(CBR)し、
曲間のサンプル数を無理やりに合わせ、あたかも1つのファイルを再生していると
デコーダーをだますやり方で行われている。このため、X-apli等でエンコードしたファイルは
1曲1曲の長さが違ってきてしまう。(LAMEでいう所の--nogapオプション)

Walkmanがmp3再生に対応したのは、私が記憶している中では
MZ-RH10であり、mp3を再生するデコーダはWalkmanの中では結構長く、
レガシーな物なのではないかと想像した。
なおかつ、ISO基準で本来はLAMEタグには対応しない方が自然である。

そこで、LAMEオプションでVBR、ABR、CBRをそれぞれエンコードして聴いてみた。
すると、CBRでエンコードしたファイルでは、確かに曲間の欠落が気にならないレベルになった。
LAMEでエンコードしてギャップレス再生が出来ている人は、CBRオプションでエンコード
している人だというのが分かった。

しかし、私はLAMEの良さはVオプションによるVBRエンコードだと思っているので、
BオプションのCBRエンコードは使いたくない。
実際にVBRエンコードの音質は高いことが知られており、OGGやACCではVBRが標準となっている。
そこで、AACでエンコードした場合のギャップレスエンコードも検証してみる事とした。

私が、AACを使ってこなかった理由はギャップレス再生の実装が不鮮明だったからである。
NEROのエンコーダが独自に実装したり、AppleがITunes(QuickTime)で実装したり(iTunSMPB)
ISO標準の方式になったりと、二転三転しているなと印象を持っていた。
NEROのエンコーダーのギャップレス方式がISO標準方式になったという情報と、
QuickTimeのエンコーダーがfoobar2000から利用出来、ギャップレス方式を選択できる事が分かったので、この2つを試してみた。
結果を表にまとめてみる。





NW-A867 NW-F807 NW-ZX1
ATRAC
MP3 LAME CBR × ×
VBR × ×
ABR × ×
AACーLC NERO VBR × ×
QT VBR × ×
ALAC VBR - -
FLAC Flaccl VBR -

×→プツっと音が鳴り明らかに曲間が切れている形式
△→一見ギャップレスの様に聞こえるが実際には数サンプル(数秒??)スキップしている形式
○→ギャップレス再生できているか、あるいは、ほとんど曲間が気にならない形式

オプション
lame.exe
-S --noreplaygain -V 0 -h - %d
neroAacEnc.exe
-lc -ignorelength -q 0.65  -if - -of %d
qaac.exe
--ignorelength --tvbr 122 -q 2  --threading --gapless-mode 2 - -o %d


結果、LAME(MP3)は CBRでエンコードすればギャップが気にならなくなる事がわかった。
AACはVBRが基本なので、1つのオプションしか試していません。

2013年10月10日木曜日

  

lossyWAVを使用してのWalkmanでギャップレス再生

X-アプリのAtracやMedia Goで取り込んだmp3/aacは、
機種によってWalkmanでギャップレス再生できそうな事は分かった。
しかし、これはLameでいう所の--nogapオプション相当の機能で、
曲の長さがオリジナルと異なってしまうエンコード方法である。
オリジナルと一緒の長さを保ったままファイルを作成しようとすると、
可逆圧縮しか道は無さそうである。

通常のアルバムはLAMEでmp3にエンコードを行い、liveや、
NonstopMixのCDはflacでエンコードするのがいいのかなと思う。

だが、flacはファイルサイズがでかいのでWalkmanに入る曲が少なくなってしまう。
そこで、lossyWavでflacファイルを作ることによって、
不可逆圧縮でWalkmanでギャップレス再生できるファイルを作成してみた。

lossyWavとは何か?
lossyWavは、波形を最適化することによって、可逆圧縮をしたときに
ファイルサイズを少なくできるプログラム。
当然、波形をいじくるので可逆圧縮ではなくなる。
Wavファイルのサイズが小さくなるわけではない、あくまでもこの後に
可逆圧縮をかけることが必要。

用意するファイル
lossyWav 1.3.0
Flaccl 0.3
fpFlac (Open CL対応のグラボを持っていない場合)


Foobar2000のコンバート設定では--stdoutで2つのプログラムの橋渡しが可能らしい。
そこで、lossyWavとflacclを組み合わせて、LossyFlacを作ってみる。
LossyWavとFlacclを適切な場所に設置し、パスを通しておく。

コマンドラインオプション(lossyWav+Flaccl)
/d /c lossyWAV - -q X --silent --stdout|CUETools.FLACCL.cmd --quiet -b 512 -8 --verify  --cpu-threads 1 - -o %d
(スレッド数を増やすとエラーが出たのであえてスレッド数は1にしてある)

コマンドラインオプション(lossyWav+fpFlac)
/d /c lossyWAV - -q X --silent --stdout|fpFLAC -b 512 --threads 12 -f %s %d -V -8
(スレッド数は手持ちのパソコンの物に変更する。)

lossyWavの-q <X>オプションは
I , E , H , S , C , P , X
←高音質   高圧縮→
Xを指定するとflacファイルのビットレートが320kbpsぐらいになる。

Flaccl/fpFlacの方は-bオプションで512を指定してやる必要があるっぽい。

一応、出来上がったファイル名の末にlossyを付けることにした。

出来上がったファイルをNW-F807に転送して聞いてみた所、
ギャップレス再生される事を確認した。
今後、容量不足になった時にはLossyFlacを利用していこうと思う。

2013年10月3日木曜日

  

fpFLACを使った高速エンコード

Core i 7 3612QMのノートPCでは、flacclで変換速度が思ったほど伸びなかった。そこでOpenCLベースではなくて、通常のエンコーダを使って見ることにした。

flake
本家のエンコーダよりも高速化されているバイナリらしい。
flacclの-verifyオプションで使用されていたりするが、あくまでもテスト段階らしい。

fpFLAC
マルチスレッド処理のエンコーダということで
fpFLACを試して見ることにした。
(※エンコードするにあたって、64bitアプリケーション環境が必要です。)


可逆圧縮は、コンバータ設定にあるBit depthのHighest BPS mode supportedを16に設定する。
(ビットパーフェクトに出力するため)

EAC向けコマンドラインオプション
/c fpFLAC--threads 8 -f %s %d -V -8
圧縮率は本家と同じ-8にしてverifyをかけるために-Vオプションを付けた。
サイレントモードはどうも無いっぽいのでそのまま。

Core i 7 3612QMのノートPCで54分のCDが15秒ほどでエンコードできた。
GeForceやRadeonを搭載していないノートPCでは、
fpFLACの方が高速でエンコード出来ることが分かった。


※2017-08-11 fpFLACの配布元URLが変更になっていたので修正

2013年9月26日木曜日

  

LAMEでmp3エンコード

LAME 3.99.5 32bit/64bit
公式ソースからビルドされたバイナリ。

AltiVec/SSE Optimized LAME Encoder
AltiVec/SSEを使って高速化したエンコーダらしい。

LAME 64bitにパスを通すとEACがエラーで起動しなくなる。
EAC本体は32bitなのだがLAME 64bitのパスが通っていると
その機能を内包した状態で起動しようとするからである。

foobar2000は本体は32bitで動いているが
コンソールアプリには純粋にコマンドラインを投げるだけなので
64bitエンコーダが利用できた。

LAMEの強みはLAMEタグによるギャップレスエンコードと
VBRの最適化にあると思うので-Vオプションを使うことにした。
-V 0 ~ -V9
←高音質 低音質→

EAC
-S --noreplaygain -V 0 -h %s %d
foobar2000



Encoder file:任意LAMEを置いたディレクトリを選ぶ
Extension:mp3
Prameters:-S --noreplaygain -V 0 -h - %d
Format is:lossy
Highest BPS mode supported:24
Encoder name:MP3 (tmkk-LAME)分かり易い名称。
Bitrate (kbps):245VBR(V0)オプションなので、245ぐらい。
Settings:V0VBR V0オプションを使用するので。

  

flacclを使った高速flacエンコード

Flaccl
flacclはGPUの持つGPGPU機能をOpenCLで動かすエンコーダ
OpenCLに対応したグラボを用意すれば動作する。
CPUを利用したエンコーダとは速さが違う気がする。
上のHPからDLできるのはflaccl 0.3だが、
CUETools_2.1.4の中にはflaccl 0.4が含まれている。(違いはよくわからん)

可逆圧縮は、コンバータ設定にあるBit depthのHighest BPS mode supportedを16に設定する。
(ビットパーフェクトに出力するため)

エンコードオプション
-0 ~ -11
←高速低圧縮 低速度高圧縮→
本家flacは-8までなのでとりあえず-8にしてる
--cpu-threads X
Xの場所にCPUのスレッド数を入力する。
--opencl-type X
通常は設定の必要はないが、intelのIvy Bridgeでエンコードする時は
CPUと指定してやる必要があった。

EACやfoobar2000で設定してやると、
うちはCore i 7 980Xと560 TIなので、
/c CUETools.FLACCL.cmd --quiet -8 --verify  --cpu-threads 12  %s -o %d
ってな設定で450倍~500倍の速度が出た。

Core i 7 3612QMのノートでは
/c CUETools.FLACCL.cmd --quiet -8 --opencl-type CPU --verify  --cpu-threads 8  %s -o %d
で一応動いたが速度はあまり出ず7倍程度だった。