FC2ブログ

「オフセット補正」にご用心

19/09/29初稿

 本稿は、当初「DB照合サービスとは何か」記事に記していたものを、分量多くなったこともあり独立させた記事です。元の記事を前提に記します。

 さて、リッピングにおいて「DB照合サービス」、少なくともAccurateRipを用いるには「ドライブオフセット補正」は必須です(CTDBでは不要)。
 しかし、細かな事情がいろいろありそうですので、気を付けないと意図せぬ結果に悩むことになりそうです。
 本稿、そのことについて記しておきます。


■“Overread”とオフセット補正

 オフセット補正すると、通常の読み取り範囲を“はみ出して”読む部分が出てきます。それが「Overread」です。

・Overreadしないでプラスオフセット補正すると最終トラック末尾が欠損
 ≪EAC≫ではドライブオプションに「Overread into Lead-In and Lead-Out」の設定があります。

When using the read offset,there will be some data missing either at the beginning or at the end of a CD,depending on whether is offset is positive or negative. Some drives allow reading before the actual CD starts or after the CD has ended. So no samples will be missing in the extraction using this compensation.
出典:≪EAC≫の「Overread into Lead-In and Lead-Out」のカーソルポップアップヘルプ

 「オフセット補正すると、プラス補正なら最後(マイナス補正なら最初)のサンプルを取りこぼすけど、その辺が読めるドライブなら救える」ってことですね。
 実際、この設定をオフにしてプラスにオフセット補正すると最終トラック末尾を補正分取りこぼすようです。

 具体的には、+667(推奨値)だと補正した分667サンプルが末尾に増えない現象です。先頭は減っています(前トラックの末尾に移動した)から、その分が欠損しています。

No-Overread(wataco)

 ≪WaveCompare≫を見ると、先頭のゼロサンプルは667減っていますが末尾は変わっていませんよね。結果、サンプル総数が588の整数倍になっていません(フレーム数あとの+表示はそれを表しているのですね)。

・CD全トラックリッピングでの結果
・+0(補正なし)なら大丈夫
・+637、+2でもダメ。つまり補正するとダメっぽい
・3タイトルで同じ結果だったのでディスク依存ではなさそう
・示したのは日立LG製BD-ROM/DVDライタ:GGC-H20Nの結果だが、Pionner製BDR-S05Jの+667(推奨値)でも同じ現象。ドライブ依存でもなさそう

 このオプションをチェックしないと、≪EAC≫がOverreadに入ると読み込みを切ってるようですね。

・Overreadしてプラスオフセット補正したのに最終トラック末尾がゼロに変質
 では、Overreadすると読むべきサンプルが読み出せるのでしょうか。

 AccurateRipのページ(*)によると、ほとんどのドライブはマイナスオフセット(補正値がプラス)のようですので、プラス補正の場合=最終トラック末尾について見てみます。プラス側にオフセット補正して読む位置を後ろにズラすのですから、最終トラック末尾に補正なしでは読まなかったサンプルがくっつくことになります。

*:http://www.accuraterip.com/driveoffsets.htm

 プラス補正は物理的リードアウト直前のサンプルまでドンピシャで読むようにするものですから、逆に言うと補正しても物理的リードアウトは読みません(+30補正しすぎ問題は後述)。ですから物理的にはオーバーリードしておらず読めるハズですが、≪EAC≫にはOverreadできるできないを判定する機能があります。ドライブ仕様としては何か事情があるようです。
 そこで、その判定結果が以下の2台で、実際何がくっついてくるのか試してみます。

・プラス補正必須だがLead-Out読み非対応ドライブ:GGC-H20N
・プラス補正必須でLead-Out読み対応ドライブ:BDR-S09J

 対象トラックは、末尾がゼロだと何か起きているかワカリマセンから、「補正なしだと末尾がゼロではない最終トラック」とします。
 Overreadする設定にして、≪EAC≫で補正値を変えてリッピングした最終トラックの最後の部分を≪Wavosaur 1.3.0.0≫で示します。

  上・・・GGC-H20Nで補正なし(S09Jも同等になるハズ)
  中・・・BDR-S09Jで+667補正あり
  下・・・GGC-H20Nで+667補正あり

最後がゼロじゃない最終トラックのオフセット補正(改訂)

 H20Nの補正しない場合(上)と比して、S09Jで+667補正(中)すると確かに最後に667サンプル増えています。意図した結果になっているようです。
 しかし、H20Nで+667補正(下)すると、補正で増えた667サンプルは実際のデータではなくゼロとなり、そればかりかその前の2352サンプルもゼロに書き換えられ、末尾合計3019サンプルがゼロになっています。
 普通はトラック末尾はゼロなので、ゼロへの書き換えに気付くことはないでしょう。2352サンプルはちょうど4フレームです。H20Nでは、プラス補正されると「補正で後ろを延長して読む分+さかのぼって4フレーム」をゼロに書き換えているということになります。

・両ドライブとも、念のため補正値はAccurateRipのページでも確認。≪MusicBee≫で検出してもこの値
・+637だとゼロサンプルが30個少なくなるだけだったことから、「+30補正しすぎ問題」は関係ない
・補正値を-2にするとゼロにならない
・≪CUERipper≫でも同じ結果になる
・≪MusicBee≫だと、末尾状態が補正なしと変わらない。が、サンプル数は667減。つまり、上記で見た≪EAC≫の「Lead-Outを読まない」設定状態になる模様(関連設定は見当らないので読まないで固定の模様)
・別タイトルでは9フレーム分ゼロに書き換えられていたので、特定タイトルの現象ではない(フレーム数違いはタイトルの何かに依存して変化する?)

 書き換えないドライブもあり、書き換えるドライブではそのフレーム数も異なることから、ドライブ依存と言っていいでしょう。実際に≪EAC≫のOverread能力判定結果通りになったということです。

・Overreadで末尾がゼロに変質するのは「Lead-Outが読めない」からか
 ドライブを追加して≪EAC≫の判定結果との関係を調べてみました。オフセット補正値はすべて≪EAC≫が表示したものです。

・GGC-H20N(+667):Only Lead-In・・・書き換え(上述の通り)
・BDR-S09J(+667):Only Lead-Out・・・ゼロなし(上述の通り)
・スリムドライブ(+6):None・・・書き換え(*1)
・PX-716A(+30):Lead-In & Lead-Out・・・ゼロなし
・DVR-105(+48):Only Lead-Out・・・ゼロなし
・PX-W8432T(+355):Lead-In & Lead-Out・・・ゼロなし
・FX48(+12):Only Lead-Out・・・ゼロなし
・SW-5582(+102):Only Lead-In・・・書き換え(3042個ゼロ付き *2)
・iHES208(+6):Only Lead-In・・・書き換え(2946個ゼロ付き *2)
・iHOS104(+696):None・・・ゼロなし

*1:前者タイトルは5フレーム、後者が10フレーム分ゼロに書き換えられました
*2:5582は3042-102=2940、iHES208は2946-6=2940で、いずれも5フレーム分が書き換えられたということです。

 以上より、プラス補正する場合はこの検出結果でLead-Outが読めるドライブじゃないとダメなようです。
 が、iHOS104はNoneなのに書き換えていませんから、検出結果との関係は絶対的なものでもなさそうです。
 まとめると次のようになります。

「プラス補正すると読まなくてはならないLead-Outが読めない(と≪EAC≫に検出される)ドライブは、オフセット補正すると最終トラック末尾のサンプルがゼロに書き換えられる可能性がある(大丈夫かもしれない)」

・ところで「Lead-Inが読めない」と問題はあるのか
 ≪EAC≫のOverread能力判定について、ちょっと疑問に思っていることがあります。

・Lead-Inとトラック01の間には必ず2秒以上のINDEX00があります。
・リッパーの読み出し開始はINDEX01からです。
・マイナスオフセットにしてもマイナス補正にしても2秒以上はありえません。
・トラック01のINDEX00を読む(*)場合でも冒頭2秒はカットされますから、Lead-In領域はどうせリッピングされません。

 ですから、マイナス補正してもLead-Inが読まれることはないハズです。
 とすると、「Lead-Inが読める」という判定はどういう意味を持っているのでしょう? 上記の通りLead-Outは読めないと問題になるのは解るのですが、いずれ読まれることがないLead-Inについては“どっちでもいい”気がするのですが。シンプルに「Lead-In=トラック00(Lead-Out=トラックAA)を読むコマンドレスポンスが正常に行えるか」の確認結果なのでしょうか。
 強いて挙げるなら「トラック01のINDEX00を読む場合、冒頭2秒について、最終的にリッピング結果からは削除するにしても、それも含めてアクセスできる必要がある」という問題はありえる?(というか普通はトラック01のINDEX00は2秒ですけれど)

*:INDEX00は音声データですから“読む気になれば”読める領域です(だからHTOAが成立する)。

・オフセット補正必須のAccurateRipはOverreadできなくても成立するのか
 当然ですが上記の影響でARチェックコードは変化してしまいます。

・実際、上記H20NとS09Jのオフセット補正結果のリップで生成されるコードは異なることを確認
・もちろん≪EAC≫のCRC値も異なる
・なので当然DB照合結果も異なる
・事例のトラックは、H20NとS09Jともconfidece5で返されたチェックコードはどちらとも異なり照合NG
・≪MusicBee≫で667サンプル不足したリップでは「一致せず」

 H20NはさておきS09Jはパーフェクトモードで補間発生していませんし、補正したトラック最後まで読めているのですから照合OKになっていいハズです。ならないのはちょっと不思議です。ディスクオフセットバージョンが無かったためならよいのですが。
 いずれにしても、補間とは関係なく「プラス補正が必要なドライブでは、補正すると最終トラックのDB照合用のチェックコードがドライブによって違う場合がある」と言うことはできます。

 “オフセット補正(AccurateRip)して使うなら”、ドライブは上記を考慮して選んだ方がよいかも知れません。最終トラック末尾がゼロじゃないタイトル探し出して(または自作して)、オフセット補正の有無で末尾が変化しないか確認する、ってカンジですかね。
 いろいろ難しそうですね。

・Overreadできないなら読めない分をゼロで埋めて救済する
 上記のリッピングは≪EAC≫オプションの「Fill up missing offset samples with silence」ノーチェックでの結果です。これは以下ポップアップヘルプによると「読めるドライブ以外で補正する場合のオプション」です。

When using offset correction without the drive being able to overread into lead-in/lead-out,this flag specifies if the missing samples should be fillied with silence or just left out,resulting in a WAV file with some missing samples.
出典:≪EAC≫の「Full up missing offset samples with silence」のカーソルポップアップヘルプ

 「Overreadしない設定(ドライブの能力に関わらず“しない”)の時に欠損するサンプルを埋める処置」ということですね。
 上記GGC-H20Nを+667補正&Overreadしない設定で当オプションをEnableにすると、確かに末尾に667個のゼロサンプルが追加されました。

No-Overread FillUp(wataco)

 “読めた場合の実サンプル値もゼロなら”、≪EAC≫がゼロをFill upすれば結果的に同じデータになりますので、確かに「Overreadできないドライブでもできるドライブと同じ結果が得られ」ます。
 が、実サンプルがゼロではないタイトルも上述の通り存在することは覚えておいた方がいいでしょう。


#本項、19/03/09ごろ「オフセットとギャップ記事」に追記したものを、19/09/14「DB照合サービスとは何か」に移動し、さらに本稿に移動したものです。


■オフセット補正のそもそも論

・物理的「リードイン・リードアウト」とソフトからみえる「Lead-In・Lead-Out」
 ところで、音楽CDの規格によると、音声領域は以下の領域に挟まっています。

・最初:リードイン領域とトラック01のINDEX01との間には最低2秒(88200サンプル)のポーズ期間(トラック01のINDEX00=音声データ)がある
・最後:リードアウト領域はトラックナンバーAAの音声トラック

 よって、物理的な実際のCD盤面のデータに対するドライブの対応は、

A.マイナスオフセット(プラス補正)の場合(大半のドライブはこちら)
 リードイン:普通読まない(*)
 トラック01のINDEX00期間:仕様なので当然読めるハズ
 リードアウト:当然読まない

*:規格上最短INDEX00の2秒を超える88200超のマイナスオフセットのドライブでない限り。またはHTOAなどトラック01のINDEX00をリッピングする場合以外

B.プラスオフセット(マイナス補正)の場合
 リードイン:当然読まない
 トラック01のINDEX00期間:当然読まない
 リードアウト:仕様なので当然読めるハズ

と考えられます。

#ちなみに、オフセットは「+667」といった588で割り切れない値になっていますので、フレーム単位ではありません。よって、フレーム単位で読み込みを調整しているのではなく、ドライブ内のメモリからズラして読みだしているということになります。

 つまり、オフセットを持つドライブでは物理的なトラック01のINDEX00やリードアウトは「読む」「読める」、つまり「“物理的オーバーリード”はできる」のが基本でしょう。そして、正しくオフセット補正するということは物理的なトラック01のINDEX00やリードアウトを読まなくなる(読まないようにする)ことですから、物理的オーバーリードは不要になるハズです。
 厳密に言えば、HTOAも音声データとして扱えますから、マイナスオフセットドライブなら物理的リードインも読めると考えられます。

 こう考えると、≪EAC≫が言う「Lead-In」「Lead-Out」とは、その名を持つディスク上の物理的な領域と区別し、「ドライブがオフセット入りで処理してリッパーに見せている仮想的な領域」と位置付けた方が解りやすいのではないでしょうか。
 本稿ではそう解釈し、物理的リードイン・アウトと区別するためそれらは英語で記すこととし、それらを読むことを「Overread」と位置付けることにしています。

・Overread設定の目的は何か
 さて、とすると、敢えて「Overreadする/しない」を設定できるようにしてある意図は何でしょう?

 オフセットを持つドライブにとってはオフセット読みが仕様=普通です。
 そういうドライブにオフセット補正を指示して物理的なINDEXやリードアウト位置にピッタリ合わせて読みだそうとするのは、ドライブにとっては逆に普通じゃない動作と言えそうです。
 とするなら、

「オフセット補正でOverreadすると意図せぬ結果を返すドライブがあるので、Overreadしない(通常状態で読む範囲しか読まない)でオフセット補正するモードも用意した」

のでは? 

・実際、上記の通り意図しない結果「末尾をゼロに書き換えてしまう」をもたらすドライブが存在します。
・同じくAccurateRipが使える≪MusicBee≫では上記の通りOverreadはしない仕様のようです。
・≪CUERipper≫ではOverreadする状態と同じ結果を出しましたので、する仕様のようです。AccurateRipも使っていますが、DB照合サービスのメインは「オフセット補正不要のCTDBだから」かもしれません。
・≪EAC≫ドライブ認識後のデフォルトではOverreadオフのようです。
・といってOverreadしないと補正した分欠損しますので、フォロー機能として≪EAC≫には「Fill up missing offset samples with silence」が準備されていると考えるとツジツマが合います。

 “「Overread into Lead-In and Lead-Out」はチェックすべし”という説明があっても、鵜呑みにしない方がよさそうです。


■余談

・+30補正しすぎだとしたら
 もし+30補正しすぎだとすると、Overreadして+667補正したS09Jの最後の30サンプルは物理的リードアウトを読んでいることになります。ゼロはなく±3程度のランダム値ですから読んでいるのでしょう。また、もうちょっと増やして+670補正するとゼロではない3サンプルが追加されましたので、このタイトルの物理的リードアウト(CD規格上音声トラック“TrackAA”として扱われている)のサンプル値はゼロではないようです。

・マイナス補正する場合のトラック01の先頭にも問題あるか
 マイナスに補正する場合はトラック01の先頭に同様の問題が発生する可能性も考えられますが、最終トラックに問題があることが解っただけで十分ですので、本Blogでは扱わないことにします。
 プラスオフセットのドライブは稀なようですし、所有していませんし。
 まあ、「+30補正しすぎ」が是なら、+30未満の補正値は実はマイナス補正=プラスオフセットとなります。その意味ではいくつか所有していることになりますけれど。

・トラック01のINDEX00やリードインを見てみたい
 S09J補正なしでリッピングした結果、トラック01の冒頭がゼロじゃないタイトルもありました。INDEX00の末尾を667サンプル分読んだもの、ということになりますね。HTOAなんてあるくらいですから、トラック01のINDEX00はやっぱり普通に読めるのでしょう。
 こういうタイトルでリードインまで読みたいと思って≪EAC≫でGapをくっつけて読んでも「トラック01のINDEX00は通常は2秒」かつ「リッパーはトラック01のINDEX00の冒頭2秒をカット」しますので、結局何もくっつきません。ちなみに、≪EAC≫のオフセット補正は±10,000までのようですから、INDEX00より前までは読む設定はできません(ドライブが対応してるかは別として)。

・いろいろな設定
 本稿では、≪EAC≫を「Drive read command」を「Autodetect read command」に設定して用いています。
 ≪EAC≫には他にも多様な設定がありますので、もしかしたら本稿のような状態にならないようにすることも可能かも知れません。
 が、AccurateRip搭載でオフセット補正必須でも設定がないリッパーもありますし、「ご用心」には変わりないと思います。


 なお、本稿で用いたリッパーのバージョンは以下の通りです。
  ≪EAC V1.3 from 2 September 2016≫
  ≪CUERipper 2.1.6≫
  ≪MusicBee 3.3.7165≫


メインメニューへ

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

リッパーの「DB照合サービス」とは何か

19/09/14初稿

 本稿、ドライブオフセットやディスクオフセットやギャップやINDEXに関してはこちらの記事を前提にしています。


■「DB照合サービス」とは何か

・セキュアモードの限界
 複数回読みで補間結果が同じになり、エラー発生を認識できないことがあります。

 ≪EAC≫には自動的にCD全体のリッピングを2度行ってトラックごとのCRC値を2度生成して比較する機能もあります。Copy(本番)とTestのふたつのCRC値とその比較結果欄がそれです。ですが、TestとCopyの“2回”では一致してしまう可能性もそれなりに高いでしょう。
 これを異なるドライブで行うのなら、その補間結果が全く同一になる可能性は低いかもしれません。けれど、その場合はドライブオフセット補正は必須です(*)。何より、ドライブ変えて2回リッピングしてその結果を比較するのはメンドクサイですよね。
 ですので、複数のドライブで比較することは考えないことにします。

*:あるCDのトラック02をドライブオフセット補正せず異なるドライブ(補正値異なる)でリッピングし、WAVEコンペア結果は一致しますが異なるCRC値になることを念のため確認しました。
 また、同じドライブに入れたまま続けて補正値0と+1でリッピングしても、全く異なるCRC値になりました。

 なお、ここで言っている「≪EAC≫のCRC値」はローカルなもので、以下に記すAccurateRipなどの「DB上の照合データ」とは関係ありません。

・“n=1”の限界をオンラインデータベースで突破する
 つまり、リッピングする同一タイトルの枚数が“n=1”では限界があるということです。
 といって「CDは必ず2枚ずつ買う」などというのは非現実的です。
 そこで、インターネット環境を活かし、「複数ユーザのリップ結果から生成した照合用コードをDB化する」ことでn数を増やすサービスが開発されたのですね。本Blogでは、それを「DB照合サービス」と呼ぶことにします。
 代表的なのが「AccurateRip」です。「CUETools-DataBase(CTDB)」というサービスもあります。
 それぞれ、特定リッパー専用サービスではありません。例えば≪EAC≫では両方採用しており、リッピング結果ログに両方が記録されます。

 なお、≪EAC≫では、ドライブとの相性により、設定によってはセキュアモードだとかえって正しく読めないことがあります。正確に活用するには非常に注意を要するということであり、これも「限界」の一種と考えられるでしょう。


 ということで、以下、オンラインDB照合サービスについて見ていきます。


■AccurateRip(AR)

 まずはこちら。≪dBpoweramp≫のベンダillustrate社が提供しているものです。
 オーディオ用NASにも搭載されているんですね。アイ・オー・データ製NAS:RAHF-S1の解説を引用しておきます。

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

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

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

ARチェックコードとドライブオフセット
 ところで、AccurateRipで比較に用いるチェックコードは“ドライブオフセット”が違うと異なる値になります(上述した≪EAC≫のCRC値と同じ理屈です)。ですので、ドライブオフセットを補正して読み出し位置を一定にしないと、ドライブごと(オフセット仕様ごと)のチェックコードになってしまうワケです。
 それを確認するため、補正値を手動で変更できる≪CUERipper≫を用いて(*)、異なる補正値でARチェックコードがどうなるか見てみました。
 ドライブオフセット補正した場合と補正しない場合では、ARチェックコード値はV1もV2も異なる値になりました。
 具体的には、オフセット補正が+667と提示されるドライブの補正値を+667に設定した場合と0にした場合です。

*:≪EAC≫では、AccurateRipは補正前提でないと機能しないようです(ARを選ぶとオフセット値は所定の値が入って変更できないことから)。≪CUERipper≫では補正値は自動設定されますが、変更できます。メインとする照合サービスのCTDBはオフセットを気にしない故でしょうか。

 ≪EAC≫のドライブオフセット検出用リファレンスタイトルリストは以下です。同タイトルでも日本語版は別CDと認識されるようですので、製品番号まで合ってないとダメっぽいです。
http://www.exactaudiocopy.de/en/index.php/overview/basic-technology/list-of-included-reference-cds/

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

 ・E2:エラーあり盤のトラック02
   Copy CRC B66BB840
   Accurately ripped (confidence 11) [392FCBB0] (AR v2)

 ・N2:エラーなし盤のトラック02
   Copy CRC 5E15B169
   Accurately ripped (confidence 4) [EC5B8D8A] (AR v2)

 確かに、同じタイトルの同じトラックなのにCRC値もARチェックコード値も異なります。
 そしてconfidence数も異なりますので、ディスクオフセットバージョン数の“Confidence Group”があると理解していいでしょう。

 なお、トラック01の結果は以下の通り。

 ・E1:エラーあり盤のトラック01(エラーするトラック)
   Copy CRC E6EC38E6
   Cannot be verified as accurate (confidence 12) [C4CCD74F],
   AccurateRip returned [95FCEBCB] (AR v2)

 ・N1:エラーなし盤のトラック01
   Copy CRC B28537DA
   Accurately ripped (confidence 3) [006F8261] (AR v2)

 さて、これをどう理解すればよいのでしょうか。
 illustrate社のページには次のようにあります。

Overtime AccurateRip can become like a wise-friend, someone you can rely on and trust. It works by storing peoples ripping results and comparing your result with theirs. For example 100 people rip Madonnas latest CD, of those 100 twenty have errors, the other 80 all have identical rips. If you were to rip your Madonna CD there are 2 possibilities, AccurateRip would report that 80 other people agree with your rip (confidence of 80), or that 80 disagree if your had errors. 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.
出典:http://cd-ripper.com/secure-ripper.htm

 ARチェックコードの一致は、ディスクオフセットバージョン数だけ存在するハズです。つまり、「confidence」は、いくつかのグループの中で、今回のリッピングと一致するコードのグループの一致数だと思います。
 そして、エラーがあってARチェックコードと一致しない「Cannot be verified as accurate (confidence 12)」の場合でも、confidence数12は「一致したARチェックコード数」を示しており、それと一致しなかったと言っていると理解していいようです。

 しかし、エラーによって変質しているARチェックコード値でディスクオフセットバージョンは解らないでしょう。今回は1トラックだけのリッピングですから、エラーしていない他トラックの情報からバージョンを割り出す、といったこともできないハズです。
 とすると、エラーがあった場合のconfidence数はどのディスクオフセットバージョンのものを表示しているのでしょう?
 ちなみに≪CUETools≫でE1トラックをリペアしたV2値は「5aabfc50」でした。その時E2トラックは「392fcbb0」になってましたので、エラーありディスクのディスクオフセットバージョンにおけるトラック01のエラーなしARチェックコードはリペアして得た「5aabfc50」でいいでしょう。リペア時、confidenceは11でした。しかし上記E1で一致しなかったconfidenceとして提示しているのは12です。リペアの方が後ですので減るのは変ですし、そもそもARチェックコードも違います。やはり12は別バージョンでの一致数と思われます。不一致の場合は「最多一致数グループ」のconfidence数・チェックコードを表示するのでしょうか?

 ちなみに、当タイトルの≪CUERipper≫による「AccurateRip found」数は、この時点で40(CTDBは125)でした(2枚とも)。ディスクオフセットバージョン違いも含め、登録された全数だと思われます。ARチェックコードはトラック単位で登録でき、この表示はDisk-ID単位なので、登録されたトラックの数はこの数以下であり、トラックごとにバラツキがあるのでしょう。

・confidence数は大きいほどリッピング精度が高いのか
 引用では「3個以上一致すれば100%安心」と言ってますから、3以上なら100%でドンツキなワケです。
 つまり「confidenceが3以上のAcucrateなら安心していい」という意味であって、「多ければ多いほど“Accurateレベルが高い=リッピング品質が高い”といった意味ではありません。もちろん、天文学的確率まで考えて“超正確”に言えばどれだけ多く一致しても100%ではありませんから多い方が安心ではありますが、実際にはひとつでも一致すればまず大丈夫でしょう。

・ARチェックコードと「+30補正しすぎじゃないか」問題
 ドライブのオフセット補正値はDB(*)に集められています。これは物理的なトラックの一番頭から読み出し開始するべく設定された値の“ハズ”でした。しかし、実は+30補正しすぎだったという疑義が提起され、どうも事実のようです。
 それはリッピングにどう影響するのでしょうか?

*:http://www.accuraterip.com/driveoffsets.htm

 仮にオフセット補正を“しすぎている”としましょう。とすると、例えば+667補正の場合は+637補正が正しい、ということになりますが、+637補正で得たARチェックコードは、もちろん+667補正した場合とは違う値になります。
 しかし、DB照合サービスにおける照合値は、「ドライブごとのオフセット違いを無くす」という一定のルールに基づいて集められればよいもので、“真のトラック先頭”から読んだ場合の値である必要はありません。
 すでに問題発覚前の補正値(+30補正しすぎだが、すべてのドライブで共通)で大量のチェックコードを集めたのですから、+637で改めて集めなおす必要はなく、そのままでいいと思います。

 なお、+30するしないでリッピングしたファイルは当然異なるものになりますが、30サンプル多めに“後ろ倒し”しても、トラックの頭が30サンプル減りおしりがその分増える=トラックとしては前後の切れ目が変わるだけ(タイトルとしてはリードアウトの30サンプルを読むことになる)ですので、事実上問題にはならないでしょう。そもそもアルバムの順番通り再生する場合は減った分は前トラックのおしりにくっついていますので、トラック01の頭と最終トラックのおしり以外は問題になりません。

 ではなぜ結構問題になっているように見えるのでしょう? それは、ディスクの完全コピー“Exact Audio Copy”のためには(ライティング時のオフセットも含めて)無視できないからだと思われます。
 単にファイル化する場合の影響は上述の通りですので、混同しないようにすべきでしょう。

・ARチェックコードとプリギャップ
 フレーム数をMSFの概念で*m*s*fで表します。ドライブはPureReadオフのBDR-S09Jです。

(1)プリギャップを「前トラック末尾につける」
 デフォルトです。普通です。問題ありません。

(2)プリギャップを「自トラック先頭につける」
 ≪EAC≫では「自トラック先頭につける」こともできます。
 プリギャップがあるCD2枚でそれをやってみたところ、チェックコードは同じになりAR判定できました。くっつける場所は違ってもプリギャップは読みだしているのですから、おそらく生成するファイルとは別にデフォルト状態と同じようにギャップを扱ってチェックコードを生成しているのでしょう。

(3)プリギャップを削除する
 ≪EAC≫では削除することもできます。
 同じく2タイトルでやってみると、「もともとプリギャップが存在しなかったので関係ないトラック」以外は「Track not fully ripped for AccurateRip lookup」と出ます。削除の場合はチェックコード生成プロセスに渡る前に削除されちゃうので通常にみたてた計算できないってことでしょうか(≪MusicBee≫のギャップ削除でもAR不一致になりました)。

 例として、プリギャップが00m00s58fあるトラック04(トラック05のプリギャップは00m01s35f)のリッピング結果ログを提示しておきます。1トラックのみのリッピングです。

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

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

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

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

 しかし、もう一方のタイトル(上記のエラー入りとなしの2枚持っているタイトル)では、エラーなしトラック02(トラック03のプリギャップは00m01s49f)では以下のようになりました。

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

 このタイトルでは、1トラックじゃなくて数トラック同時でもダメなことがあります。
 「CDまるごとリッピングじゃないとAR判定できないことがある」ということですね。GGC-H20Nでもダメでしたので「≪EAC≫のクセ」でしょうか。
 いろいろな事情がありそうですので、AccurateRipを使う場合は、ギャップ処理は無難にデフォルト(前トラック末尾に付ける)が良さそうです。

 ちなみに、補間発生してミスマッチした場合は「Cannot be verified as accurate (confidence 13) [5AAA3BC6], AccurateRip returned [95FCEBCB] (AR v2)」といったログになります。チェックコード不一致ということです。「Track not fully ripped for AccurateRip lookup」は「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全体で見ているので選択する概念がないのだと推察しています。


■「DB照合サービス」は完璧か

・そのまえに「セキュアモードの現在の立ち位置」
 登場当時のセキュアリッパーは「自分で補間発生を認識して発生しないように読むもの」でしたので、「SecureモードやParanoidモードを使うためのもの」だったと言えます。
 しかし、何度読んでも平均値が入る補間が同じ個所で発生する場合、エラー発生は認識できません。が、その場合照合値はDB上の値とは一致しませんから、“DB上に照合値があれば”エラー発生を検出できます。
 ですので、「DB照合サービス」を実装した現在では

「Burstモードでリッピングして照合できたら終了。できなかったら補間発生をなくすためSecureなモードでがんばる」

という手順が効率的になったと言えるでしょう。
 なお、「これでもかとしつこく読む元祖(by illustrate社(*))」たる≪EAC≫でも、Secureモードの中でもよりしつこく読むParanoidモードはすでに推奨されていません。

What is “Paranoid Mode” and why is it not recommended?
This mode is the oldest read mode in EAC, it exists from version 0.1b on. It will read every sector twice, but in very small blocks. This will slow down extraction, no drive features are used. If the drive does caching the option below should be activated, but this could create problems on some drives. This mode is stressing the drive very much and should not be used, if one of the other secure modes works ok. The “disable CD-ROM drive cache” will disable the drive cache when using Paranoid mode, by resetting the drive after a read command. On some drives this will take several seconds and should not be used in that case.

出典:http://www.exactaudiocopy.de/en/index.php/support/faq/extraction-questions/

*:The next method is the rip-rerip way, the idea is if there is a scratch the re-rip might get a different result so that area of the CD can be ripped many times until there are matches. EAC pioneered this method (the work of PlexTools and dBpoweramp are based on EACs work, we stand on the shoulders of giants, or a giant). This method is to be really put to the test and highlights dBpoweramp’s new way of doing it.
出典:http://cd-ripper.com/secure-ripper.htm

 では、「DB照合サービス」を使えば補間発生の検出は盤石なのでしょうか?

・タイトルがDBにないと機能しない
 当然ですけれど、まずはこの問題があります。マイナーなタイトルだと危ない? また、新譜は“仲間ができるまで”ちょっと時間がかかる可能性はありますね。
 AccurateRipサイトからの引用では「3個以上一致したら(確率的に)絶対大丈夫」と言っています。まあ、違う環境で同じ照合値になるようなエラーが発生することはまずないので、現実的には、一致するものがひとつでもあれば大丈夫だとは思います。
 万一DB上にひとつも無かったらもう一枚自分で買えば解決できる?(笑)

・ディスクオフセットが一致するバージョンのタイトルがないと機能しない
 同タイトルでも表題を満たす必要があります。
 余談ですが、「DBに無かったのでもう一枚買ったらバージョン違いだった」なんて可能性もあり得ますね。
 なお、AccurateRipでは同バージョンが必要ですが、上述の通りCTDBはドライブオフセットだけでなくディスクオフセットにも影響を受けないとのこと。

・ギャップをどうリップするかに制約あり
 上記の通り、AccurateRipを利用するなら無難に「前トラックに付ける(デフォルト)」でリップした方がよさそうです。
 CTDBを利用したい場合は、そもそもギャップ処理は選べません。

・HTOAは照合できない
 細かい点&レアケースですが、AccurateRipでもCTDBでもトラック01の前にある隠しトラック(HTOA)の照合には非対応とのこと。

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

Spoon (Administrator):Yes sorry, HTOA is not in AccurateRip.
出典:https://forum.dbpoweramp.com/showthread.php?16725-HTOA-and-Accuraterip

・CTDBでカットされるディスクの最初と最後のエラーは検出できない?
 CTDBのチェックサムは“最初と最後の5880サンプル(10フレーム)”を除いて生成するらしいので、ここにエラー(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

 チェックサム生成のためにカットされるサンプル部分はほぼ無音のハズですので、そこにエラーがあっても事実上の音質には影響与えないでしょうけれど。が、本Blogではそういう点も含めてノーエラーでのリッピングを考えていますので、敢えて挙げています。

・オフセット補正値が判明しているドライブじゃないと機能しない
 AccurateRipではオフセット補正必須ですので、ドライブを認識して自動的に設定されます。逆に言うと、オフセット補正値情報があるドライブを用いる必要があるということです。
 DBには多くのドライブが登録されていますのでまず大丈夫だとは思いますが、一応条件にはなるでしょう。

・オフセット補正すると「サンプル欠損・変質」してしまうソフト設定やドライブがある
 AccurateRipでは「オフセット補正」は必須ですが、実施には注意が必要です。
 オフセット補正すると≪EAC≫で言うところのOverreadすることになります。実際、Overreadしないとサンプル取りこぼすようです。
 といってOverreadできないドライブでOverreadするとサンプル値をゼロ書き換えることがあるようです。末尾や先頭で発生しますので実サンプル値もゼロのことが多いと思いますが、そうでない場合は問題になります。

・「汎用性があるミスリード結果のチェックコード」が蓄積されているかもしれない
 ところで、上記のオフセット補正に関する注意事項の現象は、特殊な環境のみで発生するものではありません。結果も一定の規則性を持ちます。つまり、使用ドライブやリッパーの条件を満たせば同様のリッピング結果となり、そのチェックコード値がDBに蓄積されるとそれなりのconfidence数になる可能性もあります。そのconfidenceと一致しても、実際には不完全リッピングです。
 ただ、AccurateRipではそれを容認というか利用している気もします。「オフセット補正によってサンプル欠損したチェックコードは有効とする」としないと、問題が解決できなそうですから。補間発生の有無は検出できるんだからいいじゃん、と。
 なお、欠けたりゼロに置き換えられたりした部分は先頭や末尾の微小時間で通常は無音でしょうから聴いて判るような不完全さではありませんが、「完璧ではない事例」とは言えるでしょう。

・自分の「エラー入り照合コード」と照合しないよう気を付ける必要あり
 非常にまれなケースだとは思いますが、エラー入りコードをDBに登録してしまい、もう一度リッピングした時に同じ補間結果になって(冒頭のリンク記事の通り可能性あり)同じコードになった場合、DB上の自分のコードと一致してしまうかも知れません。
 特に「コード登録がひとつもなかった」のを見た気がした後は、“セルフ照合”しないように気を付けた方がよいでしょう。一度めの照合やドライブ変更した場合は(補間結果が同じになる可能性はまずないので)関係ありませんけれど。
 もちろん、照合DBに登録するデータにはリッピング環境によるIDが埋め込まれており、セルフ照合しないように考慮されています。以下はCTDBの説明です。

Submission log, including user's ip addresses and CD drive model, which is used to eliminate erroneous submissions, virtual/faulty drives, and to verify if a submission by one user is independently confirmed.
出典:http://cue.tools/wiki/CUETools_Database

 ≪EAC≫にはAccurateRipへのresult提出項に「Computer Identification」数値があります。これで判定していると思われます。

 ですが、例えば「ドライブ以外全とっかえ(IPアドレスなども)」でも同じ環境だと見抜けるのでしょうか。この場合は「平均値補間」で同じリップ結果=チェックコードを結果を返す可能性はあると思います。
 もしかしてセルフ照合の可能性も含めて「3個以上なら安心」なのかな?
 いずれにしても、こういう可能性についても覚えておいた方がよいでしょう。

 なお、エラーがあるCDを異なるドライブ(同じ型番でも)でリッピングした場合、全く同じエラーになる可能性はほぼないと言っていいでしょう。ですので、レンタルCDのエラー入りチェックコード(チェックサム)が複数の環境から登録された場合でも同じ値になることはまずありません。

・セキュアモード結果と不整合になる可能性はゼロではない
 2度読みした結果(平均値などで)補間結果が同じになったら(C2Flagを使わない)セキュアモードではエラー認識できません。が、AR照合結果はNGになるでしょう。
 一方、セキュアモードがエラー検出~リトライした結果選択された値がたまたま正しいサンプル値になったら、エラーレポートされたのにDB照合結果はOKになるでしょう。
 後者はまず発生しないと推定されますし最終的には正しい結果を得ていますからDB照合の問題点ではないと思いますが、万一そのような現象に遭遇したときに混乱しないよう、覚えておいてソンはないでしょう。

・サービスが永続する保証はない
 元も子もない話&杞憂でしょうけれど念のため。アイ・オー・データ社が言っている通りです。
 もっと言うと、サービスが続いていても、「利用者=リッピング人口」が減っていくとチェックサム(コード)の蓄積も減りますから、新譜などはうまく照合できなくなる可能性もないとは言えません。


 以上より、CTDBなら「C2エラー情報取得問題がないドライブで」「データベースにチェックサムがありさえすれば」「HTOA以外は」盤石と言えそうです。
 CTDBが使える≪CUERipper≫なら、≪CUETools≫でエラーを修復できるかもしれませんしね。


 なお、本稿で用いたリッパーのバージョンは以下の通りです。
  ≪EAC V1.3 from 2 September 2016≫
  ≪CUERipper 2.1.6≫
  ≪MusicBee 3.3.7165≫


#本稿は、セキュアリッパーに関する考察記事への追記(19/02/28)を独立させたものです。


メインメニューへ

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

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

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やっぱり便利。


メインメニューへ

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

リッピングエラーをリッピング後に修復する

19/03/01初稿

 いわゆる「セキュアリッパー」も進化してるんですねぇ。
 とあるきっかけで≪CUETools≫の「Repair」なる機能を知って試してみたのですが、こんなことまでできるようになってるんですねぇ。
 ERIは“PureReader”なので(DB照合サービスは使っていないので)長らく気が付きませんでした(苦笑)。


・≪CUETools≫のリペアとは何か
 ≪CUETools≫システムは、「CTDB(*1)」なるCDリッピングに関する独自のDBを持っており、連動するリッパー≪CUERipper≫におけるリッピング時に参照して成否を判定する機能があります(本BLOGではこれを「DB照合サービス」と呼称)。同種サービスとしては≪dBpoweramp≫などが採用している「AccurateRip(*2)」が有名ですよね(本稿では一般名詞ではなく固有名詞(商標かな?)として記述)。

*1:http://cue.tools/wiki/CUETools_Database
*2:http://www.accuraterip.com/

 なお、CTDBもAccurateRipも特定リッパーの専用機能ではありません。実際、≪CUETools≫システムはCTDBだけでなくAccurateRipサービスを併用しています(設定画面を見るとリッピングだけでなくリペアでも?)。

 CTDBはオフセット対応などを強化した仕組みのようです。その中に、なんとエラーを内包してしまったリッピングデータを「リペア(修復)」する機能があります。説明サイトの記述によると、成功したリッピングから照合値(*)以外にも“そのための”データを収集することによって実現しているようです。

180KB recovery record (about twice that for more popular CD's), which is stored separately and accessed only when verifying a broken rip or repairing it.
出典:http://cue.tools/wiki/CUETools_Database

*:リップ結果データのチェックサム的な値ですが、ハッシュ、チェックコード、CRCなどいろいろな呼び方があるので、無難(?)に「照合値」としました。

 おぉ、確かにそういう手もありますね。よく考えるものだなぁと感心しました。
 もしキチンと作動するなら、どうしてもエラーが発生してしまうCDを救済できる場合があるかも知れません。だとしたらものすごく有益な機能ではありませんか。

 ということで試してみました。

・C2エラーしてしまうCDでリペアを試す
 CIRCは十分強力ですが、手元には、PureReadのパーフェクトモードで停止してしまう(C2エラーが発生してしまう=補間発生してしまう)CDが、流石に何枚かあります。大半は傷つけてしまった(傷ついていた中古)ディスクです。
 その中から、ふたつのトラックにC2エラーがあるCD(結果的にエラー数が例として適当だったので選定)で、リペア機能を試してみます。
 ≪CUETools≫は、その名の通りリッピングしたファイルやCUEシートについての編集ツールです。リッピング自体は≪CUERipper≫を用います。

#≪CUERipper≫でリッピングしたファイル以外はリペアできないワケではないかも知れませんが、本稿ではベーシックな使い方としてセットで用います。

 ところで、≪CUERipper≫はBurstモードでもPureReadのリトライリードが発生するとエラーになるようです。ドライブが勝手に何かやってるのを待たないようですね。説明ページによるとドライブから上がってくるC2Error情報を見ているようです。≪EAC≫と同じく16回で1セットのようですが、何セット繰り返すかはエラー次第の模様。
 ということもあり、本稿のドライブはエラー発生具合がちょうどよかったGGC-H20Nを用いました。

 まず、≪CUERipper 2.1.6≫でのリッピング結果ポップアップを示します。

リペア推奨メッセージ

 CTDBと照合すると371個の異なるサンプルがあり、疑わしいセクタ(音楽CDとしてはフレーム)が60個あると言っています。リペアを試みろと推奨されていますね。
 ちなみに、どんなエラーでもリペアできるワケではないのは説明ページにもある通りです。実際、別のもっと酷いエラーが出るCDでは以下のようなポップアップが出ました。

終了ポップアップ(S05Jエラーあり:多すぎてリエア推奨されず)

 リペアの可能性は無いようです。

 さて、「このリッピングはどんな結果だったのか」は、生成される.accuripファイルに記述されています(拡張子はナニですがテキストファイルです)。
 当該CDのCTDBに関する部分を抜粋します(samples後の数字には表示を考慮した改行を入れています)。

Track | CTDB Status
1 | (126/126) Accurately ripped
2 | (126/126) Accurately ripped
3 | (126/126) Accurately ripped
4 | (126/126) Accurately ripped
5 | (125/126) Differs in 261 samples @02:14:23,02:14:48,02:15:10,02:15:23,02:19:35,02:19:48,02:19:60,02:19:73,
02:20:10,02:20:36,02:20:48,02:20:60,02:20:73-02:20:74,02:21:10-02:21:11,
02:21:35-02:21:36,02:21:48-02:21:49,02:21:60,02:21:73,02:22:11,02:22:35,
02:22:48,02:22:60-02:22:61,02:22:73,02:23:10,02:23:23,02:23:60-02:23:61,
02:23:73,02:24:23,02:24:48
6 | (126/126) Accurately ripped
7 | (126/126) Accurately ripped
8 | (126/126) Accurately ripped
9 | (125/126) Differs in 110 samples @04:39:23,04:39:39,04:39:56,04:39:72,04:40:12,04:40:29,04:40:44-04:40:45,
04:40:61,04:41:01-04:41:02,04:52:64,04:53:04-04:53:05,04:53:21,
04:53:37-04:53:38,04:53:53,04:53:70,04:54:11,04:54:27,04:55:49
10 | (126/126) Accurately ripped
11 | (126/126) Accurately ripped
12 | (126/126) Accurately ripped


 AccurateRipと異なり「DBにあるこの値と照合した」といった情報提示はされないようですね。

 さて、このリップ結果ログでは、track05に261サンプル、track09に110サンプルのエラーがあると言っています。パーフェクトモードが停止したトラックではやはり訂正不可能なC2エラーが発生(補間発生)したということです。エラートラックの@の後に記されているのはエラーサンプルを含むMSFでしょう。
 それ以外の10トラックは126個のCTDB参照データ中126個と一致したと言っています(当該CDのCTDBデータは1種類しかなかったようです)。

 では、これをリペアしてみましょう。設定は以下の通りです(もちろんERI的な設定の一例です)。
 対象として指定するのは、リッピング時に生成された.cueファイルです(ちなみに下図のファイル名は“仮名”です)。

CUETools.png

 リペア終了時にはポップアップは出ませんので、結果は新たに生成される.logや.accuripでチェックします。
 .accuripファイルを抜粋します。

CUETools DB: corrected 371 errors.
[AccurateRip ID: 001659a6-00d37568-8c0c640c] found.
Track [ CRC | V2 ] Status
01 [85467f84|713a3dc7] (15+26/41) Accurately ripped
02 [402685d6|2b59a32b] (15+26/41) Accurately ripped
03 [f55fb645|0d043b26] (16+26/42) Accurately ripped
04 [f21b17aa|3c4d9454] (15+26/41) Accurately ripped
05 [fe35de57|a4e1b066] (13+26/39) Accurately ripped
06 [017e1bff|bc4b58a4] (15+26/41) Accurately ripped
07 [697fcfa6|c8c8c169] (15+26/41) Accurately ripped
08 [b9d56f16|180b8805] (16+26/42) Accurately ripped
09 [9426dd9a|a67daa25] (15+26/41) Accurately ripped
10 [9f533049|accab39f] (15+26/41) Accurately ripped
11 [38ab9001|710a127b] (15+26/41) Accurately ripped
12 [b19d08a5|c9d3bf43] (15+26/41) Accurately ripped


#ちなみに、説明ページ(*)によると
  CRC=AccurateRip V1の照合値
  V2=AcccurateRip V2の照合値
  例えば(15+26/41)の15=V1とのマッチ数
  同26=V2とのマッチ数
  同41=ARのDBにある当該CD情報の総数
とのこと。

*:http://cue.tools/wiki/CUETools_log

 CTDBとしての結果は最初の1行だけでそっけないですが、371個のエラーをcorrection(訂正)したと言っています。371個は261+110ですね。実際、track05とtrack09を≪WaveComparer 1.32≫で比較すると、リペア前後のファイルでそれぞれ261、110サンプルの相違となりました。
 そして、以下に併用しているAccurateRipとの照合結果が続いてます。エラートラック2個もCRC値やV2値と一致しており、正常にリッピングした状態に“リペア”されたということです。

・リペアされたことを“裏取り”する
 しかし、上記の結果は「リペア前後で371個のサンプルが変化した」ことを示してはいますが、“正しい値”に変化したかどうかは判りません。≪CUETools≫だけで完結している状態だからです。≪CUETools≫を疑うワケではありませんが、客観的に納得するためには、正しい値に修復されていることを何か“別手段で裏取り”したいところです。

 ここに「エラーありディスク(PureReadパーフェクトモード停止)」と「エラーなしディスク(同完走)」を持っているタイトルがあります。エラー発生状況が相応しくないので、上記例としては用いていませんが、「エラー入りファイルをリペアしたファイル」と「エラーなしファイル」の比較が一致すれば本当にリペアできたかの証左になるでしょう。

 結果、エラーが発生してしまうtrack01の≪WaveCompare 1.32≫での比較は見事に一致。

 一例だけですので万全かどうかは解りませんし、もちろん万能ではないでしょうけれど、拭いたりなめしたりしても常用環境ではどうしてもエラーが消えないディスクがあったら、当該機能を用いて“一旦リッピングした後に”リペアしてみる価値は十分ありそうです。

 いやぁ、感服しました。

・メモ
 ≪CUERipper≫の「Read Offset」設定(正確にはオフセット値ではなくその補正値)は、ドライブを認識して自動設定してくれることになっていますが、手動で変更できてしまう模様。なのでヘタにいじるとAccurareRip照会結果は混乱します。
 CTDBはディスクオフセットからもドライブオフセットからも影響を受けないみたいです(だから補正にあまり関心がなく、故に固定していない?)。トラック単位のリッピングはできずCD単位になる点など、照会や修復用のデータをディスク全体として見ているところにミソがありそうです。

 参考までに、エラーがなかった場合の終了時ポップアップを示しておきます。

終了ポップアップ(エラーなし)


メインメニューへ

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

BDディスクの覚え書き

18/07/23初稿


■ディスク相性問題

 本項14/12/07初出。
 18/07/23、AACS:BDAV編から移動しました。

 BDZ-AT700と同時に購入した5枚組Verbatim(三菱化学)製BD-RE DL、AT700と相性問題? があるようです。
 購入当時、27GBくらいのタイトルを書き込み、とある事情でムーブバックしてさらに書き戻したら2層目がエラーで読めなくなりました(途中停止してハングしたようになる)。

 人生最初の25GB超タイトルのディスク処理であえなく玉砕(苦笑)。もちろんおろしたてメディアでした。

 何度か同じような確認を行って問題出なかったので“たまたま”なのか、またはファームが対応できてなかったのかなと思い2枚目以降はおっかなびっくりながら使ってました。
 といってもHDD容量削減のための一時的待避が主目的ですので、昨日、そろそろ1層メディアに保存しなおす作業しようかと思い立ち、ムーブバックしようとしたらエラーで停止してしまいました。何事もなかったように終了(HDDには何もなくディスクから削除はされていない)していて、最初は何が起きたか判りませんでした。最初の1枚は封印してましたので、それ以外の3枚で、です。ちなみに特筆するような回数の繰り返し使用はしていません。

 2枚目は複数タイトル記録していたのですが、全選択ムーブバックは新しい順に行われるようで、エラーした時点で終了しちゃうようです。問題タイトルを選択しなければムーブバックできました。
 3枚目と4枚目は25GB超のワンタイトルです。3枚目はPCで再生しようとしても半ハングのような状態になりましたが、4枚目は映像が乱れて再生されました。発生するのはバイト読みで22GBあたりですので、明らかに2層目への切り替わりポイント周辺です。

 どうしてくれようかと悩みましたが、試しに別のAT700でムーブバックしてみたところ、3枚目はやっぱりダメでしたが4枚目は成功しました。ならばと3枚目もやり直してみたら、2回目で成功。あきらめなくてよかった(笑)。
 3枚目は、PCでもBDR-S05Jだと映像止まるほどでしたがSW-5583だと乱れはするものの再生可能でしたので、ドライブ性能差や同じドライブでも“暖まり具合”などによって読み取り能力は変動するようです。

 試しに複数タイトルを記録している5枚目もムーブバックしてみましたが、やっぱり層切り替えを含むであろう位置にあるタイトルで失敗しました。リトライ5回目くらいで読めましたが… CDのリッピングかよ!(苦笑)

 多層メディアやっぱアブナイなぁ… レコーダとメディアどっちの問題なのか、どっちも問題なくて相性的なハナシなのかは解りませんが。
 BD-RE DLはPanasonic製しか流通していないと勘違いしていてVerbatimブランドを買っちゃったんですけど、ID読んでみたらVerbatim製でした。
 層切り替えのあたりに敢えてダミータイトルを記録して使う… なんてメンドクサイですよね(笑)。

 さて、ということもありXLには手を出していなかったのですが、この経験で、ふと「1層33GBの大容量メディア」と見なせるのでは? と思い付きました。33GB超の“連続再生しないと価値がないコンテンツ”を録画することはあまりないでしょうから(WOWOWの映画などでも30GBくらいかと)、たまにある25GB超・33GB以下のコンテンツ録画用に使うっていうのはアリかも知れません。
 まあ、素直にDR諦めてAVCモード使えばいいんでしょうけれど。

 19/03/06追記:1層だけなら使えるかと思い、BDZ-AT700でフォーマットして複数コンテンツを23GB分くらい焼いてみたのですが、後ろの方のコンテンツは再生できませんでした。


■ディスク容量

 本項15/01/11AACS記事に初出。その後BDZ-EW1200記事に移動しました。
 さらに18/07/23、BDZ-EW1200記事から移動しました。

 思うところあって初めてBD-R購入しました。BD-RとBD-REって容量同じなんでしょうか?
 Panasonic日本製BD-R(上)とSONY多賀城製BD-RE(下)、まずはまっさらの新品ブランクディスク。
 Power2Go V6にて。

BD-Rブランク:P2G

BD-REブランク:P2G

 続いてAT700 2号機でフォーマット直後。

BD-R:P2G

BD-RE:P2G

 Windows8.1update1のエクスプローラで見ると…

BD-R:AT701

BD-RE:AT701

 BD-Rにフォーマットで作られたフォルダは見えますので、UDF2.6は書けないけれど読めはするんですね。
 V9でフォーマットしたBD-REもエクスプローラでは同じ容量でした。BD-Rもたぶん機種依存性はないのではないかと。

 BD-Rはマルチトラックになるんですね。知らなかった… レコーダにおける管理上の理由(ライトワンスの容量管理?)らしいですが、エクスプローラから見える容量が異なってるのはそのためでしょうか。機種やメーカによって管理方法が異なるなら容量も統一されてないかも知れませんね。

 ディスク総容量はおそらく同じっぽい気がしますが、マルチトラックになる分だけBD-Rの方がやや小さくなるのかも知れません。

 16/05/07追記:ちなみにBD-RE DL(Verbatim製)のフォーマット状態(コンテンツなし)です。

BD-RE DL:P2G

 容量は1層の23097.8MBに対し46195.8MBと表示されました。2倍ちょっと、ですね。


メインメニューへ

テーマ : デジタル家電・AV機器
ジャンル : 趣味・実用

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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

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