FC2ブログ

リッパーの「エラー訂正」とは何か(iTunesがエラー訂正しているのか)

11/01/01初稿

 CDから正確にWAVファイルをリッピング(Ripping)するにはそれができるソフト(いわゆるセキュアリッパー)を使うべきであると言うハナシがあります。≪Exact Audio Copy≫(以下≪EAC≫)や≪PlexTools Professional≫あたりが代表的なところでしょうか。
 それらでは「C2エラー発生」をトリガにしていろいろ動いているようです。
 しかし、C2エラーは「訂正不可能」なエラーのハズなので、それが発生しちゃった状態で「リッピングソフトのできること」はかなり限られていると思うのですが、実際、どんな機能でどんな動きをしているのでしょうか。「セキュアリッパー」を使わないと「ビットパーフェクト」なWAVファイルを得ることはできないのでしょうか。

 その観点で、上記ふたつのソフトを見ていきたいと思います。


■前書き

 両ソフトとも、C2エラー発生をトリガにしていると説明しています。
 訂正可能なものは訂正すればよいのですから、それをトリガにしてリカバリ動作するのは無意味です。ので、やはりドライブが出す「C2エラー情報」は訂正不可能なものについて(*)だと思います。

*:訂正不可能なエラーはCUエラー(Uncorrectable Error)と呼ばれることもあるようですが、本Blogは訂正不可エラー=補間対象=C2エラー派です。

 なお、当Blogでは、特記なく「エラー訂正」「補間」と記した場合、“CIRCによる”C1/C2エラー訂正および補間のことを指すことにしています。
 「訂正」は正しい値に戻る動作ですが、「補間」はその保証はない動作として記述しています。また、「CIRC」はドライブ側の機能であってPC側ソフト(Ripper)の機能ではありません。
 詳しくはそもそも音楽CDのエラー訂正とは何かを考えた記事をご参照ください。

 ちなみに、「エラー訂正」にはビットエラー以外にフレームズレ問題も絡むと思いますが、本稿ではC1/C2エラーに関する考察に限定します。前者がいわゆる「Read Error」、後者がいわゆる「Sync Error」かなぁとは思ってますが…


■≪PlexTools Professional≫の場合

 まず、ソフト本体には「DAEエラーリカバリーの設定について」というタイトルのヘルプがあり、以下のような機能説明になっています。

DAEヘルプ

 次に、Plextorさんのwebサイト(*)にある説明文(11/01/01現在)を以下抜粋します。

*:http://www.skcj.co.jp/discon/plextool/ptp_06.html

音楽CDからオーディオデータを読み取る場合、ディスクの傷により、エラーが発生する場合ばあります。その対処方法として4つのモードを用意しました。

Report Errors only (no recovery action)
エラーの報告だけを行い、エラーの訂正は行いません。

Reduce the speed upon error
エラーが確認され場合は読み取り速度を落として読み込みます。

Read again upon error
エラーが確認された場合は リトライで指定された回数だけ読み込みを繰り返します。速度ダウンを許可が有効になっている場合、さらに低速で再読み込みを行います。

Recover the best sector (least errors)
最もエラーの少ないセクタを選択する。エラーが確認された場合は指定回数だけ読み込み の少なかったセクタを繰り返し、それでもエラーが残る場合は最もエラーを選択して読み込みます。速度ダウンを許可が有効になっている場合、さらに低速で再読み込みを行います。

注:日本語ヘンですね(笑)。ヘルプの文章から“エラー訂正(補間かな?)”してみます。
「最もエラーの少ないセクタを選択する。エラーが確認された場合は指定回数だけ読み込みを繰り返し、それでもエラーが残る場合は最もエラーの少なかったセクタを選択して読み込みます。速度ダウンを許可が有効になっている場合、さらに低速で再読み込みを行います」

Recover the best bytes (least errors) per sector
セクタ毎バイト単位でエラー訂正を行います。エラー訂正が確認された場合は指定された回数だけ読み込みを繰り返し、それでもエラーが残る場合は最もエラーの少なかったバイトを選択して読み込みます。速度ダウンを許可が有効になっている場合、さらに低速で再読み込みを行います。



 実際のソフトの説明とwebサイトの説明は文章が異なりますが、概ね同じことを言っているようです。

 まず最初に、「C2 Error Flag」が発生したら訂正はできないって宣言してるように読めます(やっぱりC2エラーは訂正不可=補間対象のようです)。
 効能として「エラーが無い」じゃなくて「最もエラーの少ない」とも仰ってることからも、訂正できないと理解してよさそうです。

 最後のふたつはつまり「何回か読んだ結果一番よさげなセクターまたはバイトを選択する」ということですよね。つまりエラーは発生したままであり、訂正できるという意味には取れません。

 ところで、≪Plextools Professional≫は欧州Plextorが開発したソフトらしいですね。とすると、上記の各モードの名称は原文ママの可能性が高いと思います(本文はなんとも“和訳”っぽいですし(苦笑))。
 モード名には「Correction」は使われていません。「Recover」ですね。それを踏まえて先入観なく説明を読んでみると、「エラー訂正している」とは読めないと思います。「Recover」を「訂正」としたヘルプの訳はちょっとマズイような気がします。

 以上より、C2エラーが発生したことを検出した時のリカバリ方法(エラー発生なく読めないか何回かトライするとか)がいくつか選択できるのがこのツールの機能ではないでしょうか。ヘルプの最初に書いてある通りですね(苦笑)。


■≪EAC≫の場合

 非常に多機能なソフトですが、CD焼きなどは考えず、PCで再生することを目的にWAVファイルをRippingすることに関しては、公式サイト(*)を読みますと、以下の機能を持つ「セキュアモード」が特長になると思います。

*:http://www.exactaudiocopy.de/en/index.php/overview/basic-technology/extraction-technology/

・基本的に2度読み

・拡張エラー情報に基づき、エラー検出したら最大82回読み直し(16回リトライを最大5セットで80回、デフォルトで2回読んでるのを加えて82回だと推定)

 つまり、何度も何度も粘り強く読む(ことをドライブに指令できる・読み方を設定できる)のがミソだと思います。

 さらに、解説に次のような一文があります。

One really fast mode (nearly burst mode speed) is for drives with C2 error pointer support, accurate stream and are non-caching.

 ざっくり訳しますと、

 そのひとつは、「C2エラーポインタサポート」「正確なストリーム(Accurate Stream)」と「非キャッシュ」のドライブによって得られるマジ速いモード(ほぼバーストモードと同等の速度)である。

 つまり、みっつの条件を備えたドライブなら繰り返し読みはしない(エラー発生してないことが判るので)ってことでしょう。逆に言うと、エラー発生が判らない(または信用しない)場合は、2度読みによってエラー発生の有無を確認しているということです。
 「非キャッシュ」という条件は、リトライリードする際にキャッシュから読んでいたのでは無意味ですので、「リードキャッシュがないこと」という意味だと思います。キャッシュをフラッシュするためにダミーリードとかしてたら遅くなっちゃいますし。

 また、FAQの方には次のような記事が。

What is C2?
On all CD-ROM media are at least two levels of error correction, called C1 and C2. If both fail, the output is probably not correct anymore. Most drives are not able to report if audio reads failed or not, so each block had to be read twice and be compared to make sure that everything is fine. But some newer drives are able to report if C1/C2 failed on specific samples on a read, making it possible to read only once and see if a read error occured. But there is still a problem, as some drives do not report these errors correctly, so you should test it thoroughly before trusting the results.


 「C1とC2というエラー訂正レベルがあるけど、両方やって訂正できなかった場合はもうダメ」と書かれています。Plextorと同じですね。さらに「ほとんどのドライブはエラー発生をレポートしてくんない」「だから2回読んで比較することで正確さを期していた」「しかし新しいドライブではC1/C2エラーをレポートしてくれるようになったので1度読みが可能になった」「まだ問題あるけどさ」という内容かと思います。
 エラー情報が取得できれば速度はバーストモードとほぼ同等、という先の記述とも一致しますね。

 ちなみに、≪EAC≫の優秀な機能の中で、公式webサイトを中心に調べて「単純に楽曲データとしてビットエラーのないWAVファイル得る」ことを目的とするならあまり関係ないだろうと判断した機能は以下の通りです。

・ギャップ技術
  トラック間無音部を抽出して前後どちらのトラックにくっつけるか無視するか選べる。

・トラック同期技術
  「Accurate Stream」機能を持たないドライブではトラック間に無音部分が
 ない場合に問題が起こる可能性があるのでそれを同期させる
 (同期の意味はよく判りません…)。
  Accurate Stream対応ドライブなら無関係と判断
 (Accurate Streamの意味はよく判りません…)。

・オフセット技術
  CDメディアとドライブの問題…セルCDと完全同一なCD-Rを作る時の課題であって、
 ファイル抽出とは基本的には関係ないと判断。
  17/04/18追記:前言撤回。ファイル抽出にも大いに関係ありそうです。詳細は以下に。


■セキュアリッパーの本質

 両者とも、C1/C2エラーに関する「CIRC規格で行う訂正」自体をソフトウェアで強化しているワケではありません(ドライブ側の役目なので当たり前ですが)。
 上記で見てきた通り、開発者さんの説明を読み込むと、セキュアであることの本質はC2エラー発生が判ったらいろんなやり方で何回もリトライリードすることでエラー発生なく(補間発生なく)読もうとする機能だと理解できます。複数回読んだうち一番多く得られた値を採用する、なんてこともしているようです。

 ミソは「C2エラー発生をどうやって知るか」だったんです。

 どうもC2エラーレポートはドライブによって実装が不確からしく、汎用リッパーでは「C2エラーレポートを信頼するモード」以外に、「信用せず、2度読みコンペアすることでエラー発生の有無を確認するモード」の2種があるようです。C2エラーが発生していたら繰り返し読んだ結果(=補間結果)はおそらく異なるだろうという理屈に基づくものですが、補間結果が同じになる可能性もあるので、パーフェクトとは言えません(*)。
 だからこそ、≪EAC≫ではC2エラー発生が判るなら(ドライブの情報を信用できるなら)2度読みしないし、発生しなければリトライもないので速度はバーストモードとほぼ同等、と言っているのだと思います。

*:16/07/20追記:どうも補間は「前後の平均」のようです。ですので、連続的なランダムエラーにならないと平均値は必ず一致してしまいます。実際、エラー補間値は平均値になっていること&連続していない場合は≪EAC≫に認識されないことを確認しました。

 一方、特定ドライブ専用リッパーではC2レポートを信用して動けます。例えばPlexToolsはそもそもそのドライブ専用ツールですから、エラー情報の取得や制御など、ソフトとハードの連携は確実ですのでさらに高精度に実行可能になっていると言うことでしょう。

 ちなみに、Mac用リッパー≪XLD≫には「C2エラーの情報を利用する(機能するドライブは限られます)」というチェックボックスがあるようです(*)。

*:http://www.phileweb.com/review/article/201206/29/536_2.html


■さらなるセキュアを求めて(DB照合サービス)

 本項19/02/28追記。
 見てきた通り、≪EAC≫では自分で何度も読んで違いが発生しないかを見ています。
 しかし、上述した通り、補間値が同じになると何度読んでもエラー箇所から同じデータが読みだされるためエラーを認識できません。
 ≪EAC≫には「CD全体のリッピング」を自動的に2度行う機能もあります。Copy(本番)とTestのふたつのCRCとその比較結果欄がそれです。ですが、TestとCopyの2回ではやはり一致してしまう可能性もそれなりに高いでしょう。
 異なるドライブでの比較なら流石に発生個所が完全に一致する可能性はほぼないですから違ってくるでしょうけれど、その場合はドライブオフセット補正は必須です(*)。何より、ドライブ変えて2回リッピングしてその結果を比較するのはメンドクサイですよね。

*:例えば、あるCDのtrack02をドライブオフセット補正値0と+1(AR使用しないにして手動設定)でリッピングしてみたところ、全く異なるCRC値になりました。もちろん同じドライブに入れたまま続けてのリッピングです。
 なお、≪EAC≫のCRC値は、後述するAccurateRipなどの「DB上の照合データ」とは関係ありません。

 13/12/17追記:オフセットやギャップに関してはよろしければこちらの記事をどうぞ。

 つまり、リッピングする同一タイトルの枚数が“n=1”では限界があるということです。といって2枚ずつCDを買うなんてできません。
 そこで、インターネット環境を活かし、「他の人のリップ結果から生成した照合用コードをDB化する」ことでn数を増やすサービスが開発されたのですね。
 代表的なのが「AccurateRip」です。「CTDB」もあります。それぞれ特定リッパー専用サービスではないので、≪EAC≫では両方採用しており、リッピング結果ログに記録されます。

#登場当時のセキュアリッパーは上述の通り自分で補間発生を認識して発生しないように読むものでしたので、「SecureモードやParanoidoモードを使うためのもの」でしたが、DB照合サービスを実装した現在では
「Burstモードでリッピングして照合できたら終了。できなかったら補間発生をなくすためSecureなモードでがんばる」
という手順が効率的になったと言えるでしょう。

・AccurateRip(AR)
 ≪dBpoweramp≫のベンダが複数のリッパーに提供しているものです。
 オーディオ用NASにも搭載されているんですね。アイ・オーデータ製NAS:RAHF-S1の解説を引用しておきます。

※1 本商品で採用しているAccurateRip™は、英国Illustrate Limited社のCDリッピングデータ照合サービスであり、将来予告なくサービス提供が終了する場合があります。サービス終了後も、照合機能以外のリッピング機能はご利用いただけます。
出典:https://www.iodata.jp/product/nas/personal/rahf-s1/

 V2もあります。ていうか現在はV2がメイン?

 ちなみに、DBに登録される「リップ結果データ」は以下では「チェックコード」と呼ばれています。

What are the odds of 80 people agreeing with your rip, but they really had a bad rip (ie those 80 people had bad rips which happened to give the same check code)? the odds are 4 billion x 4 billion (repeated 80 times), an astronomical number. If more than 3 people agree with your rip, it is 100% certainty it is accurate.
出典:https://www.dbpoweramp.com/secure-ripper.htm

ARチェックコードとドライブオフセット
 ところで、AccurateRipで比較に用いるチェックコードは“オフセット”が違うと異なる値になります。ドライブにはオフセットがありますから、補正しないとドライブごと(オフセット仕様ごと)のチェックコードになってしまうワケです。
 ≪CUERipper≫では、オフセット値は自動設定されますが手動で変更できますので(メインのCTDBはオフセットを気にしない故?)、補正値を変更してARチェックコードがどうなるか見てみました。
 オフセット補正が+667が必要なドライブの値をゼロに設定してみたところ、ARチェックコード値は確かにV1もV2も変化しました。
 ≪EAC≫ではAccurateRipは補正前提でないと機能しないようです(ARを選ぶとオフセット値は所定の値が入って変更できないことから)。

ARチェックコードとディスクオフセット
 ディスクオフセット(いわゆるプレス違い)が違っても、ドライブオフセットと同じ理屈で変化します。ので、同じIDのCDでも複数のバージョンがある場合は複数のARチェックコード値が存在することになりますが、それらは(結果的に?)それとして保存されているように見受けられます。
 そこで、同タイトル(同商品番号)でディスクオフセットが異なる2枚を持っているタイトルでARチェックコードを確認してみました(トラック1にエラーが出るディスクと出ないディスクです)。
 トラック2の≪EAC V1.3 from 2. September 2016≫でのリッピング結果を以下に示します。1トラックだけのリッピングです。

・エラーあり盤
  Copy CRC B66BB840
  Accurately ripped (confidence 11) [392FCBB0] (AR v2)

・エラーなし盤
  Copy CRC 5E15B169
  Accurately ripped (confidence 4) [EC5B8D8A] (AR v2)

 なお、エラーありトラック1の結果は以下の通り。

・エラーあり盤
  Copy CRC E6EC38E6
  Cannot be verified as accurate (confidence 12) [C4CCD74F], AccurateRip returned [95FCEBCB] (AR v2)

・エラーなし盤
  Copy CRC B28537DA
  Accurately ripped (confidence 3) [006F8261] (AR v2)

 「confidence」は、一致があったプレスバージョンのARチェックコード登録数だと思いますが、エラーがあった場合のconfidence数は何を表示しているのでしょう? エラーによって変質しているARチェックコード値でプレスバージョンが解るとも思えないのですが。1トラックだけのリッピングですから他トラックの情報ないハズですし。ちなみに≪CUETools≫でリペアしたV2値は「5aabfc50」でした。その時のトラック2は「392fcbb0」になってましたのでこのプレスバージョンの正しいARチェックコードがこれだと思います。一致数は11でしたので、上記で提示している「confidence 12」はまた別バージョンということでしょうか。
 ちなみに、当タイトルの≪CUERipper 2.1.6≫による「AccurateRip found」数は、この時点で40(CTDBは125)でした(2枚とも)。

・ARチェックコードと「+30補正しすぎじゃないか」問題
 オフセット補正を“しすぎている”としましょう。とすると+667は+637になりますが、もちろんゼロにする場合と同じく+667とは違う値になります。
 しかし、すでに、問題発覚前の補正値で大量のチェックコードを集めたのですから、そのままでいいと思います。DB照合サービスにおける照合値は一定のルールに基づいて集められ照合されればよいもので、“真のトラック先頭”から読んだ場合の値である必要はないためです。
 確かにリッピングしたファイルは異なるものになりますが、30サンプル多めに“後ろ倒し”しても、トラックの頭が30サンプル減りおしりがその分増えるだけですので、事実上問題にはならないでしょう。そもそもアルバムの順番通り再生する場合は減った分は前トラックのおしりにくっついていますので、先頭トラックの頭と最終トラックのおしり以外は問題になりません。

・ARチェックコードとプリギャップ
 ギャップを削除すると、「もともとプリギャップが存在しなかったので関係ないトラック」以外は判定されません。
 例として、あるCD(全10曲)の、プリギャップが58フレームあるトラック4のリッピング結果ログを抜粋しておきます。

・前トラックに付ける(デフォルト)&ARなし(ドライブオフセット補正なし)
  Copy CRC E0BC3C35

・前トラックに付ける(デフォルト)
  Copy CRC D3A19A2F
  Accurately ripped (confidence 12) [768A9CA4] (AR v2)

・自トラックに付ける(Gap解析しないとできない)
  Copy CRC 1F535ED2
  Accurately ripped (confidence 12) [768A9CA4] (AR v2)

・プリギャップを削除する(Gap解析しないとできない)
  Copy CRC FF00E783
  Track not fully ripped for AccurateRip lookup

 このトラックでは、プリギャップを「自トラックの先頭」「前トラックの末尾」のどちらにつけるかに影響されないようです。
 しかし、上記の2枚持っているタイトルのエラーなしトラック2では以下のようになりました。

・自トラックに付ける(Gap解析しないとできない)
  Copy CRC 6B5C9164
  Track not fully ripped for AccurateRip lookup

 このトラックのプリギャップは2秒と25フレームあります。長すぎると対応しきれないってことでしょうか? でも、先のタイトルのトラック10は1秒42フレームのギャップがあるけれどARできましたので、タイトルに依るのでしょうか?
 ギャップ処理は無難にデフォルトが良さそうです。

 なお、当ログから、≪EAC≫のCRC値はギャップの扱いを変えると変化することが解ります。

・CUETools-DataBase(CTDB)
 AccurateRipと同じ「“チェックコード”のDB照合」技術ですが別物です。≪CUETools≫が展開しているものです。
 「リップ結果の照合データ」はこちらでは「チェックサム」と呼んでいるようです。

You probably heard about AccurateRip, a wonderful database of CD rip checksums, which helps you make sure your CD rip is an exact copy of original CD. What it can tell you is how many other people got the same data when copying this CD.CUETools Database (CTDB) is an extension of this idea.
出典:http://cue.tools/wiki/CUETools_Database

 CD全体として扱っているのがミソのようで、ドライブオフセット・ディスクオフセットらに影響を受けないようですね。

CTDB is free of the offset problems. You don't even need to set up offset correction for your CD drive to be able to verify and what's more important, submit rips to the database. Different pressings of the same CD are treated as the same disc by the database; it doesn't care.
出典:http://cue.tools/wiki/CUETools_Database (ボールドは筆者)

 プリギャップの影響はありません。というか、そもそもどうするか選択できません。CD全体で見ているので選択する概念がないのではと推定しています。

・チェックコード(チェックサム)照合サービスは100%セキュアか
 何度読んでも平均値が入る補間が同じ個所で発生する場合、エラー発生は認識できません。が、その場合照合値はDB上の値とは一致しませんから、“DB上に照合値があれば”エラー発生を検出できます。上記ARの引用では「3個以上一致したら(確率的に)絶対大丈夫」と言っています。まあ、違う環境で同じ照合値になるようなエラーが発生することはまずないので、一致するものがひとつでもあれば現実的には大丈夫だとは思いますけれど。
 しかし、タイトル(CDのID)があったとしてもディスクオフセットが一致するバージョンがないかもしれません。
 その点、CTDBはドライブオフセットだけでなくディスクオフセットにも影響を受けないようです。
 なお、細かい点ですが、CTDBでもトラック1の前にある隠しトラック(HTOA)の照合には非対応とのこと。

No verification or recovery of HTOA (Hidden Track One Audio).
出典:http://cue.tools/wiki/CUETools_Database

 また、チェックサムは“最初と最後の5880サンプル”は含まないデータで生成するらしいので、ここにエラー(2度読みでは認識できないようなエラー)があった場合は、照合できてしまうかも知れません。が、≪CUERipper≫はドライブからのC2Error情報を参照しているようなので、たぶん照合前にエラーを認識するとは思いますが、「ドライブからC2エラー情報が確実に取れるか問題」はあるかも知れません。

If there's a match, you can be certain it's really a match, because in addition to a recovery record, the database uses a well-known CRC32 checksum of the whole CD image (except for 10×588 offset samples in the first and last seconds of the disc). This checksum is used as a rip ID (CTDBID) in CTDB.
出典:http://cue.tools/wiki/CUETools_Database

 以上より、CTDBなら「C2問題がないドライブで」「データベースにチェックサムがありさえすれば」「HTOA以外は」盤石と言えそうです。


 さて、次に「セキュアとは言われていないリッパー」の方も見てみます。


■≪iTunes 9≫の場合

 セキュアと言われてないリッパーにも「エラー訂正」ってありますよね。しかし、いくら調べても何をやっているのか全くと言っていいほど判りません。
 そこで、≪iTunes≫の「エラー訂正」について実験してみました。≪iTunes 9.0.1.8≫にて。

 まず、チェックを入れるとリッピング時間は本当に遅くなるのか確認します。
 対象は以下の2トラックとしました。

・CCCDの、あるトラック
・PureReadのパーフェクトモードが停止することでC2エラー入りであることを確認した、あるトラック

 ドライブは以下の通り。S05JのPureReadはもちろん標準モードにて。なお、追加調達分は≪iTunes 11≫、19年分は≪iTunes 12.6.2.20≫で確認しています。   

   ・Pioneer製BDライタ:BDR-S05J(2010年製)
   ・Pioneer製DVDライタ:DVR-105(2002年製)
   ・Panasonic製BDライタ:SW-5582(2006年製)
   ・LITEON製BD-ROM/DVDライタ:iHES208(2009年製)
   ・LITEON製BD-ROM:iHOS104(2009年製)
   ・Plextor製DVDライタ:PX-716A(2004年製)
   ・日立LG製BD-ROM/DVDライタ:GGC-H20N(2007年製)
   ・Panasonic製BDライタ:SW-5583(2008年製) 13/05/15追加調達
   ・Logitec製SlimDVDライタ:LDR-PMJ8U2LBK 19/02/09追加調査

 Logitec製の中身はHL-DT-ST DVDRAM GP68N(日立LG製?)です。

 …どのドライブを使っても両トラックともONとOFFで明確なタイム差は認められませんでした。最外周トラックではドライブの最大倍速に近い速度が出ています。少なくとも50%以上の速度は出ていますので、ONでもOFFでも1度読みだと推定します。
 また、iHES208とiHOS104にて、同じディスクの「エラーなしトラック」→「エラーありトラック」連続リップしてみたところ、トラックが変わっても回転音は変わりませんでした。つまりシフトダウンなどはしていないようです。これもONとOFFで同じです。

 これでは何も判らないので、ドライブを追加で調達してきました。なるべく古め、安そうなヤツを。

   ・MITSUMI製CD-ROM:FX48B0M(2005年製)
   ・東芝サムスン製DVDライタ:TS-H653
   ・Plextor製CD-RW:PX-W8432T(2000年製) 13/05/08追加調達
   ・TEAC製SlimDVD-ROM:DV-28S-Y 13/05/12追加調達
   ・RICOH製DVD+RW:MP5240A(2003年製) 13/05/13追加調達

 この5機ではONとOFFで差が! 古い(安い?)ドライブには差が出る要因がある?
 以下、具体的数字はFX48のものです。

・エラーなしトラック
 ONにすると、OFF時と回転音は変わらないのに倍速表示が半分以下になり、実際に時間も約2.5倍(11:27が28:89)になりました。半分以下どころじゃない遅さになるみたいです。
 「回転音が変わらずリップ時間が長くなった」ということは、複数回読みをやってるっぽいです。
 トラックのデータ量とドライブの倍速仕様から計算すると、OFF時は2度読みはできない速度が出ているので1度読みだと思います。ON時は、時間は3倍にはなっていないことから2度読みと推察します。

・同じディスクのエラーなしトラックとエラーありトラック
 ふたつを連続リップすると、ONでもOFFでも「エラーありトラック」に移った途端に急ブレーキがかかって減速します。この時の「エラーありトラック」リップ時間は、OFFが52:50、ONだと2:54:20。3倍以上になっています。

 …どうも、「iTunesエラー訂正」ONとOFFで、訂正挙動の変わるドライブと変わらないドライブがあるのは間違いないようです。一体何が違うのでしょう?
 そこで、これらドライブのEAC的特徴を調べてみます。Ver1.0 beta1 from 15.Novenver 2010にて。「エラーありトラック」のあるディスクを入れて。

         Cache AcStm C2info
 変化しない軍団
    SW-5582  Yes  Yes  Yes
    SW-5583  Yes  Yes  Yes (*)
    PX-716A  Yes  Yes  Yes 
    iHES208  Yes  Yes  Yes
    LDR-PMJ8 Yes  Yes  Yes (V1.3 from 2 September 2016にて)
    iHOS104  Yes  Yes   No
    BDR-S05J  Yes  Yes   No
    DVR-105  Yes  Yes   No
    GGC-H20N  No  Yes  Yes

 変化する軍団
    FX48    No  Yes  Yes
    TS-H653   No  Yes  Yes
    PX-W8432T  No  Yes  Yes (*)
    DV-28S   No  Yes  Yes (*)
    MP5240A   No  Yes  Yes (*)

*:Ver1.0 beta3 from 29.Augst 2011にて

 これを見ると、「iTunesエラー訂正」ONとOFFでの挙動の変化は「Cache」のYes/Noと関係していそうに見えます。が、H20NはNoでも挙動変化しません。
 Panasonic製スリムドライブのUJ-852ではYesになる場合とNoになる場合があったことや、そもそもどんなCache仕様だと影響を受けるかEACとiTunesで同じとは限らない点などを鑑み、ここではH20Nは例外として「Cache機能がNoだと挙動が変化する」と仮定して話を進めたいと思います。

 一方、「C2 Error Info」機能の有無は「iTunesエラー訂正」のONとOFFでの挙動に変化を与えないようです。
 変化するドライブは「iTunesエラー訂正」がONでもOFFでもC2エラーありトラックでシフトダウンしますので、「C2 Error Info」情報を常に利用していると思われます(変化するドライブはすべて「C2 Error Info」がYes=機能あり)。変化しないドライブには「C2 Error Info」機能がYesのものもNoのものもありますので、iTunesはこの情報を使っていないようです。

 なお、変化しないドライブは「デフォルトで最高速読み(1度読み)しており“遅くするトリガがないから変わらない”」と判断しています。「デフォルトで複数回読みしており“速くする(複数回読みしなくていい)トリガがないから変わらない”」とは思えません。
 前述の通り、変化しないドライブではONでもOFFでも1度読みの速度が出ていますが、変化するドライブでは最高速の半分以下の速度しか出なくなりますから、変化しないドライブのデフォが複数回読みとは思えないためです。
 ちなみに、「CD-DAのCIRC」と「CD-ROMのEDC/ECC」は全く別のエラー訂正システムと理解すべきです。ゲームソフトなどのCD-ROMコピープロテクトを回避する機能として「EDC/ECCのエラーレポートを無視する」というものがあるようですが、言うまでもなく音楽CDのリッピングとは無関係です。だって音楽CDにはEDC/ECCなんて元々入ってないのですから(苦笑)。

 また、「キャッシュ機能がYes/No」とは、ドライブがバッファを持っているか否かとは単純には関係ないようです。
 そこで、以下iTunesの想定においては、「キャッシュを無効化できるかできないか」という観点で記します。Noは「Noにできる=無効化できる」という意味です(もちろん実際にキャッシュがない場合も含む)。

 これらを総合すると、「iTunesエラー訂正」とは、

・リードキャッシュ機能がNoなドライブの場合
 ON/OFFに関係なく、「C2 Error Info」を受けたらシフトダウンする。
⇒OFF時は“1度読み”しており「リッパーの読み方だけでは補間発生やフレームズレを認識することはできない」ハズだが、それでもシフトダウンするということは「C2 Error Info」以外にそのトリガはないとの推定から。

 ON時は2度読みを行っていると推察する。
⇒FX48の例では、OFF時の2倍以上3倍以下の読み取り時間になることから。

 加えて、ON時のリップ時間の増加率がエラーなしよりもエラーありトラックの方が大きい(同じくFX48の例)ことから、ON時はOFF時より多くの回数読んで補間値を選定している可能性がある。ただし、シフトダウンしているので何らかの誤差かも知れない。

・リードキャッシュ機能がYesなドライブの場合
 キャッシュがあるとフラッシュしないと複数読みする意味がない。が、フラッシュ動作はえらく大変かつ副作用も大きい(?)ので、フラッシュしない。つまりONでも2度読みをやらない。
 「C2 Error Info」も活用せずONでもOFFでもシフトダウンしない。活用するためにはやっぱりキャッシュをフラッシュする必要があるため。
 つまり、リードキャッシュがあるドライブだと判断したら、エラー訂正をONにしても“なにもしない”(潔く諦めてる?)。なのでRipping速度が変わらない。

と想像します。ネット上では「フレームズレ対応」っていう情報もあるようですが、どうもそれじゃないような。あ、でも、2度読みしてるとすれば結果的には対応していることになるのかな?


 キャッシュ機能がNoなドライブ(古い・安いドライブ?)なら、結構“セキュア”なリッピングしてるような気がしますね(笑)。
 「iTunesは新しい(高い?)ドライブほど“セキュア”なリッピングしない」ということになり、それは感覚的には逆のイメージなことが解りにくい要因のひとつかも知れません。

 どうも、キャッシュ機能がNoなドライブを前提にしているような気がします。
 その上で、「エラー訂正を使用する」のチェックに関係なく「C2 Error Info」が上がってくることをを前提にちょっとセキュアなリッピングしてるようです。
 じゃあ「エラー訂正を使用する」をチェックするのはどういう意味かと言うと、具体的には「C2 Error Info」が上がることを信頼しないで自分で2度読みして確認するということでしょう。
 ということで、機能名と実動作の関連性が薄くて解りにくいですね。もともと“Mac用ソフト(Macのハード事情に合わせて開発された)”だからかも知れません。


■ということは

 「エラー訂正」について、「CIRC(ハードウェア)のC1/C2エラー訂正」と「ソフトウェア側でがんばる機能」がごっちゃに語られる場合が多々あることに気を付ける必要がありそうです。ソフトウェアの機能表記が、正しい値に戻る保証がないのに「エラー訂正」となってるのがそもそもヨロシクナイのではと思いますけど…

 さて、ソフト側では「CIRCエラー訂正」はしていないのですから、Ripping品質の「要(かなめ)はやっぱりドライブ性能」なのです。ドライブの読み取り性能が低ければソフト側が何度読んでもダメなものはダメでしょう。C1やC2のエラー訂正動作はCIRCによる規定なので差は無いため、要は光学的な性能になると思います。
 そして、最近では“ソフトウェアに言われなくても”自分でリトライ試みたりするドライブが登場しています。
 その代表格がPioneerの「PureReadシリーズ」と考えていいと思います。
 要するに

・セキュアリッパー:特定ドライブ専用・・・代表例≪PlexTools Professional≫
 勝手知ったるドライブと一心同体でやってるので動作は保証されるが特定ドライブでしか使えない。

・セキュアリッパー:汎用ドライブ用・・・代表例≪EAC≫
 がんばってソフトウェアでやってるから特定ドライブ以外でも機能するが保証の限りではない。
 例えば、ドライブのファームにどんなバグがあるか判ったもんじゃない。
 ただし、「DB参照サービス」をうまく使いこなせれば(DBにあれば)盤石かも知れない。

・セキュアとは言われてないリッパー:汎用ドライブ用・・・代表例≪iTunes≫
 いわゆる「エラー訂正」をONにするとちょっとがんばるけど、セキュアリッパーほどはがんばらない(一般的利用での利便性を優先していると思われる)。
 また、リードキャッシュ機能があるドライブだと諦めちゃう。

・リッピング精度向上機能付きドライブ・・・代表例「PureReadシリーズ搭載ドライブ」
 ドライブのファームウェアで処置。それを専用ユーティリティで制御できる。
 ファームレベルなのでPC側とI/F規定していないような情報も使った多様なリトライできる。
 また、「パーフェクトモード」なら最終的な補間発生を確実に認識できる。
 メーカが動作保証しているもの以外のリッピングソフトは相性が若干懸念されるが(ドライブが勝手にやってるリトライ動作で誤動作しないか)、選択の余地あり。
 また、セキュアリッパーである必要なし… というか逆にリッパーは「どシンプル」な方がいいような。

というまとめでどうでしょう。

 CD面とのレーザービームのやりとり関連はドライブにお任せするのが一番。「読み取りは盤面で起こってるんだ!」ってなカンジですかね。
 ということで、現時点では「PureReadシリーズ+お好みのリッピングソフト(*)」が、便利さとBitPerfectなRippingの両立が可能なナイス・コンビネーションじゃないかと思います。

*:もちろん動作保証がない場合は充分な事前動作確認が必要です。また、セキュア的な機能は何もしない設定がいいと思います。リトライ的な動作がPureReadとソフトでバッティングしちゃうとヘンなことになる可能性ありますので。

 PureReadの効能と、PureRead2の進化についてはそれぞれ別エントリーに記載していますのでよろしければご確認ください。

 12/08/04追記:EACとiTunesの動作について新旧ドライブで確認してみました。


■備考

・Accurate Stream
 ヨクワカラナイ「Accurate Stream」について、LINNのwebページの解説を引用しておきます。

1. ‘Accurate Stream’ – This feature means that the drive should be capable of sample-accurate reads and hence should have no Read Offset Jitter.
出典:https://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminology

 正確にサンプルが読めるのは普通アタリマエだと思いますので、ぶっちゃけ「Read Offset Jitter」、つまりオフセットが変動しなければいいみたいですが、手持ちドライブで全部Yesだった通り、結構古いものでない限り“Accurate”なのではないでしょうか。

 本家(?)の解説っぽいところも。

Modern CD drives (every drive bar a handful in the last 4 years) support Accurate Stream, this feature allows a CD drive to precisely locate an area of CD (unlike their counter part - ordinary CD players), it also puts an end to the requirement for a CD Ripper to jitter correct (that is jump back more than required to re-sync when ripping blocks).
出典:https://www.dbpoweramp.com/spoons-audio-guide-cd-ripping.htm

 「CDプレーヤではできない」「PC用CDドライブにはできるものがある。て言うか最近は普通できる」ってことでしょうか。リトライリードするために読む場所を正確に指定できるってことみたいです。
 普通ミクロなイメージがある「ジッタ」という用語に惑わされない方がよさそうです。


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

・アフィリエイトは「Amazon.co.jpアソシエイト」のみです

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

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