FC2ブログ

セキュアリッパーの限界を見極める

19/09/14初稿

 セキュアリッパー考察記事で見てきた通り、≪EAC≫では自分で何度も読んで違いが発生しないかを見ています。
 C2エラーが発生していたら繰り返し読んだ結果(=補間結果)はおそらく異なるだろうという理屈に基づくものですが、補間結果が同じになる可能性もあるので、パーフェクトとは言えません。
 ≪dBpoweramp≫のページでも、「概ね違うエラーになるけど同じエラーになるかも」と言っているようです。

CD is read twice, if a section contains an error it will likely return different errors, so can be detected. This is true mostly but not always, consistent errors exist and in our opinion present more of a problem to secure ripping than the C2 error pointer detection 'hole'.

Either way there is an error and a secure ripper might not be able to detect the error (if a re-read returns the same error...).

出典:http://dbpoweramp.com/spoons-audio-guide-cd-ripping.htm

 とすると、前提条件が成立しないことになります。どうなっているのでしょうか?


#以下、PureRead機能あったればこそ確認できたことでもあるのでPureRead3+記事に追記(16/07/18)していたものです。


■補間は平均値か

・PureRead3+の実験結果を分析する
 C2エラーしたサンプルの補間値はその前後サンプルの平均値と言われています。
 ちょうど、PureRead3+記事で採取した「S09Jマスターモード(1)」の「138個のエラーを含むリッピングファイル」が、それを調べるのに適当そうです。

 138個のエラーの中で、サンプルNo.5388506(5238DAh),5388508(5238DCh),5388510(5238DEh)という“ひとつおきに3個”集中している部分につき、「正しい値に挟まれた補間値」がどうなっているか確認してみました。

 バイナリエディタでバイナリ値を覗きますので、≪WaveCompare≫もHEX表示にして該当部分を示します。左側が傷なしエラーなしディスクの正常値、右側が傷ありディスクでC2エラー発生により補間された値になります。

S09Jm 補間

 ≪WaveCompare≫では相違サンプルの前後(間)は表示されませんので、バイナリエディタ≪Bz≫で該当サンプル部分を確認。
 Intel形式ですのでバイト単位でひっくり返して読みます。
 以下画像ではサンプルNo.5388506(5238DAh)のLとRにあたる02FFhと08DFh部分をマークしています。

S09Jm 補間 バイナリ

 ≪WaveCompare≫と≪Bz≫で読んだ、「傷なしディスクの正しい値」と「傷ありディスクの補間された値」をサンプルごとに整理しました。
 C2エラーして補間された値には()で正しい値を付けています。

サンプルNo   L        R
 5238D9   009C       2429
 5238DA   02FF(015F)   08DF
 5238DB   0563       0CA6
 5238DC   0706(08BD)   094D(0BE3)
 5238DD   08AA       05F4
 5238DE   0590(060F)   009D(FEF3)
 5238DF   0276       FB47

 HEX値なので解りにくいとは思いますが、Windows付属のプログラマ電卓などで10進数に直したり計算したりできます。
 してみると、確かに補間値は前後のサンプルとの平均値になっているようですね。

 「この例だけ」「BDR-S09Jだけ」での結果ですので一般的かどうかまでは解りませんが、補間の実体が少しは解ったかなと思います。

 ちなみに、いくつかのC2エラー発生ファイルを覗いてみると、補間は“ひとつおき”に発生しているっぽく見え、それもCIRCの機能なのではないかと思えます。が、リッピング性能の低いドライブ(TEAC製スリムドライブ)だとやっぱり連続補間も発生(補間値の算出に補間値が使われている?)していましたので、「連続しないことが保証される」というレベルではないようです。

 本件について、CIRCに関する以下の情報を引用させていただきます。

この誤りかもしれないデータは正しく読みだされたデータに挟まれるようになっています.これでうまく補間がとれることになります.補間としては,平均値がよく用いられます.
出典:「図解コンパクトディスク読本」 P.110

 余談ですが、以下「技術者に訊く「PURE READ」 - 忠実なリッピングと原音再生を目指した機能の詳細を探る」記事によると、挟まれなかった場合は直前の正常値を連続させるとあります。

傷のせいで読めなかった部分は、従来だとドライブが前後の情報から予測して補間します。しかし何カ所も連続で読めない箇所が続いた場合は「前値ホールド」、つまり前の値をそのまま続けて入れてしまうんです。そして読み取れる場所が来るといきなり波形が大きく変わるので「プチッ」というノイズが発生してしまうんですね。
出典:https://www.phileweb.com/interview/article/200909/04/26.html

・CCCDを≪EAC≫Secureモードでリップすると
 本項19/09/23追記:以前、リッピング防止のためわざとC2エラーを仕込む「コピーコントロールCD(CCCD)」というCD(のようなもの)がありました。PureReadパーフェクトモードではすぐに停止してしまいますので、実際、ドライブにとってはC2エラー発生していると思います。
 あるCCCDを≪EAC≫のSecureモードでC2エラーを使わない設定でリッピングしてみたところ、エラーが発生しているハズなのにErrorCorrectionインジケータは点灯せず、AccurateRipも照合できてしまいました。
 これは、

・仕込まれたC2エラーによる補間結果は平均値なため2度読みでも同じになった
・補間は平均値を入れるのが一般的なので異なるドライブでも同じ値になる
・つまり補間されてもリップ結果は同じ=チェックコードも同じになる
・AccurateRipのDBに同じチェックコードが登録されているため照合OKになった

ためだと推察できます。

 余談になりますが、CCCDの挙動をメモしておきます。

・≪iTunes≫+S09JPureReadパーフェクトモード 上記タイトル
 エラー検出してリトライし、途中停止

・≪iTunes≫+S09JPureReadオフ 上記タイトル
 ドライブもリッパーもセキュアじゃなければ意図されたエラー含みでリッピングできてる

・≪EAC≫SecureMode(C2使わない)+S09JPureReadオフ 上記タイトル
 ErrorCorrection作動せず。やっぱり補間結果が同じになっているらしい
 GapDetectしてみたがGapやスタート位置など変化なし。TOCに細工はない模様

・≪CUERipper≫Burstモード+S09JPureReadオフ 上記タイトル
 たぶん全曲16回読みを繰り返した。結果AR、CTTBとも1トラック以外一致
 つまり意図した補間発生の補間結果が一致したということか(やはりほとんど平均値ってことか)
 1トラックだけ一致しなかったが、仕込まれたエラーじゃなくて本当に発生した?

・≪CUERipper≫Burstモード+S09JPureReadオフ  別の2枚組タイトル(1/2)
 10%段階(おそらくトラック01)で16回読みを10回くらいやって、最後は読めないとなった。トラック01だけリッピングされてた
 ≪EAC≫でGapDetectしてみたがGapやスタート位置など変化なし。TOCに細工はない模様

・≪CUERipper≫Burstモード+S09JPureReadオフ  別の2枚組タイトル(2/2)
 全部読めた。エラー入りだった
 ≪EAC≫でGapDetectしてみたがGapやスタート位置など変化なし。TOCに細工はない模様

・補間結果が「アタリ」になることは“ありえる”
 シンプルな可能性をひとつ挙げます。
 サイン波のゼロクロス点にサンプルがあったとすると、その値はもちろんゼロです。そしてその前と後ろのサンプルの値は±が違うだけになります。つまりその2点の平均値はゼロです。
 ですので、ゼロクロス点サンプルがエラーとなり平均値補間された場合、“アタリ”になります。
 「C2エラーが発生したけれどリッピング結果は補間なし状態になる」ことも(確率は非常に低いですが)あり得る、と言えます。


■補間の実態から考えるセキュアリッパー

・補間結果が同じでもセキュアに読めるのか
 さて、普通は平均値だとすると、正しく読めたサンプルに挟まれたエラーサンプルの補間値は何回読んでも同じになるハズです。
 とすると、「2度読んだ結果が同じになる=補間発生を認識できない」ことがあるのでは?

 試しに以下のリッピングしてみました。

 ・傷ありディスクのtrack10
 ・BDR-S05Jマスターモード
 ・≪EAC V1.1 from 23. June 2015≫ C2エラー情報は使わず(*)Secureリッピング

*:ていうかこの組み合わせだと使えません。影響を受ける余地がないということになるので実験には好都合ですが。

 このリッピングでは、これまでの結果から「連続ではない10個程度の“お決まりの”サンプルでC2エラーが発生する」と予測されます。そして、それらはドライブ内で平均値補間されてから≪EAC≫に認識されているハズです。そして、その補間値は2回読んでも同じになる可能性が高いということです。

 以下、ログです。

Exact Audio Copy V1.1 from 23. June 2015

EAC extraction logfile from 18. July 2016, 16:27

Unknown Artist / Unknown Title

Used drive : PIONEER BD-RW BDR-205 Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 0
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Not detected, thus appended to previous track

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

~省略~

Track 10

Filename F:\10 Track10.wav

Peak level 77.6 %
Extraction speed 1.3 X
Track quality 100.0 %
Copy CRC 15EA2D26
Copy OK

No errors occurred

End of status report


 「Track quality 100.0 %」「No errors occurred」とあります。
 確かにリッピング中「Error correctionゲージ」は一度も点灯していません。
 つまり、≪EAC≫は「ノーエラー」だと言ってることになります。

 しかして、このファイルとエラーなしファイルとの≪WaveCompare≫結果は以下の通りです。

S05Jm 補間 EAC

 ノーエラーじゃありません。


 さらに、「補間の有無で≪EAC≫のCRC値が異なる」ことを念のため確認します。
 当傷ありディスクtrack09につき以下ふたつのリッピングを行った結果、ふたつのCRC値は全く一致しませんでした。

  ・補間あり=S05J標準モードでリップ
   (傷なしディスクtrack09とWAVEコンペアで327相違あり)
  ・補間なし=S05Jパーフェクトモードでリップ
   (傷なしディスクtrack09とWAVEコンペアで一致)

・「ディスクオフセット」の事例
 ところで、上記の補間有無でのCRC比較は、普通に考えると「傷なしディスクと傷ありディスクのtrack09」で比較すれば簡単ですよね。ですが、そうではなく「傷ありディスクのtrac09で、PureReadの動作モードを変えて補間有無を作り出して」比較するのは何故かというと、傷ありディスクと傷なしディスクでは「読み出し位置が101サンプルズレている」ためです。
 上の≪WaveCompare≫を見ると、比較開始点が101サンプル異なっていますよね。そのため、傷ありと傷なしからのリッピングではWAVに切り出された位置が異なるので、補間発生がないtrackでも「≪WaveCompare≫一致・CRC不一致」なファイルになってしまうのです。これではCRC値だけの比較ができません。

 いわゆる「ディスクオフセット」によるものです。念のためですが、ドライブもリッパーも同じですからそれらによるオフセット違いではありません。
 ウチに2タイトルある“同タイトル2枚”では両方ともズレてました。
 ちなみに、上記ディスクでは、信号面にある刻印の製品番号以降が「-1-V4C14」「-1-S2C11」と異なっていました。


 以上、「≪EAC≫のセキュアモードでは補間発生を見逃すことがある」という実例を確認することができました。
 なお、本稿では補間が平均値であることを確認しましたが、「平均」に限らず何等かのルールに従って補間すれば何度読んでも同じ値になるのが普通でしょう(セキュアモードに補間発生を知らせるためにランダムな値にする、なんてしないでしょう)。
 別に平均値だから補間発生を見逃すワケではありません。念のため。

 個人的には、やっぱり補間有無はC2エラー情報で認識した方が安心です。


 CIRCがんばってる。PureReadやっぱり便利。


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

・Amazonアソシエイトに参加しています(アフィリエイトはAmazonのみです)

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