FC2ブログ

いまさらながらの「HDCD」

19/11/20初稿

 「HDCD」の存在は知ってはいましたが、特に興味はありませんでした。
 が、ふとしたことから「知らずに所有しているかも知れない」ことを知り、調べてみたら確かに持ってました(苦笑)。
 ということで、いまさらながらHDCDについて。


■HDCDとは

・概要
 「High Definition Compatible Digital」の略です。紛らわしいですが公式には「HDな音楽CD」ではありません。CDに限った技術ではないから、かも知れませんが、事実上CDに限っていいでしょう。
 Pacific Microsonics Inc.社が開発したCD-DA互換でCD音源を高音質化する技術ですが、PMI社は2000年にMicrosoft社に買収されたとのことです。
 買収したのですから当然ですが、当初MS社はHDCDを推していたようです(だから≪WMP≫にデコード機能がある)。
 が、いつの間にかフェードアウトしてしまいました。


Reference Hdcd Sampler
(Amazonアソシエイト)

#調べていると、HDCDに関する情報はかなり錯綜しているように思います。これは、オープンな技術資料がない(少ない)ことに加え、MS社が推しのために「20bitだ」とかちょっと紛らわしい喧伝したためではないかと想像しています。

 今となってはいわゆるオワコンと言っていいでしょうし買った覚えもなかったので気にしていなかったのですが、実は以下の通りだと知って無視できなくなりました。

・HDCDロゴがないのにHDCDエンコードされているタイトルが存在する
・スキャンしてみたら実際持っていた
・リッピングファイルをソフトウェアデコードできる
・つまり対応プレーヤなどのハードウェアが無くても活用できる
・リッピングをやり直さなくても活用できる(ERIは無加工WAVEなので)

 DVDプレーヤ用ICにデコーダが内蔵されていたようで、一時期のDVDプレーヤには対応機種が多くあるようです。

・技術
 現時点では「対応プレーヤ」で再生することは現実的ではありませんが、リッピングしたファイルはPCソフトで24bitにデコードできます(以下、特記なき“デコード”はPCによるソフトウェアデコードを指します)。そのため、HDCD技術について知っておきたいと思います。
 上述の通り何が正しいか判断するのはなかなかに難しいのですが、いろいろ調べた結果と公式サンプラーなどで実際に波形をチェックした結果から、私なりの理解を記します。

 AD変換時の技術は無視します。上述の通り興味の対象はソフトウェアデコードですので、それにほぼ関係ないためです。

(1)高域集中型ディザ
 16bit化する際、「高域集中型ディザ」を用いることを特長にしています。
 ですが、ビット深度を減らす際(丸めの際)に付加するディザの一種とみなし、特別扱いする必要はないでしょう。いずれにしてもデコードに影響しませんし。

(2)動的フィルタ特性
 再生時の2倍アップサンプリング(リコンストラクション)フィルタを、ダウン時に応じた特性に動的に変更できるようにしているようですが、本当に動的なのかはヨクワカリマセン。
 まあ、そういうアップサンプリングするソフトウェアデコーダじゃない限り関係ないと言えますし、かつそういうデコードソフトは寡聞にして知らないので、“どっちでもいい”ことにします(苦笑)。
 繰り返しになりますが、それに対応したDA変換(対応CDプレーヤ内のDACなど)は興味の対象外です。

(3)ピークエクステンション(PE)
 一種のコンプレッサと見ればいいでしょうか。0dB~-9dBをノンリニアPCM化して0dB~-3dBに収めるようです。デコードすると差分の6dB分ピークが伸長されたことになります。普通の16bitより6dB増えるのですから、17bit相当のダイナミックレンジが得られるという寸法です。

(4)ローレベルエクステンション(LLE)
 PEとは逆に、音量が小さい区間をブーストして記録します。この際、下位bitに2~3bit相当の分解能アップがあるという触れ込みで、PEと合わせて「約20bit」ということのようです。

(5)制御コード埋め込み
 HDCDであることを示すのは当然として、エンコードがかかっている場所が16bitの最下位ビットに特定パターンとして埋め込まれます。といっても楽曲全体ではなく間欠的な微小時間であり、最下位ビットの高速な変化は「高域ディザ」と見なせるので音質的影響はないというリクツのようです。
 「HDCDは1bitを制御コードに使っているので15bitしかない」というのは正しいとは言えないでしょうし、確かに実質的影響はないと思いますが、「実はコード埋め込みを正当化(?)するために高域集中型ディザを導入した」ような気もしないではありません(苦笑)。
 なお、不可逆圧縮したり音量をいじったりイコライジングしたりして改変すると制御コードが壊れますのでデコードできません。
 また、リクツ的には、エンコードされたところでリッピングエラーの補間が発生したらデコード失敗する可能性あるのかも知れませんが、もしそうなっても基本的に互換だから大丈夫ってことかな、と推察しています。
 ちなみにエンコードはトラックごとです。

・何が標準で何がオプションか
 「コード埋め込み」は当然必須です。「高域集中型ディザ」はHDCDを名乗るのに必須っぽいですがデコードには関係しません。「動的フィルタ特性」はヨクワカリマセンが、これも上述の通り事実上デコードに関係しませんのでワカラナイままでいいことにします(特に以下に示す「隠れHDCD」では採用例少ない(?)ようですし)。
 PEとLLEはどうもオプションみたいです。
 LLEはあまり採用例はないようです(特に以下に記す「隠れHDCD」では?)。また、デコードでは24bit化されますので(16bitの次はフォーマット的に24bitなので)有効性はに関係なく下位bitのフォーマット的拡張は十分ですから、LLEが効いているのなら気にしなくても反映されるでしょう。
 一方、PEについては注意しないと伸長した分反映されずに潰れてしまいます。

 ですので、「いまとなっては、ソフトウェアデコードにおいてPEだけ意識しておけばよい」と思います。

 なお、言うまでもありませんが、デコードで24bit化されるからと言ってHDCDは24bitハイレゾというワケではありません。


■「隠れHDCD」をどう扱うか

・「隠れHDCD」とは何か
 これが今回の記事作成のきっかけです。承知で買っているならいいのですが、「HDCD」のロゴがないのにHDCDエンコードされたタイトルが存在するのですね。
 「真性HDCD」はAD変換から特徴的技術を用いているようですので、それらも含めてHDCDだと言ってるとするなら、PEなどのオプションだけ使ったような場合はHDCDを名乗れないのかも知れません。
 なんとなく「音楽制作者がPEやLLEを単純に“コンプの一種”としてしか意識していないから」な気もしますが…(苦笑)

 一応通常の音楽CDと互換なのでそのまま聴くことはできますが、エンコードされてるのですからできることならデコードしたい気がします。
 なんだかエンファシスと同じようなハナシですが、こちらはCD標準規格ではないところが異なります。

・「隠れHDCD」の見つけ方
 いくつかありますが、リッピングしたファイルではなくディスク直でしたら「≪WindowsMediaPlayer≫で再生してみる」のが一番手っ取り早いでしょう(マウントだけではダメです)。
 ウィンドウの左下に(ちっちゃく)「HDCD」ロゴが表示されます(ディスク直のみです。ファイル再生では表示しません)。

HDCD WMP

 いちいちディスク再生しなくても、リッピングしたファイルに対しては≪foobar2000≫を用いる方法があります。簡単かつ対応機能情報もとれるのでオススメです。「foo_hdcd.fb2k-component」をインストールした≪foobar2000≫に既存ライブラリのファイルをどっさり登録し、Utilitiesから「Scan for HDCD tracks」を実行するだけで以下のようなレポート出してくれますので、手間はかかりません。

HDCD fb2k

・「ニセ隠れHDCD」ではないか
 ロゴがないのですから何があっても不思議はないかも知れませんが、上述の手段でHDCDと表示されながら「PE:Disable、TF:Disable、gain:0dB」「PEがEnableだがピークが実効性がある程度に圧縮されているようには見えない(≪foobar2000≫でデコードすると-6dBされ“ほんのちょっとだけ”ピークが尖る)」といったファイルもありました。
 これには以下のような可能性が考えられますが、真実はワカリマセンね。

・マスタリング時に意図せずエンコーダがONしておりHDCDを示すコードだけが入ってしまった
・または意図せずPEなどが働いた
・HDCDエンコードであることを知らずにデータをいじってしまっておかしくなった(ベスト盤収録時など)
・高域ディザなどだけがHDCD仕様(制御コード入れる意味はありませんが…)
・制御コード誤検出

 HDCDだと検出されても、その効果について関心がある場合は、実際にはどうなのか波形を見たりして確認する必要がありそうです。

 なお、「PE:Disable、gain:0dB、FT:Intermittent」と判定されたタイトル(ピークはまるまっておらず潰れている)は、≪foobar2000≫でデコードしたファイルと元ファイルに下位8bitをゼロ詰めしたファイルがWAVコンペア一致しました。当然-6dBされていません。
 つまり「デコードしても下位にゼロ詰めして24bitにしただけ」なワケで、やっぱり「フィルタ特性」機能はファイルオーディオでは無視していいと思います。その意味では、対応プレーヤなどでHDCDだとなってもファイルオーディオにとっては普通のCD、というケースもあるということですね。

 「隠れ」でHDCDエンコードしてもいいですけれど、ヘンテコなことはしないで欲しいです(苦笑)。

・デコード方法
 デコードファイルを生成する無償の方法をいくつか。

 ≪foobar2000≫を上記の通りオプション拡張、ConvertのProcessing設定でHDCDデコードを有効にして24bit出力すればOK。
 リッピングすればリアルタイムデコードになりますし、CDダイレクト再生にもファイル再生にも適用されます(再生音量が半分になることから)。
 ≪CUETools≫でHDCDデコードをONにして≪CUERipper≫で生成したCUEシートを指定。
 ≪HDCD.exe≫。CUIですけれど。
 ≪TuneBrowser≫ではリアルタイムデコードリッピングできます。

 公式SAMPLERにおいて、≪foobar2000≫と≪TuneBrowser≫のデコード結果はWAVコンペア一致しました。
 ≪CUETools≫と≪HDCD.exe≫は一致しました。
 前者と後者は一致しませんが、バイナリを見ると、相違はデコードされた箇所で後者は下位4bitがゼロ(つまり20bit)になっている点のようです。
 後者は「HDCDは20bit相当ですよね、だったらそれ以下はどうせ演算誤差だから」として敢えて20bit化しているのかも知れません。
 デコード機能・性能の違いではなさそうです。

#≪MusicBee≫もプラグインを入れればイケるようですが未確認です。
 ≪WindowsMediaPlayer≫は、HDCD対応に設定してもリッピングでデコードしません。同S/PDIF出力をデジタルキャプチャすると、デコードされていませんがHDCDだと認識されないファイルになりました。DirectSoundは16bitだとLSBがバケますから大丈夫なのかと思っていましたが予想通りダメなようです。DSにはピークリミッタ問題もありますから、PEエンコードされた部分もおかしくなってしまうかも知れません。推しのハズなのにこの塩対応… 何のために買収したんでしょう?


■実際の効果を見る

・ピークエクステンション(PE)
 発見した隠れHDCDの、あるトラックのPE波形を示します(R-ch)。公式SAMPLERではないのは、こちらの方がより変化が判りやすかったためです。

 1番上・・・リッピングファイル
 2番目・・・下位8bitにゼロ詰めして24bit化、≪Wavosaur≫で-6dB化
 3番目・・・≪foobar2000≫でデコードした24bitファイル
 4番目・・・≪foobar2000≫でデコードした24bitファイルを≪Wavosaur≫で+6dB化

HDCD PE波形(hl-Lch)


#≪Wavosaur≫で「Volume ±6dB」すると1bitシフトになることは別途確認済み(ただし波形編集ソフトなのでもちろん+する場合はWAVE形式として処理されるので注意)

 1番目で、素のままだとピークが圧縮されている様子が解りますね。そして、2番目と3番目を比べると、デコードすると全体的に-6dB小さくなり、その分のヘッドルームにピークが伸長されていることも解ります。
 つまり17bit相当になってるということですね。
 ところで、2番目のファイルを反転して3番目のデコードファイルとmixするとエクステンションが働いていないところのサンプル値はゼロになります(働いていないところでは1bitたりとも変化していないということでもあります)。つまり、24bit化して-6dB(下位方向に1bitシフト)して元のLSB情報は失われていない状態からデコードしていると推定されます。

 よく「HDCDはデコードすると音が小さくなる」と言われますが、ピーク伸長しているので当然ですよね。HDCD対応プレーヤなどでは普通のCD再生も-6dBして音量レンジを合わせていたようです。しかし、ファイルオーディオにおいて他より音が小さいからと+6dBすると、当たり前ですが伸長した分が潰れます(4番目参照)。
 ということで、言うまでもありませんが、デコード前後を比較試聴する場合は音量違いに留意する必要があります。上図で言うと、3番目(デコード結果)との比較には1番目ではなく2番目の方が適しているのでは、ということです。

#「PE非対応LLE対応」などのファイルでデコード結果の最大音量が-6dB以下でしたら潰れませんけれど。

 なお、≪foobar2000≫のHDCD decoderには「Halve output volume」なる設定があり、「しない」「常に実施」「PEを検出した時のみ実施」と、Halve=-6dB化する条件を選べます。≪foobar2000≫、流石…

 PEには「疑似17bit化」の効果はありそうです。ただし、トラックのそこらじゅうで発動しているワケではなく、ピンポイントで使われているようです。「突出するピークがある時に用いる機能」ということですので、本来当然だとは思います。

・ローレベルエクステンション(LLE)
 こちらは、発見した「隠れHDCD」で対応しているものはありませんでしたので、「RR-S3CD:HDCD SAMPLER (Vol.1)」を用います(L-ch)。

 上図・・・≪foobar2000≫でデコードした24bitファイル
 下図・・・「デコードファイル」と
      「元ファイルに下位8bitにゼロ詰めして-6dBして波形反転したファイル」をmix

HDCD LLE波形(Rch)

 縦軸のレンジが異なるので注意してください。

 PEが発動するようなレベルではないので、この差分はLLEで発生したものと考えていいと思います。
 下図はデコードして発生した「元の16bit以下」のデータということになります。16bitだと-90dB(±1)と-∞dB(0)にしかサンプルはないハズですが、確かにその間のレベルのサンプルも出現しています。
 これもPEと同じく、トラックそこら中というワケではなく逆にほとんど発動していないようです。
 そして、PEもLLEも発動していない区間は前述の通り反転mixするとゼロサンプルになりますので全く変化はありません(下図の-∞dB部分のサンプル値はバイナリエディタで見ると実際にゼロ)。

・実際のデータ
 繰り返しになりますが、デコードしたら24bitファイルになったからと言って、もちろん24bit解像度ではありません。では、どんなデータになっているのでしょうか。

 下位bitがゼロでない部分をバイナリエディタで示します。ただし、見やすくするためさらに下位8bitにゼロ詰めして32bit化(もちろんFixed)したものです。左から4ByteずつR-L-R-Lchのサンプルとなります。
 Intel形式ですので4Byte単位でひっくり返してみる必要があります。

HDCD fb2kでdecodeしてwcpで32bit化したバイナリ

 これを見ると、Lchはずっと80hか00hです。PEするために-6dB(下位へ1bitシフト)して下位8bitのMSBになった「元16bitの時のLSB」がゼロとイチでパタパタしてるってことですね。
 Rchでそれ以外の値になっているのがデコードされたサンプルだと思います。24bitフルにゼロイチが変動していると言っても演算結果としてのものですから、これをもってダイナミックレンジが何bit拡大したかを言うのは困難でしょう。発動しているのは楽曲のごく一部分ですし。

・HDCDをどうとらえるか
・波形を観察してみるとPEもLLEも発動しているのはごく一部のようです。制御コードがあるところが発動箇所と思われますので、ざっくり10%程度というところでしょうか。
 ので、「HDCDは20bitの情報量を16bitに詰め込んだCD(デコードすると20bitになるCD)」というのは当たらないと思います(いずれにしても圧縮ですし)。

・LLEが2~3bit分の拡張に相当するかどうかは微妙な気がします。LLEはヘタにかけると互換CDとして問題になりそうな気もします。

・PEは「ピーク潰しマスタリングよりマシ」と考えればデコードしなくてもいいかも知れませんし、デコードすれば明らかな違いがありそうです(実際聴いてどうかは別)。

・発見した隠れHDCDのうち、LLEがEnableになっているものはありませんでした。動的フィルタ特性は気にしないことにしますので、事実上考慮すべきはPEだけでした。

・44.1kHzデータにおけるデコード差分はそのまま聴こえるワケではありません。イマドキはオーバーサンプリングデジタルフィルタで波形復元されるため、その結果が実際に聴く差分となります。そこで、PE検証の2番目と3番目のファイルをResampler-Vで8倍し、一方を反転mixして「再生される差分」を抽出しました。

 上図・・・オリジナル
 下図・・・差分

decode差分

 時間軸を拡大して見ると差分発生は断片的なのですが、差分ファイルは普通の音量でもハッキリ聞こえました。この音源はデコードするしないで差が判る気がしたのですが、あながち気のせいじゃないかも知れません。


 ということで、

・LLEはとりあえず無視してよい(採用少ないようですし)
・PEの1bit拡張はそれなりに有益
・HDCDの効果は疑似17bit化できること
・特にエンコード箇所が多い音源はデコードしないと劣化状態で聴いてることになりそう

と考えておこうと思います。


 これからはリッピング時に「隠れHDCDじゃないか」「ニセ隠れHDCD(フラグが立ってても機能していない)じゃないか」チェックしないと、です。


 なお、上記結果は手持ちのソフトウェアデコード環境における結果ですので、「対応CDプレーヤ」などでの公式ハードウェアデコード結果が同じである保証はありません。≪foobar2000≫らのデコードに問題ないことも前提です。


#ソフトバージョン
 ≪foobar2000≫1.4
 ≪HDCDdecoder≫1.19
 ≪Wavosaur≫1.3.0.0
 ≪WaveSpectra≫1.51
 ≪WindowsMediaPlayer≫12.0.18362.418
 ≪Bz≫1.62


メインメニューへ

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

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

19/10/17初稿

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


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

 まず押さえておきたいのは、「音楽CDの規格はリッピングなど想定していない。“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の前へ巻き戻し”できる機種なら再生できるようです。SONY製CDプレーヤ:CDP-770(88年発売のCD専用機)では確かに巻き戻して再生できました(ディスプレイ表示はTRACK1、INDEX0、走行時間はマイナス)。

#CDP-770では一般的な00m02s00fのINDEX00も-2secまで巻き戻しできました。00m02s37fのタイトルは一瞬-3secになるのを確認。

 リッピングでは、「プリギャップを自トラック先頭にくっつけるモードでリッピングしてから分離する」などの手が考えられますが、例えば≪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≫でのトラック単位リッピングにおいて「サンプル欠落や存在しないサンプルの付加などはない」ということですね。
 ≪CUERipper 2.1.6≫でも大丈夫でした(対象タイトルは先とは別の全4曲CDですが)。
 もちろんすべてのリッパーでそうであるかは不明ですが、大丈夫な可能性高いのでは。

・≪WindowsMediaPlayer≫の不思議
 本項19/10/27追記:≪WindowsMediaPlayer 12.0.18362.418≫は、ギャップ読みは大丈夫ですが最終トラック末尾を1フレーム(588サンプル)取りこぼすようです。

 全4曲のCDにおいて、≪iTunes 12.10.0.7≫≪EAC Ver1.3 from 2 September 2016≫≪CUERipper 2.1.6≫はそれぞれ全曲上述の通り一致しますが、≪WMP≫だけ上記の結果になりました。
 TOCやサブコード情報による曲長から算出されるサンプル数は≪WMP≫だけ異なります。
 BDR-S09JとGGC-H20Nで同じ結果になりましたのでドライブ依存ではないでしょう。
 もう1タイトル最終トラックをリップしてみたところやはり1フレーム少なくなりましたのでタイトル依存でもないと思います。

 聴いて判るものではありませんし、もしかしたら“取りこぼし”ではなくリードアウトの直前1フレームを敢えて読んでいない(安全のため?)のかも知れませんが、「パーフェクト・リッピング」には適さないですね。

#なお、当比較は≪EAC≫≪CUERipper≫のオフセット補正はオフして行っています。「≪iTunes≫はオフセット補正していないから」です。オフセット補正については本項から離れる話題なので別稿にて。

・「トラック単位でもサンプル増減なくリッピングしているか」確認方法エトセトラ
 本項19/10/26追記:上記の確認は、マキシシングル、ミニアルバム、8cmCDなどの収録曲が少ないタイトルの方がメンドクサくなくていいですね。
 ファイルのサンプル数確認方法をいくつか記しておきます。

・≪foobar2000≫≪Wavosaur≫などに読み込ませればプロパティで確認できます。
・≪iTunes≫では「曲の情報/オプション/停止」がトラックの長さになっています。秒以下は1/1000単位ですので75を掛ければフレーム数になります。総秒数に75を掛けてフレーム数を算出し、秒以下のフレーム数を足し、588を掛ければサンプル数になります。
・余計なことしていないWAVファイルなら、ファイル容量から44Byte引いて4で割ればサンプル数になります。

・トラック単位でリッピングしたらプリギャップはどこへいく?
 プリギャップは前トラック末尾にくっつけるのが一般的です。設定できないリッパーではそうなっているようですし、設定可能な≪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≫による再生において曲間に本来存在しないギャップはない」と言えます。

#キャプチャの冒頭末尾は当然ファイルのそれと一致しませんが、ゼロサンプル詰めになりますので≪WaveCompare≫なら無視して比較してくれますので。

・「トラック単位でもサンプル増減なく再生しているか」確認方法エトセトラ
 本項19/10/26追記:「自分のお気に入りのプレーヤソフトがファイル間ギャップや欠損なく再生できているのか確認したいけれど、S/PDIFキャプチャできるデバイスなんて持ってない」という場合も当然あるでしょう。
 そこで、「WindowsデフォルトサウンドAPIのDirectSound」と「PC標準装備」でデジタルループバックする方法をひとつ紹介しておきます。
 ≪Audacity 2.1.0≫を用いる方法です。対応しているサウンドデバイスなら、デバイス内部で(外でケーブル繋がなくても)「ループバック」録音できます。以下Realtek製デバイスの設定例です。

  ・「編集/設定/デバイス/ホスト」で「Windows WASAPI」を選択
  ・「編集/設定/デバイス/録音」で
   「Realtek Digital Output (Realtek HIgh Difinition Audio) (loopback)」を選択

 そして、プレーヤをDigital Output(S/PDIF)からの再生に設定すれば録音できます。

#≪Audacity≫に限らずloopbackが選択できるソフトなら可能でしょう。また、PCの再生音を録音するツール(例:≪WaveClipper≫)を用いる手もあります。

 DirectSoundだとDigitalOutでもWindowsサウンドミキサーを通りますからそれに関する注意は必要ですし、万全を期してもビットパーフェクトは無理です(WAVコンペアはできない)。
 が、時間軸上の誤差は生じないハズですし微小ノイズが混入しても波形が崩れるレベルにはならないでしょうから、得られたファイルを波形編集ソフトで比較すれば表題の確認はできるでしょう。

#WASAPIやASIOを使えるプレーヤばかりではありませんから、DSで再生する例にしています(WASAPI再生・WASAPI録音は上手くいかなかったという事情もあり)。

 簡易的には、クラシックやライブなどトラックに切れ目がないハズのタイトル(自分で切れ目がないCDを焼いてもいいでしょう)を再生して“耳で確認”でもいいと思います。
 この方法は“完璧”ではありませんが、聞き取れない=実質的には問題ないということですので。
 万一後日サンプル増減が発覚したとしても、ファイルを改変してしまったワケではありませんからプレーヤソフトを選びなおせばいいだけですし(リッピングとは重要度が違います)。

・いわゆる「ギャップレス再生」のいろいろ
 ただし、上記はWAVファイルをローカル再生する場合のハナシです。ERIとしては扱っていないので確定情報ではありませんが、ネット情報によると、「ポータブルプレーヤにおける圧縮ファイルの連続再生」「ネットワークオーディオ」などではファイル間ギャップの発生はありえるようです。
 その場合は、ギャップレス再生とは「本来存在しないギャップが発生しないようにする機能」を指すワケですね。マッチポンプ的な名称?(笑)

 また、ファイルにある“プリギャップ”を削除して再生することを指す場合もあるようなないような。

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


■余談

・リッパーは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でも同じでした。
 SONY製CDプレーヤ:CDP-770ではマイナスカウントが確認できました(ディスプレイ表示はTRACK15、INDEX0)。

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


図解 コンパクトディスク読本
(Amazonアソシエイト)

#JIS-S8605は2016年に廃止されてしまいましたが、一度制定された規格が(追加はあれど)変わることはないので問題ないでしょう。廃止理由は「レッドブックもあるしIEC608もあるから」ですし。

・結論から: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の先頭フレームを走行時間0(=00m00s00f)として加算されていきます。MSFはリードインにもあり、同じく加算ですが開始走行時間は0でなくてよいことになっています。
 INDEX00期間では“減算”されて最後の走行時間が0になるように割り振られます。2秒であれば最初のフレーム番号が00m01s74f、最後が00m00s00fということでしょう。後述するようにCDプレーヤではINDEX00期間は「マイナス表示」ですが、フレーム番号から算出する秒数にマイナス記号付ければよいようにしてあるということでしょうか。

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

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

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

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