FC2ブログ

メインメニュー

Electric Emotional Entertainment Reserch Institute
 本「メインメニュー」は、話題ごとに古い順を原則につながりを考慮して並べています。

*更新情報(新規登録は右記「最新記事」をご覧ください)

 19/10/17:「CDの構造」記事から「プリギャップ関連」を独立させました。
 19/10/03:「オフセットとギャップ」記事から「CDの構造」を独立させました。
 19/09/29:「DB照合サービス」記事から「オフセット補正注意」を独立させました。
 19/09/26:おかげさまで10周年(カウンタは377,707)。ありがとうございます。
 19/09/14:「PureRead3+」記事から「平均値補間」を独立させました。
 19/09/14:「エラー訂正」記事から「DB照合サービス」を独立させました。
 更新履歴

・007:諸事


【PC-Audio】
・053:ファイルオーディオの基礎知識
・129:ジッタの基礎知識

■リクツ
・066:デジタルデータはコピーで劣化するか
・089:リッピングソフトによる「ビット品質差」は存在するか (同じ0/1に音質差はあるか)
  ・140:リッピング環境による「ビット品質差」は存在するか (&仮想ドライブ効果考察)
・113:サンプリング定理を改めデジタルオーディオの原理を勉強する
  ・116:サンプリング周波数と周波数成分と帯域制限を可視化する
・117:PCのアップサンプラとDACのデジタルフィルタはどんな関係か (UDA-1活用へ)
  ・124:PCソフトはDACチップハードのデジタル処理を代替できるか
・132:アップサンプラの「位相応答」とは何か
・133:「インパルス応答」のエコーは問題なのか
・121:PCMの「TruePeak」とは何か
・120:DSDの「MaxPeak」とは何か

■ハイレゾ
・065:ハイレゾファイルの中身はハイレゾ(良マスタリング)か
  ・151:ハイレゾ商品の実際
  ・152:DSDとPCMで波形が著しく違う商品の不思議
    ・153:DSDとPCMで波形が著しく違う商品の制作プロセス
・110:ハイレゾフォーマットの効能を聴き比べるには
  ・111:試聴準備:ハイサンプリング領域に成分があるか
  ・155:試聴準備:ピークが潰れていないか(ハイレゾに限らず)
  ・112:試聴準備:システムはハイレゾ高域を再生できているか
・128:ハイサンプリング領域にノイズ問題はないか
・125:ビット深度は“16”で足りているか
・069:foobar2000とSoX Resampler
  ・119:foobar2000とResampler-V (&DSD変換)

■リッピング(ソフトウェア)
・015:WAVフォーマットを理解しておく
・165:音楽CDの構造を理解しておく
  ・167:プリギャップはどう読まれどう再生されるか
  ・091:オフセットなどの「ズレ」はリッピングにどう影響するか
・052:音楽CDのエラーとは何か (&補間エラー名称はC2かCUか考察)
  ・051:EACやiTunesが「エラー訂正」しているのか (セキュアリッパー考察)
    ・068:セキュアリッパーの限界:ドライブ相性
    ・162:セキュアリッパーの限界:平均値補間
  ・163:リッパーの「DB照合サービス」とは何か (AccurateRip&CTDB考察)
    ・164:DB照合サービスの注意点:オフセット補正
    ・161:DB照合サービスの新機能:リッピングエラーをリッピング後に修復する
  ・166:リッピングエラー(補間)はインパルスノイズになる
・084:音楽CDの「エンファシス」とは何か

■リッピング(ハードウェア)
・013:PureReadの効能
  ・045:PureRead2は進化しているか
  ・139:PureRead3+は進化しているか
・014:リッピング条件が異なるとリップされたデータは変化しているか
  ・082:ダメージディスクでは何が起きているか (リッピングまとめ)
  ・083:光学ドライブのダメージディスクリッピング得手不得手

■送る
・009:WASAPIおそるべし
・018:デジタルケーブルで音は変わるか
  ・071:HDMI光アイソレーション
・022:デジタル転送時にデータは変化しているか
  ・080:検証用デジタルデータ操作法
・040:デジタルなのに音が変わるワケ
  ・070:DAC方式とDSD再生
・039:ppmがジッタなのか
  ・050:アシンクロナスモードはフロー制御しているか
・114:インターフェイスとDAC事情から「ジッタ」について理解しておく
  ・115:ジッタ対策に何ができるか考える
・081:プレーヤソフト設定とデータ仕様が異なるとビット深度はどうなるか

■鳴らす(USB→S/PDIF)
・010:PCセレクト(1):ONKYO製HDC-1L
・011:DDCセレクト(1):ONKYO製SE-U55SX
  ・024:SE-U55SX電源を安定化電源で
・041:DDCセレクト(2):RATOC製REX-Link2EX (USB-I/Fをワイヤレス化)
  ・042:REX-Link2EX電源をeneloopとかレギュレータで

■鳴らす(HDMI)
・023:SACDのDSD再生から始めるHDMI-Audio (&HDMI規格まとめ)
・044:PCのHDMIでハイレゾ&マルチ再生を試す (915GME&H55で味見)
・061:PCセレクト(2):J&W製E350-GT (S/PDIFからHDMIへ宗旨替え)
・062:PCセレクト(3):GIGABYTE製GA-E350N-USB3 (HDMI-Audio構築&UpSampling)
  ・063:HDMIリンクスピードと音質 (&HDMIモード詳細)
  ・072:Audio-I/FとしてのHDMIデバイス変更

■鳴らす(USB)
・090:DACセレクト(1):SONY製UDA-1
  ・118:UDA-1を「なんちゃってNOS-DAC」として活用する
・122:Audio-I/FとしてのUSB検討
・123:PCセレクト(4):GIGABYTE製GA-X79-UD3 (パワーオーディオに宗旨替え)
・126:DACセレクト(2):TEAC製UD-503 (&ヘッドホンバランスケーブルあれこれ)
  ・127:UD-503のデジタル処理を確認する
・156:PCセレクト(5):ASUS製Z170-A (世代のジャンプアップを試す)

■いじる
・064:プレーヤソフト制御法
・029:OSチューン(&Thindowsのつくりかた)
・046:H/Wチューン
  ・073:クロックや電圧をいじる
  ・077:CPUコア数をいじる
・157:デジタルチューン


【Audio】
・028:アナログケーブルで音は変わるか
・033:805 VS 805S とユニット増し締め
・048:AVアンプの活かし方
・049:音が変わるって科学かオカルトか
・054:電力と節電とピークシフト (システムの実消費電力)
・088:グランドとアースを理解する
  ・144:グランド・アースとケーブル構造の関係を再考する(電線病治療)
    ・145:グランドとアースをチューンする
・078:iTunes10と11で音質は異なるか:AAC編
  ・079:iTunes10と11で音質は異なるか:WAV編


【Visual】
・059:AACS都市伝説を追う:BDAV編
・143:BDZ-EW1200導入記
・158:BDディスクの相性・容量


【PC】
■ソフトウェア
・026:Windows7アップグレード所作
・075:Windows8導入記
・138:Windows10(無償)ライセンス挙動

■ハードウェア
・038:DisplayPortとHDCPとWQXGAと
・047:MatrixRAIDの挙動を理解する
  ・142:Windows10の「記憶域」は使えるか
・055:パーティションオフセットの諸問題
・058:GfxカードとQuickSyncVideo共存方法
・076:GA-Z68X-UD3H-B3をUEFI化する
・147:Z170を修める
  ・149:NVMeも修める

■モバイル
・086:パケット料金を抽象化して考える
・087:モバイルルータとMVNO回線を選ぶ
・108:miix2でWindowsをモバイルする:ハード編
・109:miix2でWindowsをモバイルする:ソフト編
・130:スマホでG4通信とFOMA通話をデュアルSIM運用する
・137:ThinkPad X220改造とWindows10化


では

ギャップはかくリップされかくプレイされる

19/10/17初稿

 本稿、「音楽CDの構造」記事の内容をそれに特化するため、そこから独立させました。ですので、構造記事を前提として記しています。


■音楽CDにおける「ギャップ」を正しく理解する

 まず押さえておきたいのは、「音楽CDの規格はリッピングなど想定していない。どころか、PC用ドライブ自体想定しておらず“CDプレーヤで再生”することを想定した(それしか想定していない)もの」であることを念頭に置くことではないかと思います。

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

・ギャップ理解のコツ:「ギャップ」を断絶的に捉えない
 詳しく取り上げる前に、「ギャップ」という名称についてちょっとだけ。
 「ギャップ」と呼ばれてはいますが、INDEX00期間(普通にサンプルがある)を指し、「裂け目,隙間,断絶」といった状態ではありません。それが証拠(?)にCD規格では「ポーズ(休止)」と呼ばれています。名称のイメージに惑わされないようにした方がよいでしょう。

・ギャップ理解のコツ:本当は「ポーズ」
 ポーズではなくギャップと呼ばれているのは、オーサリング時に曲間の「隙間」を示す用語として使われているものをリッピング用語に転用したためではないかと推測しています。また、CD-ROMやCD-RのJISにはデジタルデータトラックの区切り領域の名称として「プリギャップ」「ポストギャップ」が出てきます。これらを混用している可能性もありますね。

 ですので、リッピング的には本来なら「ポーズ」と呼んだ方がよいと思いますが、既に馴染んでしまっていますし、「ポーズ」というと止まってるみたいですから、本稿も「ギャップ」という名称を採用します。が、CUEシートの「PREGAP」「POSTGAP」コマンド的なものではなくCD規格的なものとして記述します。CD-ROMなどに言う「プリギャップ」「ポストギャップ」はCD-DAとは無関係なので無視します。

・プリギャップ(ギャップ)
 上のリンク先記事に記したしたINDEX00(本来なら「ポーズ」)のことです。
 トラック01には2秒以上付けることが必須ですが、トラック02以降は任意です。また、トラック01のINDEX00は通常はアクセスされません。
 というような特殊事情があるので、本稿ではトラック01のINDEX00期間はプリギャップとは呼ばないことにします。

・ポストギャップ
 プリギャップと異なりCD作成プロセスにおける概念で、先の記事に示した構造の通りCD-DAにはポストギャップに相当する領域はありません。CD-DAにおいてトラック間にギャップを入れるにしても、プリとポストに分ける意味はありませんよね。そもそもCD-DAの読み方としてはプリギャップすらトラックの開始ではありませんし。
 編集時点で存在してもCDになった時点で音声部分と合体しトラック最後の部分になるものです。つまり、リッピングしたWAVデータとしてはトラック末尾のゼロサンプルに相当します。プリギャップと異なり“リッピング時に付加されたものではなく普通に音声データとして読み出される”と理解してよいでしょう。なお、通常はゼロサンプルだと思いますがトラック末尾が“ゼロ近傍”なCDもあります。と言ってもそれが元ポストギャップなのか否か、判断しようはありません。

 よって、原則として、リッピング時に考える必要はありません。なのでリッパーなどにも「ポストギャップ」の概念はないハズです。例えば、≪EAC≫のGap Analyzingでは「Detecting Pre-Track Gaps」というダイアログが出て、検出結果が反映されるメイン画面にはGap欄は1列しかありません。Gapの処理設定でも「Gap」としか記述はなく、「Pre-Gap / Post-Gap」といった区別はありません。

・HTOA(Hidden Track One Audio)
 トラック01のINDEX00が以下の特徴を持つことを利用して仕込んだ隠しトラックが「HTOA」です。

・CDプレーヤであれリッピングであれ、CDの開始はトラック01のINDEX01なのでアクセスされない。
・長さの下限は2秒だが上限はない。

 CDプレーヤでは、“トラック01の前へ巻き戻し”できる機種なら再生できるようです。
 リッピングでは、「プリギャップを自トラック先頭にくっつけるモードでリッピングしてから分離する」などの手が考えられますが、例えば≪CUERipper≫にはズバリHTOAをどうするかの設定があるので簡単です。
 リッピングする設定にすれば、“見立てINDEX00期間(先頭2秒をカットされたINDEX00)”が、「00.(HTOA).wav」というファイル名(拡張子はもちろんファイル形式によって異なる)でリップされます。ただし規格上のトラックナンバ00はリードイントラックです。
 リッピングする設定にしても、“見立てINDEX00期間”が2秒以上なければ無視されます。

#余談:LBAはトラック01のINDEX00においてはAMSFから150フレームマイナスした位置がスタートと決まっているようですので、「トラック01のINDEX00を読む場合でもLBAマイナス領域は読まない」結果が“見立てINDEX00”なのかも知れません。


■ギャップとリッピング

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

『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≫のオフセット補正はオフして行っています。「≪iTunes≫はオフセット補正していないから」です。オフセット補正については本項から離れる話題なので後述します。

・トラック単位でリッピングしたらプリギャップはどこへいく?
 プリギャップは前トラック末尾にくっつけるのが一般的です。設定できないリッパーではそうなっているようですし、設定可能な≪EAC≫もそれがデフォルトです。「対象トラックのINDEX01から次トラックのINDEX01直前まで吸う」というコンセプト(次のトラックのINDEX00を含めてしまう)ですね(よって、トラック01の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全面をスキャンして(サブコードを読んで)検出する必要があるためです。


■ギャップとファイル再生

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

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

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

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

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

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

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

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

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

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

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


■余談

・リッパーはINDEX02以降をどう読んでいるか
 普通は、INDEX01頭から次トラックのINDEX01直前までをひとつのトラックとしてリッピングします。
 INDEX00領域を自トラック先頭にくっつける設定の場合は、INDEX00(ない場合はINDEX01)頭から次トラックのINDEX00(ない場合はINDEX01)直前までをひとつのトラックとしてリッピングします。
 ギャップを削除する場合はINDEX00領域を削除します。
 ですので「INDEX02~INDEX99はあってもなくても関係ない」のが基本です。

#ここではCUEsheetを使って分割するなどの件は無視しています。

・CDプレーヤカウンタのプリギャップ表示
 一説に「プリギャップはマイナス表示される」とありますが、例えば前述の15曲入りCDのプリギャップはSONY製BDプレーヤ: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ソフトプレーヤでも同様の表示されるようです。

・リッピングソフトの時間表示
 上記タイトルの、≪EAC≫のCD挿入時のStart、Length、Gap表示、Gap除去(*)したLength、≪iTunes 12.6.2.20≫表示 は以下の通りです。

  Track13:0:51:37.74 0:04:37.25 0:00:01.44 0:04:34.54 04m37s
  Track14:0:56:15.24 0:06:01.24 0:00:02.46 0:05:54.65 06m01s
  Track15:1:02:16.48 0:05:30.01 0:00:06.34 0:05:30.01 05m30s

*:Gap Detect(Secureで)した状態でLeave Out Gapを実施

・≪EAC≫の表示は「時:分:秒.フレーム」。元になるCDのTOCやINDEX情報の秒以下はフレーム単位。
・CDブックレットには時間記載なし。
・BDR-S05Jと≪iTunes≫で行ったリッピングファイルの≪WaveCompare 1.32≫での時間表示はLengthと一致。
・≪EAC≫ではTrackのLength(長さ)をStartに単純に足すと次のTrackのStartになっている。
・≪EAC≫のLengthは他の結果と同じ。
・Gap除去した結果は、次TrackのGapが減っている。

 つまり、一般的にはGapはやはり前トラック末尾にくっつき、INDEX01がTrackの切れ目として動いているということです。「TrackとGap(正確にはポーズ)以外の要素はない」ということが解ります。

 なお、例えば≪WaveCompare≫では秒以下の表示方法を選択可能です。ソフトによって、秒以下の表示はフレーム数か時間かに注意が必要です。


メインメニューへ

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

リッピングエラーノイズはインパルスノイズである

19/10/14初稿


■リッピングエラーはどんな波形異常になるか

・リッピングエラーはインパルスである
 これまで調べてきた結果、リッピングエラーは、大規模な発生(正誤が交互にならないような発生)やフレームごとズレたりするエラーを除くと「C2エラー=補間」となり、次のような現象になります。

  ・C2エラーは補間される
  ・CIRCはエラーサンプルが正常サンプルに挟まれて発生するようにできている
  ・C2エラーは平均値で補間される

 バースト的なエラーはノイズとなり「音質劣化」の問題ではなくなる可能性が高いと思いますが、「パラパラ発生する補間と音質劣化の関係」は具体的に解っていませんでした。というより定量化しようがないかなぁと。
 が、あるとき、実はこれもサンプリング定理に基づいて考えるのがよいのではないかと思いつきました。
 補間値は普通サンプリング定理に基づいた値にはなりません。サイン波の頂点が補間された場合をイメージしてみてください。絶対にサイン波として復元できませんよね。

 ということで、実際の楽曲(検証によく利用しているタイトルのトラック01)で以下の波形をとってみました。リッパーは≪EAC≫です(関係ありませんが流れでオフセット補正入り)。いつもはLchですが適当な補間を探していたら今回はRchになりました。

・上:補間なしディスク:BDR-S09J(PureReadパーフェクトモード)
・中:補間ありディスク:GGC-H20N
・下:2波形の差分

エラーありなし波形と差分 wataco

#縦線は補間サンプルすべてではなく代表的4か所。ディスクオフセットは≪EAC≫のオフセット補正で補正。ドライブが異なるのは、補間発生状態が記事に適当なのはGGCだったが補間なしはPureReadパーフェクトモードで保証するため。

 この図を見ると、実際、エラーは正常値に挟まれて発生しており、平均値で“ならされている”のが解ります。
 そして、平均値補間されたサンプル値と正常サンプル値の差分は「インパルス」と言えます。
 ですので、それがサンプリング定理に基づいて復元された結果は「インパルス応答波形」になるハズです。

・「リッピングエラーインパルス」の実波形
 ということで、上記を≪foobar2000≫のResampler-V(DAC設定)で8倍してみます。8倍OSDFのDACチップからの出力波形のシミュレーションになっているハズです。

エラーありなし波形と差分 x8

#差分(インパルス応答波形)のみ、解りやすくするため振幅方向を拡大しています。

 確かにインパルス応答波形になることが確認できました(傷ありなし8倍の差分をとっても同じ結果になりました)。中央は複数の応答が重畳されているので解りにくいかも知れませんが、右側の補間値はインパルス応答波形になっているのがよく解ります。
 補間による差分(インパルス)すらリコンストラクションされた賜物で、補間あり音源もナントナクそれっぽい波形になっていますね。

 以上より、補間による音質劣化は「補間値と正常値の差分のインパルス応答波形がノイズ成分として重畳されたもの」と言えます。補間入りのリッピング音源はこのようなノイズ入りで聴くことになる、ということです。


■実際にはどんな音質劣化になるか

 さて、どんなノイズになるかは解りましたが、実際にどんな劣化として聞こえるのか気になるところです。
 インパルス応答波形ノイズはナイキスト周波数のサイン波のようなものですので、それ単独ではまず聞こえないでしょう。
 あとは発生量やレベル(補間値と正常値の差分)によると思いますが、重畳されるとどんな劣化になるのか、ひとつ極端な“体験方法”を思いつきましたので記しておきます。

  ・単純間引きで22.05kHzにダウンサンプリングする
  ・リニア補間で44.1kHzにアップサンプリングする
  ・元音源と聞き比べる

 「楽曲全域に渡って半分のサンプルで平均値補間が発生したリッピング」を人工的(?)に生成したものと言えるハズです。
 ≪foobar2000≫のプラグインMultiResamplerなどで実施できます(プラグインなのでリアルタイム処理も可能ですね)。

 試しにやってみたところ「想像より酷くない」気がします。あくまでも「個人の感想」ですけれど(笑)。
 拘るなら、「左右チャンネルを細工ありとなしにしたファイル」「細工ありとなしの区間を交互につないだファイル」などを作って試聴してみるのもイイカモです。

 この“体験結果”は、「リッピングで補間発生をどこまで気にするか(音質的に拘るか)」の指標にできるかも知れません。


メインメニューへ

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

音楽CDの構造

19/10/03初稿

 リッピングについていろいろ考えるためには、そもそもCD-DA(音楽CD)がどんな構造になっているのか知る必要があります。
 本Blogとしては、「オフセットとギャップ」記事で考え増補していたのですが、量が増えたこともあり本稿に独立させました(オフセット記事は「リッピング時のズレ」に特化)。


■CD-DAの構造

 CD-DAについての勉強が難しいのは「その後成立したCD-ROMやCD-Rなどの情報が錯綜している」点ですね。CD-DA規格時には存在しなかったCD-DAをリッピングするための技術(MMC規格)用語がCD-DA説明のために使われていたりします。また、例えば同じ2352Byteの取り扱い単位についても、規格によってフレーム、ブロック、セクタ、セクションなどいろいろな呼び方があります。同じ単語でも意味が違うこともあります(「フレーム」など)。
 これに惑わされないようにするのが“コツ”だと思います。
 本稿では、“惑わされないために”以下の2情報を最優先に利用します。JIS-S8605は廃止されていますが規格自体に変更はないでしょう。

・JIS規格「JIS-S8605 コンパクトディスクディジタルオーディオシステム」
・CD開発者の方の著作「図解コンパクトディスク読本」

・結論から:CD-DA構造
 まず、結論的に調べたCD-DA構造を図示します(3曲入りの場合)。「ポーズ」は通例では「プリギャップ」だと思いますが、JIS記述を優先して記します(JISにはプリギャップという用語はない)。

CD-DA構造(改訂2)

・「JIS-S8605 コンパクトディスクディジタルオーディオシステム」より
 ベースとしたJISの記述は以下の部分です。原文を優先しましたが、そのままではなく読みやすく加工した部分もあります。

(1)12
・ディスクの記録領域は,次の3部分に区分される
  リードイン領域
  プログラム記録領域
  リードアウト領域

(2)17.5.1
・INDEX00はポーズを示す
・各トラックの最初には,同一トラック番号のポーズ区間をもつことができる
・最初のオーディオトラックは2~3秒のポーズが先行する
・一つのプログラムが複数のディスクに分けられるときのトラック番号は,連番としてもよい
・一つのトラックの最小長さは4秒とし,先行するポーズ時間は含まない

・オーディオトラック番号は01から始まり連続して増加する(最大99)
・オーディオトラックにはINDEX01~99を設定できる
・オーディオトラック内のINDEX番号は01から始まり連続して増加する

・リードイントラックのトラックナンバは00
・リードイントラックにINDEXはない
・リードイントラックにAMSFはない
・リードイントラックの終わりはプログラム記録領域のスタート位置になる

・リードアウトトラックのトラックナンバはAA(BCD(*)的に99の次の10・10)
・リードアウトトラックのINDEXは01
・リードアウトトラックは最終トラックの終点位置から始まりポーズを持たない
・リードアウトトラックはオーディオトラックとして符号化する

・一つのトラック中の走行時間は,6けたのBCD符号で表し,MIN, SEC, FRAMEに各2けたを割り当てる
 トラックのスタートではタイムは“0”とし,タイムはオーディオ部分では増加する
 ポーズ部分では減少して,ポーズの終わりでは“0”になる
 リードイントラック及びリードアウトトラックではタイムは増加する

・ディスク上の走行時間 (ATIME) は,6けたのBCD符号で表し,AMIN, ASEC, AFRAMEに各2けたを割り当てる
 プログラム記録領域のスタート位置では,走行時間は“0”にセットし,TNOはディスク上の最初のトラックの数値となる

*:BCD(Binary-coded decimal)=2進化10進数

・「図解コンパクトディスク読本」より
 特記なき場合、音楽CDにおける「サンプル」はステレオ(4Byte)です。読みやすさを考慮し、図解は稿末に記しました。

・CIRCは6サンプルをワンセットとして扱う
・サンプルの1ByteはEFM変調によって14bitに変調される
・6サンプルは24ByteなのでEFM変調結果は24個の14bitデータになる
・次の内訳で「最小データ単位」を形成する
  ・同期パターン:24bit
  ・EFM変調された8bit(8種)のサブコーディング:14bit
  ・EFM変調したサンプルデータ:14bitデータ24個
  ・12個のEFMデータごとに付加するパリティ:14bitを4個ずつ
  ・上記合計34個のbit塊の間に結合bit:3bit
  ・合計:24+14+14x(12+4)+14x(12+4)+3x34=588bit
・これがCD盤面に連続して記録されている
・これをを98個束ねるとチャンネルとしてのサブコードが読める塊になる
  #ここでは「サブコーディングフレーム(*)」と仮称する(SCフレームと略)
・SCフレームの区切りはサブコーディングが同期パターン(S0,S1の2行)であることで判別する
・EFM解除されたサブコーディング8bitが98bit/種の8種サブコードになる
・正確にはS0,S1で頭が削られるので情報ビット数としては96bit
・サブコードにはCRCを含む(CIRC対象ではないがノーケアではない)
・なのでトラック番号などが記録されている情報ビット数としては72bit
・「最小データ単位」中に6サンプルあるのでSCフレーム中のサンプル数は588個
・4Byte/サンプルなのでSCフレーム中の音声データ量は2352Byte
・44100/588=75なので1秒にあるSCフレームは75個

*:読本では588bitフレームが98個まとまったフォーマットをこう呼んでいることから。

#余談:CD-DAではSCフレームから取り出される実データ量は2352Byteですが、CD-ROMでは2352Byte中にさらにエラー訂正するための冗長データを持たせているので、実データ量は2048Byteとなっています(厳密に言えば実データ量が違う複数のモードがあります)。


■JISをかみくだく

 以下、上記をもうちょっと解りやすく書いてみます。

・領域
 CD-DAにはリードイン領域・プログラム記憶領域・リードアウト領域しかありません。プログラム記憶領域には音声トラック(INDEX00含む)しかありません。CD-ROMやCD-Rなどと混ざらないようにしたいところです。

・INDEX00
 「ポーズ」と呼ばれるINDEX01に続いていく領域です。JISには「同一トラック番号の~」とありますから当該トラック関連データではありますが、あくまでも「ポーズ」であって「トラック」には含めていないようです。
 そして、「INDEX00=ポーズ」は「最初のトラック=トラック01(*)」には「2~3秒先行する=付けることが必須」です。上図で「ポーズ01(特殊プリギャップ)」としている領域がこれに当たります。
 その他トラックでは「もつことができる=任意」です。設ける場合の時間規定もありません。実際あったりなかったりしますし、あっても時間はまちまちです。
 通常は無音(データ的な0000hだけでなくほぼ無音の意味とする。以下同義)ですが、「無音であること」といった規定はありません(実際0001hやFFFFhなどの場合もあり)。これを利用して「MC」や「トラックにカウントされない曲」を入れたりすることがあります。
 ポイントは、トラックの再生開始(CDプレーヤでの頭出しなど)はINDEX00ではなくINDEX01であることです。つまりトラック01のINDEX00期間は通常アクセスされないので、これを利用して隠しトラックにすることもあります。

*:JISによればディスク最初のトラックナンバは(複数枚組タイトルでは)連番にしてもよいので01ではない可能性もありますが、本Blogでは無視します。

#余談:数フレームしかないINDEX00=「ショートギャップ」が設けられたタイトルもあります(もちろんトラック01のINDEX00を除く)。かつて、リッピング防止のためドライブやリッパーを混乱させようとしたものですが、今となってはその効果はありません。

・INDEX01~99
 INDEXは99までトラック内に設定できます。かつてはCDプレーヤで「インデックスサーチ」として利用されていたこともありますが、現在ではINDEX02以降を持つCDはほとんどないと思います(クラシック再販盤などではまだ残っている模様)。民生用対応CDプレーヤもほぼないでしょう。
 ファイル再生において「02以降のINDEXを認識してサーチなどに利用できる」環境を整えるのはかなり困難&バーター条件が多い&一般的ではない気がしますので、本Blogでは無視しています。

・FRAME
 MIN,SEC,FRAMEという走行時間(位置)の最小単位です。FRAMEは1/75秒を表します。
 一方、読本の読み解き通り、CD-DAのデータ単位は1秒間に75個あるため、これを「フレーム」と呼びたくなります。
 しかし、CD-DA規格「JIS-S8605」や読本では、原初のひとまとまり588bit(EFM&CIRCデコード前)を「フレーム」と呼んでいます。一方CD-R規格「JIS-X6282」では「EFMフレーム」と呼んでいます。
 難しいところですが、本Blogでは「FRAME(1/75秒)分の音声データ588サンプル2352Byteのひとまとまり」をフレームと呼んだ方が解りやすいと考え、そう定義して記述しています。

#余談:音楽CDは音声データをフレーム単位でしか読み出せないのですから、リッピングしたサンプル総数は588の整数倍になるハズ。いくつかやってみると確かに割り切れます。割り切れなかったら何等かのエラーが発生したとみていいでしょう。

・SECTOR
 本Blogで「フレーム」とした単位のことを「セクタ」「セクション」「ブロック」と呼ぶこともあるようです(*)。JISの状況をみてみます。

・CD-DA規格「JIS-S8605」・・・どれも出てきません。
・CD-ROM規格「JIS-X6281」・・・1秒間に75個あるひとまとまりを「セクション」、アドレスを持ち独立アクセスできる2352Byteのひとまとまりを「セクタ」と呼んでいます。ただし、「セクタ」には2352Byteすべてを実データとして使えるモードはありません。
・CD-R規格「JIS-X6282」・・・用語説明の項で2352Byteの“データを記録する最小単位”を「ブロック」、アドレスを持ち独立アクセスできるひとまとまりを「セクタ」と定義しています。

 本Blogでは、CD-DA規格にないことからCD-ROMやCD-R(以降の)用語であってCD-DAには無関係と考え、「セクタ」「セクション」「ブロック」は無視します。AMSFはあるものの独立アドレスを持たないデータ単位を「セクタ」と呼ぶのは憚られますし。
 CD-DAの記述で「セクタ」などが用いられている場合は、どんな意味で使われているのか注意した方がよいでしょう。

*:https://av.watch.impress.co.jp/docs/20010319/dal02.htm

 なお、オレンジブック系の業界団体のwebサイト「Orange Forum」には次のようにあります。

 このプログラムエリアには、LPレコードのように、信号がディスク全面に連続的に記録されているわけではありません。Red Bookの場合、1秒間を75の“フレーム”という単位に分け、このフレームをデータのひとまとまりとしています。フレームがRed Bookのデータのひとまとまりの単位であるということは、すべてのCDファミリーのデータの単位もこのフレームということです。ただし、フレームと言うのはオーディオ系の言い方で、PC系、およびデータ系では“ブロック”と呼んでいます。
出典:http://www.cds21solutions.org/osj/j/family/index.html

・MSF
 フレームの位置はMSFで示されます。「Minute,Second,Frame」のことです。トラックごとのMSFは、INDEX01の先頭が1フレーム目(走行時間0=00m00s00f)です。
 INDEX00期間では“減算”されて最後の走行時間が0になるように割り振られるようです。2秒であれば最初のフレーム番号が00m01s74f、最後が00m00s00fということでしょう。後述するようにCDプレーヤではINDEX00期間は「マイナス表示」ですが、フレーム番号から算出する秒数にマイナス記号付ければよいようにしてあるということでしょうか。

・AMSF
 MSFは「トラックの中におけるフレームの位置」を示します。一方、ディスク全体の中での位置(絶対位置)はAMSFとして記録されており、その起点はプログラム記録領域のスタート位置(つまりトラック01のINDEX00の最初のフレーム)です。走行時間を0=00m00s00fにセットすることになっています。サブコードやTOCでトラックと同様に扱われていることから、AMSFはリードアウトまで貫通していると理解しています。
 なお、リードインにはAMSFパラメータはありません(同領域はTOCのための“PMSF”に用いられている。MSFはある)。

#余談:MSFとAMSFの仕様を見ると、リッピングソフトの時間(フレーム)表示やCDプレーヤの演奏時間表示はMSFやAMSFそのままではなく“計算されたもの”と考えた方がよいでしょう。例えば、≪EAC≫のトラック01開始時間表示はINDEX00が通常の00m02s00f分のタイトルでは00m00s00fですが、00m02s37f分あるタイトルでは00m00s37fですので、AMSFそのままではなく00m02s00f分マイナスしています。ただし、≪CD Manipulator≫のようにそのまま表示するものもあります。

・LBA
 フレーム位置としてMSFではなくLBA(Logical Block Address)が用いられることもありますが、「フレームとセクタ」と同じく、少なくともCD-DAにおいてはMSFだけ意識しておけばよく、LBAは無視していいと判断しています(JISではCD-ROMにもCD-Rにも出てきません)。

#余談:MMC的にはLBAはAMSFから150フレーム進んだ位置になります(リードインなどのヤヤコシイ事情は別として)。つまり通常ならトラック01のINDEX01期間の先頭フレームを起点とするようです(トラック01のINDEX00期間はマイナスになる)。ですが、CD-DAにおいてはトラック01のINDEX00は150フレームちょうどと規定されていませんので、トラック01のINDEX01の最初のフレームが必ずLBA起点になるワケではありません。

・サブコード
 フレームを構成するデータが揃うと揃うサブコードはP,Q,R,S,T,U,V,Wの8チャンネルありますが、リッピングに関係にあるサブコード=Qチャンネルに絞ります。さらに、Qチャンネルには3モードありますがモード1に絞ります(モード2と3はオプション。稿末に記述)。
 オーディオトラックとリードアウトトラックの各フレームのサブコードには以下の情報が入っています。「トラックのプロパティ」のような情報ですね。
  ・トラック番号
  ・INDEX番号
  ・トラック内におけるフレーム位置(MSF)
  ・CD内におけるフレーム位置(AMSF)
  ・エンファシス有無
  ・デジタルコピー許可・禁止(事実上未使用)

#余談:リードアウトトラックもオーディオトラックと共通フォーマットですので、再生対象ではないのにエンファシスなどの項目があります。無意味な気もしますが、「オーディオトラックとして符号化する」とあることも合わせて考えると、万一CDプレーヤがオーバーランなどして“音声トラックとして”読む可能性を(読んでも大丈夫なように)想定しているのかも知れません。TOCのスタート位置精度は±1秒ともありますので、読んじゃう可能性あるのかも。
 さらに、トラック01の前には2秒以上のINDEX00区間を必須としていることを考え合わせると、一方リードインは読まないようにする想定なのだと思われます。
 もちろん、「規格策定当時、CDプレーヤで再生する」ことを想定した設計として、です。

・TOC
 「Table Of Contents」のことです。CDの「目次」または「概要説明」です。リードイントラックのサブコードに「自トラックの情報」ではなく「CDタイトルの情報」として以下が繰り返し入っています。
  ・最初のトラック番号
  ・最後のトラック番号
  ・各トラックの開始位置(事実上INDEX01のAMSF)
  ・リードアウトトラックの開始位置
  ・各トラックのエンファシス有無
  ・各トラックのデジタルコピー許可・禁止(事実上未使用)

 CDプレーヤやリッピングソフトは、まずこのTOCを読んで各トラックの位置やエンファシス有無などを把握します(ただしINDEX00位置は解りません)。一般的なリッパーはTOC情報に基づいてトラック分割やエンファシス処理を実施します(なのでINDEX01位置でしか分割できません)。実トラックを読みにいかなくても全体像が把握できるようになっているワケですが、トラック内サブコード情報とTOC情報が合致していないタイトルもあることがリッピングをヤヤコシクしています。

#余談:MacOSなら「drutil」というコマンドでTOC読めるらしいですね。


■CDデータ構造図(読本の読解による)

 読本の記述に則り、ここでは588bitの最小単位を「フレーム」として記します。

・フレーム(588bit)98個で構成されるSCフレーム(シンボル間結合bitは省略)
CDフレーム

・各シンボルのビットは縦に並んでおり、フレーム01のシンボル01から縦にシリアルに読み出すイメージ。
・「EFM」はもと8bitのデータがCD盤面記録用14bitに変調された状態を示す(ただしS0とS1はEFMパターンとしてのみ利用)。
・CIRCデータ計24シンボルは計8シンボルのCIRCパリティと共にEFM解除された後CIRCデコードされて24Byte=6サンプルになる。

・EFM解除された(S0,S1以外)サブコーディング8bit(=8ch)96個
CDサブコードチャンネル

・コントロール:音声チャンネル数(事実上2chのみ)、コピー許可禁止(事実上未使用)、エンファシス有無を示す。
・アドレス:チャンネルのモードを示す。
・データ:TNO,INDEX,MIN,SEC,FRAME,AMIN,ASEC,AFREME。詳細は以下。
・CRC:コントロール・アドレス・データのエラー検出用コード。JISに「CRCは,CONTROL,ADR及びDATA-Qに関する16ビットの誤り検出コードであり~」とあることから。

・サブコーディングQチャンネル(モード1)のデータ部
CDサブコードデータ

・4bitずつのBCD符号でそれぞれ2桁の10進数を示す。


■余談

・容量
 JEITA(*1)や磁気研究所(*2)によると、音楽CDは74分、CD-R(CD-ROM)は650MBとなっています。
 74分は333,000フレームです。CD-ROMでは1フレーム(セクタ)にパリティなどを除いた“真水”データを2048Byte記録しますから681,984,000Byteとなります。これを1024で2回割って1024単位系のMBで表すと確かに650MBになります。
 ちなみに74分の1644PCMは783,216,000Byteとなります。パリティなどを付加してデータを記録する場合はざっくり87%相当になるということですね。

*1:https://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=233&ca=14
*2:http://www.mag-labo.com/?p=1142

・ISRC
 ≪EAC≫に設定があります。
 モード3のQチャンネルで記録される情報です。
 「International Standard Recording Code」の略称で、そのトラック音楽の録音IDのようなものです。
 必須ではありません。読みだしてCUEsheetに記載する場合もあります。
 詳細は「JIS-X0308 国際標準レコーディングコード(ISRC)」に定められています。

・UPC
 ≪EAC≫に設定があります。
 モード2のQチャンネルで記録されるPOS情報です。
 「Universal Product Code」の略で、米国やカナダで使用されている商品コードとのこと。POSコードの具体的規格名ですね。欧州系の「EAN(European Article Number)」もあります。
 必須ではありません。読みだしてCUEsheetに記載する場合もあります。


メインメニューへ

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

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

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:節電記事のみ例外)

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