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≫


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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

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