FC2ブログ

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

13/11/30初稿

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


■はじめに

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

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

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

 現時点では概ね次のように理解しています。ただ、難しいので間違いある可能性大です。ご了承ください。

 結論から記します。

「CD-DAリッピング時のサンプル読み出し位置はドライブごとに異なる。オフセットと呼ばれる。WAVファイル化した時、ドライブごとのオフセット差の分サンプル位置が異なる。リッピングソフトの読み方によっても異なることがある」

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


 JIS規格「JIS-S8605 コンパクトディスクディジタルオーディオシステム」およびCD開発者の著作「図解コンパクトディスク読本」の情報を優先的に利用しています(JIS-S8605は廃止されていますが規格に変更はないでしょう)。


■CD-DAの構造

 さて、上記結論はCD全体のハナシです。トラック間には“ギャップ”が存在します。それをどうリッピングしているのかも気になるところです。そのため、まず予備知識として、ERI的に調べたCD-DA構造を図示させていただきます。

CD-DA構造(改訂)

・TOCは「Table Of Contents」のことです。

・フレームはCD-DAが扱うデータの単位です。CD-ROMが登場して以後はセクタと呼ばれることもありますが、以下に記す通り再生時間のカウントで使われているのはフレームですので、CD-DAにおいてはフレームでよいでしょう。
 フレームは1秒間に75あります(588ステレオサンプル/フレーム)。ですので、上図150フレームは2秒になります。無音領域のハズです。

・フレームの位置はMSFで示されます。「Minute,Second,Frame」のことです。MSFはトラック1のINDEX00期間の先頭(リードインの直後)が起点です。INDEX01ではありません。

・各フレームには以下の情報が入っています。
  ・トラック番号
  ・INDEX番号
  ・トラック先頭からのMSF
  ・CD先頭からのMSF

・フレーム位置としてLBA(Logical Block Address)が用いられることもありますが、「フレームとセクタ」と同じく、CD-DAではMSFだけ意識しておけばよく、LBAは無視していいと判断しています。
 ちなみに、LBAはトラック1のINDEX01期間の先頭を起点とするようです。ですので、MSFとはトラック1のINDEX00期間分ズレます。

・INDEX00期間はそのトラックのデータですが、トラックの再生開始(CDプレーヤでの頭出しなど)はINDEX01からです。

・INDEXは99までトラック内に設定できます。かつてはCDプレーヤで「インデックスサーチ」として利用されていたこともありますが、現在ではINDEX02以降を持つCDはほとんどないでしょう(クラシック再販盤などではまだ残っている模様)。いずれにしても、リッピング&ファイル再生においては無視してよいでしょう。

・リードアウトは音声トラック(90秒らしい)として扱われており、そのトラックナンバは「AA(10進数だと170)」です。リードインは「00」です。ちなみに「Lead」であって「Read」ではありません。

・オフセット・ギャップ理解のコツ:「INDEX」の意味を切り分ける
 “インデックス=索引”的に捉えると、例えばトラックの先頭位置を示す“点”のように思ってしまいますが、CDの規格としては上述したような意味になっていますので、“期間”と捉えた方が解りやすいのではないかと思っています。
 CUEシートに記載されるINDEXは“点”のイメージですが、あくまでも「CD焼き」「イメージファイルの再生」などの際にトラック位置を知るためのものと考えた方がよいでしょう。
 ということで、本稿の「INDEX」はCUEシート的なものではなくCD規格的なものとして記述します。

・オフセット・ギャップ理解のコツ:「ギャップ」を断絶的に捉えない
 詳しくはのちに取り上げますが、「ギャップ」という名称についてちょっとだけ。
 「ギャップ」と呼ばれてはいますが、INDEX00を設けた場合のINDEX00~INDEX01間(普通にサンプルがある)を指し、CD規格では「ポーズ(休止)」と呼ばれています。つまり、「裂け目」「隙間」「断絶」といった状態ではありません。名称のイメージに惑わされないようにした方がよいでしょう。
 これは、オーサリング時に曲間の「隙間」を示す用語として使われていた「ギャップ」をリッピング用語に転用した結果ではないでしょうか。とはいえ既に馴染んでしまっていますし、「ポーズ」というと止まってるみたいで違和感ありますから、本項も「ギャップ」で記述します。
 ということで、本稿の「ギャップ」はCUEシートの「PREGAP」「POSTGAP」コマンド的なものではなくCD規格的なものとして記述します。

・プリギャップ
 トラック毎に設定されているINDEX情報によって制御される“曲開始前の待ち時間”です。CD再生においてはINDEX01が曲開始タイミングですが、INDEX00をINDEX01より前に設定することで、その差分を“曲間”とするものです。
 「曲間無音部」として利用するのが普通ですのでゼロサンプルが記録されていることが大半ですが、CD規格の「ポーズ」としてはゼロ必須ではないので、MCが入ってるケースがあるようです。有意な音声ではないのに0000hじゃない場合もあるようですし。
 トラック1には2秒以上付けることになっていますが、トラック2以降は付けるか否かは任意です。というような特殊事情があるので(詳細は後述)、本稿ではトラック1のINDEX00期間は「プリギャップ」とは呼ばないことにしています。

・ポストギャップ
 プリギャップと異なりCD作成プロセスでのハナシです。CDになった時点でポストギャップは音声トラックの最後の部分となる模様。つまり、リッピングしたWAVデータとしては末尾のゼロサンプルに相当します。プリギャップと異なり“リッピング時に付加されたものではなく普通に音声データとして読み出される”と理解してよさそう。ていうかリッピング時には存在しない概念ですね。
 なお、通常はゼロサンプルだと思いますがトラック末尾が“ゼロ近傍”なCDもあります。と言ってもそれが元ポストギャップなのか否かは判断しようがありません。

・リッパーはトラック間をどう読んでいるか
 さて、構造は一応解りました。では、リッパーはトラック間をどう読んでいるのでしょうか。プリギャップも含め、サンプルの欠損やダブリなどはないのでしょうか。
 昔、次のような考察したことがあります。

====
 CarryOnMusic10+5582とS05Jという2種類の環境にて、あるCDの1曲目と2曲目を連続リッピングして≪WaveCompare≫で1曲目の末尾と2曲目の先頭のゼロサンプル数確認し、それを足してみます。
 すると、末尾と先頭のサンプル数は異なりますが両環境で合計値は一致しました。
 このことから、トラック間のゼロサンプル数は一定だけどトラックの切れ目判定がリッピング条件によって異なる、と推察されます。
 合計値が同じということは、曲と曲が流れで繋がるようなアルバムのファイル再生でもCD再生と同じように繋がると思います。
====

 今回さらに踏み込んで、全15曲のあるCDにて以下を比較してみました。プリギャップ2から15まで全部あるCDです。ドライブはBDR-S05J。

a.≪iTunes 10≫でトラックごとにリップした15曲を波形編集ソフト≪SoundEngine≫でマージしたWAVファイル

b.≪EAC Ver1.0 beta3≫でimgとしてCDまるごと取り込んだWAVファイル

 …以下の通りWAVコンペア一致。

mergeimg compare

 ゼロサンプル数は先頭も末尾も一致です。総サンプル数も一致です。≪EAC≫のimg抽出はCDまるごと連続読みしていると思われますので、つまり≪iTunes 10≫でのファイル単位リッピングにおいて「サンプル欠落や存在しないサンプルの付加などはない」ということですね。
 もちろんすべてのリッパーが同様かは不明です。

 なお、当比較は敢えて≪EAC≫のオフセット補正はオフして行っています。オンした場合にどうなるかは本項から離れる話題なので後述します。


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

・リッピングしたらプリギャップはどこへいく?
 以下にリッピング図を示しますがそれを見るちょっとその前に。
 プリギャップは前のトラックのおしりにくっつけるのが一般的のようです。設定できないリッパーではそうなっているようですし、設定可能な≪EAC≫もそれがデフォルトです。「対象トラックのINDEX01から次トラックのINDEX01直前まで吸う」というコンセプト(次のトラックのINDEX00を含めてしまう)ですね。よって、トラック1のINDEX00期間はリップされません。

 ≪EAC≫は処理を設定できます。
  「Leave Out Gaps」・・・リップ時にギャップ削除
  「Append Gaps To Previos Track (default)」・・・“前トラックのおしり”にくっつけ
  「Append Gaps To Next Track」・・・“次トラックの先頭”にくっつけ

 ミソは、「前のトラックのおしりにくっつくのが普通」ってところですね。CDプレーヤのトラック頭出しはINDEX01に飛びますので、その動作と合わせているのでしょう。

 ちなみに、「Append Gaps To Previos Track (default)」以外はギャップ検出しないと選択できず、検出には結構時間を要します。これは、TOCにはトラック開始地点(INDEX01)情報はありますがINDEX00の位置情報はないため、CD全面をスキャンしてINDEX00位置を検出する必要があるためと推察しています。

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

CD-DA構造とオフセット

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

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

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


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

 ドライブにはオフセットがあります。そこで、リッピング時にそれを補正する機能を持つソフトがあるワケですね。≪EAC≫や≪dBpoweramp≫などです。ですので、「ドライブオフセット補正機能」を有するリッパーの場合、同じドライブ同じリッパーを使っても当該機能のON/OFFや設定する補正値の違いで先頭末尾の状態は変わります。
 先の15ファイルマージと一気読みを比較したCDにおいて、オフセット補正した場合を示します。

mergeAccuimg compare

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

 常用するリッパーを選ぶ際にはこのあたりの事情も確認した方がいいかも知れません。
 
 「≪EAC≫補正値は+30多すぎるのでは問題」については本稿の本質と無関係ですので触れません。


■ズレの正体:その他編

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

・トラック1のINDEX00期間処理
 特殊な事例かとは思いますが。
 トラック1のINDEX00期間はCD再生やリッピングにおいてアクセスされません。普通のCDではジャスト2秒設けられているようで、CUEシートなどでは必ず2秒マイナスされ、その結果が“見立てINDEX00期間”となるようです。通常はゼロとなるので当該INDEX00期間は存在しないように見えます。2秒以上あった場合に、「2秒以上の分」が見立てINDEX00期間として扱われるようです。
 この“慣例”に引っかかるアプリ(ドライブ?)がある? 例えば、INDEX00期間が2秒+37フレームの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以降もズレたままです)。ので、“引っかかっている”ように思えますね。どうも「トラック1のINDEX00期間は絶対2秒(150フレーム)」と決めちゃっているようです。
 ちなみに≪WMP 12≫も同様のリップする模様です。

・ディスクオフセット
 同タイトルでもプレス違い(?)でディスク自体のデータ位置が異なっている場合があります。


■再生時に“間”や“途切れ”は起こっているか

 リッピングではtrack先頭末尾にサンプルの欠損やダブリはないことが解りました。では、再生時の完全性はどうでしょう。
 連続ファイル再生時、ファイル間でデータ欠落や本来ない“間”は発生していないのでしょうか。

・いわゆるギャップレス再生とプリギャップ・ポストギャップは無関係
 詳しくは知らないのですが、いわゆる「ギャップレス再生」とは、例えば同じCDからリップした1曲目のWAVファイルの音声データの最後と2曲目のデータの最初が連続して再生されることと理解しています。
 ここで言う「ギャップ」とは、「CD再生では存在しない“間”」が出来てしまうことを指していると思います。プリギャップやポストギャップといった「意図的に設けたギャップ」のことではないでしょう。同じく“ギャップ”という名称ですが意味が異なることに注意です。
 前述した通り、

 ・プリギャップデータはリッピングによって「前の曲のおしり」に付加されるのが一般的
 ・ポストギャップはそもそもトラック内の音声データ化している
 ・リッピングによって曲間サンプルの増減はない

です。
 よって、ファイルオーディオにおいては、データの連続再生さえ出来れば「ギャップレス再生=CD再生と同じ曲間時間で再生」出来るということです。プレーヤが新たにギャップを削除したり挿入したりする必要はありません。

・PCにおけるギャップレス再生の実際
 ≪uLilith≫であれ≪foobar2000≫であれ、これまで用いたプレーヤで、ライブ曲のようなトラック間が連続するWAVファイルのギャップレス再生が出来なかったことは“少なくとも聴感上は”ないため、PC-Audioにおいて「ギャップレス再生」は特段の課題ではないと認識しています。
 ですが、一応その定量的確認ということで、ファイル再生について簡易実験してみました。

 あるふたつのファイルにつき、

a.≪PlayPcmWin≫で連続再生してS/PDIFキャプチャし、ひとつのファイルを生成

b.≪SoundEngine Free≫でマージしてひとつのファイルを生成

してWAVコンペアした結果、一致しました。つまり「≪PlayPcmWin≫による再生において曲間に本来存在しないギャップはない」と言えます。

・いわゆる「ギャップレス再生」のいろいろ
 ただし、上記はWAVファイルをローカル再生する場合のお話です。ポータブルプレーヤにおける圧縮ファイルの連続再生やネットワークオーディオではギャップが発生することがあるようで、それを防止することが「ギャップレス再生」と呼ばれていることもあるようです。つまり、「本来存在しないギャップが発生しないようにする機能」を指すのですね。マッチポンプ的な名称?(笑)
 また、“プリギャップ”を削除して再生することを指す場合もあるようなないような。

 複数の意味で使われているようですね。


■エラーしていないのにWAVコンペアソフトで一致しない?

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

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

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

*:上記「トラック1のINDEX00が2秒+37のCD」のトラック2ですが、たまたま見つけた一例として、です。

0000じゃないプリギャップ

 アドレスを見ていただくと解りますが、かなりの数のサンプルが先頭からずっとFFFFhです。
 このようなファイルの場合、≪WaveCompare≫は先頭に「ゼロサンプルなし」と認識して比較を開始するようです。
 このようなトラックにつき、先の「トラック1のINDEX00期間に引っかかる」「オフセット補正の有無」などによって全体のズレ方が異なるリップしたファイルでは、先頭の状態が異なっていることになります。
 なので、先頭から比較を開始しますがすぐにサンプル相違にぶつかってしまいます(上記の例だとFFFFh以外が出現したところから相違)。その後も曲の先頭=INDEX01に相当するサンプル位置も含めて全部ズレているワケですから全部相違となってしまいます。
 しかし、「音楽データの相違」と見なす状態ではありません。ズレてるだけなので。
 プリギャップにMCが入ってる場合などもこうなりますね。

 なお、FFFFh(-1)がずっと連続している状態はバイアス成分であり音声データとは言えませんから、本来あってはならない状態であることは付記しておきます。
 サンプル状態によっては、冒頭がゼロサンプルじゃなくてもちゃんと一致点を見つけてくれます。

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

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

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

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

・WAVコンペアソフトのパラメータがすべて一致するのにファイルコンペアソフトで一致しない?
 WAVコンペアで以下がすべて一致するのに、ファイルコンペアソフトで一致しない場合があります。
   比較結果
   サンプル総数
   先頭ゼロサンプル数
   末尾ゼロサンプル数
 これは、リッパーによってヘッダやフッタが付加されたのが原因であることが大半ではないかと思います。
 もちろんこの場合は「ファイル容量」が異なりますのですぐ判ります。


■つまるところ

 以上、やっぱりデジタルシステムはキッチリカッチリ融通効かさず動いてることが確認できました。何よりです(笑)。

・ドライブオフセット値、気にする?

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

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

 プラスでもマイナスでもトラック間の切れ目がオフセット分ズレますが、CD収録順通り聴いている限り全く問題ありません。

 ということで、個人的には、ドライブ選択条件としてはほぼ無視していいと判断しています。どれでもいい場合はオフセット量が少ない方が気分的にはいいかも知れませんが、プラスオフセットだとトラック1の“先頭サンプル”取りこぼしになりますので気分的には気になるかも知れません。
 リッパーについては、念のためプリギャップをどう処理する仕様か確認した方がよいかも知れませんね。前に付けるのか後に付けるのか。サンプル増減はないか。出来ればトラック1のINDEX00期間の読み方も(2秒決め打ちしていないか)。
 それなりのリッパーなら例えズレはあってもサンプル増減などはないと思いますけれど。

 なお、オフセット値を補正しないとDB照会用のデータ値が異なってしまいますから、セキュアリッパーにおいてDB照会機能を利用する場合は(Overread対応も含め)気にする必要があるでしょう。

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

EACdeCUE.png

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


■オフセット補正

 本項19/03/09ごろ追記。

・オフセット補正と「リードイン・リードアウト」
 本項19/02/28追記:≪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」のカーソルポップアップヘルプ

 ディスクに依存するかも知れませんが(3タイトルしかやってませんので)、日立LG製BD-ROM/DVDライタ:GGC-H20Nでは、オフ設定でオフセット補正すると最終トラックのデータを取りこぼすようです(サンプル数が558の倍数になっていない)。+667(推奨値)、+637、+2でダメでした。0(補正なし)なら大丈夫。Pionner製BDR-S05Jでも+667(推奨値)ではダメでした。
 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」のカーソルポップアップヘルプ

 ところで、音楽CDの規格によると、上図の通り先頭トラックINDEX01とリードイン領域との間には最低2秒(88200サンプル)のポーズ期間があり、リードアウト領域はトラックナンバーAAのAudioトラックです。
 よって、

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

*:INDEX00を超える88200超のマイナスオフセットのドライブでない限り

(2)プラスオフセットの場合
 リードイン:当然読まない
 トラック1のINDEX00期間:当然読まない
 リードアウト:仕様なので当然読めるハズ(規格上Audioトラックですし)

と考えられます。
 つまり、オフセットを持つドライブでは物理的なINDEX00やリードアウトは「読む」「読める」、つまり「“物理的Overread”はできる」のが基本でしょう。そして、正しくオフセット補正すると物理的なINDEX00やリードアウトは読まなくなりますから、Overreadは不要になるハズです。

 こう考えると、≪EAC≫が言う「Laed-In」「Lead-Out」とは、その名を持つディスク上の物理的な領域ではなく、「ドライブがオフセット入りで認識している仮想的な音声トラックデータ」において、

・トラック1のINDEX01より前=Lead-In
・最終トラックのあと=Lead-Out

を表していると理解した方がよいのでは。本稿ではそう解釈し、物理的リードイン・アウトと区別するためそれらは英語で記すこととし、それらを読むことを「Overread」と位置付けることにします。


 さて、とすると、敢えて「Overreadしない」とする意図は何でしょう?
 もしかしたら、ドライブにとってはオフセット読みが仕様なのですから、“仮想的にはOverreadしていない”状態なのであり、補正すると逆に“仮想Overread”状態となるのではないでしょうか? とするなら、

・「Overreadする」と指示すると誤動作するドライブがある
・「Overreadしない」と指示すると誤動作するドライブもある

ということでしょうか? だとすると、上記GGCやBDRは後者ということになります。ちなみにドライブ認識後のデフォルトではオフのようです。

・オフセット補正と「最終トラック末尾」
 AccurateRipのページ(*)によると、ほとんどのドライブはマイナスオフセットのようです。

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

 つまりプラスにオフセット補正することになりますから、最終トラック末尾に補正なしでは読まなかったサンプルがくっつくことになります。普通は無音(ゼロ)が増えるだけだと思いますが、「補正なしだと末尾がゼロではない最終トラック」で、実際何がくっつてくるのか確認してみました。補正しても物理的リードアウトには入っていませんから物理的には読めるハズです。
 ≪EAC V1.3 from 2. September 2016≫とGGC-H20Nで+667(補正値)、+0(ARなし)でやってみたところ不思議な結果に。
 最終トラックの最後の部分を≪Wavowaur 1.3.0.0≫で示します。上が補正なし、下が+667補正ありです。
 +667補正すると、何故か補正なしの場合の最後2352サンプルがゼロになり、それに667個のゼロサンプルを加えた3019サンプルがゼロになったのです。
 Overreadする設定です(しないと取りこぼすので)。「Fill up missing offset samples with silence」はノーチェックにて。

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

・+637だとゼロサンプルが30個少なくなるだけでしたので、「+30補正しすぎ問題」は関係ないでしょう。
・補正値を-2にするとゼロになりません。
・≪CUERipper 2.1.6≫でも同じようになりました。

 普通はトラック末尾はゼロなのでゼロへの書き換えに気付くことはないでしょう。2352サンプルはちょうど4フレームです。プラス補正の場合、「補正で後ろを延長して読む分はゼロ、さらにさかのぼって4フレームをゼロ」に書き換えているのでしょうか。
 タイトルを変えてみると、やはり9フレーム分ゼロに書き換えられていましたので、特定タイトルの現象ではないようです。フレーム数が違っているということは、タイトルの何かに依存するのでしょうか。
 ドライブを変えてみると、

・スリムドライブで+6補正・・・前者が5フレーム、後者が10フレーム分ゼロに書き換えられました
・PX-716Aで+30補正・・・書き換えません
・BDR-S09Jで+667補正・・・書き換えません

となりました(すべてARの補正値)。書き換えないドライブもあり、書き換えるドライブではそのフレーム数も異なることから、ドライブ依存っぽいです。
 ということで、ドライブを追加して≪EAC≫での「Overread」検出結果と「補正後の書き換え」の対応を調べてみました。補正値はすべて≪EAC≫が表示したものです。

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

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

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

 オフセット補正(AccurateRip)するドライブは、上記を考慮して選んだ方がよいかも知れません。
 いろいろ難しそうですね。

 なお、マイナスに補正する場合はトラック1の先頭に同様の問題が発生する可能性も考えられますが、プラスオフセットのドライブは稀なようですので(所有していませんので)、ここでは扱わないことにします。


■おまけ

・HTOA(Hidden Track One Audio)
 トラック1のINDEX00の長さは2秒以上となっていますが上限はないようです。普通は2秒の無音ですが、CD上の位置づけはトラック1のデータですので、楽曲を入れることも可能です。しかし、CDプレーヤであれリッピングであれ、通常はCDの開始はトラック1のINDEX01ですからアクセスされません。
 この仕組みを利用して仕込んだ隠しトラックが「HTOA」です。
 CDプレーヤでは、トラック1の前へ“巻き戻し”できる機種なら再生できるようです。
 リッピングでは、ギャップを自トラックの先頭にくっつけてから分離するなどの手が考えられますが、≪CUE Ripper≫ならズバリHTOAの扱いに関する設定があるので簡単です。上述の通り“見立てINDEX00期間”が「track00」としてリップされます。

#ただし、CD規格上のトラックナンバー00はリードインのことです。

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

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

・プリギャップありのCDをつくる
 ≪WMP 12≫の書き込み設定「トラック間のギャップなしでCDを書き込む」のチェックをハズすと、プリギャップありCDが作れます。もちろん書き込むファイルにプラスして、です。詳述すると、≪EAC≫で読み込んだCUEシートにINDEX01と1秒74フレームの差分があるINDEX00が存在するCDです。
 OS標準ソフトで明示的に長めのプリギャップがあるCDを作れるので、何かの実験に使えるかも。

#フレームは00から始まりますので、74フレームまであるとジャスト1秒です。なのでフレーム番号で言うと1秒と00~74フレームある、ということですが、時間的には2秒でしょう。

・時間表示
 ≪EAC≫の表示は「分:秒.フレーム」。元になるCDのTOCやINDEX情報の秒以下はフレーム単位。
 CDの音声データ管理はフレーム単位なので、リッピングしたサンプル総数は588で割り切れるハズ。いくつかやってみると確かに割り切れます。割り切れなかったらリッピングエラーでサンプル増減が発生したとみていいでしょう。
 ≪WaveCompare≫では秒以下の表示方法を選択可能。ソフトによって、秒以下の表示はフレーム数か時間かに注意。

・CDプレーヤカウンタのプリギャップ表示
 一説に「プリギャップはマイナス表示される」とありますが、例えば前述の15曲入りCDのプリギャップはBDP-S470では単純に前の曲の演奏時間として表示されました。14曲目と15曲目の間なんて以下の通り6秒もあるので見逃しではないでしょう。14曲目の演奏が06:00カウント超えるのも見ましたし。
 PanasonicのUHD-BDプレーヤDMP-UB90-Kでも同じでした。

  TRACK 14 AUDIO
   TITLE "Track14"
   PERFORMER "Unknown Artist"
   FLAGS DCP
   INDEX 00 56:12:53
   INDEX 01 56:15:24
  TRACK 15 AUDIO
   TITLE "Track15"
   PERFORMER "Unknown Artist"
   FLAGS DCP
   INDEX 00 62:10:14
   INDEX 01 62:16:48


 “CDプレーヤ”じゃないからかも知れませんけど(苦笑)。PCソフトプレーヤでも同様の表示されるようです。

・わざと?
 ドライブごとにオフセットは一定です。つまり、設計上固定できるということでしょう(それがAccurate Stream?)。なら、オフセットを敢えて設けている(または敢えて放置している)ということになります。実は「アドレス情報がないからズレる」というのはなんだか解せていません。フレームには絶対時間(絶対フレーム番号)入ってますし。TOCとかINDEXは読めてるワケですから補正のしようもあるでしょうし。

 はてな~

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


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

・アフィリエイトは「Amazon.co.jpアソシエイト」のみです

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

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