スポンサーサイト

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

光学ドライブオールスターバトル

13/06/02初稿

 「健常なディスク」における光学ドライブのCDリッピング性能差はおそらく無視していいでしょう。
 が、では「ダメージディスク」では差があるのでしょうか。
 つまり、「読み取り性能のいいドライブ・悪いドライブ」は明確な差をもって存在するのでしょうか。
 存在するとしたら、コンパチ仕様やベンダによってその傾向はあるのでしょうか。
 また、それはどんな種類の傷でも同じなのでしょうか。

 傷ついたトラックを2種準備してその確認を試みました。


■ドライブ総進撃

・前提条件
・2タイトルとも別途傷のないCDを準備して正常なデータを得ていますので、これとWAVコンペアします。
 ちなみに、いつの間にか自然に付いてた傷であり、敢えて付けたものではありません。その方が現実的であろうからです。

・基本的なドライブの光学特性(レンズ・ピックアップ(を動かすアクチュエータ))を見るのが目的ですので、リッパーはソフトウェア側の小細工なしに≪iTunes11.0.2.25 x64 エラー訂正なし≫を用います。

・ドライブも敢えてクリーニングなどは行いません。古いドライブや中古ドライブは、現時点での実力として比較するのが現実的であろうからです。クリーニングは下手すると逆効果になりかねませんし(ちなみにERIは完全禁煙です)。

・PureRaedはリッパーではなくドライブ側の機能とみなし、S05Jはパーフェクト,マスター,標準3通りのモードでエントリーさせます(それぞれP,M,Hと略)。ちなみにiTunesはPureRead動作保証外ですが特に問題ないと判断しています。

・リッピングは1回としました。こんな実験でもない限り何度も繰り返してリップすることはないでしょうから(だって何度やったってノイズ差にならない限りはどれが一番いいかは判らないんですから)、例え1回だけでも“実際にそういう結果になることはあり得る”とは言えるためです。

・ファイル比較は≪WaveCompare 1.32≫です。いつもありがとうございます。

・OSは≪Windows7 HomePremium SP1 x64≫、ハードはZ68の自作機です。

・PATAドライブは以下にてUSB接続しています。

   ←ウチの実物は黒いけど。

・エントリードライブ
  ・SATA:Pioneer製BDライタ:BDR-S05J (2010年製) F/W1.12
  ・PATA:Pioneer製DVDライタ:DVR-105 (2002年製) 中古
  ・PATA:Panasonic製BDライタ:SW-5582 (2006年製)
  ・SATA:Panasonic製BDライタ:SW-5583 (2008年製)
  ・SATA:日立LG製BD-ROM/DVDライタ:GGC-H20N(2007年製)
  ・SATA:LITEON製BD-ROM/DVDライタ:iHES208-1 (2009年製)
  ・SATA:LITEON製BD-ROM/DVDライタ:iHES208-2 (2009年製)
  ・SATA:LITEON製BD-ROM:iHOS104-1 (2009年製)
  ・SATA:LITEON製BD-ROM:iHOS104-2 (2009年製)
  ・PATA:Plextor製DVDライタ:PX-716A(2004年製) 中古
  ・PATA:RICOH製DVD+RW:MP5240A (2003年製)
  ・PATA:Plextor製CD-RW:PX-W8432T (2000年製) ジャンク
  ・PATA:MITSUMI製CD-ROM:FX48B0M (2005年製)
  ・USB外付け:TEAC製スリムDVD-ROM:DV-28S-Y (推定2011年製)

 iHES208とiHOS104は2台ずつあるので同型番の個体差が見られるカモという意味で2台エントリーさせました。ただしiHES208はF/Wバージョンが異なります。
 傷トラック1には以下も特別エントリーします。当時のデータが残っていたもので。というか残っている中から傷のあるトラックを探したんですが。

  ・Pioneer製BDC-S02J (2007年製)  09年度リッピング
   (「リッピングエラーの正体」より)
  ・Pioneer製DVD-303S (1998年製?) 99年度リッピング
   (「リッピングエラーの正体」より)


■読んでみた

 ただし、それぞれ1回しかやってませんし(実際何度もやるとかなり異なる場合もある)、スピンアップを待つといった気を遣っていませんし(その方が実際のリッピングに近いでしょうから)、何か間違いもあるかも知れませんし、中古はどんな過去を持っているか不明ですし、傷トラックとしてはたかだか2サンプルだけですから、これで何か結論が出るってものではありません。
 「こういうこともあるんだね」といったひとつの情報として。

・傷トラック1
 あるCDのtrack01です。切り傷や打痕というより擦り傷ですかね。

わた子:トリミング

 注目の結果は…

  1位 SW-5582:相違0
  1位 SW-5583:相違0
  1位 iHES208-2:相違0
  4位 DVR-105:相違667

 これ以外はWAVコンペアでごっそり差違が出てしまいました。
 サンプル増減により途中で比較対象がズレて「連続相違」が発生している場合は相違数を見ても実体は把握できません(*)。
 そもそも聴感上あきらかなノイズが出るレベルに劣化していますので、相違数としでではなく主観的ノイズレベルとして順位付けすることにします(もちろんノイズレベルとデータ劣化レベルの相関は判りません)。

*:実際、以下ではBDC-S02J以外は「連続相違」発生を確認しています。が、最大表示の2000サンプルより後でズレが発生している場合は確認できません。S02Jはなんかそれクサイです。

  5位 BDC-S02J(09年度):相違3,807,674
      166secあたりに小さな「プツ」ノイズあり
  6位 DVD-303S(99年度):相違65,777
      43secに小さなノイズあり
  7位 PX-W8432T:相違11,963,326
      62~90secの背景に「パタパタパタ…」という音あり
  8位 iHOS104-2:相違3,341,314
      28secくらいで「ブチ」ノイズ 103secあたりで「ボツ」ノイズ
  9位 iHOS104-1:相違3,547,008
      28secくらいで「ブチ」ノイズ 109secあたりでちいさな音とび?
  10位 iHES208-1:相違4,698
      27secで「バチッ」ノイズ
  11位 FX48:相違15,876
      11secに「ガリガリ」ノイズ,181sec~小さなノイズあり
  12位 MP5240A:相違11,769,208
      20sec~90secあたりまで連続的な「ちっちっちっちっ」ノイズ
      102secに「ブチ」ノイズ

 以下はさらに悪化してもはやノイズとも言えないレベル。一応相違数も記しますがほとんど意味はないと思います。

  13位 BDR-S05J-H:相違1,052,381
      15~40sec断続的に音飛びして時間が短くなっており、
      その後正しい時間軸に戻る
  14位 BDR-S05J-M:相違323,136
      38secあたりでいわゆる“壊れたレコード”のようになる
  15位 DV-28S-Y:相違12,402,096
      リッピング中「チャチャチャ」と音を立ててた
      再生するとぐちゃぐちゃ

 以下は読めなかったドライブ。

  予選落ち GGC-H20N:途中まででリッピング停止
      iTunesタイムアウト? 短いファイルになった
  予選落ち PX-716A:マウントできず
  出場辞退 BDR-S05J-P:自分で停止してるので…

 この傷トラックではPanasonicのBDドライブが優秀な成績でした。中古のDVR-105も健闘しています。99年度と09年度のリッピングもいいですね。
 PureRead2はまるで振るいませんがな(爆)。

 特筆すべきはPX-W8432Tです。「パタパタ…」は正常データにはない音ですのでエラーが聴こえているとうことになりますが、伴奏に溶け込んだカンジなのでこれだけ聴いていたらエラーによるノイズとは気付かないでしょう。
 ノイズだかオリジナル音声だか区別付かないエラーもあり得る、ということです。

 ここで特別参戦SONY製BDプレーヤBDP-S470。S/PDIFを録音してみました。
 結果、途中無音になるなどぐちゃぐちゃ。AV機器としての面目躍如というワケにはいかなかったようです。

 なお、iHES208-1で複数回リップしたところ、パーフェクトになることもありました。結構バラつきあるようですね。

・傷トラック2
 傷にもいろいろあって、あるドライブで読めるけどあるドライブでは読めない、といった“優劣”は経験上ディスク(トラック)によって異なると感じています。しかし、定量的に確認してはいませんでした。確認するには、得手不得手が顕著に表れるような“特徴の異なった傷”を探し出す必要があると思ったためです。
 で、探し方を考えてみました。
 例えば、上記傷トラック1はPureReadが苦手な傷だったと推定されます。では、PureReadで効果のあったトラックは逆説的に「傷の多様性」としての対象として有意ではないかと。
 ということで、PureRead2評価記事で「PureReadでは補間発生したがPureRead2では完走したtrack09」を用いました(残念ながら99年度と09年度の当トラックデータは残っていません)。

 今度は切り傷っぽいでしょうか。

SKG:トリミング

 相違2000サンプル表示の確認では連続相違は発生していないようですが、今回もノイズレベル優先で順位付けすることにします。
 傷トラック1での順位を()に記してみました。303SとS02Jの分は繰り上げています。

  1位(8位) iHES208-1:相違0
  1位(圏外) BDR-S05J-P:相違0
  1位(12位) BDR-S05J-M:相違0
  4位(11位) BDR-S05J-H:相違17
  5位(4位) DVR-105:相違57
  6位(圏外) GGC-H20N:相違84
  7位(5位) PX-W8432T:相違275
  8位(1位) iHES208-2:相違444
  9位(圏外) PX-716A:相違3,426
  10位(1位) SW-5582:相違1,762
        70secに「ボツ」ノイズあり
  11位(10位) MP5240A:相違8,115
        106secあたりに小さな「チリチリ」ノイズあり
  12位(7位) iHOS104-1:相違42,654
        92secに小さな「チッ」ノイズあり
  13位(6位) iHOS104-2:相違39,958
        92secに小さな「チッ」ノイズあり
  14位(圏外) DV-28S-Y:相違331,614
        107secあたりに「プツプツ…」という音あり
  15位(1位) SW-5583:相違8,477
        153~163secに「ポツ」ノイズ2回 最後に「グシャ」ノイズ

  予選落ち(9位) FX48:開始直後にリタイア(笑)

 傷トラック1ではダメダメだったS05Jのマスターモードはエラーなし、標準モードも大健闘しています。
 かなりノイズが入ったiHES208-1も今回はパーフェクト達成。逆にiHES208-2は急降下。iHESはバラけましたが同じLITEONでもiHOS104は“安定してあんまりよくない”ですね(笑)。
 DVR-105は今回もそれなりにがんばってます。
 PX-W8432Tは名誉挽回ってカンジでしょうか。同じプレクのPX-716Aはなんとか踏みとどまったカンジ?
 逆にエラーなしだったSW-5582は振るわず。同じくパーフェクトだったSW-5583も今回はダメでなんと最下位に転落。ただ、track10と連続リップすると全く違う結果になるので、何か特殊事情がありそうです。
 TEACのスリムドライブは今回もよくないです。原則ノートPC用ですので小さく軽くすることが優先されるのでしょうから、やはりスリムドライブは不利なのかも知れません。

 ところで、当TEACリップでも傷トラック1のPX-W8432Tと同じような「演奏みたいな微妙なノイズ」が聴こえました。おそらくこれも“こんな実験”でもしなけれなデータエラーとは思わなかったでしょう。

・結果
 まず、ノイズレベルによる順位付けはあくまで独断と偏見によることをご了解ください。

 傷によるノイズ発生箇所やレベルは、ドライブ(ベンダ…もしかしてF/Wでも)によってずいぶん違うようです。傷の状態が違えば読み取り成績もまるで違っています。少なくともパーフェクト達成グループのメンツは入れ替わっていますし、一方ではマウントできなかったドライブが一方ではそれなりの成績になったりもしています。

 F/Wまで同じ2台のiHOS104はほぼ同じ結果になっていますが、F/Wが異なるiHES208はかなり異なる結果に。個体差なのかF/W差なのか微妙(笑)。

 現実的に“今現在”の状態として判断するなら、BDが悪いとも言えません。
 古いほどいいとも言えません(中古がダメとも言えません)。
 CD/CD-RWがステキとも思えません。
 AV機器なら安心とも言えません。
 PureReadがダメダメというワケでもありません。

 オススメのベンダは見つかりません。また別の状態の傷ではまるで違った結果になりそうです(注:個人の感想です)。

 「ドライブの傷ディスク読み性能は傷の状態によって異なる=得手不得手は激しい」ってことですね(注:見方には個人差があります)。

 今回、「演奏に紛れるようなノイズになるエラーもある」ことが判ってオッカナイです。こういうのを知ると、私としてはやっぱりエラー発生が明示的に判るリッピングしたいですね。


■考えたこと

 光学メディアはCDから始まり、そのライタブル、DVD、そのライタブル、BD(最初からライタブル)と発展してきています。
 ドライブ側はそれに合わせてコンパチ対応を進めてきています。

 しかしながら、CDとDVDとBDでは必要な光学特性が全く違います。レーザーの波長が異なるのは言うまでもありませんし、例えば記録面とのレーザー焦点距離、記録密度なども違います(*)。技術的には素人なのでこれ以上の言及は避けますが、理想的にはそれぞれに最適なレンズやピックアップ・アクチュエータ(サーボ)が望ましいとは言えるでしょう(ライタブルに関しての事情はヨクワカリマセンし影響は規格違いより小さいと思いますので割愛します)。
 が、実際には物理的にもコスト的にもコンパチ機にそれぞれの専用光学系を搭載することはできません。そこで、兼用光学系が開発され、搭載されることになります。

*:http://panasonic.co.jp/blu-ray/story01/

・レンズ事情
 CDしかなかった時代はすべてのドライブがCD専用光学系を搭載していました。アタリマエですが。
 DVDが登場した時、初期段階ではCD用とDVD用の「ダブルレンズ」方式でしたが、現在ではCD/DVD兼用「シングルレンズ」になっています。DVR-105やPX-716A、DV-28S-Yはシングルレンズです。
 さらにBDが登場し、そのコンパチ機では、再びCD/DVD用とBD用の「ダブルレンズ」(*)時代に突入しています。CDに関しては、DVDと兼用レンズという意味でDVD時代と事情は変わらないと思います。

*:http://pioneer.jp/dvdrrw/story/index_15.html

   ←レンズ部の写真はこっちの方が解りやすいかも。

・コンパチであるということ
 レンズが共用ということは、CDとDVDどちらにもオプティマイズされておらず、どちらもなんとかなる落としどころに調整されていると推測します。さらに言うと、どちらかというと優先順位はDVDの方が高くなっているのではないかと(さらに言うと、書き込み速度が最優先だったのでは…)。

 アクチュエータに関しても、DVDドライブではレンズがシングルかダブルかに関わらずCDとDVDは兼用になりますのでやっぱりDVD優先の設計になっているのではないかと。BDドライブではさらにBD用チューンが最優先になっているのでは。
 あくまで推測ですが。

・リッピング最強世代を考察する
 以上を是とすると、CDの読み取りにはCD専用の光学系がベストでしょうから、CDドライブが一番有利な可能性があります。が、あまりに初期のものだとまだ技術的にこなれていなかったり、そもそもCD-DAを読めなかったりする可能性もあります。リッピングという概念が出てくるより前の機種では、コマンドをちゃんと受け付けるかといった点で疑問符が付きます。といって技術がこなれてくると過剰品質の場所や程度が解ってきてしまい(笑)、それを削ってギリギリのコストで必要十分な性能を出す「コストダウン」が厳しくなっていきます。

 CD世代のベストは難しいですね。

 DVDドライブでは、初期の「CD/DVD専用ダブルレンズ」の方が「CD/DVD共用シングルレンズ」より好ましいと言えるかも知れません。

 BDドライブでは、機能性能出しの優先順位的に、CD読みに関してはDVDドライブよりさらに厳しくなっている可能性があります。一方で、逆に、BDでより細密なピックアップ制御を実現している分だけ結果的にCD読みも有利になっている可能性もあります。実際、本実験における2サンプル両方とも、エラーなしを達成しているのは実は“BD世代だけ”です(もちろんエントリー数が一番多いという要素もありますが)。

 と考えてみましたが、あくまでも非常にざっくりとしたイメージです。各ドライブには、前述の通り得手不得手があります。また、古いドライブには劣化の危険もあります。

 ということで、こと「基本的な光学性能がいい」ドライブとして何を買えばいいのか、についての明確な答えは難しそうですね。
 イマドキは外付けになる場合も多いでしょうけれど、スリムは避けて“お気に召した”5.25inchドライブをUSBで外付けした方が無難な気もします。



 ERIとしては、「基本的光学性能」ではなく「補間発生検出装置」という意味でもちろんPureReadは1台欲しいところですけれど。
 好意的に考えるなら、Pioneerにおける「PureRead」は、「コンパチ機においてCD読みの優先順位が下がっていく」という光学・メカ技術のトレンドに対するファームウェア技術でのリカバー、という位置づけなのかも知れません。


メインメニューへ

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

CDリッピングエラーの正体

13/05/02初稿

 いやぁ、奥深い。


■検証の経緯

 まず、いままでやってきたことをまとめてみます。

・第1段階:ドライブやリッパーが異なると読み出されたデータは異なるか
 リッピング条件とエラー記事において、補間やフレームズレがないなら音声データは同じバイナリになることを確かめました。当時はまだそういうことすら明確でない段階だったんですね。
 この実験で副次的に、「補間やフレームズレは頻繁に発生するものではない」ということも判っています。

・第2段階:リッピング条件が悪いと補間(エラー)はどのくらい発生しているか
 続いて同記事で、「ディスクに擬似的に発生させたダメージやリッピング中の振動印加で、読み出されるデータは変わってしまうか」を確認しています。
 その結果、多少の脂汚れくらいのダメージでは補間は発生せず、ましてやドライブの振動でも補間は発生せず、つまり普通のリッピングで補間(エラー)はほとんど発生しないだろうと考えています(第1段階での結果を裏付ける形になりました)。

 以上より、「イマドキのものならばドライブやリッパーは中途半端に拘ってもあまり意味がない」と結論しています。

 ただし、ディスクのダメージはあくまでもシミュレーションであることをはじめ、基本的には「健常なディスク」の検証となっています。ですので、(シミュレーションではなく)傷ついていたりプレス不良だったりするディスクで、実際に「どのくらい補間が発生しているのか」や「フレームズレは本当に発生しているのか」といったことは判っていませんでした。

 その後、いい塩梅に傷がついたトラックや、なぜだか読みにくいディスク…プレスが良くない(?)ディスクを発見しましたので、本稿では、そのようなディスクのリッピングにおいて何か起こっているのかを確認してみます。


■第3段階:ダメージディスクのリッピングでは何か起こっているか

 ERIでは、前世紀(笑)からリッピングをやっています。そのため、過去2世代のシステムでリッピングしたデータがいくつか残っており、その中にダメージディスクが数タイトルあります。物理的に同じCDです。
 ですので、このディスクなら、現在のシステムも加えて3世代での結果を比較できます。
 昔のドライブ(中古ではない当時の状態の結果)はよかったのでしょうか…?

 エントリーは以下の通りです。

  ・99年当時:DVD-303S+CD2WAV(詳細は上記第1段階記事参照)
  ・09年当時:BDC-S02J+iTunes9 x86(推定。OSはXP HomeEdition x86)
  ・現在:BDR-S05J+iTunes11.0.2.25 x64(エラー訂正なし)
  ・現在:iHES208+iTunes11.0.2.25 x64(エラー訂正なし)

 現在のOSはWindows7 HomePremium SP1 x64です。

・事例1(傷ディスクA)
 ある打痕傷ありCDで、S05JのPureRead2パーフェクトモードだと途中停止してしまう(補間が発生する)track07の場合、いくつかの世代における補間(結果ハズレ)発生数は以下の通りになりました。WaveCompare1.32にて。

  ・303S・・・7563893~8147197サンプル間に相違187(不連続)
  ・S02J・・・7268346~8548429サンプル間に相違1366(不連続)
  ・S05Jマスターモード・・・7207360めから連続相違発生(*)
  ・S05Jパーフェクトモード・・・途中停止
  ・iHES・・・エラーなしデータと一致

*:サンプル増減が発生してズレた後を比較?

 総サンプル数は約1600万なので真ん中へんです。

 確かに読み取り性能はドライブによって異なるようですね。同じPioneerでも古い方がいい結果になってるようにも見えます。古い方がディスクの状態がよかった可能性もありますので何とも言えませんが、303SからS02Jまでの10年間にCDをケースから出した記憶はありません(確証はありませんが、リップして聴いてワケですから)。
 マスターモードがiHESに負けてるのはいかがなものか(苦笑)。ただ、マスターモードはどうもアヤシイ場合がある(標準モードより酷くなるなど)ので調べたところトンデモナイ事実が。詳細は後述です。

 ちなみに、エラーなしデータをどうやって得たのかというと、もう一枚CDを買おうかと思ながら各リッピング後、盤面をなめすように拭いてパーフェクトモードでリップしたら停止しなくなったのです。それがiHES208と一致していますのでエラーなしで間違いないでしょう。
 リッピング前のディスクのメンテは重要ってことで(苦笑)。

・事例2(傷ディスクA)
 同ディスクのtrack01では以下のような現象が発生していました。

  ・303S・・・ある部分で連続25サンプル欠損
  ・S02J・・・パーフェクトモード完走データと一致

25サンプル欠損

 303Sでは、エラーなしデータの2630537めのサンプルが2630512めになっています。25サンプル少ないワケです。25サンプルってフレームズレでもないですよね…欠損した後は一致しているようですが…
 古いドライブの方がいいとも言えない? リッパー要因???

・事例3(傷ディスクB)
 外周部にそんなに派手じゃない傷があるディスクのtrack10にて。

  ・303S・・・7855657めから連続不一致。25サンプル多い???
        総サンプル数は同じ
  ・S02J・・・パーフェクトモード完走データと一致

 WAVコンペアだけだと何が起こっているか解りませんので、バイナリを見てみます。

25サンプルダブリS05Jバイナリ

25サンプルダブリ303Sバイナリ

 上がパーフェクトモードで正確に読んだハズの当該部分、下が303Sの「25サンプル多い」部分です。
 色つけした部分は合計200Byte=50サンプル分ありますが、同じ25サンプルが2回繰り返されています。ダブリでリップしてデータ化しちゃったってことですね(総サンプル数は同じなのでどこかで25サンプル減ってるってことに)。
 ドライブ性能に依るものなのかリッパーに依るものなのかは不明ですが、track10はちょうど傷のあたりっぽいですので、99年当時のシステムではそれによってエラーしたのでしょうか。

 ダメージディスクのリッピングでは、サンプルは読み損なって減るだけでなく“増える”こともあるようです。


■ダメージディスクと向き合う

・音質は劣化しているか
 補間(結果ハズレ)発生は、データ上は音質劣化であることは間違いありません。しかし、それが実際に聴き取れるか否かは別問題です。
 CIRCによる補間は“できるだけ元の値に戻そう”として値を類推しているのであり、サンプル欠損ではありません。
 残念ながら類推結果がハズレだった場合は、サンプル値が本当の値とは若干異なることになりますが、正しい値との差分は大半は±10、大きくて±数百くらいです。
 連続して発生することも原則ありません。上記のように数千個の補間が発生したとしても、例えば4410個発生しても“のべ”0.1sec分です。普通は、これが数秒間に分散して発生するのですから、それを「ヴェールがかかったよう」などの音質劣化として認識することはできないハズです。

(1)事例1では
 約360secの楽曲の真ん中あたりの約30secの中で補間が発生しています。
 99年度リップ303Sでは187個で、その実際は以下の通りです(187個のうち最後のところ)。

303Sエラー

 これを音質劣化として聴きとれると思われるでしょうか?

 一方、09年度S02Jでは1366サンプルの補間が発生しています。
 この30sec間の傷んだサンプル比率は前者0.01%、後者は0.11%です。曲全体の音質劣化には聴こえないのは当然として、この30秒間の“痛みの差0.1%分”を、「S02Jの方が音質が悪い」と認識できるでしょうか。私はできませんでした。

 なお、ダメージにもいろいろなレベルがありますし、ドライブによっても得られるデータは異なります。
 上記は本稿の事例1のレベルを想定して記しており、もっと酷いダメージでは極端な補間ハズレや連続差違発生、大量のサンプル欠損(増減)があり得ます。が、そうなった場合は“音質劣化”ではなく「ガリ」「ブツ」といったあきらかなノイズや音飛びにまでなる可能性が高いでしょう。

(2)事例2,3では
 サンプルが連続で25個増えたり(ダブったり)減ったりしても、特殊な値でない限りは認識できないでしょう。

 念のためですが、本稿は「ダメージディスクのリッピングで何が起きているか」を見ているのであり、通常では発生しない状態に関する考察です。

・どうすればいいのか
 前述の通り、打痕傷のあるトラックや全面的に読みにくいディスクにおいては数分の曲の中で数千サンプルに補間が発生することがあり、実際ドライブによってその数は異なります。
 つまり、「健常ではないCD」においてどこまで補間発生を食い止められるかは、ドライブの「基本的光学性能」に依存することになります。

 事実上音質差としては判らないとしても数千個の補間発生は流石にキモチワルイですね。そういう意味ではいわゆる「定番ドライブ」は「そのへんのドライブ」より補間発生が少ない“可能性は高い”でしょうから“安心感は高く”なるとは言えましょう。
 が、定番ドライブでも絶対にエラーが発生しないワケではないので、パーフェクトに安心できるワケではありません。“安心感のレベルが異なるだけ”、ということです。

 もし、使いたいソフトとドライブの組み合わせのリッピング精度が心配なら、上記第1段階記事と同じ手法(身元が確かなWAVファイルと一致するリップできるか)で確認してから常用すればよろしいかと思います。ただ、「フレームズレ」問題はまだ若干アヤシイかも知れませんが。

・本当の問題は何か
 しかし、本当の問題は「ドライブによる安心感向上」では解決できないと考えています。

 補間ハズレなどのエラー発生によるデータ劣化の程度は、最小は「1サンプルの片チャンネルが±1違っただけ」と規定できるでしょう。
 しかし、最大の規定はできません。上述の通り少しのエラーではそれを聴き取ることはできませんが、ダメージが酷くなってくるとサンプル欠損や補間大ハズレがどんどん増えていき、あきらかな音質劣化やノイズが発生するようになります。敢えて言うと最後はマウント不可になるのでそれが最大かも知れませんが、もう音の問題ではないのでそうは考えません。
 そして、普通のリッピングでは「エラーゼロ~マウント不可直前」という範囲がある“劣化の程度”を知ることはできません。

 「ブツ」「チッ」といったノイズにならない限りエラーでデータ劣化したことは判りません。さらに言えば「何か聴こえた」としてもそれがエラーによるノイズなのかオリジナル音声なのか判断する術がありません。
 つまり、「エラーが発生していても気づかず対策できない」ことこそリッピング問題の本質と考えています。


 ではどうすればよいのでしょうか。

・対策:事実上判ってしまう(ノイズが入る・音が飛ぶ)場合
 これは逆にラッキーなケースと言えるかも知れません。エラーがあることが判ったのですから、以下のような対策がとれますので。

 ・CDをリペアする
 ・リッピング性能が“よさげ”なドライブを追加購入する
  (追加したドライブの方がよく読める保証はないが)
 ・セキュアリッパーを試してみる(効果があるとは限らないが)
 ・手持ちのCDプレーヤでちゃんと再生できたら、そのS/PDIFを録音する
 ・CDを買い直す またはリッピングを諦め配信で入手する

・対策:とにかく補間が発生してたらヤダという場合
 絶対に補間が発生しないソリューションは存在しませんから、これは「補間発生したかどうかを知りたい」という意味になるでしょう。つまり、補間発生を認識できるシステムが必要です。
 そのシステムとしては、リッパーのエラー訂正とは何かに書いた理由で、セキュアリッパーよりもPureReadが確実ではないかと思っています。
 「PlexTools Professional」と組み合わせたPlextorドライブなら補間発生を認識できたようですが、今となっては(新たに導入するには)現実的ではないでしょう。
 EACなどのセキュアリッパーを十分理解して慎重に運用すれば認識できるかも知れませんが、DBに当該CDのデータがあるかないかなどにも左右されるハズなので、安定的とは言えないと思いますし。

・余談:PureReadドライブの基礎体力
 イマドキのドライブの場合、健常なディスクではほぼ差は出ないと思いますが、ダメージディスクの読み取り耐性においては実際差(得手不得手)があるようです。しかしながら、光学的読み取り性能の基礎体力をウリにしたドライブは現在は売られていません。中古ではレーザーやメカの劣化などが心配です。

 PureReadは例えて言うなら「基礎体力というより運動神経でカバー」しようってところが違いますが、「現在唯一の“リッピング性能をウリにした”ドライブ」であるとは言えるでしょう。
 ただし、そのメリットは基礎的光学性能が良いことではありません(悪いという意味でもありません。実際の性能がどうかは別問題という意味です)。「補間」が発生する可能性は健常なCDでもゼロではありませんから、「補間」の発生を「補間しないこと」で確認できる「パーフェクトモード」最高、ということです(笑)。

 経験上、どうもPureReadドライブの基礎体力的性能は“ビミョ~”な気がしますが、PureReadを作動させてナンボですから。
 健常なCDじゃない場合…例えばプレスが悪くて補間が発生しまくるような場合も、それが起こっていることが認識できなければ何もできないワケで。
 上記の事例1は、パーフェクトモードで停止することで補間発生を認識し、簡易リペアもどきをやることで補間なしリッピングに成功した例と言えます。普通だったら補間発生したデータをそのまま受け入れているところでしょう。ていうか実際303SやS02Jでのデータは受け入れてたワケです。
 …「その方がシアワセ」という考え方もあるかも知れませんが。

 どんなに優秀なドライブでも補間発生はあり得るワケですから、もし読み取り性能がサイコーじゃないとしても、補間発生を確実に告げてくれるっていうのは「補って余りある美点」だと思います。

 PureReadのパーフェクトモードを用いる主目的はERI的には補間発生を知るためではありますが、補間発生を抑える効果もそれなりにあるだろうと思っています。
 実績として、中古CD約60枚のリッピング(iTunesでの)において途中停止なし、低速リッピングになったことなし、です。すべて国内盤ですが。
 新品の“輸入盤(25枚組クラシック)”では1枚だけ減速しました(停止はせず)。
 中古ではありませんが、リッピングなんてなかったころにCDプレーヤで結構聴き込んで傷付けちゃったディスクでは「補間で停止」は発生しています。


■ディスクへのダメージ以外のエラー要因

 健常なディスクでも不正確なリッピングしてしまうことがあります。

・リッパーソフトの設定ミス
 EACのドライブ相性などはその例かも知れません。
 また、303S+CD2WAVにおいて「曲中の、両チャンネルとも値がゼロの1サンプルが欠損している」というリップ結果がありました。たまたまレベルがゼロになっただけで有意なサンプルのハズですが、当時の「CD2WAV32 R3.00 beta1」の設定を見ると「無音エリアをスキップする」という項目があるので、これをチェックしていたため削除された可能性があります。
 というようなカンジで、高機能なリッパーほど下手に使うと逆にハマることがありそうです。

・ドライブのファームバグ
 PureReadだと起こりやすいのかも知れませんがPureReadだけの問題でもないでしょう。
 上記の傷ディスクAでBDR-S05Jのマスターモードがおかしかったので、傷ありと傷なしの2枚持っているリッパー実験に使ったディスクで試してみたところ、マスターモードはやっぱり連続相違となります。WaveCompareの結果をテキストエディタにコピーして検索で一致点を調べてみると、588サンプル分ダブリになっている模様。
 リッパー変えても似たような結果になるので、なんだかファームウェアバグくさいと思って更新履歴(*)をみたところ、1.10に「PureReadの不具合修正」ってのがあるじゃないですか! ライティングサポート更新だけだろうと購入時の1.08のままにしていたので、最新の1.12にUpdateしたら「マスターモードで5サンプルの相違、標準モードで12サンプルの相違」となりました。マトモな動作になったぽいです。

 あぶないあぶない。

*:http://pioneer.jp/device/dev00001r.html


■エラーしてないのにコンペア一致しないこともある原因

 本稿で記しているのはあくまでもエラーしている場合ですから、ファイルコンペアで一致しないのはアタリマエです。
 が、エラーしていないのにファイルコンペアで一致せず、さらにWAVコンペアでも一致しない場合もあります。

・ドライブを変えるとコンペア一致しない場合
 これは、ドライブのオフセット値違いに依るであろうと推察しています。

・リッパーを変えると全面的に違うデータになる場合
 これは、「エンファシスCD」対応の違いである可能性があります。


■WAVコンペア注意

 以下を鑑みると、リッピング結果をチェックする際に相違数だけを見ると判断を誤る可能性がありますので、注意が必要です。

・サンプル増減エラー後の比較
 WaveComapreなどでは1サンプル分でも増減があるとその後はズレた対象が比較されますので、最後まで異なるサンプルとしてカウントされちゃいます。
 1サンプル無いためにズレた場合もその後は全部相違になってしまいます。その発生個所が曲の前の方だと曲サンプルの大半が相違になりますが、後ろの方だと少なくなります。例えばそれをもってドライブの性能差と判断することはできないでしょう。
 差違の実際を確認し、連続発生している場合はズレの可能性もよく確認した方がいいと思います。
 ただし、サンプル増減によるズレなのか、本当に値が異なっているのかの判断は簡単ではありません。

・曲間ギャップ部のエラー
 例えば、総サンプル数と近しいサンプル番号において連続して差違が発生していても、そこはプリギャップ部かも知れませんので、それなら楽曲本体には影響ないハズです。

・相違数
 相違数はサンプル数です。ステレオなので音声データは1サンプル中2個含まれますが、どちらかが異なっていれば相違とカウントされるようです。

・補間結果アタリ
 補間した結果は“アタリ”の場合もあります。それは「補間発生」ではありますが「WAVコンペア相違」にはなりません。
 解りにくくなるのでERIでは補間アタリを無視しています(特記なきは補間発生=類推結果ハズレとして記述)が、実際にはそういう事情があります。


メインメニューへ

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

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.ファイルサイズはすべて同じでした。


メインメニューへ

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

音楽CDの「エラー訂正」を再確認する

11/01/13初稿

 PC-Audioするには、まずは「ビットパーフェクト」なリッピングしたいものです。少なくともパーフェクトに行う方法をひとつは持っていて、パーフェクトだったのか否か認識できるようにはしたいですよね。
 そのためには、まず「そもそもCDのRippingにおける読み取りエラーってナンなのか」について整理しておく必要があるでしょう。
 でも、よく解らないんですよね。新旧の情報が錯綜してて…


■そもそもCD-DA(音楽CD)のエラーとは何か

・訂正と補間と補完と補正と
 まず、用語の意味と用法を整理しておきましょう。

 ・エラー訂正=エラーを認識して正しい値に修正すること。
 ・エラー補間=訂正しきれなかった時に「たぶんこんなカンジ」と“補う”こと。
          正しい値に戻らないことを覚悟した方がいい。

という「訂正」と「補間」がごっちゃになってるように思います。辞書引いてみると、

 ・訂正
    言葉や文章の誤っている部分を正しく直すこと
 ・補間(法)
    ある変域内で、いくつかの変数値に対する関数値が知られているとき、
    同じ変域内の他の変数値に対する関数値を推定し、近似値を求める方法
 ・補正
    足りないところを補い、あやまりを正すこと(補って正すこと。字義の通り)
 ・補完
    補って完全なものにすること(字義の通り)

ということで、明確な違いがありますので誤用しないよう気を付けたいですね。
 CDの規格としては、「訂正」と「補間」が正しいようです。「補正」「補完」などは意識して使用を避けたいでところです。

・それは「CIRC」という規格
 CD-DAの「エラー訂正」動作は「CIRC(Cross Interleave ReadSolomon Code)」という規格に定められています。
 リッピングに関するCIRCのポイントを2点記します。

・ポイントその1
 CIRCに基づく読み出しはドライブ内のコントローラチップが処理しています。
 PC側ソフトでやってるワケではありません。

 「ドライブ内のコントローラが担っている」ということについては、元DVDドライブ開発者に確認しましたし、SONY製CXR3005R(古い)といったCDドライブコントローラICのdatasheetなど見ても解ると思います。
 まあ、元々PCじゃなくてAudio機器たる「CD Player」のために作った規格ですから当たり前ではありますが。

・ポイントその2
 CIRCでは、パリティを付けたり分散したりしてデータを記録しています。
 “冗長度なくリニアに記録された無加工PCMデータ”に対してエラー訂正をやってるワケではありません。

 CDプレーヤやPCドライブは「CIRC規格に準じて」記録されたデジタルデータに対して「規格に準じたエラー訂正」を行いながら読み出しているのです。記録時点から考慮されているという点において、リッピングソフトでの“いわゆるエラー訂正”とは決定的に違うということです。

・エラーの種類と問題になるエラー
 さて、それではそのエラー(CIRCの動作)について見ていきましょう。訂正と補間の違いは何でしょう?

 そもそも、CD-DAで発生するエラーの訂正には2段階あります。

・C1段階
 盤面からの読み出しにおいて、エラーは必ず発生するものとしてCIRCは想定されており、もともと付加されているパリティ情報によって「訂正」されます。
焼いたCD-RよりプレスCDの方がエラー発生は酷いという話もありますね。
 C1段階(Correction第1段階)で訂正できなかったエラーをC1エラーと呼ぶのが普通みたいです。

・C2段階
 エラーはさらにより多くの情報から「訂正」が試みられます。

 C2段階(Correction第2段階)でも訂正できなかったエラーをC2エラーと呼ぶのが普通みたいです。

 そして、

 「訂正」できなかったエラー=C2エラーは周辺データから類推「補間」されます。

 C2エラーが発生して初めて「補間」が行われるワケですね。

 Ripping中、エラーは発生するものなのです。「音楽CD(CIRC)という規格にとってエラー発生は折り込み済み」なのです(安価なプレスメディアを使えるようにするためです)。
 ですので、Ripping品質においては「“訂正”発生」は問題ではなく、「“補間”発生」こそ問題なのです。
 盤面からの読み出しエラーとC1エラーはいくら発生しても構いませんが(極論ですが)、C2エラーの補間はハズレを覚悟する必要があり、つまり“リッピング時のデータ劣化”となりますので。

・リッパーは何をしているのか
 「補間によるハズレの可能性」はどうしようもないハズなのですが、「リッパーにおけるエラー訂正」は、それをどうにかしようとしているように見えます。
 といってもCIRCは原則としてドライブハードの処理であり、かつCIRCを外部から制御する概念は原則ありません。ので、できるかぎりエラーなくRippinngするために“ソフト側にできること”はかなり限られているハズです。何をしているのでしょう?

 ざっくり言うと、「ドライブ内での補間発生を検出し、検出したら補間が発生しないまで“読み直し”する」ものです。あくまでも読み直すだけです。独自の信号処理的エラー訂正などは行っていません。
 詳細はリッパーのエラー訂正記事で考察してみましたのでよろしければどうぞ。
 なお、PioneerのPureReadはPC側ソフト処理ではありません。といってCIRC規格以外のことをやっているワケではありません。ドライブのファームウェアがピックアップや光源制御なども行うリトライリードするものです。

・「脆弱」なんて言うな
 ところで、「CD-DAのエラー訂正機能は脆弱なので~」といった記述などを見かけることがありますが、違和感あるんですよね。
 「脆弱」という理解の元を辿ると、音楽CD(CD-DA)の後に策定されたCD-ROMフォーマットのエラー訂正性能がCD-DAよりも高いことから、逆にCD-DAは性能が低い=「脆弱」という認識に変化していったのではないかと思われます。

 CD-ROMとCD-DAでエラー訂正性能が異なるのは当たり前です。CD-ROMでは1bitたりともミスは許されませんが(CD-ROMから営業Excelファイルを読み込む時に売価がひと桁違ったりしたら大変でしょ?)、CD-DAはストリーミングデータ再生の中でちょっとくらいエラーしても実害はないのですから。
 エラー訂正能力も異なりますが、それでもエラーが残った場合の扱いが異なる点もポイントです。CD-DA(音楽CD)ではエラーを類推補間して済ませますが、CD-ROM(データCD)ではエラーはエラーとして扱います(フツウは読み出し停止)。

 といっても、CIRCのエラー訂正能力も音楽CDを読み出すには必要十分に強力なので、「脆弱」というのは不正確(というか規格策定に携わった技術者に失礼)だと思っています。
 実際、よほど酷いディスクじゃない限り補間発生しませんから、傷ついてもいないのにエラー多発する場合は「偏心」「プレス不良」「材料や工程自体が粗悪」といった“規格外の不良品”である可能性が高いのでは。エラーがあるCD-ROMは不良品として扱われますが、CD-DAは本来CDプレーヤで再生するものでエラーがあっても再生可能にしてあるため、そういうディスクも流通してしまっているのでしょう。
 そういうディスクでエラー発生するからと言ってCIRCが脆弱と言うのは、リッピングありきで考えている故、1980年代初頭の技術であることを忘れた故の間違いです。CD-DA規格策定当時Rippingの精度なんて考慮していませんし、高度な信号処理できる安価なシリコンチップなんてなかったのですから。


 なお、あまりweb上に情報のないCDのフレーム(CD-ROMだとブロック)構造ですが、以下リンク、オレンジブックの規格推進団体フォーラムの「CDファミリーの系譜(*)」が参考になると思います。

*:http://www.cds21solutions.org/osj/j/family/index.html

 CD-ROMにはCD-DAにはない「EDC/ECC」が追加されており、
   ・EDC・・・Error Detection Code
   ・ECC・・・Error Correction Code
このふたつの合体技で強力なエラー訂正を行っているそうです。
 もちろんCD-DAの読み取りではEDC/ECCは無関係です。だってそのためのデータが入ってないんですから(笑)。


■参考リンク:藤本健のDigital Audio Labolatory

・第1回:迷信だらけのデジタルオーディオ 【CDにまつわる噂を徹底的に解体!】
 ~ 第1回 そもそもオーディオCDって何だ? ~
 http://av.watch.impress.co.jp/docs/20010312/dal01.htm

・第2回:迷信だらけのデジタルオーディオ
 ~ 音楽CDリッピングが100%正確でない理由 ~
 http://av.watch.impress.co.jp/docs/20010319/dal02.htm

・第4回:迷信だらけのデジタルオーディオ
 ~ CDプレーヤーの読み込みの仕組み ~
 http://av.watch.impress.co.jp/docs/20010402/dal04.htm




 さて、基本的には以上でよいと思っていますが、C1やC2の意味に関する混乱もあるようですので、以下、それについてERIなりに考察しておこうと思います。


■エラーの定義が2種類になったのは何故か

 実はC1エラーとかC2エラーとかCUエラーって「俗称」みたいです。明確な定義がないためにその理解には2種類あるようですね。
 本稿上記の定義より1段階前にズラして、

 ・C1エラー・・・C1段階に入力されるエラー
 ・C2エラー・・・C2段階に入力されるエラー
 ・CUエラー・・・C2段階から出力される(つまり最後まで訂正できなかった)エラー

とする説明も見かけますが、どうも少数派のようです。
 便宜的に、訂正不可能なエラーの名称を象徴として、こちらを「CU説」、本稿前半で説明したものを「C2説」と呼称することにします。
 「エラー」をC1やC2のInputと見るかOutputと見るか、というのが原則的違いでしょうか。

 上述の通りC1やC2のCは“Correction(訂正)”のイニシャルと推定していますので、C1エラーとは「Correction1 Error(訂正第一段階におけるエラー)」という意味に取るのが一番スッキリしていると思っています。
 ですが、そのC2説ではC1段階にInputされるエラーの名称は“ない”ことになります。それもキモチワルイから(?)でしょうか、さらに「C1エラー=C1段階へのInput、C2エラー=C2段階からのOutput」という理解も存在するようですね。今度はC1段階のOutput=C2段階へのInputの名称がなくなっちゃいますが(苦笑)。
 全体を一段前にズラしてC1段階へのInputの名称は得たものの、逆にC2段階からのOutputの名称がなくなってしまうので「CUエラー」という名称を追加したのがCU説、ということすね。
 しかし、「Correction処理して初めてエラーしてることが判る」のではないかと思いますので、「C1段階へのInput=盤面から読み取った時点のデータにはエラーの概念はない」でいいのではないかと。

 ということで、C2説でいいと思っていますが、どうしてCU説ができたのでしょう。C2説でいいのかの確認のためにも、ひとつERI的仮説を考えてみたいと思います。
 キーワードは「セキュアリッパー」として知られる(?)Plextor製「PlexTools Professional」じゃないかと推察しています。

 PlexToolsのヘルプなどにはC1エラー/C2エラー/CUエラーの説明が複数あります。ので、それらをチェックしてみます。
 念のためですが、あくまでも「音楽CDの読み取りにおけるエラー名称の説明」としてどうかをみていきます。データCDの説明としてではありません。

・Rippinng機能「DAE」ヘルプの記述
 まず、同ソフトのリッピング機能のヘルプを見てみます。

DAEヘルプ

 「C2 Error Flag」に関する記述から推察される「C2エラー」の意味からして、C2説と思います。「C2段階でエラーしたのがC2エラー=不良セクタは訂正できない」と読めますので。「CUエラー」という用語も出てきていませんし。

  判定:DAEヘルプはC2説

・Q-Check機能マニュアルの記述
 次に、Q-Check機能につき、以下URLのマニュアルP.79~にある「C1/C2/CU」に関する記述を見てみましょう。
http://plextor.jp/pc/download/software/plextool_doc.pdf
 以下抜粋。
Q-Check01.gif
Q-Check02.gif
Q-Check03.gif

 なお、Q-Check画面表示は以下の通り「C1」「C2」「CU」であって「C1 Error」といった記述にはなっていません。

C1C2CU.gif

 「Q-Check機能で用いられる“C1”という単語」と「“C1エラー”という単語」は同義ではない、という点にまず注意が必要でしょう。データCDの場合について言及していることからも、「C1エラー/C2エラー」ではなく、「当ソフトのC1/C2 Testの結果」を示しているような気がします。そもそも、Q-Check機能は「ディスク品質」チェックを目的としているため、訂正成功失敗に関わらず“エラー発生数”自体に注目しているとお見受けしますので。

 さて、それはそうと、同じマニュアルなのに前半と後半で「C2」の意味の説明が矛盾するんですけど…
 前半には「Q-Check C1/C2 Testではそれらのエラー訂正を行った合計を表示し」とありますので、

 ・C1・・・C1でエラー訂正を行った合計を表示
 ・C2・・・C2でエラー訂正を行った合計を表示

ととれますけど、後半は

 ・C1・・・BLER=E11+E21+E31
     つまりC1でエラー訂正を行った数(訂正成功も失敗も合計)
 ・C2・・・E22
     C2でエラー訂正を行ったうち成功したものの“一部”
     だってE12がありませんから…
     エラー訂正を行った合計とすると、E32もないし
 ・CU・・・E32
     C2で訂正できなかったもの

 どっちでしょ? Q-Check機能の意図からすると、それぞれの訂正段階へのInput数を示すという前半の方が納得力ありますが… だんだんこんがらかって来ました(苦笑)。
 ただ、本稿の目的からするとここの詳細を考えてもあまり意味はありません。「C2」として記されていますので、「CIRCにおけるC2エラーのことではなくQ-Check機能としてのC2」の説明と理解し、ここでは無視することにします。

 後半の説明でそのまんま「C2でもエラー訂正できない場合はCUエラーとなってしまいます」と記されているので、

  判定:Q-Checkマニュアルの記述はCU説

でよろしいかと思います。

・Q-Check機能ヘルプの記述
 「C1/C2/CU」の意味として次のように解説されています。マニュアルからの抜粋版みたいですね。
Q-Check.gif

 しかし、抜粋版ゆえに「C1エラー」「C2エラー」「CUエラー」といった用語が唐突に使われており、「C1/C2/CU」との関係がちょっと紛らわしくなっています。
 いずれにしても、マニュアルと同じく

  判定:Q-Check機能ヘルプはCU説

でいいでしょう。こちらにオリジナリティはないと思われます。

・PlexToolsサイトのFAQの記述
 「C1/C2/CUエラー」について次のように解説されています。

C1/C2/CUエラーとは?
CDのエラー訂正は2段階で行なわれ、第1段階(C1デコーダ)で訂正された、または訂正できなかったフレーム数がC1エラーとして報告されます。(ほとんどのランダムエラーは、この時点で訂正されます)
このC1デコーダで訂正ができなかった場合、第2段階であるC2デコーダで訂正され、その訂正されたフレーム数がC2エラーとして報告されます。このC2デコーダでも訂正できなかった場合にはCU(Uncorrectable Error)となります。

出典:http://plextor.jp/pc/support/faq_soft_ptp.html

 箇条書きにすると

 ・C1エラー・・・C1デコーダで訂正されたフレーム数
      または できなかったフレーム数
 ・C2エラー・・・C2デコーダで訂正されたフレーム数
 ・CUエラー・・・最後まで訂正できなかった分(おそらくフレーム数)

として報告される(表示される)ということですね?

 つまりC1エラー数は「C1デコーダで処理した数」なのでC1デコーダに入力されたエラー数ってことですね。C1“デコードエラー”ではない、と(“または”の意味がちょっとアヤシイですけれど、“どちらか”という意味には取れないのでは)。
 一方、C2エラーの方はなんと「C2デコーダで訂正された数」であって「C2デコーダで訂正できなかった=“エラー”の数」とは真逆の値ってことですね。

 う~む… こうなるとワケ判りませんね(*)。だってC2エラーの意味を明確に「C2で訂正された数」と言ってるワケですから、C2で処理した(入力された)総数でもないしC2でエラーした数でもないってことですよね。
 書き換えると

 ・C1エラー・・・C1デコーダに入力されたエラー数
     =盤面からの読み出し品質を表す?
 ・C2エラー・・・C2デコーダで訂正されたエラー数
     =訂正できた数でエラー程度を表す?
 ・CUエラー・・・最終的なディスク品質を表す?

 Q-Checkマニュアルに「C2=E22(2バイトのC2エラーを訂正した合計/秒)」という“似た記述”がありますが、上述の通りそれは「C2」についてであって「C2エラー」の意味説明ではないと思います。よって、当FAQの記述はCU説とも区別しておきたいです。
 CX説とでも呼びましょうか(苦笑)。

*:繰り返しますが、あくまでも「音楽CD読み取りエラー名称の説明」の観点で、です。もし、データCDに特化した説明だとするならそのように区別すべきで、音楽CDの説明と混同してはマズイでしょう。

  判定:FAQはCX説(新説)

・ああ勘違い?
 以上を見てみますと、次のPlexTools関連情報にある用語説明は基本的に同等であることが解ります(「Ripping機能DAEのヘルプ」はC2説なので異なる)。

 1.Q-Check機能のマニュアルおよびヘルプ画面による「C1/C2/CU」
    ・・・ソフト画面の用語と推定される

 2.webFAQによる「C1エラー/C2エラー/CUエラー」
    ・・・“エラー”が付いてるのでCIRCエラーの意味と取れる

 つまり、ここで当のPlextorさん自身が勘違いしちゃってるのではないでしょうか。
 「Q-Check機能マニュアル」を抜粋した「ヘルプ」の紛らわしい記述に自分で翻弄され、1.にあるQ-Check画面表示の「C1/C2/CU(CIRCではなくQ-Checkとして)の意味」の記述を、「C1エラー/C2エラー/CUエラー(CIRCとして)の意味」として2.に転用しちゃった(混用しちゃった)ように見えます。
 CX説はこのように誕生したのではないかと推察します。
 なので、CX説は気にしないでいいでしょう。


■C2説かCU説か

 本項17/01/21改訂:主旨説明を見直しました(コメントありがとうございました)。

・CU説誕生
 上記考察を踏まえた上で、Plextor技術者の見解を引用させていただきます。

藤本:ということは、音がいいという評判のプレクスターさんも、これまで書き込みという点においては、音に対して特別な基準とか規定を作っていたわけではないんですね?

浅野:社内の製造における段階では、ジッターとかオーディオキャプチャについては非常に厳しい規定を設けてきました。他社がどうしているかはわかりませんが、オレンジブックの基準内に入るというだけでなく、それ超える厳しいものとなっています。それが結果として音がいいということになったんじゃないかなと思っています。

藤本:とはいえ、各社さんともエラーが起こらないドライブを作るというのは大前提になっていますよね。では、最初にもおしゃっていたように、データは変わらないのに音が変わってしまうとういのはなぜなんでしょう?

浅野:C1エラー、C2エラーというけど、CDにおいてはエラーは出て当たり前です。いずれの場合もC1エラー訂正、C2エラー訂正が行われてデータ的には正しいものになるのです。もしC2エラー訂正でだめだったら、はじめてCUという形でデータエラーとなります。

植松:まあ、C1ですべて訂正できるべきだというのが、一般的な考え方になっています。でもC2エラーが出たらいけないかというと決してそうではない。C2ポインタで修正できれば基本的にOKであり、データ上問題はないんです。

出典:http://av.watch.impress.co.jp/docs/20010611/dal14.htm

 明確には言い切れませんが、「もしC2エラー訂正でだめだったら、はじめてCUという形でデータエラー」と仰っているので、Plextorの見解はCU説と言っていいでしょう。

 以上より、PlexToolsのQ-Check機能のマニュアル(ヘルプ)がCU説の出所ではないかと思われます。

・CU説の信憑性
 本項17/01/21追記。

 「Rippingにおけるエラーの意味として本当にC2説でいいか」の再確認のため、CU説の信憑性を改めて考えてみます。
 状況を列記します。

・世の中のCU説はどうもPlexToolsの「Q-Check機能のマニュアル(ヘルプ)」から発生したような気がします。

・実際、Plextorの設計者さんは「音楽CDの読み出し時における説明」としてCU説に立っているようです(「オレンジブック」とか「音がいい」という文言がありますので)。

・が、同ソフトの中でも「DAE機能のヘルプ」はC2説です。本稿の主旨「音楽CDのエラーの説明として」CU説の信憑性はどうか考えると、ひとつのソフトの説明の中にC2説もあることがポイントになります。

・また、「Q-Check機能のマニュアルやヘルプ」のC1/C2/CUは音楽CD読み取りエラー(C1エラー/C2エラー/CUエラー)のことを説明していないのではないかと思いますが、webFAQでは混用されているようです。

PlexToolsは欧州Plextorが開発したものらしいですから、マニュアルやへルプは英文から和訳したものではないかと思われます。ローカライズ過程における“変質”もあるかもしれません。実際、「Recover」の訳を「訂正」としている例もありますし。

・CDの開発に携わったという中島平太郎氏著「図解コンパクトディスク読本」のCIRC説明ページには「CU」なんて出てきません。



・ちなみに、もしかするとCU説やCX説は、“それ単独”で“RippingにおけるC1エラー/C2エラー(/CUエラー)の説明としてではない(例えばディスク品質としての説明)”なら筋が通るように解釈できるかもしれませんが、本稿はあくまでも「RippingにおけるC1エラー/C2エラー(/CUエラー)の意味」について考えているので、そうであってもあまり意味は持ちません。


 これら状況を見ると、「音楽CD読み出しエラーの説明としてのCU説」はちょっと説得力ないですね(苦笑)。あくまでも個人的には、ですが。

 ということで、本BlogではC2説に基づくことにしています。


メインメニューへ

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

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

11/01/01初稿

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

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


■前書き

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

*:CUエラーと呼ばれることもあるが、本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追記:前言撤回。上記はこの技術の主目的じゃなさそうです。
  「セキュアリッピングで比較に用いるCRC値生成のためにオフセット値を統一する」
 のが主目的でしょう。

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


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

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

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

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

*:16/07/20追記:どうも補間は「前後の平均」のようです。ですので、連続的なランダムエラーにならないと平均値は必ず一致してしまいます。実際、エラー補間値は平均値になっていること&連続していない場合はEACに認識されないことを確認しました。
 ですので、セキュアリッパーにとって補間有無を知る本命は「CRC値照合」ということでしょうけれど、データベースにないタイトルでは機能しないと言う点でこれも盤石ではありません。

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

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

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


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


■iTunes9の場合

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

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

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

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

   ・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追加調達

 …どのドライブを使っても両トラックとも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
    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」機能の有無と関係していそうに見えます。が、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なんて元々入ってないのですから(苦笑)。

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

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

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

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

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

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


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

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


■ということは

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

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

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

・セキュアリッパー:汎用ドライブ用・・・代表例「EAC」
 がんばってソフトウェアでやってるから特定ドライブ以外でも機能するが保証の限りではない。
 例えば、ドライブのファームにどんなバグがあるか判ったもんじゃない。

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

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

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

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

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

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

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


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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

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