スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

EACはお古いのがお好き?

12/04/14初稿

 17/08/28:コメントいただきましたので、リンク先記事で考えた結果を簡易的に記すなど、解りやすく改訂してみました。


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

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

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

という理由からです。

 セキュアリッパーは、原則的にはそれ自身がエラー訂正や補間をするワケではありません。CIRCに基づき訂正や補間を行うのはあくまでもドライブです。セキュアリッパーは「補間発生を認識し、補間が発生しないまでリトライリードさせる」などの“ドライブ制御”を行うものです(1度でダメでも何度も読めば補間なく読めることもあるかも、という考え方)。

 しかし、そもそも“そのためにキチンと規定されたI/Fを持っているとは言い難いハードウェア”をうまく制御できるとはあまり思えなくて。例えば、ドライブ内で補間が発生するとC2 Error“フラグが立ち”ますが、それをドライブが正常に認識できるとは限らないらしい点や、リードキャッシュがあるとリトライリードがうまくできないらしい点などです。

#もちろん、そういう問題は時間が解決する面もあるでしょうから、本稿時点のハナシとご理解ください。

 また、リッピングデータ資産は「基本的な動作を自分なりに理解できた方法」で作らないと、実は補間発生しまくりだったりしたら、後々泣くに泣けないことにもなりかねません。

 なので、ハードウェア側(ドライブ側)でリトライリードなどの制御が完結しており、その動作を理解できている(*)と思っているPuresReadを活用することを優先し、各種ドライブやリッパーを実験・調査した結果、「PureReadと≪iTunes≫の組み合せ」を選択した次第です。

*:ざっくりですが、PureReadは「セキュアリッパーがやってるようなリトライリードなどをドライブ内のファームウェアがやるもの」と言っていいかもしれません。なお、PureReadがOFFでももちろんCIRCによるエラー訂正・補間は機能します。CIRCのON/OFFや訂正・補間の方法を変更することはできません(もちろんセキュアリッパーといえどもできません)。CD読みの基本中の基本ですので。

 もちろん≪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≫だけ≪音くらべ≫にて(ヘッダに独自データくっつけるため«WaveCompare»で認識できないので)。
 なお、≪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 infomation」=補間発生通知を信じたら、信じず自分なりの方法で確認(複数回読んで同じになるか確認)するより正しく補間発生を認識できた、ってことですかね。

・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≫のバージョンにも依るでしょう。
 例えば、上記の結果からは「Drive is capable retrieving C2 error infomation」はチェックしておいた方がいいように見えますが、一概には言えない気がします。“納得のリッピング”するためにこのあたりの動作をキチンと解明するのは大変そうです。

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


 ちなみに…

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

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

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


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


メインメニューへ
スポンサーサイト

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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

カテゴリ
検索フォーム
FC2カウンター
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。