FC2ブログ

リッピングにおけるオフセット理解のギャップを埋める

13/11/30初稿

 本来、もっと早く理解しておかねばならなかったことですよね。いまさら感満載ですが(苦笑)。
 リッピング条件とエラーについて考察した記事にちまちま追記していたのですが、本件は「エラーとは無関係(エラー起きていない前提)」ということもあり独立記事にしました。


■はじめに

 CDからリッピングされたデータは「普通のファイルコンペアではバイナリ一致するとは限らない」のはもはや常識かと思います。リッピングに使ったドライブやソフト(*)によって先頭と末尾の状態が異なるためです。
 ちなみに一致することもあります。ていうか
  読み取りエラーがなくて
  オフセット差がなくて
  余計なヘッダフッタが付いていない
WAVファイルは普通のファイルコンペアでも一致するハズです。

*:ソフトの影響については特殊事例のようです。後述。

 しかし、先頭末尾のデータが異なるのは何故か、ずっと疑問でした。0000h=正真正銘のゼロだけなら疑問はないのですが、バイナリを覗くと0000hではなく0001hやFFFFh(-1)など、“ゼロ近傍”も出現しているためです。いくらドライブやソフトに依存するとは言え、デジタルシステムにおいて「読み出し値がゼロ近傍のランダムな値になる」とは思えず。何らかのズレによって読んでない(読めない)なら潔くゼロでいいじゃん、と。

 それについて調べた結果得られた結論は次の通りです。

「CD-DAリッピング時のサンプル読み出し位置はドライブによって異なる。オフセットと呼ばれる。オフセット値が異なるドライブでWAVファイル化すると、その差のぶん、サンプル位置が異なる。また、同じタイトルでもロット違いでオフセットが違ったり、リッピングソフトの読み方によっても異なることがある」

 “CD-R焼き”では常識だと思いますが、“CD読み”としては補間エラーに注視して本件は後回しにしてまして。
 結論だけ見るとえらくシンプルですが、結論に至るためには、トラック単位ではどうなっているのかといった色々細かい事情について体系的に理解する必要がありました。以下、それを順次記していきます。


 といっても、そのためにまずは「音楽CD(CD-DA)のしくみ」について知っておく必要があります。ERI的に調べた記事を前提に記します。


■ズレの正体:ドライブオフセット編

 ドライブには「オフセット」があります。ドライブごとにその値は違い、0~数百サンプル分、読み出しが実際のディスク上の位置より早かったり遅かったりするものです。

・オフセットとリッピングの関係
 上記リンク先のCD-DA構造をベースに、リッピングがどう行われているかを図示してみます。プリギャップの行き先は前トラック末尾とし、各プリギャップは100サンプル分以上ある場合として説明しています(1フレームは588サンプルですので普通はありますが)。
 なお、リッピングにおいてトラックのつなぎ目にサンプルの欠落や増加はない前提です。

CD-DA構造とオフセット(改訂)

・オフセット0を理想リッピングとした時の+100と-100の状態
  A・・・トラック01の先頭音声データが100サンプル分欠落する
  B・・・トラック02の先頭音声データ100サンプル分が
     track02先頭ではなくtrack01末尾に付加される
  C・・・トラック03の先頭音声データ100サンプル分が
     track03先頭ではなくtrack02末尾に付加される
  D・・・リードアウト領域の先頭データ100サンプル分が
     track03末尾に付加される
     (リードアウトが読めないドライブの場合どうなるかはヨクワカリマセン)
  a・・・トラック01のINDEX00領域の末尾データ100サンプル分が
     track01の先頭に付加される
     (当該領域が読めないドライブの場合どうなるかはヨクワカリマセン)
  b・・・プリギャップ02末尾の100サンプル分が
     track01末尾ではなくtrack02先頭に付加される
  c・・・プリギャップ03末尾の100サンプル分が
     track02末尾ではなくtrack03先頭に付加される
  d・・・track03の末尾音声データが100サンプル分欠落する

・ファイル再生する時の影響
  A・・・先頭トラックのみの問題。純粋に音声サンプル欠損
  a・・・track01(先頭トラック)の先頭で余計なデータが再生されるが、
     通常ゼロデータ(のハズ)
  B,b,C,c・・・CDの連続再生よろしく連続再生する場合には全く問題ない
     プレイリスト再生や頭出しの際に影響が出るが、プリギャップ末尾や
     トラック先頭なので無音(に近いレベル)が大半であろうから、
     実視聴では問題にならない
     そもそもこの領域に音声がある楽曲はプレイリスト再生や頭出し再生に
     不向きであろう
     プリギャップがない場合、bとcは前トラック末尾が次トラック先頭に
     付加されることになるため、前の末尾が付加されたtrackを前trackから
     続けて再生しない場合は違和感が出る可能性アリ
     (例えば後述するNORDOSTのCDで頭出し再生すると冒頭にノイズが出る)
  D・・・track03(最終トラック)の末尾で余計なデータが再生されるが、
     通常ゼロデータ(のハズ)
  d・・・最終トラックのみの問題
     純粋に音声サンプル欠損だが、末尾はポストギャップやフェードアウトや
     曲の余韻

 ドライブ違いによるオフセット差により、リッピングしたファイルの先頭末尾が異なってしまうことが解ると思います。ただし、いずれも実際には聴き取れないであろう微少時間です(仮にオフセット1000でも0.02秒分)。
 一番“ヤなカンジ”なのを強いて挙げればAでしょうか。ということもあるので、ほとんどのドライブのオフセットはマイナスなのかも知れませんね。
 ちなみに≪EAC≫の「read sample offset correction」の値はその名の通り“補正値”なので、読み出しが-100サンプル分早いドライブの値は「+100」となります。

・ドライブオフセットによるズレの実例
 まず、リッピングされたサンプル総数について確認しておきます。曲の長さはTOCに記録されているためどんなリッピングでもマトモに行えば“サンプル総数”が変わることはないハズです。ていうか実際同じですね(昔は違うこともあったかなぁ…)。
 さて、あるCDのトラック1リッピングにおいて「LITEON製iHES208+iTunes6」に対し「Panasonic製SW-5582+iTunes6」では、後者が96サンプル分後ズレしてました(その分先頭のゼロサンプルが増えており末尾が切れている)。
 この値がオフセット差分のハズです。オフセット補正値はAccurateRipのDB(*)によると、208は+6、5582は+102なので差分はズバリ96サンプルとなりツジツマが合います(30サンプルズレ問題はすべてのドライブに一律なので差分としては無視してOK)。

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

 ≪dBpoweramp≫のオフセット検出結果でもそれぞれ+6と+102でした(現環境では何故か≪EAC≫はiHES208を認識しないので≪dBpoweramp≫で追試)。

*:14/01/05追記:Windows8.1にしたら今度はS05Jを認識しなくなりました。NEOのwnaspi.dllを入れて外部ASPIを使う設定にしたらiHESと両方認識しました。

 なお、前述した通りリッピングによるトラック間のデータ欠損や増加はありませんので、このズレは上記図の通りCDすべてのトラックのリッピング結果に波及します。

・オフセットズレは物理的に同じドライブならずっと同じだよね?
 ドライブごとにオフセットは一定です。つまり、設計上固定できるということでしょう(それが「Accurate Stream」かな?)。
 なら、オフセットを敢えて設けている(または敢えて放置している)ということになります。逆に言うと、設計上そうなっているなら、EACがQ&Aで言っている通り、同型番のドライブでもファームウェア変更で変更される可能性はないとは言えないでしょう。

 はてな~

 Pioneerさん、ドライブユーティリティに「ドライブオフセット設定機能」とか付けたらウケると思いますよ~

・オフセットズレはリッパーによって変わらないよね?
 オフセット値はドライブによって決まっており、リッパーが違っても変わらないハズです。ただし、オフセットは変わりませんがプリギャップに関するリッパー動作違いで読む位置が異なる場合があります。詳細は後述。
 一応、BDR-S05Jと以下のリッパーの組み合わせであるトラックをリッピングした結果を比較してみたところ、後述するリッパー動作によるズレ(誤動作?)を考慮すれば「先頭末尾のゼロサンプル数」「総サンプル数」はすべて一致しました。

 ≪iTunes 11≫,≪EAC≫,≪dBpoweramp≫,≪Power2Go≫,≪WMP 12≫,≪CD2WAV≫


■ズレの正体:ディスクオフセット編

 同タイトルでもプレス違い(?)でディスク自体のデータ位置が異なっている場合があります。
 具体例を「補間値が平均値になる記事」に記しています。

To complicate matters further, audio CDs have built in pressing offsets, that is, audio CDs are manufactured in batches, or pressings. At a later time when a new batch of CDs are created, they are written with a different offset (in relation to earlier CDs), although the CD appears (from its table of contents, or track indexes) as identical to previous pressings.
出典:http://www.cd-ripper.com/

Different pressings of the same CD
出典:http://cue.tools/wiki/CUETools_Database

It has to be the same pressing like I used, as different pressings usually uses a different offset.
出典:http://www.exactaudiocopy.de/en/index.php/category/faq/offset-questions/


■ズレの正体:リッパーによるドライブオフセット補正編

・オフセット補正
 ドライブのオフセットは、次のような理由で補正が必要な場合があります。

a.ディスクとして、限りなく元CDに近い複製CDを作成したい
b.リッピング時にDB照合サービスを利用したい

 ですので、「ドライブオフセット補正機能」を有するリッパーの場合、同じドライブ同じリッパーを使っても当該機能のON/OFFや設定する補正値の違いで先頭末尾の状態は変わります。

 15トラックあるCDのまるごとリッピングにおいて、オフセット補正による差を示します。

mergeAccuimg compare

 補正オンした場合、≪EAC≫が自動認識するBDR-S05Jのオフセット補正値は+667ですので、≪EAC≫は≪iTunes≫(補正なし)に比して読み始めを667サンプル遅らせています(そこがオフセットゼロ位置のつもりということです)。その分先頭のサンプルは≪iTunes≫読みより減っており、末尾は増えています。総サンプル数は同じなので。
 「オフセットがマイナスの時補正値はプラスの値。補正結果先頭のサンプルが減る。つまり補正値がプラスだとファイルの中のサンプル位置は先頭方向にズレる」ということなので、感覚的にはちょっとワカリニクイですよね。

 常用するリッパーを選ぶ際にはこのあたりの事情も確認した方がいいかも知れません。

・ドライブのオフセット値は気にするべきか
 ところで、オフセットがあっても、その値がどうでも、ファイルの先頭末尾の微小時間の状態が異なるだけです。よって、原則として「オフセット補正した方が音質がよいWAVファイルができる」といったことはありません。

(1)オフセットがマイナスのドライブ
 トラック01先頭の取りこぼしはありません。
 マイナスで余計に読むトラック1のINDEX00期間は普通はゼロのようです。
 最終トラックの末尾は欠落しますが聴きとれる時間ではありません。

(2)オフセットがプラスのドライブ
 最終トラック末尾の取りこぼしはありません。
 プラスで余計に読むリードアウトは普通はゼロのようです。
 トラック01の先頭は欠落しますが聴きとれる時間ではありません。

#ですので、余談ですが「補正値が+30多すぎるのでは問題」も音質には関係ありません。一律に30ズレているのなら上記aとしては問題かも知れませんがbとしては問題ないということです。よって本稿では触れません。

 プラスでもマイナスでもトラック間の切れ目がオフセット分ズレますが、CD収録順通り聴いている限り全く問題ありません。ライブで連続するトラックをCD収録順ではなくプレイリスト再生するような場合は差が生じるリクツですが、事実上問題にならないでしょう。
 ということで、個人的には、ドライブ選択条件としてはほぼ無視していいと判断しています。どれでもいい場合はオフセット量が少ない方が気分的にはいいかも知れませんが、プラスオフセットだとトラック1の“先頭サンプル”取りこぼしになりますので気分的には気になるかも知れません。
 なお、余談ですが、オフセット補正が必要な「DB照合サービス」を利用する場合は、オフセット補正値が判明しているドライブを選択する必要があります。


■ズレの正体:オフセット補正以外のソフトウェア編

・プリギャップ処理
 もはや言わずもがなですが、前述した通りプリギャップを前後どちらのトラックにくっつけるか、はたまた除去するか、といったリッパー動作の違いでもズレます。

・トラック01のINDEX00期間処理
 特殊な事例かとは思いますが。
 トラック01のINDEX00期間はCD再生やリッピングにおいてアクセスされません。普通のCDではジャスト2秒設けられているようで、CUEシートなどでは必ず2秒マイナスされ、その結果が“見立てINDEX00期間”となるようです。通常はゼロとなるので当該INDEX00期間は存在しないように見えます。2秒以上あった場合に、「2秒以上の分」が見立てINDEX00期間として扱われるようです。
 この“慣例”に引っかかるアプリ(ドライブ?)がある? 例えば、INDEX00期間が00m02s37f分あるCDがあるのですが(以下≪EAC≫で生成したCUEシート参照)、5582+CarryOnMusic10でのリップは5582+iTunes6に比して先頭に21,756個ゼロサンプルが多くなっていました。588で割るとズバリ37フレーム分。

REM COMMENT "ExactAudioCopy v1.0b3"
PERFORMER "Unknown Artist"
TITLE "Unknown Title"
FILE "Range.wav" WAVE
  TRACK 01 AUDIO
   TITLE "Track01"
   PERFORMER "Unknown Artist"
   INDEX 00 00:00:00
   INDEX 01 00:00:37  ←ココ
  TRACK 02 AUDIO
   TITLE "Track02"
   PERFORMER "Unknown Artist"
   INDEX 00 04:21:58
   INDEX 01 04:22:10
  TRACK 03 AUDIO
    ・
    ・


 この分ズレていることになります。
 CDプレーヤで再生する時はINDEX01からスタートするハズなので、37フレーム分をファイル先頭に含める必要はないでしょう。有意な音声情報があるかも知れないことを考慮したのかも知れませんが、サンプル総数(演奏時間)はTOCなどの情報通りで増えていないため、21,756サンプル分“尻切れ”になっています(track02以降もズレたままです)。ので、“引っかかっている”ように思えますね。どうも「トラック01のINDEX00期間は絶対2秒(150フレーム)」と決めちゃっているようです(LBAはAMSF-150と決まっているようなので、LBAだけで判断したため?)。
 ちなみに≪WMP 12≫も同様のリップする模様です。

 このタイトルは、≪EAC Ver1.3 from 2 September 2016≫でDetectGaps(Method A/Secure)すると以下のようになります(ドライブオフセット補正有無で変わらず)。

EAC GapDetect beforeーafter

 ちなみに、StartとLengthはDetect前後で変わってませんし≪CD Manipulator≫のTOC情報(サブチャンネル解析せず)も全く同じ値になりましたので、TOCに入ってるトラック開始時間情報でしょう。実際、track01はtrack02との差分04m21s48f分リップされました。

・サブチャンネル解析
 しかし、≪CD Manipurator≫のサブチャンネル解析(セクタサーチ:最高速)をかけると、以下のように数値が変化しました(後日もう一度やっても同じ)。≪CD Manipulator≫はINDEX00から2秒マイナスせずに表示します。

CDMのTOC解析(セクタサーチ)

 track01の長さが04m21s20fに。≪EAC≫ではtrack01の長さは04m21m48f分、track02との間に00m00s27f分のプリギャップがあると言ってますのでプリギャップを除いてみても04m21s21f分ですから1フレーム少なくなっています。その分track02の開始位置は1フレーム早くなっています。他にも差異があるトラックがあります。
 サブチャンネル解析する場合はいろいろ事情がありそうです。INDEX00の先頭フレームがリードエラーしている場合の処理とか?
 音楽CDの規格としては「わざわざサブコード読んでリアルINDEX位置を探りにくる」のは想定外だと思いますので、≪CD Manipulator≫に限らず同様機能は覚悟して使った方がよいのかも知れません。

 なお、もう1枚持っているエラー入り盤の方は、≪CDManipurator≫のサブチャンネル解析は以下のような結果に(すべて最高速度)。いずれも時間表示はコマ落ちのようになってました。
  ・セクタサーチ:終了したのですがトラックが1個しかないような結果に
  ・等倍追跡:成功
  ・2倍追跡(高速):「解析できず」と出ました

 ≪EAC≫のDetectGapsや≪CUERipper≫では可能でした。

 このあたり、PureReadオフのBDR-S09Jにて。


■ズレを想定したコンペアソフトでも一致しないことがあるワケ

 これまで見てきたのは「ズレ」です。これに影響されず比較してくれるのが≪WaveCompare≫という素晴らしいソフトなのですが、どうも、エラーは発生していないにも関わらず一致しないことがあるようです。
 それは何故でしょう?

・無音プリギャップがないCDをオフセット値が異なるドライブで読んだ場合
 トラックの間は有意な音声サンプルで繋がっています。その切れ目がオフセット差分ズレちゃうと、先頭にゼロサンプルがない状態でズレますので頭っから相違になるでしょう。
 トラックの先頭や末尾がゼロではなく、プリギャップがない場合にも同様に結果になるでしょう。

・プリギャップ部が0000hでない場合
 あるトラック(*)をリップしたら、サンプル先頭はFFFFhで始まって途中から0000hやFFFEhなどが散見されるファイルになりました(オフセット問題に関連するかも知れませんが、補正しても0000hからの開始にはなりませんでした。+30サンプルを考慮してもしなくてもです)。

*:上記「トラック01のINDEX00が00m02s37fのCD」のトラック02ですが、たまたま見つけた一例として、です。

0000じゃないプリギャップ

 アドレスを見ていただくと解りますが、かなりの数のサンプルが先頭からずっとFFFFhです。

#当トラック02の前には27フレームのプリギャップがありますので、マイナスオフセット667のドライブでそこを読んでいることになります。

 このようなトラックは、先の「トラック01のINDEX00期間に引っかかる」「オフセット補正の有無」などによって全体のズレ方が異なるリップしたファイルでは、先頭(末尾)の違いが「0000hの数」だけではなくなります。
 プリギャップにMCが入ってる場合などもこうなりますね。

 ≪WaveCompare≫は、こういう場合でも一致点を探してくれてきちんとコンペアできることが多いのですが、見つからない場合もあるようです。
 実際、当トラック02は「一致点が見つからない」ようです。「ゼロサンプルなし」と認識して先頭から(またはどこか適切と判断したところから)比較を開始するでしょうから、当然すぐにサンプル相違にぶつかってしまいます(上記の例だとFFFFh以外が出現したところから相違)。ズレは途中で解消されませんから、ファイルの最後まで全部相違となってしまいます。

 実際にやってみます。当トラックを含むタイトルは物理的CDとしてディスクオフセットが異なる傷あり(トラック02はエラーなし)と傷なしの2枚持っています。
 そこで、通常読み2種に≪EAC≫のオフセット補正を用いて傷なしのディスクオフセットを吸収(+101補正)して読んだファイルを加えた3種でWAVEコンペアしてみます。

  ・「傷なし補正あり」VS「傷あり」・・・一致
  ・「傷なし補正なし」VS「傷あり」・・・延々と相違
  ・「傷なし補正あり」VS「傷なし補正なし」・・・延々と相違

 原則「一致点を探す:200」で行っていますが、数値を大胆に変更しても一致しないようです。
 しかし、「音楽データの相違」と見なす状態ではありません。ズレてるだけなので。

 「一致点を探す」も万能ではないことを示しているワケですので頼り切りにならず(笑)、先頭から連続して延々相違になる場合はリッピングエラーによる相違ではない可能性を検討した方がよいでしょう。

#FFFFh(-1)がずっと連続している状態はバイアス成分であり音声データとは言えませんから、本来あってはならない状態であることを付記しておきます。

・ちなみにオフセットズレとギャップ領域とサンプルの見え方
 オフセット値が異なるドライブでリッピングしたファイルの先頭や末尾のバイナリを比べた場合、どうみえるでしょうか。
 リッピングとオフセット図をご参照ください(オフセットズレはプリギャップを超えない前提で記します)。

 まず先頭について。
 例えば先読みするドライブだと、先頭にプリギャップのおしりがくっつくでしょう。逆に遅延読みするドライブだとトラックの冒頭が切れます。
 次に末尾について。
 例えば先読みするドライブだと、末尾にくっついている次トラックのプリギャップの最後が切れるでしょう。逆に遅延読みするドライブだと、次トラックの冒頭がくっつきます。

 プリギャップやトラック冒頭末尾データ値がゼロの場合。
 音声データとして「ゼロ」から始まって「ゼロ」やで終わる曲は珍しくないでしょうから、先頭末尾のゼロサンプルはどこまでが「ズレなどによって付加されたもの(例:先読みでプリギャップのおしりがくっついている)」なのか「元々の音声データ」なのかをパッと見で判別するのは困難でしょう。ドライブの正確なオフセット値をさっぴいて考える必要がありますね。
 プリギャップやトラック冒頭末尾データ値がゼロではない場合。
 先頭末尾部分の状態は全く異なって見えるでしょう。

 WAVコンペアソフトの結果解釈(相違点がごっそり出てもエラーによるものとは限らない)やバイナリエディタでの観察では、これらの点を加味する必要があると思われます。

・WAVコンペアでズレてないのにファイルコンペアで一致しない
 WAVコンペアで以下がすべて一致するのに、ファイルコンペアソフトで一致しない場合があります。
   比較結果
   サンプル総数
   先頭ゼロサンプル数
   末尾ゼロサンプル数
 サンプル数が同じでエラーもなくズレてもいないのですから、ファイルコンペアソフトでも一致しそうに思えます。

 これは、リッパーによってヘッダやフッタが付加されたのが原因であることが大半ではないかと思います。
 もちろんこの場合は「ファイル容量」が異なりますのですぐ判ります。


■おまけ

・プリギャップ情報=INDEX情報を取得する方法
 とりあえず≪EAC≫でCUEシートを作成するのがお手軽でしょうか。

EACdeCUE.png

 「Single WAV File」で作成するのがミソ。CD全曲をひとつのWAVファイルとして扱う場合のCUEシートなので、INDEX情報がCDと同じ状態で取得できる(ハズ。このあたりも一筋縄ではいかない事情がありそう)。

・オフセット確認?
 例えば「プリギャップがゼロサンプルでトラックの先頭からいきなり音声」みたいな“INDEX01位置がサンプルとして明確に判るCD”があれば何か判るかもしれないと思ってちょっと探してみたところ、目的そのまんまじゃないのですがヘンテコなCD見つけちゃいました。「ノードスト システムチューニング&セットアップ用ディスクNordost TD1(ノードスト)」です。

 まず、≪EAC≫でCUEシートを抽出したところINDEX00がひとつもありません。つまりプリギャップが存在しません(19/09/29:BDR-S09JでDetectGapsしてみてもGapはありません。Start、Length共TOCとの齟齬はありません)。
 そして、ノイズトラックなどではトラックの最後までノイズデータです。
 ということでトラック切れ目がサンプルとして判るかもと思ったのですが、リッピングすると前トラック末尾のサンプルが次トラック先頭にくっついています。これがオフセットの正体かとも思いましたが、オフセット補正しても数百サンプルが残ります。
 なんだかINDEX01の位置が本来のトラック先頭からズレてるような気が… このCDは曲間を意味するであろう連続ゼロサンプルがなく、トラック間はゼロ周辺やノイズっぽいデータで繋がっています(ポストギャップも存在しない?)。ですので“ここがINDEX01だろう”という位置も想定できないため、なんとも言えませんが。
 もし商用CDでもそういうことがあるのなら、やっぱりオフセットは素人には扱えそうにないですね。

・プリギャップありのCDをつくる
 ≪WMP 12≫の書き込み設定「トラック間のギャップなしでCDを書き込む」のチェックをハズすと、約2秒のプリギャップありCDが作れます。もちろん書き込むファイルにプラスして、です。
 OS標準ソフトで明示的に長めのプリギャップがあるCDを作れるので、何かの実験に使えるかも。


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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

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