EACはお古いのがお好き?

12/04/14初稿

■リッピング環境選定の考え方

 巷ではリッパーとして評価の高い≪EAC≫ですが、ウチでは使っていません。

「エラー訂正はCIRCというドライブの機能なのでドライブに任せるのが一番。なのでPureReadシリーズがベストだろう」

という理由からです。

 そもそも、リッパーというソフトウェアが、“そのためにキチンと規定されたI/Fを持っているとは言い難いハードウェア”をうまく制御できるとはあまり思えなくて
 制御してるとしても、基本的な動作を自分なりに理解できたRippingでデータ資産作らないと、後々泣くに泣けないことにもなりかねません。

 なので、ハードウェア側(ドライブのことです)で制御完結しているPuresReadの効能を代表に各種ドライブやリッパーを実験・調査した結果、「PureReadと≪iTunes≫の組み合せ」を選択した次第。
 もちろん≪EAC≫も試しましたが、例えば次のような結果をもたらすことがあったので採用しませんでした。


 本稿では、「WAVコンペア一致」とはもちろんファイルコンペアではなく先頭末尾のゼロサンプル以外の一致を指します。


■≪EAC(Exact Audio Copy)≫挙動の不思議

 あるトラックを以下のリッパーとドライブの組み合わせでリッピング。
 PureReadのPerfectModeで停止しないトラックです。もちろん物理的に同じディスクです。

  1.iHES208+iTunes6
  2.iHES208+CarryOnMusic10
  3.SW5582+iTunes6
  4.SW5582+CarryOnMusic10
  5.BDC-S02J+iTunes6
  6.BDC-S02J+CarryOnMusic10
  7.BDR-S05J(PerfectMode)+iTunes9
  8.BDR-S05J(PerfenctMode)+WMP12
  9.DVR-S16J(PerfectMode)+iTunes9

 実は、このトラックは「微妙に傷がついていて“油断すると補間発生しちゃう”」トラックなのです。

#だからこそこのような実験できるのですが、そういうトラックを探すのが難しい場合はCD-Rとかで自作したCD-DAに微妙に傷つけて作るのもアリかも知れません。絶対正しい元WAVデータはあるワケですし。

 上記でできたファイルは、波形本体部分が一致することを≪WaveCompare≫にて確認。
 ≪WMP≫はヘッダに独自データくっつけるため認識できないのでそれだけ≪音くらべ≫にて。
 なお、≪iTunes≫のエラー訂正は有効無効が混在していますが、結果的にWAVコンペア一致しているので考慮すべきパラメータにはならないでしょう。

 さらに念のため、同じタイトルをもう1枚調達(つまり同じCDの2枚目。こちらには少なくとも見た目傷はありません)し、上記7番と同じ条件でRippingして得たファイルもWAVコンペア一致を確認しています。
 物理的に違うディスク(傷やプレスの状態は違う)から読み出したデータも一致するのですから、元になったリニアPCMデータとしてはまず間違いなく正しいと思います。これだけの組み合わせで一致するのですから補間結果が偶然一致したとは考えられません。

 つまり、この9通りの組み合わせには「油断はなかった」と考えてよく、まず間違いなく「正しい」リッピングできたと言っていいでしょう。
 以下、「たぶんオリジナルファイル」と呼称します。


 さて、次に≪EAC V1.0 beta 1 from 15.November 2010≫を用いて同CD同トラックをリッピングします。油断なく取り込めるでしょうか?
 新しいドライブとしてPanasonic製BDドライブ「SW5582」、古いドライブとしてMITSUMI製CD-ROMドライブ「FX48」を使います。SW5582は上記ではエラーなくリッピングできているドライブです。

・SW5582+SecureMode
 「Drive has `Accurate Stream`feature」と「Drive caches audio data」にチェック(デフォルトのまま)。
 最後の方(進捗98.8%)でErrorCorrectionゲージが全部点灯するまで再読み込み。
 結果、「たぶんオリジナルファイル」とWAVコンペア一致しないファイルが出来上がる。
 2回リップして生成したファイルどうしはWAVコンペア一致(笑)。
 普通に考えたらベストな環境・設定に見えますが、補間発生しているということです。

 「Drive caches audio data」のチェックをハズしてみても同じ。

 「Drive is capable retrieving C2 error infomation」をチェックすると「Drive has `Accurate Stream`feature」はグレーアウトして選択不能、cacheはハズしたままでやってみると「たぶんオリジナル」とWAVコンペア一致

 ドライブからくる「C2 error info」を信じたら、信じないで自分で確認するより正しくできたってことですかね。

・SW5582+BurstMode
 特に引っかかりなく完了。
 結果、「たぶんオリジナルファイル」とWAVコンペア一致するファイルが出来上がる。

・FX48+SecureMode
 「Drive has `Accurate Stream`feature」と「Drive caches audio data」にチェック(デフォルトのまま)。
 まんべんなく10カ所ほどErrorCorrectionが作動したが、ゲージの最上段(16回分)の点灯でクリア。
 結果、「たぶんオリジナルファイル」とWAVコンペア一致するファイルが出来上がる。

・FX48+BurstMode
 特に引っかかりなく完了。
 結果、「たぶんオリジナルファイル」と全然WAVコンペア一致しないファイルが出来上がる。


 以上、≪EAC≫と新しいドライブを組み合わせてSecureModeでリッピングする場合、「よかれと思ってやったら逆に正しく読めなくなる設定」があるようです。
 一方、古いCD-ROMドライブだとSecureModeが正しく作動しているようですね。Error発生したら繰り返し読みして正しいデータの読み出しに成功しているということでしょう。
 実際、BurstModeだと補間発生しまくりのようですので、これは確かに“SecureMode”の価値アリ、ですね。

 ≪EAC≫が認識する両ドライブの違いはなんでしょう?
 FX48はリードキャッシュは「No」と認識されています。SW5582は「Yes」です。AcuStrmとC2infoはどちらも「Yes」。
 リードキャッシュを備えているドライブの制御が出来ていないのでしょうか? 例えばリトライリードのつもりでリードキャッシュから見当違いのデータを読み出してるとか…
 詳細はドライブの機能調査記事をどうぞ。

 そもそも、≪EAC≫自身が「キャッシュがあるとややこしくなってヤバイぜ」って警告してますもんね。

EACドライブ機能警告

 上記結果を見る限りでは、

・古いドライブ(リードキャッシュなしのCD-ROMドライブとか)を使ってる場合は確かに補間発生を抑える効果がある
・そうではないドライブ(リードキャッシュがあり、そもそもリッピング精度が上がっているドライブ)を使ってる場合は(設定によっては?)逆効果の可能性がある

ようです。
 つまり、ドライブによっては真逆の結果を導く可能性があるので、相棒にするドライブの新旧というか機能とのマッチングに注意(最適な設定)が必要かも知れませんね。もちろん≪EAC≫のバージョンにも依るでしょう。

 ≪EAC≫は詳しくないので何か間違ってるかも知れませんけれど、やっぱ私はPureRead+iTunesでいいや。


 ちなみに…

・FX48+iTunes9エラー訂正なし
 結果、「たぶんオリジナルファイル」と全然WAVコンペア一致しないファイルが出来上がる。

・FX48+iTunes9エラー訂正あり
 訂正なしより2倍くらいの時間がかかる。
 結果、「たぶんオリジナルファイル」とWAVコンペア一致するファイルが出来上がる。

 このトラックは新しいドライブだとC2 Error発生=補間発生しないけれど、FX48では発生しちゃうんですね。
 おお、≪iTunes≫の「エラー訂正を使用する」って効いてるんだ(笑)。


P.S.すべてファイルサイズは同じでした。


メインメニューへ

テーマ : オーディオ
ジャンル : 趣味・実用

最新記事
ERIへようこそ

Author:らかせ
「最新記事」または
「メインメニュー」からどうぞ

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です

・一応、拍手にコメント(非公開)付けられるようにしてあります

・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください

・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください

・引用の考え方については「007:諸事」をご参照ください

・アフィリエイトはAmazonのみです

・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

カテゴリ
検索フォーム
FC2カウンター