EACはお古いのがお好き?

12/04/14初稿

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

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

「エラー訂正はCIRCというドライブの機能なのでドライブに任せるのが一番。なのでPureReadシリーズがベストだろう。というか基本的な動作を自分なりに理解してるRippingでデータ資産作らないと後々泣くに泣けないことにも」

という理由からです。
 例えばEACについてですが、そもそも何がExactかって言うと主にオフセットまで正確に“CD-DAを丸ごとCopyすること”に対してであり、Rippingのセキュアさはその手段、と理解しています。

 リッパーというソフトウェアが、“そのためにキチンと規定されたI/Fを持っているとは言い難いハードウェア”をうまく制御できるとはあまり思えなくて。なので、ハードウェア側(ドライブのことです)で制御完結しているPuresReadの効能を代表に、各種ドライブ性能やリッパーを実験した結果「PureRead+iTunes」を選択しています。
 もちろんEACも試したことがありますが、例えば次のようなリッピング結果をもたらすことがあります。


 まず、あるトラックを以下のリッパーとドライブの組み合わせでリッピングしてできたファイルの波形本体部分が一致することをWaveCompareにて確認(WMPのみ認識されないため音くらべにて。WMPはヘッダに独自データくっつけるため)。
 以下、WAVコンペア一致とはもちろんファイルコンペアではなく先頭末尾のゼロサンプル以外の一致を指します。

  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

 つまり、まず間違いなく「正しい」リッピングできているファイル群を準備。これだけの組み合わせで一致するのですから補間結果が偶然一致したとは考えられませんので。
 以下、「たぶんオリジナルファイル」と呼称します。

 PureReadのPerfectModeで停止しないトラックです。もちろん物理的に同じディスクです。iTunesのエラー訂正は有効無効が混在していますが、結果的にWAVコンペア一致しているので考慮すべきパラメータにはならないでしょう。

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

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

 以下、EAC V1.0 beta 1 from 15.November 2010において同CD同トラックをリッピング。
 Panasonic製BDドライブ「SW5582」とMITSUMI製CD-ROMドライブ「FX48」を使います。

・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は詳しくないので何か間違ってるかも知れませんけれど、やっぱ私はPureRead+iTunesでいいや。


 ちなみに…

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

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

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


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


メインメニューへ

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

ERIへようこそ

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

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です
・一応、拍手にコメント(非公開)付けられるようにしてあります
・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください
・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください
・引用の考え方については「007:諸事」をご参照ください
・アフィリエイトはAmazonのみです
・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

最新記事
カテゴリ
検索フォーム
FC2カウンター