FC2ブログ

リッピングエラーをリッピング後に修復する

19/03/01初稿

 いわゆる「セキュアリッパー」も進化してるんですねぇ。
 とあるきっかけで≪CUETools≫の「Repair」なる機能を知って試してみたのですが、こんなことまでできるようになってるんですねぇ。
 ERIは“PureReader”なので(DB照合サービスは使っていないので)長らく気が付きませんでした(苦笑)。


・≪CUETools≫のリペアとは何か
 ≪CUETools≫システムは、「CTDB(*1)」なるCDリッピングに関する独自のDBを持っており、連動するリッパー≪CUERipper≫におけるリッピング時に参照して成否を判定する機能があります(本BLOGではこれを「DB照合サービス」と呼称)。同種サービスとしては≪dBpoweramp≫などが採用している「AccurateRip(*2)」が有名ですよね(本稿では一般名詞ではなく固有名詞(商標かな?)として記述)。

*1:http://cue.tools/wiki/CUETools_Database
*2:http://www.accuraterip.com/

 なお、CTDBもAccurateRipも特定リッパーの専用機能ではありません。実際、≪CUETools≫システムはCTDBだけでなくAccurateRipサービスを併用しています(設定画面を見るとリッピングだけでなくリペアでも?)。

 CTDBはオフセット対応などを強化した仕組みのようです。その中に、なんとエラーを内包してしまったリッピングデータを「リペア(修復)」する機能があります。説明サイトの記述によると、成功したリッピングから照合値(*)以外にも“そのための”データを収集することによって実現しているようです。

180KB recovery record (about twice that for more popular CD's), which is stored separately and accessed only when verifying a broken rip or repairing it.
出典:http://cue.tools/wiki/CUETools_Database

*:リップ結果データのチェックサム的な値ですが、ハッシュ、チェックコード、CRCなどいろいろな呼び方があるので、無難(?)に「照合値」としました。

 おぉ、確かにそういう手もありますね。よく考えるものだなぁと感心しました。
 もしキチンと作動するなら、どうしてもエラーが発生してしまうCDを救済できる場合があるかも知れません。だとしたらものすごく有益な機能ではありませんか。

 ということで試してみました。

・C2エラーしてしまうCDでリペアを試す
 CIRCは十分強力ですが、手元には、PureReadのパーフェクトモードで停止してしまう(C2エラーが発生してしまう=補間発生してしまう)CDが、流石に何枚かあります。大半は傷つけてしまった(傷ついていた中古)ディスクです。
 その中から、ふたつのトラックにC2エラーがあるCD(結果的にエラー数が例として適当だったので選定)で、リペア機能を試してみます。
 ≪CUETools≫は、その名の通りリッピングしたファイルやCUEシートについての編集ツールです。リッピング自体は≪CUERipper≫を用います。

#≪CUERipper≫でリッピングしたファイル以外はリペアできないワケではないかも知れませんが、本稿ではベーシックな使い方としてセットで用います。

 ところで、≪CUERipper≫はBurstモードでもPureReadのリトライリードが発生するとエラーになるようです。ドライブが勝手に何かやってるのを待たないようですね。説明ページによるとドライブから上がってくるC2Error情報を見ているようです。≪EAC≫と同じく16回で1セットのようですが、何セット繰り返すかはエラー次第の模様。
 ということもあり、本稿のドライブはエラー発生具合がちょうどよかったGGC-H20Nを用いました。

 まず、≪CUERipper 2.1.6≫でのリッピング結果ポップアップを示します。

リペア推奨メッセージ

 CTDBと照合すると371個の異なるサンプルがあり、疑わしいセクタ(音楽CDとしてはフレーム)が60個あると言っています。リペアを試みろと推奨されていますね。
 ちなみに、どんなエラーでもリペアできるワケではないのは説明ページにもある通りです。実際、別のもっと酷いエラーが出るCDでは以下のようなポップアップが出ました。

終了ポップアップ(S05Jエラーあり:多すぎてリエア推奨されず)

 リペアの可能性は無いようです。

 さて、「このリッピングはどんな結果だったのか」は、生成される.accuripファイルに記述されています(拡張子はナニですがテキストファイルです)。
 当該CDのCTDBに関する部分を抜粋します(samples後の数字には表示を考慮した改行を入れています)。

Track | CTDB Status
1 | (126/126) Accurately ripped
2 | (126/126) Accurately ripped
3 | (126/126) Accurately ripped
4 | (126/126) Accurately ripped
5 | (125/126) Differs in 261 samples @02:14:23,02:14:48,02:15:10,02:15:23,02:19:35,02:19:48,02:19:60,02:19:73,
02:20:10,02:20:36,02:20:48,02:20:60,02:20:73-02:20:74,02:21:10-02:21:11,
02:21:35-02:21:36,02:21:48-02:21:49,02:21:60,02:21:73,02:22:11,02:22:35,
02:22:48,02:22:60-02:22:61,02:22:73,02:23:10,02:23:23,02:23:60-02:23:61,
02:23:73,02:24:23,02:24:48
6 | (126/126) Accurately ripped
7 | (126/126) Accurately ripped
8 | (126/126) Accurately ripped
9 | (125/126) Differs in 110 samples @04:39:23,04:39:39,04:39:56,04:39:72,04:40:12,04:40:29,04:40:44-04:40:45,
04:40:61,04:41:01-04:41:02,04:52:64,04:53:04-04:53:05,04:53:21,
04:53:37-04:53:38,04:53:53,04:53:70,04:54:11,04:54:27,04:55:49
10 | (126/126) Accurately ripped
11 | (126/126) Accurately ripped
12 | (126/126) Accurately ripped


 AccurateRipと異なり「DBにあるこの値と照合した」といった情報提示はされないようですね。

 さて、このリップ結果ログでは、track05に261サンプル、track09に110サンプルのエラーがあると言っています。パーフェクトモードが停止したトラックではやはり訂正不可能なC2エラーが発生(補間発生)したということです。エラートラックの@の後に記されているのはエラーサンプルを含むMSFでしょう。
 それ以外の10トラックは126個のCTDB参照データ中126個と一致したと言っています(当該CDのCTDBデータは1種類しかなかったようです)。

 では、これをリペアしてみましょう。設定は以下の通りです(もちろんERI的な設定の一例です)。
 対象として指定するのは、リッピング時に生成された.cueファイルです(ちなみに下図のファイル名は“仮名”です)。

CUETools.png

 リペア終了時にはポップアップは出ませんので、結果は新たに生成される.logや.accuripでチェックします。
 .accuripファイルを抜粋します。

CUETools DB: corrected 371 errors.
[AccurateRip ID: 001659a6-00d37568-8c0c640c] found.
Track [ CRC | V2 ] Status
01 [85467f84|713a3dc7] (15+26/41) Accurately ripped
02 [402685d6|2b59a32b] (15+26/41) Accurately ripped
03 [f55fb645|0d043b26] (16+26/42) Accurately ripped
04 [f21b17aa|3c4d9454] (15+26/41) Accurately ripped
05 [fe35de57|a4e1b066] (13+26/39) Accurately ripped
06 [017e1bff|bc4b58a4] (15+26/41) Accurately ripped
07 [697fcfa6|c8c8c169] (15+26/41) Accurately ripped
08 [b9d56f16|180b8805] (16+26/42) Accurately ripped
09 [9426dd9a|a67daa25] (15+26/41) Accurately ripped
10 [9f533049|accab39f] (15+26/41) Accurately ripped
11 [38ab9001|710a127b] (15+26/41) Accurately ripped
12 [b19d08a5|c9d3bf43] (15+26/41) Accurately ripped


#ちなみに、説明ページ(*)によると
  CRC=AccurateRip V1の照合値
  V2=AcccurateRip V2の照合値
  例えば(15+26/41)の15=V1とのマッチ数
  同26=V2とのマッチ数
  同41=ARのDBにある当該CD情報の総数
とのこと。

*:http://cue.tools/wiki/CUETools_log

 CTDBとしての結果は最初の1行だけでそっけないですが、371個のエラーをcorrection(訂正)したと言っています。371個は261+110ですね。実際、track05とtrack09を≪WaveComparer 1.32≫で比較すると、リペア前後のファイルでそれぞれ261、110サンプルの相違となりました。
 そして、以下に併用しているAccurateRipとの照合結果が続いてます。エラートラック2個もCRC値やV2値と一致しており、正常にリッピングした状態に“リペア”されたということです。

・リペアされたことを“裏取り”する
 しかし、上記の結果は「リペア前後で371個のサンプルが変化した」ことを示してはいますが、“正しい値”に変化したかどうかは判りません。≪CUETools≫だけで完結している状態だからです。≪CUETools≫を疑うワケではありませんが、客観的に納得するためには、正しい値に修復されていることを何か“別手段で裏取り”したいところです。

 ここに「エラーありディスク(PureReadパーフェクトモード停止)」と「エラーなしディスク(同完走)」を持っているタイトルがあります。エラー発生状況が相応しくないので、上記例としては用いていませんが、「エラー入りファイルをリペアしたファイル」と「エラーなしファイル」の比較が一致すれば本当にリペアできたかの証左になるでしょう。

 結果、エラーが発生してしまうtrack01の≪WaveCompare 1.32≫での比較は見事に一致。

 一例だけですので万全かどうかは解りませんし、もちろん万能ではないでしょうけれど、拭いたりなめしたりしても常用環境ではどうしてもエラーが消えないディスクがあったら、当該機能を用いて“一旦リッピングした後に”リペアしてみる価値は十分ありそうです。

 いやぁ、感服しました。

・メモ
 ≪CUERipper≫の「Read Offset」設定(正確にはオフセット値ではなくその補正値)は、ドライブを認識して自動設定してくれることになっていますが、手動で変更できてしまう模様。なのでヘタにいじるとAccurareRip照会結果は混乱します。
 CTDBはディスクオフセットからもドライブオフセットからも影響を受けないみたいです(だから補正にあまり関心がなく、故に固定していない?)。トラック単位のリッピングはできずCD単位になる点など、照会や修復用のデータをディスク全体として見ているところにミソがありそうです。

 参考までに、エラーがなかった場合の終了時ポップアップを示しておきます。

終了ポップアップ(エラーなし)


メインメニューへ

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

リッピング・ゴースト

16/07/16初稿

 やっぱり気になるリッピング(笑)。もう考え尽くしたと思っていたのですが、BDR-S09J導入をきっかけにまたぶり返しちゃいました。

 本稿、ファイルはすべてオプション付いてないプレーンWAV、排他WASAPIまたはASIO再生、余計なエフェクトや変換はない前提です。
 また、リッピング結果の「エラー」とは、特記なきはC2エラー=補間発生のこととしています。


■経緯

 リッピングと音質に関してはかなり昔からいろいろ考えています。もしやり方が違うと音質違っちゃうなら、やり直しなんて大変ですから本格的にファイルオーディオ始める時に考えたんですね。
 その経緯を簡単にまとめると次のようになります。

・CDのエラー訂正とは何かを理解しておく
・C2エラー発生はPCやリッパーや振動などで変化しない

 ということで、エラー量はリッピング環境を変えても(ドライブの光学性能差は除く)フツウは変化しないと考えています。ていうか健常なディスクではほとんど発生しないようですから、万一発生した場合にそれを認識できる仕組みがあればいいと判断しました。

 さらに、

・WAVフォーマットを(とってもシンプルであることを)理解しておく
・ドライブにはオフセットがあり、それが違うことでリッピング位置が変わり、それでWAVファイル中のtrackデータ位置が変わり、前後の「ゼロサンプル」状態が変わる
・ヘッダフッタにオプションを付けるリッパーがあるので、リッパーを変えると再生動作が変わる可能性がある

 ということを考えました。
 リッピング環境が変わると曲間分割位置が変わる可能性があるので「ゼロサンプル」状態が変化します。が、その違いは音質に影響していないと判断しました(ちなみに、ゼロサンプルと呼称していますが曲間に相当するデータであってゼロとは限らず、一般的には“ゼロ近傍”です)。
 一方、ヘッダフッタが変われば(プレーヤによっては)再生動作が変化しますから、それによる音質変化は否定できません。なので余計なヘッダフッタは付けないことを原則にしています。

 そして、念押しにネット上で見かける「バイナリ違いが発生していなくてもリッピングの仕方で音質が変わる(もちろん再生環境は同一(*)でも)」ことがあるのか、“ビット品質”という概念で考えてみました。同じ0や1にも音質差がある、という考え方です。
 しかし、PCMデータをCD-DAとして焼いたCD-R/RWをエラーなしリッピングすれば元のPCMデータそのものが得られます。ドライブの電源を良質にすると抽出できる量が増えるような情報は“もともとどこにも無い”と思っているので、私はその考え方ではありません。

*:同一ストレージでも記録場所までは同時に一致させられませんので、普通これだけは違いとなりますが。

 ちなみに、「楽曲ファイルはコピーによって音質変化しない」とも考えており、本件はそれが前提となっています。

・リッピングソフトを変えると“ビット品質”が変わって音質が変わるのか

 理屈も思いつきませんでしたし、念のため試聴しても変わって聴こえませんでした。

 ということで、PureReadのパーフェクトモードで補間発生だけモニタしつつiTunesでリッピングしています。

 ところで、上記ビット品質記事に「やっぱり気になるので、リッパーだけでなくハードウェアも含めて差をつけても変わらないか」を追記していたのですが、本来は「リッピングソフトでの違い」がお題目の記事なのでちょっと違和感はありました。
 今回、ハードウェア条件違いのサンプルを追加して再試聴してみましたので、ハード違いに関してはこちらに記載し直すことにしました。
 ということで、以下「■フツウの試聴テスト」項は、13/11/02追記としてリッパー比較記事に初出のものです。大変勝手ながら、以下はその比較記事に続けて読んでいただいた方が解りやすいかと思います。

 さて、リッピングの仕方を変えてファイル生成すると、楽曲部のバイナリも再生環境も完全一致しているのに音質が違うことはあるのでしょうか?


■フツウの試聴テスト

・光学ドライブのエラーなく(補間発生なく)読める性能とビット品質は無関係
 ちなみに、光学ドライブにもし「音質のよいビット品質でストレージに記録できる性能」差が存在するとしても、「補間発生少なく読める性能」と関係あるとは言えないでしょう。例えば、低消費電力なスリムポータブルの方が低ノイズなので「ビット品質」にはいいかも知れませんよね。ダメージディスクでもない限り、普通の補間はパラパラとランダムに発生するだけで「全体的な音質差」にはなりえませんし(局所的な音質差としても聴き取れませんけど)。
 ということは前提として。

・異なる環境でバイナリ一致のファイルを作る
 一応、「電気的にノイジーだったりソフトが忙しく動いてる方が不利」じゃないかと仮定して進めます。
 以下、それに基づき無理矢理作った悪条件と好条件(⇒で示す)です。
 それなりに工夫(笑)してかなり差を付けたつもりですので、“サイテー”と“サイコー”ではないにしても何か違いは出るだろうと。

 ・CPU:3.4GHz
   ⇒  BIOSで1.6GHzに固定(スレッド数は8のまま)
 ・HDD:システムSSD+RAID1 HDD2機+2TBのデータHDD2機
   ⇒  データ用HDDを取り外し
 ・光学ドライブ:内蔵BDドライブ2機+外付けFX48
   ⇒  BDR-S05Jのみ
 ・光学ドライブI/F:PATA→USB変換→USBハブ経由で接続
   ⇒  チップセットのSATA直結 
 ・リッパー:iTunes11.0.5.5(エラー訂正あり)
   ⇒  dBpoweramp R14.4(BurstMode タグ書き込みなし)
 ・CPU負荷:TMPGEnc4.0Xpressによるmpeg2→mpeg4でほぼ100%
   ⇒  リッピングのみ
 ・ドライブ負荷:2機のBDドライブからRAID1 HDDにファイルコピー
   ⇒  リップ以外何もできず
 ・アース:部屋のアース端子からアース線を抜く
   ⇒  接続

 リッピング対象はリッパー左右比較と同じCDのtrack01です。本当は外周の方が倍速上がるので悪環境になるのですが、CDによって“最外周”って異なりますから、とりあえず最内周にしました。

 iTunesを「エラー訂正なし」にしているのは、2度読みさせて負荷をかけるためです。

 dBpowerampは逆に「BurstMode」で負荷を減らしています(C2エラー発生はないtrackなのでBurstModeで問題ないハズ)。
 また、デフォルトではなく「Disable Tag Writing」に設定しているのは、「極力余計なことしない好条件」を作るためです。

 FX48はリッピング光学性能が低そうなのでセレクト。上述の通りビット品質との関連があると思ってるワケではありませんがこれくらいしかパラメータがないので(苦笑)。電源はPCと同じタップから供給(もちろんACアダプタ)。机の引き出しの上にグラグラするように設置。

 BDR-S05Jは…まあ一応メインドライブなので。ただしPureReadはOff。FX48と同じ理由で、逆に負荷を下げるためです。対象trackはPureRead使わなくても補間エラーは発生しませんので問題ないでしょう。
 が、BDR-S05JはdBpowerampで倍速設定が「Maxかx40」しか選べません。ので、純正ユーティリティで「常時静音モード」にしました。こうするとtrack01は4倍速で読みます(dBpoweramp表示にて)。FX48は約9倍くらいでした(iTunes表示にて)。2度読みした結果なので物理的な速度は18倍くらいだと思います。
 PCの外に出し、コーリアンボードで上下をサンドイッチ(ベゼル部のみ若干上下に大きいのではみ出し)。その上に鉛の円柱を置きました。

 ちなみに、好条件=低速にしたのは、セキュアリッパーやPureReadがリトライリードする際には「シフトダウン」するからです。エラーなく読もうとする時には速度を下げてるんですから、その方がビット品質にも“好条件”かなと。イメージ的には低速の方が電気的ノイズもメカ的ノイズも少なそうですし(空気抵抗がある以上、あんまり高速回転だと振動なんかも不利でしょう)。

 リッピング結果はもちろんWaveCompare一致。楽曲部のバイナリは同じということです。ファイルコンペアでは不一致でした(ドライブもリッパーも異なるのでオフセットズレは仕方ないでしょう)。
 リッピング先はUSB2.0接続の外付け2.5inch-HDDです。別名のフォルダにファイル生成。フォルダ階層は同じです。

・試聴
 リッピングするPCと再生するPCを兼用している場合は、リッピング環境を変えたら再生環境も変わってしまいますが、今回は上記HDDをリッピングしたPCから“再生専用PC”に移動し外付けしてそのファイルを直接再生しています。
 つまり再生環境は全く同一(HDD上のファイル位置は違うけど。仕方なし)、さらにストレージ間コピーはしてない“生”ファイルってことですね。

 さあ、いよいよ試聴です。どきどき。

 まずはPlayPcmWinにて。

 …やっぱり違い判りません。

 メモリ全展開型だと判りにくいのかも知れませんので、気を取り直してuLilithにて。

 …やっぱり判りません。

 ということで、本編での結論を覆す結果にはなりませんでした。


■バイナリ一致サンプル追加

 さて、ここからは再び本稿での新しい記載となります。

 上記の「ハード違い」による差分はZ68システムの設定によって作り出したものでした。ですが、PC自体にもっと差を付けた方がよかったかも知れません。
 そこで、「ノートPCによる完全バッテリ駆動(*)でのリッピング」のファイル追加してみようと思い立ちました。
 再生システムも当時よりかなり進化してると思いますし(以下再生システム参照)。

*:ただし、ノートPCのバッテリ駆動は音質に良いと判断しているワケではありません。バッテリと言ってもPC内部で必要な複数電圧をすべて化学変化による発電で賄ってるワケでもないので。「デスクトップのATX電源との対比として」という意味です。

 上記2サンプル「とりあえずサイコー」「とりあえずサイテー」もHDD(比較試聴したHDDではありませんが)に保存してありますので、それらとの比較を行います。もちろん物理的に同じCDで。

・リッピング環境
 バッテリ駆動しますので、ドライブはスリムドライブをUSB2.0で外付けします(スリムが好条件なのかについては上述の通り)。
 その他、ERI手持ち機材で可能な限り“ビット品質によさそうな”対策してみました。どんなもんでしょう?

 ・PC
    ThinkPad X220 Windows10Pro 64bit
    バッテリ駆動(LCD輝度最低) 常駐系アプリインストールなし
    しまった、メモリはシングルアクセスに戻せばよかった…
    デュアルでやっちゃいました
 ・PC状態
    BIOS(UEFI)でLANを始め内蔵カメラなど切れるものは全てdisable
    CPUはシングルコア、THもdisableに設定
    (シングルスレッド状態をタスクマネージャで確認)
 ・ドライブ
    スリムDVD-ROM NEC製PC-VP-BU47(ドライブ本体はTEAC製DV-28S-Y)
    コーリアンボードで上下を挟み鉛円柱を載せて制振
 ・USBケーブル
    USBフィルタボード:エミライ製ES-OT4経由でアコリバ製USB-1.0SPS
    電源側はモバイルバッテリSONY製CP-F10LSAVPに接続
    eneloop4本直列直結では駆動できませんでした
 ・リッパー
    ≪dBpoweramp R16.0 Trial≫ BurstMode(リッピング時に負荷をかけない) 
    AccurateRip Off(オフセット補正しない)
    Disable Tag Writingチェック(余計なヘッダフッタを付けない)
    ドライブ速度x4に設定(リップ時x4と表示されていた)
 ・リッピング先
    X220の内蔵SSD(CFD製CSSD-S6T128NHG5Q:ベンダはTOSHIBA)
    GPTのUEFIブート設定,パーティション分割したDドライブ,NTFS

 USBフィルタはStereo誌付録です。

 リッピング後、X220からSSDを取り出してZ68メインPCにUSB2.0接続、今回リッピングしたフォルダに3年前の「とりあえずサイコー」と「とりあえずサイテー」ファイルをコピーしてみっつのサンプルを揃えました。中身以外にファイル名とSSD上の記録場所が異なるワケですが、どうしようもないので無視します。リッパーや光学ドライブで制御できることでもありませんし。
 このストレージを再生PCに接続してそのまま再生します。
 今回の「スペシャルベスト」はコピーなしの第一世代となります。それもUSB接続などではなく、SATA3でノートPC基板に直接接続されたストレージです。純度高いですよね?
 対する過去の2ファイルはコピーであることに加え、変換を入れることでさらに不利にするため敢えてUSB接続にしてみたものです。

・みっつのサンプル
 これで3種のサンプルが揃いました。

 ・とりあえずサイテー
   Z68フル稼働+グラグラFX48+iTunes
 ・とりあえずサイコー
   Z68最低限稼働+制振BDR-S05J+dBpoweramp
 ・スペシャルベスト
   X220シングルスレッド+制振スリムドライブ+dBpoweramp+フルバッテリ駆動

 三すくみで≪WaveCompare 1.32≫した結果を提示しておきます。音質を確認するワケではないのでコピーしたファイルを使用。

BDR VS FX48

X220 VS FX48

BDR VS X220

 ファイルの仕様を明示しておきます。

・ゼロサンプル数(曲間サンプル)と楽曲部バイナリ:ドライブ違い=オフセット違いのため先頭ゼロサンプル数がすべて異なりますが楽曲部バイナリは一致です。

・補間有無:3サンプルとも、PureReadパーフェクトモードでのリップデータと≪WaveCompare≫で一致するので補間は発生していません。

・サンプル数:すべて同じ12,491,472サンプルになっています。

・ファイルサイズ:プロパティで見るとすべて49,965,932Byteで一致します。

・ヘッダ:バイナリエディタで全く同じであることを確認しました。容量はオプションもなく一番ベーシックな44Byteです。

・オプションフッタ:ファイルサイズが同じでヘッダが同じでサンプル数も同じということは、フッタはないということです。
 実際、バイナリエディタでファイルの末尾を見てもほぼ無音レベルのデータが並んでいるだけです。
 ちなみに、「12,491,472サンプル×4バイト+ヘッダ44バイト=ファイルサイズ49,965,932バイト」です。フッタ(オプションメタデータなど)が存在する余地はありません。

・再生環境
 その時点での環境は使用機材履歴に記録していますが、今回はここに明記しておきます。

 ・PC:X79システム 再生専用
 ・PC電源:CSE製TX-200(アイソレーショントランス) アース接続
 ・PC電源ケーブル:AET製HIN AC EVD
 ・TX-200電源ケーブル:同上
 ・プレーヤソフト:≪foobar2000 1.3.8≫ PortableMode(*1)
 ・ファイル在処:X220のストレージ(*2)
 ・DAC:TEAC製UD-503 DSD256モード DSDデジタルフィルタは150kHz設定
 ・DAC電源:CSE製RG-50(クリーン電源レギュレータ)
 ・DAC電源ケーブル:同上
 ・USBケーブル:アコリバ製USB-1.0SPS
 ・ヘッドホン:SONY製MDR-Z7とSENNHEISER製HD700 アクティブGND駆動

*1:Resampler-V(SoX)で32倍アップサンプリング後DSD256変換(FP64 TypeD)再生  
*2:X79のチップセットSATA2にミヨシ製SATA-272(20cm)で接続。電源はシステムSSDの枝分かれ

 リンク先に記した通りアップサンプリングやDSD変換はPCでやらない場合はDACチップで実施されますので、「余計な変換」とは考えていません。

・試聴
 オフセットが異なっているので前後の曲間サンプル数が異なっていますが、楽曲部バイナリは一致です。オプショナルなヘッダフッタもないので再生時の動作が異なることはありえません。
 ファイル自体はそういうものですが、それを生成したリッピング環境“だけ”はかなり違うと思います。
 猛烈に念のためですが、猛烈に特殊な運用でない限りファイル生成してから再生するまでにストレージ電源は切れることがある前提です。

 リッピング時にフラッシュメモリセルに宿り、無通電でも存在し続け、再生時にはバッファやレジスタを幾重にも伝播していく、0/1を超越する音質差要因「GHOST IN THE CELL」は存在するのでしょうか…

 …ふたつのヘッドホンでブラインドで3サンプルをランダムに聴きましたが、違いは感じませんでした。
 少なくとも「こりゃヤバイ」とは思いませんでしたので何よりです(笑)。

 もちろん、個人的主観的判断なのは言うまでもありません。冒頭に記した通り「変わると思ってない」って“プラシーボ”効果もあるかも知れませんしね(苦笑)。


■仮想ドライブ幻想

 「ドライブ直ではなく、一旦イメージとして読んだファイルで作る仮想ドライブからリッピングした方がよい」という説もありますよね。
 しかし、音楽CDは音楽CDとしてしか読めないと理解しているので、ウチではリッピングに採用していません。

 が、今回「ビット品質のスペシャルベスト環境」として導入するかどうか判断するため、それなりに調べてみました。

・仮想ドライブからのリッピングとは何か
 始めに。そもそも音楽CD(CD-DA)はCD-ROMではありません(CD-ROM規格は音楽CD規格を利用して作られたもの)。データディスクではありませんから、いわゆるISO化はできません。実際、≪ImgBurn≫でもISO化は選択できません。
 ですので、音楽CDをイメージ化できるソフトウェアがあっても、それはISOイメージ生成ではないハズです。ここはCD-ROMやDVD以降(映像メディアだがファイルシステムに則ったデータディスク)と決定的に異なる点です。

 それを踏まえた上で、以下プロセスを踏んでリッピングしてみました。音質比較するワケではないのでフツウにZ68メインマシンにて。

 ・イメージ化:≪ImgBurn 2.5.8.0≫で「BIN+CUE」化
 ・仮想ドライブ化:≪DAEMON Tools Lite 10.4≫
 ・リッパー:≪iTunes12.4.1.6 x64≫ エラー訂正なし
 ・イメージ化に使ったドライブ:BDR-S05J マスターモード
 ・CD:PureRead対決で使った傷ありCD
 ・リッピング対象:S05Jのパーフェクトモードで停止するtrack10

 結果、10個のエラーがあるファイルができました。
 続いて、PureRead3+をテストした時に使った3回のS05Jマスターモード結果のうちのひとつとの比較を示します。

S05Jm 補間 imgbrn比較

 比較対象のエラー数は9でした。上図の通り相違は1サンプルしかありませんから、10個のうちの9個まで補間結果も共通だということでしょう。
 このことから、仮想ドライブリップはフツウに“マスターモードでの直接リップ4回目”に見えます。

 なお、イメージ化する際、S05Jはシフトダウンしてリトライやってました。
 そもそも、上述の通り音楽CDは音楽CDとしてしか読めないハズです。

 やはり、音楽CDのイメージ化とはリッピングのことではないでしょうか(そもそもCUEファイルとセットだし…)。

・BINとWAVの違いとは何か
 でも、できあがるファイルは「.bin」ですよね。そこで、表題の比較してみます。
 同じタイトルですが買い直した傷なしディスク(こちらは補間発生はありません)から、全トラックを1ファイルにしたBINとWAVを生成します。傷ありと同じタイトルである意味はありませんが、流れとして(笑)。

 ・BIN
   ≪ImgBurn≫で「BIN+CUE」化
 ・WAV
   ≪EAC V1.1 from 23.June 2015≫で全トラックをリッピングして「WAV+CUE」化
   ≪ImgBurn≫と合わせるためオフセットズレ補正なし。フッタなしを確認

 プロパティで「サイズ」を見ると、BINが477,056,160Byte、WAVが477,056,204Byte。その差44ByteはバッチリWAVファイルのヘッダバイト数です。
 そこで、WAVファイルのヘッダをバイナリエディタでカットしてファイルコンペアしてみると、ファイル内容一致。
 逆に、BINファイルの先頭にWAVファイルのヘッダを追加し、拡張子を.wavにし、CUEファイル冒頭の対象ファイル記述を対応させると、そのCUEファイルで曲ごとに分割表示されて再生できちゃいます。

 つまり、≪ImgBurn≫でイメージ化されたBINファイルはWAVファイルの音声データ部そのもの、ということです。そしてそれは、「音楽CDのイメージ化とはリッピングに他ならない」ことを示しているとみていいでしょう。
 ちなみに、IMGで吸い上げてもBINとファイルコンペア一致の全く同じものができます。CUEファイルも冒頭以外は同じ。

 中身が同じになるのですから、仮想ドライブからのリッピングとは「わざわざファイルを仮想ドライブ化してリッピングという形式にしてるけど、ファイルコピーするのとほぼ同義」ということです。

 イメージ化は実はリッピングだとすると、エラーはその時点で補間済みですから、得られたファイルを仮想ドライブ化してリップするとエラーしようがありません。ノーエラーで「補間済み」のデータが読み出されることになります。
 つまり、イメージファイルからリッピングするとエラーがなくなりますがエラー訂正が強力になったからではありません。「イメージ化する際に補間済みなだけ」ということです。

 ということで、エラー発生低減方法としては意味がないと判断しました。
 そして、ビット品質(それがあるならですが)的にも「コピー世代を重ねるだけなので逆に不利」と考えて採用しませんでした。


 なお、少なくとも≪ImgBurn≫によると上記の通りですが、ISO化できない以上他ソフトでも同じだろうと考えています。


■さてどうする?

・変わるという体験談をどうとらえるか
 ということで、ERI的にはいくら考えてみても試してみても「楽曲部バイナリが同じなら差はない(余計なヘッダフッタがないのは前提)」という結論になっちゃうのですが、世の中には変わるという体験談も結構ありますよね。

 それら主観評価は全くもって個人の自由の領域ですけれど、もし参考にする場合は

・ファイルのヘッダフッタも同じか。プレーヤソフトの動作が変わる可能性があるので
・それはバイナリレベルで確認されているか
・最低でも、楽曲部バイナリは一致か(≪WaveCompare≫で一致か)
・FLACとWAVEで比較したりしていないか
 可逆でも。ファイルバイナリ違っちゃいますけど
エンファシスCDを対応非対応のリッパーソフトで比較していないか
 音声バイナリが違っちゃいますけど
・本当に再生環境は同一か
 リッピング環境と完全分離していない場合、リッピング条件を変えたら
 再生環境も変わったことになるので


といった客観的条件がどうなっているか考慮した方がよいと思っています。

 やや余談になりますが、補間って普通はパラパラ離散的に発生するので楽曲全体への“ヴェールの枚数”的音質差にはならないハズ(大量に連続的に発生すると局所的なノイズになるかマウント不可になる)なので、実は、補間有無的には「楽曲部バイナリ一致」は客観的条件にしなくていいと思っているのですが、話がヤヤコシクなるので敢えて挙げています。
 シャレにならないくらいまんべんなく大量に発生してたらヴェールの枚数的音質差になるかも知れませんが…
 ていうか、こういう試聴する時にそんなディスク使っちゃダメっす(苦笑)。

・「プロ」の発言をどうとらえるか
 コピー劣化について考えた時にも記しましたが、「音楽制作のエンジニア=必ずデジタル信号処理やコンピュータシステムについても詳しい」とは限らないのではないかと思えますので、発言者のスキルや発言の正確な意味や“意図(目的)”など、よく吟味した方がよいと考えています。
 特に「そういうことにしておいた方が儲かる」立場の方の場合は、“営業トーク”の可能性も考えた方がよいでしょう。

 加えて、マスタークロックを使う目的は録音・編集と再生では異なるであろう点など、「プロ製作現場の事情とコンスーマ再生事情は異なる」ことも念頭に置くべきでしょう。
 ちなみに、プロ用ツール(ソフト・ハード)が高価なのは「数売れないから」「高信頼性や長期安定供給が求められるのでメンテナンスコストがかかるから」といった理由が大きいと思っています。特にソフトは「ビット品質的に高音質だから」じゃないでしょう。

・リッピング速度
 「ビット品質に関するハードウェア条件としてはドライブの読み取り倍速性能がかなり支配的なのだ」という説もあるかも知れません。
 だとすると、普通のリッピング動作はCAVでしょうから同じCDでも内周と外周で読み取り速度が異なり「1曲目は音がいいのだが15曲目は悪い」なんてことが起こっていることになります。内周と外周で同じ曲が入っていることはないので気付かないのかも知れませんが、CD-Rでそういうディスクを作って確認してみることはできそうですね(記録時の速度とかいろいろめんどくさそうですが)。
 あ、カラオケがオマケについてるCDだと、もしかして「同一CDの別track」に同じ音声データ入ってるかも知れませんね。前奏部分とか。

 この影響があるとすると、「低速CLV読み取り」が可能なドライブ&それを設定可能なリッパーの組み合わせで使うしかありません。もちろんリッピング前にスピンアップ完了しないなんてもってのほかです(笑)。ドライブとリッパーの選定自由度がすごく狭まりそうです。実際に組み合わせてみないと判んないでしょうし(例えばS05Jは選びでありませんでしたがiHES208は結構選べるみたいです)。

・CD状態
 リッピング条件で音質変わるとすると、同じCDでもプレス(*)状態によっても読み出し波形が変わってリップファイルの音質変わりそうです。
 「初回プレスが一番いい」とか「いや、数回後の方がスタンパがエージング(爆)されてきて良くなる」とか、いろんな説がありそうです。ドライブ制振するより影響デカイ気がしますが、ユーザにはどうしようもないですよね。

*:http://www.itmedia.co.jp/pcuser/articles/0707/25/news001.html

 もっと遡ると、マスタリングスタジオがデータ入稿に使っている「生ディスクのブランド」「焼きドライブ」などによっても、スタンパの状態が変わってプレスされたCDの音質は激変しそうです。
 いわんやディスク入稿とネット入稿をや。

・配信ファイル
 リッピング条件違いによる「ビット品質差」があるとすると、配信ファイルのダウンロード条件違いでもそれは発生しそうですよね。DL時、ネットワーク機器も制振した方がビット品質は良くなるのでしょうか? 落とすソフトもブラウザと専用ダウンローダでは違うとか。
 もしかしてインターネット接続環境にも依存? ADSLより光ファイバの方がいいとか、光でもギガより100Mの方がいいとか、NTTよりKDDIの方がいいとか、DLは真夜中に限るとか?
 配信サイトのサーバにも依存?


 …やっぱり考えないことにしようっと(笑)。


メインメニューへ

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

PureRead3+を調べてPureReadを再評価する

16/07/02初稿

 個人的にですが、ここのところ光学ドライブ(特に5インチ版)の先行き不安がじわじわ膨らんできてました。
 そしてあるとき「PureReadドライブを追加確保しておかないと無くなっちゃうかも」という強迫観念に耐えきれなくなり(笑)、久々に新型ドライブ買っちゃいました。
 Pioneer製BDR-S09J(新品)です。残念ながら色はピアノブラックのみになってしまいました。
 BDR-209JBKも出てますが、PureReadは「第2世代」の模様。

 目的のPureRead機能は世代が上がって「PureRead3+」になっています。
 PureRead2になったS05J買った時は「PureRead VS PureRead2」やりました。もう6年ほども前になるんですねぇ。
 PureReadドライブの意義は「C2エラー(補間)発生検出装置」と位置づけている(笑)とはいえ、リッピング性能は高いに越したことはないですから、また比較してみました。

 なお、リッピングとエラー訂正とソフトとハードについてはこちらの内容が前提です。
 また、本稿はリッピング環境が違うと音声バイナリが同じなのに音質が違うファイルになる説とは全く関係ありません。補間発生=バイナリ不一致に関してですのでアタリマエですが念のため。

 本稿で記すリッピング結果の「エラー」は、特記なきはC2エラー=補間発生の意味とします。


■PureRead2 VS PureRead3+

 PureRead2機種は変わらずBDR-S05J(1.12)です。S09JのF/Wは最新の1.34にUpdateしました。

 Z68メインマシンにSATA接続。リッピングソフトは≪iTunes12.4.1.6 x64≫にて。
 PureRead使う時はリッパーに余計なことさせない方がよいと考えていますので、エラー訂正なしに設定します。
 なお、このバージョンでも≪iTunes≫とPureRead3+の相性問題はないようです。純正の≪Power2Go8≫と同じ挙動示すようですので。ただし、PureRead3+を設定する≪Pioneer BD Drive Utility≫を立ち上げたままだと干渉するようです。

・パーフェクトモード対決
 まずは、先の「無印 VS 2」対決時にS05Jでも停止したtrack10が救えるかどうかで補間発生阻止性能差をみてみます。
 確認のためS05Jで久しぶりに同CDの3曲をリップしたところ、6年前に3回やって一致した結果と完全に一致しました(3曲中2曲は完走、track10のみ停止)。なので1回で確認終了。

 さて、期待のS09Jはどうでしょう?

 …なんと3曲とも途中停止しました。

 S05Jでも停止したtrack10では、できたファイルサイズはS05Jより小さいです。つまりS05Jでは突破できたダメージ箇所で停止してるってことですね。また、その位置もまちまちになっています(S05Jは毎回同じところで停止)。ある時はあるダメージを突破でき、ある時はできなかった、ということですね。

       正常  S05J   S09J(1) S09J(2) S09J(3)
track09  46742KB  正常   7259KB   7259KB   7259KB
track10  36682KB 21040KB  6294KB   10291KB   11531KB
track11  42631KB  正常   781KB    781KB    781KB

 なんとも期待ハズレな結果に。

・マスターモード対決
 しかし、しかしですよ、もしかしたらパーフェクトモードは「諦めがよくなっている」けれど、マスターモードや標準モードの性能は上がっているかも知れません。また、パーフェクトモードの仕様上「最初の補間発生」で停止位置は決まってしまいますから、単に「最初に遭遇する補間発生ダメージとの相性問題」かも知れません。
 そこで、補間発生しても全部読むマスターモードで補間発生具合を比較してみます。

 同じくtrack10にて。同タイトルの「傷なしディスクのtrack10=もちろんパーフェクトモードで停止しない=正常データ」と比較します。
 S05Jでは12倍速くらい(iTunesの表示)で読みました。
 結果、1回目は9サンプル、2回目も9、3回目は8サンプルの相違(正常データとの相違ですから、これが補間発生したエラーサンプルということです)。
 その中では、次の2サンプルについて補間結果(または補間せずに済んだ)が違ったようです。

        正常     S05J(1)   S05J(2)  S05J(3)
5388110:  -1618, -3268  -1535, -3268    正常     正常
6651621:   1986, -635    正常    1986, -685   正常

 なるほど、3回目のみ1サンプル分補間発生が少ないワケですね。

 S09Jでは4倍速くらいで読んでました。
 結果、1回目138、2回目104、3回目139サンプルの相違。S05Jより全然多い…
 相違の内容もそれぞれ90サンプル分くらい異なります。

S09J-M:track10

 S09Jの1回目の138エラーのうち、S05Jの3回で補間値に相違があったサンプルNo.5388110~6651621までを表示しています。


■結果

 以上より、“少なくともこのダメージディスクに関しては”、S05J(PureRead2)の方が、S09J(PureRead3)よりよさそうです。
 もちろん、ドライブの個体差かも知れませんし、ダメージとの相性かも知れません。そもそも1枚のCDでしかやってませんので、全く一般論にはなり得ません。

 ただ、今回は「DVDドライブとBDドライブという違い」や「バルクとリテールの違い」などはなく、一応「BDR-S0*J同士の世代間対決」ですので、「PureRead3+は明らかによくなってる」と思えない結果になったのは残念です。

 もしかして“エックス”だと違うんですかね?
 施されたいろんな施策が“リッピングの光学特性”改善になってるなら買いですけど… っていうか、やるだけやったって言う安心感で?(苦笑)

 でも、実はS06Jでもちょっとやってみたんですが、「S05J>S06J>S09J」だったんですよね。S06Jは私がずっと管理してたモノではないのでハード状態はなんとも言えないのですが。

 ちなみに、S05J、S06J、S09Jそれぞれの設定ユーティリティではそれぞのドライブしか見えませんでした。


 ということで、S05Jがいいのかウチのがたまたまアタリ個体(逆にS09Jがハズレ個体)だからなのかは判りませんが、手持ちのBDR-S05Jを大切にした方がよさそうです。
 PureRead特性が若干違うとしても、万一ダメージディスクに当たった時にそれを知らせる「C2エラー(補間)発生検出装置」としては充分利用可能なワケですから、

「普段はBDR-S09Jのパーフェクトモードでリッピングし、もし停止してしまった場合のリカバーにS05Jを投入」

という運用にしようかと思います。
 PureRead3+だと、ディスク入ってても設定できるし本体に設定保存できるので便利ですし。


■補間は平均値か

 本項以下16/07/18追記。PureReadとは直接関係ないような気もしますがPureRead機能あったればこそ確認できたことでもあるので、この稿に記すことにしました。

 C2エラーしたサンプルの補間値はその前後サンプルの平均値と言われています。
 ちょうど良さそうな気がしたので、S09Jマスターモード(1)の138個のエラーサンプル中、No.5388506(5238DAh),5388508(5238DCh),5388510(5238DEh)という“ひとつおきに3個”集中している部分につき、それを確認してみました。

 バイナリエディタでバイナリ値を覗きますので、≪WaveCompare≫もHEX表示にして該当部分を示します。左側が傷なしエラーなしディスクの正常値、右側が傷ありディスクでC2エラー発生により補間された値になります。

S09Jm 補間

 ≪WaveCompare≫では相違サンプルの前後(間)は表示されませんので、バイナリエディタ≪Bz≫で該当サンプル部分を確認。
 Intel形式ですのでバイト単位でひっくり返して読みます。
 以下画像ではサンプルNo.5388506(5238DAh)のLとRにあたる02FFhと08DFh部分をマークしています。

S09Jm 補間 バイナリ

 ≪WaveCompare≫と≪Bz≫で読んだ、「傷なしディスクの正しい値」と「傷ありディスクの補間された値」をサンプルごとに整理しました。
 C2エラーして補間された値には()で正しい値を付けています。

サンプルNo   L        R
 5238D9   009C       2429
 5238DA   02FF(015F)   08DF
 5238DB   0563       0CA6
 5238DC   0706(08BD)   094D(0BE3)
 5238DD   08AA       05F4
 5238DE   0590(060F)   009D(FEF3)
 5238DF   0276       FB47

 HEX値なので解りにくいとは思いますが、Windows付属のプログラマ電卓などで10進数に直したり計算したりできます。
 してみると、確かに補間値は前後のサンプルとの平均値になっているようですね。

 「この例だけ」「BDR-S09Jだけ」での結果ですので一般的かどうかまでは解りませんが、補間の実体が少しは解ったかなと思います。


 ちなみに、いくつかのC2エラー発生ファイルを覗いてみると、補間は“ひとつおき”に発生しているっぽく見え、それもCIRCの機能なのではないかと思えます。が、リッピング性能の低いドライブ(TEACスリム)だとやっぱり連続補間も発生(補間値の算出に補間値が使われている)していましたので、「連続しないことが保証される」というレベルではないようです。

 本件について、CIRCに関する以下の情報を引用させていただきます。

この誤りかもしれないデータは正しく読みだされたデータに挟まれるようになっています.これでうまく補間がとれることになります.補間としては,平均値がよく用いられます.
出典:「図解コンパクトディスク読本」 P.110

 余談ですが、挟まれなかった場合は直前の正常値を連続させるようです。

傷のせいで読めなかった部分は、従来だとドライブが前後の情報から予測して補間します。しかし何カ所も連続で読めない箇所が続いた場合は「前値ホールド」、つまり前の値をそのまま続けて入れてしまうんです。そして読み取れる場所が来るといきなり波形が大きく変わるので「プチッ」というノイズが発生してしまうんですね。
出典:https://www.phileweb.com/interview/article/200909/04/26.html


■補間の実態から考えるセキュアリッパー

・補間結果が同じでもセキュアに読めるのか
 さて、普通は平均値だとすると、正しく読めたサンプルに挟まれたエラーサンプルの補間値は何回読んでも同じになるハズです。
 とすると、セキュアリッパーの2度読みを考えた時に懸念しましたが、やっぱり「2度読んだ結果が同じになる=補間発生を認識できない」ことがあるのでは?

 試しに以下のリッピングしてみました。

 ・傷ありtrack10
 ・BDR-S05Jマスターモード
 ・≪EAC V1.1 from 23. June 2015≫ C2エラー情報は使わず(*)Secureリッピング

*:ていうかこの組み合わせだと使えません。影響を受ける余地がないということになるので実験には好都合ですが。

 このリッピングでは、これまでの結果から「連続ではない10個程度の“お決まりの”サンプルでC2エラーが発生する」と予測されます。そして、それらはドライブ内で平均値補間されてから≪EAC≫に認識されているハズです。そして、その補間値は2回読んでも同じになる可能性が高いということです。

 以下、ログです。

Exact Audio Copy V1.1 from 23. June 2015

EAC extraction logfile from 18. July 2016, 16:27

Unknown Artist / Unknown Title

Used drive : PIONEER BD-RW BDR-205 Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 0
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Not detected, thus appended to previous track

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

~省略~

Track 10

Filename F:\10 Track10.wav

Peak level 77.6 %
Extraction speed 1.3 X
Track quality 100.0 %
Copy CRC 15EA2D26
Copy OK

No errors occurred

End of status report


 「Track quality 100.0 %」「No errors occurred」とあります。
 確かにリッピング中「Error correctionゲージ」は一度も点灯していません。
 つまり、≪EAC≫は「ノーエラー」だと言ってることになります。

 しかして、このファイルとエラーなしファイルとの≪WaveCompare≫結果は以下の通りです。

S05Jm 補間 EAC

 ノーエラーじゃありません。


 この≪EAC≫によるCRC値は正常データのそれと異なりますから、AccurateRipなどのデータベース照会機能を利用すれば補間発生を認識できます。
 が、逆に、データベース照会は必須で、ローカルのリッピング結果だけでは認識できないとも言えます。

 つまり「2度読みによるエラー発見(とリトライ)ではエラーを見逃すことがある。セキュアリッパーのセキュア機能はデータベース照合こそが本命で、前者は補助的機能」ということですね。

 念のため、「補間の有無で≪EAC≫のCRC値が異なる」ことを確認しました。
 以下ふたつのリッピングで得た当傷ありディスクtrack09のCRC値は全く一致しませんでした。
  ・S05J標準モード(傷なしディスクと327相違あり=補間あり)
  ・S05Jパーフェクトモード(傷なしディスクと一致=補間なし)

 ≪dBpoweramp≫のページでも、「概ね違うエラーになるけど同じエラーになるかも」と言っているようです。

CD is read twice, if a section contains an error it will likely return different errors, so can be detected. This is true mostly but not always, consistent errors exist and in our opinion present more of a problem to secure ripping than the C2 error pointer detection 'hole'.

Either way there is an error and a secure ripper might not be able to detect the error (if a re-read returns the same error...).

出典:http://dbpoweramp.com/spoons-audio-guide-cd-ripping.htm

・エラー発生さえ無ければCRC値は一致するのか
 ところで、上記のCRC比較で「なぜ傷なしディスクのtrack09ではなく傷ありディスクの補間なし結果と比較するのか」というと、傷ありディスクと傷なしディスクでは「読み出し位置が101サンプルズレている」ためです。上の≪WaveCompare≫を見ると比較開始点が異なってますよね。
 そのため傷ありと傷なしからのリッピングではWAVに切り出された位置が異なるので、補間発生がないtrackでも「≪WaveCompare≫一致・CRC不一致」なファイルになります。
 念のためですが、ドライブもリッパーも同じですからそれらによるオフセット違いではありません。
 ウチに2タイトルある“同タイトル2枚”では両方ともズレてました。

 「セキュアリッパーにとってはデータベース値照合こそ本命」と記しましたが、タイトルの照合値がデータベースにないと話は始まりません。
 しかし、同じタイトルなのに物理的に違うディスクではサンプル位置が異なることがある=データベースにタイトルがあっても照合値が一致しないことがあるということで、これってどう対応してるのでしょうか?
 オフセットによって複数の照合値がある前提で収集していて、同じタイトルでも複数の照合値があるってことですかね。どうもそれっぽいので、「データベースにプレスバージョンが同じタイトルがあること」が照合条件になりそうです。

 個人的には、やっぱり補間有無はC2エラー情報で認識した方が安心です。


 CIRCがんばってる。PureReadやっぱり便利。


メインメニューへ

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

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

13/11/30初稿

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


■はじめに

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

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

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

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

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


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

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

 というふうに正確さを期したつもりですが、すべて正しい保証はありません。ご了承ください。


■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はMSFとは異なりトラック1のINDEX01期間の先頭フレームを起点とするようです。

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

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

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

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

・オフセット・ギャップ理解のコツ:「ギャップ」を断絶的に捉えない
 詳しくはのちに取り上げますが、「ギャップ」という名称についてちょっとだけ。
 「ギャップ」と呼ばれてはいますが、INDEX00期間(普通にサンプルがある)を指し、「裂け目,隙間,断絶」といった状態ではありません。それが証拠(?)に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全面をスキャンして検出する必要があるためと推察しています。


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

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

・オフセットとリッピングの関係
 上記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≫


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

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

a.ディスクとして、限りなく元CDに近い複製CDを作成したい
b.セキュアリッパーにおいてDB照合機能を利用したい

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

 先の15ファイルマージと一気読みを比較したCDにおいて、オフセット補正した場合を示します。

mergeAccuimg compare

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

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

・ドライブのオフセット値は気にするべきか
 ところで、オフセットがあっても、その値がどうでも、ファイルの先頭末尾の微小時間の状態が異なるだけです。よって、原則として「オフセット補正した方が音質がよいWAVファイルができる」といったことはありません。
 ですので、余談ですが、「補正値が+30多すぎるのでは問題」も音質には関係ありません。一律に30ズレているのなら上記aとしては問題かも知れませんがbとしては問題ないということです。よって本稿では触れません。

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

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

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


■ズレの正体:その他編

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

・トラック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≫も同様のリップする模様です。

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


■オフセット補正の注意点

 本項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の先頭に同様の問題が発生する可能性も考えられますが、プラスオフセットのドライブは稀なようですので(所有していませんので)、ここでは扱わないことにします。


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


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

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

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

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

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

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

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

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

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

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

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

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


■おまけ

・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はリードインのことです。

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

EACdeCUE.png

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

・オフセット確認?
 例えば「プリギャップがゼロサンプルでトラックの先頭からいきなり音声」みたいな“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秒(フレームで言うと75個)と00~74フレーム(つまり75個)、ということであり、時間的には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さん、ドライブユーティリティに「ドライブオフセット設定機能」とか付けたらウケると思いますよ~


メインメニューへ

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

CDリッピングソフト音質差を右と左で比較する

13/10/15初稿

 CDからリッピングしたファイルについて、再生環境条件は全く同一で、かつ音声データのバイナリが全く同一でも音質が変わるという説があります。吸い上げるバイナリは同じなのに、例えば「高音質な(低音質な)リッピングソフト」があると。

 内蔵HDDと外付けHDDで比較なんて論外なのは言うまでもありませんが、理屈上の理想条件としてはストレージ上の位置やファイル名まで同一、とにかく違うのはファイルの出自だけ、という意味です(実際には同時に成立させるのは不可能ですが)。
 再生環境とリッピング環境を兼ねている場合は、ドライブやリッパーソフトを追加削除してリッピング環境を変えたら再生環境も同一とは見なせないのはもちろんです。ドライブは動作してなくても通電してますから電気的条件変わってますし組み込んだだけで振動などメカ条件も変わってますし、ソフトも、立ち上げなくとも何か常駐してるかも知れませんしレジストリ書き換えたことで何か影響あるかも知れませんし。

 私はその説を取るものではありませんが、特に「リッパーソフトで音が変わる」について、やってみないままでいるのもナンなのでチャレンジしてみました。ちょっとオモシロイやり方思いついたのをきっかけに。


 特記なきはWAV形式、再生は排他WASAPI、余計な変換やエフェクトは当然何もなし、です。


■どんな考え方があるのか

 デジタルオーディオ処理には大きく分けて3ステップあると思っています。

  Step1.ストレージへの記録
     (無通電状態を経由。ストレージ以外の環境は以降と全く関係しない)
  Step2.ストレージから読み出して転送してDACチップに入力
  Step3.DACチップでアナログ化

 この後はアナログオーディオですね。

 さて、ERIでは音声バイナリ一致でも音は変わると考えていますが、それはStep2と3、つまり“再生動作中”に関してです。

 ので、本稿で取り上げるのは、「再生環境(Step2,3)が全く同一でも、異なるリッピング環境(Step1)で生成されたファイルは再生時に音が異なる」という説についてです。ストレージに記録する時に差が生じ、その後「無通電状態」になっても影響を持続するということですね。

 なので、通常語られる「デジタルなのに音が変わる」よりさらに一歩踏み込んだ説と言えるでしょう。レベルが違うことを認識して考える必要があると思います。
 「CDの読み取りエラー(C2エラー)の量」の差の話との混同しやすい点にも注意が必要でしょう。音声バイナリ不一致なので論外ですが念のため。


 さて、「リッパーによって音が変わる」可能性ですが、まず、大きくふたつに分けて考えた方がよいと思っています。

A.ファイル構造説
 リッパーによって生成するファイルが異なる。音声データとしてのバイナリは同一でも、ヘッダやフッタ、および楽曲データ(trackデータ)の前後に付加される「ゼロサンプル(*)」の状態が変わることで、音声データ本体の再生品質が左右される。
 具体的に言うとWaveCompareでは一致するがファイルコンペアでは不一致な状態。

*:厳密に言うと±1程度の値の場合もありますが、本稿では煩雑さを避けるため「ゼロサンプル」「無音データ」などと記します。

 以下に上記を表す簡易図を示します。

WAVファイルとCD構造

 この後の考察の参考として。

 この説は、楽曲部バイナリは一致でもファイルバイナリが一致しませんので本当は「バイナリ一致なのに~」には当てはまりません。
 が、一応、「楽曲部バイナリは一致しているのに音が変わる」可能性につき以下で吟味します。


B.ビット品質説
 ファイル生成するアプリ(つまりリッピングソフト)やOS、光学ドライブなどのハード環境によってリッピング時に記録された「ビットの品質」が異なる。品質の影響は無通電状態でも保持されコピーしても残留し(*)、HDDからメモリに展開する際もそれはメモリの電荷にまで及び、最終的にDACのアナログ変換結果に影響を与える。
 よって、同じバイナリでも音質が異なる。すべてメモリに展開してから再生するプレーヤでも影響は免れない。

*:そもそも再生時ストレージから読み出されて最終的にDACに届くまでにメインメモリや各種バッファ上に「何度も何度もコピー」されているのですから、伝播すると考えないワケにはいきません。さらにそもそも、バッファなどを介しても影響するからこそ記録時にビット品質差が生まれるのですから、再生時には伝播しないという理屈は成立しがたいでしょう。
 一応、ビットそのものだけでなくビット品質がそのビットを扱う時にシステム全体に与える影響の伝播も含むこととします。
 なお、コピー劣化説も存在しますが、今回は、元々ビットに品質差がありそれがコピーで劣化してもしなくても伝播する、としておきます。

 さて?

・「ファイル構造説」:フォーマットについて
 これは完全に0/1の世界のハナシですので、バイナリエディタでWAVファイルの中身を確認すればすぐに事実が解ります。大変シンプルなフォーマットですので音質差を発生させようがないんですけど(苦笑)。

 記事で≪iTunes≫版と≪EAC≫版のヘッダ部分を確認していますが全く同一でした。フッタにライブラリ管理用などの付帯データの類は付いていませんでしたし。つまりファイル構造としては同一であり、違うのは(というか“違う可能性があるのは”)「ゼロサンプル」の値と数だけ、となります。
 ヘッダフッタは“余計なものはない一番シンプル”というレベルで同一なのですから、プレーヤソフトはそれに基づいて余計はことをする余地はなく、つまり≪iTunes≫版と≪EAC≫版でリップしたファイルに対しプレーヤの動作が異なることはあり得ません。「≪iTunes≫より≪EAC≫でリップした方が音がいい」という理屈(仮説)は思いつかないのです(「ゼロサンプル」については後述)。

 さて、記事では当時高音質と評価されていたので≪EAC≫を比較対象にしたのですが、新たに、最近音がいいリッパーとして評判らしい≪dBpoweramp CD Ripper≫が生成するWAVファイルの中身も確認してみました。
 まずはインストールしたままのデフォルト状態でリッピング。

 と、こちらにはフッタが付いていました。
 以下添付します。反転したところがそれ。この前までが音声データで、先頭末尾のゼロサンプルも含めたサンプル数は≪iTunes≫版と同じです(つまりこの反転部分だけプラスされている)。

dBpowerampフッタ

 その意味では“≪iTunes≫より余計なことしてる”ワケですね。

 このフッタはカバーアート表示に対応していますので、規格に反応するプレーヤにおいては画像表示が加わるワケですから再生動作が異なるとは言えるでしょう。
 なので、「肥大化したファイルで再生時に余計なことをして音質を悪化させる」可能性は否定できないでしょう。
 そして、そうだとすると、≪iTunes≫より≪dBpoweramp≫のファイル形式の方がそれ、ということになります。


 つまり「≪iTunes≫はリッピング時に余計な付加情報を付けてデータが肥大化しているので音が悪い」という説にとっては事実は逆になっているということです。

 ただし、あくまで≪dBpoweramp≫デフォルト設定の場合です。オプション設定でプレーンWAVファイル出力にすることもできますので。

 リッパーとしてはプレーンWAVを出力する方が“王道”だと思いますので、本稿ではオプションなしのプレーンWAV」であることを前提として記します。

 なお、≪dBpoweramp≫版と≪iTunes≫版の≪WaveCompare≫一致は言うまでもありません。

・「ファイル構造説」:ゼロサンプル状態について
 音声本体データにくっついている「ゼロサンプル」の状態がΔΣ方式DACの動作(演算して1bitデータを作るロジック)に影響を与える可能性も一応考えることはできます。
 ΔΣ型DACは入力されたPCMデータを演算して1bitデータを生成し、それをD/A変換しています。DACは最初に入ってくる先頭のゼロサンプルも有意サンプルとして扱うハズです。ということは、ゼロサンプルの状態によって生成される1bitデータは異なるということになります。
 当該演算はフィードバックを含みますので影響はしばらく後の演算結果まで波及する可能性があります。が、どれくらい後までどのくらいのレベルで影響するのかといったことは難しすぎて判りません。

 ただし、本件はあくまで素人考えの理屈上のハナシですし、仮にあったとしても冒頭のほんのわずかだけでしょうし、そもそも「あらゆるトラックをどんなΔΣ変換方式のDACで再生しても高音質になるよう当パラメータを調整してリップするリッパー」というのも考えにくいです。≪dBpoweramp≫なんて有料商品なのですから、そんなすごい機能があるなら大々的に宣伝してるでしょうし(特許取得! とか声高に)。ドライブにも依存するハズですから無理でしょうし。

 ちなみに、オプション設定で「Disable Tag Writing」にした≪dBpoweramp≫版は≪iTunes≫版と「ファイルコンペア」でも一致しました。つまりヘッダフッタのみならず「ゼロサンプル」の数も値も同じということです。オフセット補正はされていないと言うことですが、不確かながら「AccurateRip」ダイアログで“Close”をクリックした記憶があります。
 ≪iTunes≫と一致することからも“≪dBpoweramp≫は「ゼロサンプル」について音が良くなるような操作はしていない”と考えていいでしょう(iTunesもたまたまよかった、と考えることもできますけどね)。
 また、以下での試聴において「ゼロサンプル」の影響はない、とも言えます。

 以上より、「ファイル構造説」は私的には成立していません(ヘッダフッタが異なって再生動作が変わるのは論外として)。

・「ビット品質説」について
 ということで、確認すべきは「ビット品質説」のみになります。0/1というデータとしては同じなのだけれどストレージ上で0や1を示す電気的磁気的品質が異なるという説ですね。ビットレベルでアナログ的な差があり、それは“最終的にアナログ音声に影響を与えるレベル”のものである、という説です。

 具体的には
「記録時に“強く磁化”されたHDDのビットが読み出される時のノイズは“弱く磁化”されたビットより大きい」
とか
「記録時に“ジッタが大きい”クロックで記録されたビットを読み出す時と“ジッタが小さい”クロックで記録されたビットを読み出す時では読み出された信号の立ち上がり・立ち下がりエッジのタイミングが異なる」
のでその後の回路に影響を与える、といった考え方かと思います(私の自説ではありません、念のため)。
 なお、「ビット品質差で読み出し時にリトライやエラー訂正動作が異なる」という可能性は、微妙なリッピング環境差でそれほどの差(エラービット大量増)が発生するということになり、そんなデリケートさではコンピュータシステムは成立しえないと思いますので考えません。

 ボールド部は重要なポイントだと思っています。
 全くのたとえ話ですが、
「地球の地磁気には向きがあるので、HDDの向きによってヘッドがディスク面を磁化させる際に影響がある。リッピングはHDDのビットの長さ方向を南北方向に合わせた方がビットがキレイに記録(磁化)される」
という説があったとします。
 この説を考える時、「地磁気がHDDのビット磁化に影響を与えるのか否か」というステップと、「記録時にビット磁化に影響を与えるとしたら、それを読み出して再生する時アナログ音質にまで有意な(聴きとれる)影響があるか」を考えるステップがあります。
 この時、「ビット磁化に影響を与えるし、それはアナログに再生する時人間が聴きとれる変化になるレベル」という説でしたら2ステップで議論する意味はあるでしょう。
 ですが、「ビット磁化に影響を与えるが、人間が聴きとれる再生音の変化にまではならないレベル」という説なら、もはや「地磁気はビット磁化に影響を与えるか否か」を考えても意味ありませんよね(少なくとも趣味のオーディオ的には)。と言うか敢えて唱える必要ないがな(爆)。


 さて、ビット品質差違を生む要因としては大きくふたつの説

・リッピング時の条件によって生成された段階ですでに違う
・コピーによって劣化する

があると思います。
 が、後者についてはすでにコピー劣化について考えた記事で成立しがたいと考え、念のためハード・ソフトの条件を悪化させた状態で複数回コピーしたファイルと元ファイルの聴き比べを行った結果違いを確認できていませんので、私的には“ない”と判断しています。ので、本稿では最初から除外して記述しています。
 さらに、本稿では「ストレージ上の場所」や「ファイル名階層の影響」などについては「ビット品質以外の条件は同一」の範疇として無視していますが、それらの影響可能性については上記記事で考えた通りです。

 次に前者についてですが、見方としては大きくハードとソフトに分けられると思います。
 ハードウェア的条件差については、上記記事で「コピーでビット品質は(聴いて判るような)変化しない」と判断したのと同じ考え方でいいと思います。つまりリッピング時にもハードで差は出ないと考えており、今回はパラメータとしては無視します。


 ので、残る論点は冒頭で示した通り「生成時点でのソフトウェア的な条件差」、つまり「アプリ=リッピングソフトによってビット品質差は発生しえるか(繰り返しますが聴いて判るレベルの差として、です)」になると言っていいでしょう。
 しかし、私としては
「ストレージへの記録時、聴いて判るレベルの音質差になるビット品質差をリッパーソフトが発生させる。再生時にはメモリやバッファにコピーされながらDACまで転送されるが、それでも影響が残るレベルの品質差である(音声データそのものではなく間接的影響も含む)」
とは思えず…
 確かにリッパーソフトが違えばシステム動作は異なるでしょうから、「プレーヤソフトが変わったら音が変わるって言うなら同じじゃないか」と言われたらある意味そうなんですが、“影響の程度感”として実感できないんですよね。無通電になっても影響するってところも。
 間接的影響にしても、再生中“ず~っと均一に”ディスク面からビット読み出ししてるワケでもないし。このあたり、「アナログ再生」とは決定的に違うところですよね。

 なお、例えばHDDへ記録する時の記録位置や断片化がリッパー優劣の要因である可能性については、これもほぼ考えられないと思います。だってOSの管理領域ですからリッパーには制御できませんし、コピーしたら変わっちゃいますし。


■リッパーによるビット品質差違を試聴する

 理屈上可能性を見いだせないことはあまり試す気にならない(苦笑)タチなのでやってませんでしたが、確認された現象から理屈を考えねばならなくなることもあり得ますし、何より“やってみたって実績”も欲しいですしね(笑)。

 と言っても、仮説も立たないのですから何をどう変化させて試せばいいのかはムズカシイです。
 リッピング時のOS環境などももちろんパラメータになると思いますが、まずはリッパーの違いだけを見ることにします。逆に他のパラメータは弄らず、リッパーだけで何か違いがあったら他のパラメータも実験してみる、ということで。HDD上の場所など、どうしようもない部分は今回は無視です。

・セキュアであることとビット品質は無関係
 ちなみに、≪EAC≫や≪dBpoweramp≫などの「セキュアリッパー」が「セキュアリッパー」であるが故に≪iTunes≫などの「フツーのリッパー」より高音質であるという根拠は、一応“補間エラーの差”ですから、セキュアであるかないかは“ビット品質の差”とは直接関係ないでしょう。
 と言うか個人的には逆に、セキュアリッパーの方が忙しくいろんなことしてますからノンセキュアよりシステム負荷が大きいのでビット品質(があるのなら)には不利な気がしてます。リッピング中に一所懸命いろんなログとるなどでリッピングファイル以外にも複数ファイルのリードライトしてて断片化が大きくなるとか???
 セキュアリッパーってなんぞやについてはリッパーのエラー訂正考察記事をどうぞ。

・同時に聴けるんじゃないか?
 すんごく微妙な違いの聴き分けになると思いますが、ここでひとつ思いついたことが。
 普通は同じファイルについてOS設定やプレーヤ設定や電源の取り方などを変えて比較試聴するワケですから、どうしたって同時には比べられません。
 しかし、普段聴いてるのは「ステレオ」です。2ch同時に聴けるのです。そして、今回のパラメータは「ビット品質」であり、コピーしてもその影響は保持される(*)ということですから、生成出自が異なるWAVファイルのデータをLとRに配置すれば、同時に聴くことができるではありませんか。
 同じファイルにしてしまうワケですから、“ビット生成出自以外はほぼパーフェクトに同条件”で聴くことができます。ストレージやメモリ上の位置までほぼニアリーぢゃん。
 これを思いついたからこの比較やる気になったとも言えます(笑)。まあ、半分シャレですけど。

*:その前提でなければ語っても現実的な意味がないので。リッピングした第一世代(?)しか聴かず、絶対コピーしないなんて管理はできないのでコピー前提で影響あるってことでないと。「出自による品質がいいものがコピーによる劣化で悪いものとトントンになることもある」なんて考え方は考慮しません。何かあるなら何か違いは残るだろうと言うことで。
 「リッパーで差はあるけどコピーしたらワカンナクなる」という説なら、逆にリッパーでの差違は無視していいと思いますし。
 なお、一度もコピーしない管理を前提とするなら、もはや当Blogにとってそれは「ファイルオーディオ」ではないので対象外ということで(笑)。


 波形編集ソフトでWAVファイルのチャンネル編集する必要がありますが、「ビット品質」を問題にする説においてはメモリ上に展開してもなお影響は伝播するのが前提でしょうから問題ないでしょう。
 波形編集ソフトについてはこちら

・左右別生成ファイルを作って比較する
 私のメインPC(スペックはコピー劣化記事の実験参照)、BDR-S05Jのパーフェクトモードにてリッピング。途中でシフトダウンなど起こさずスムーズに終了しましたので2度読みなどは発生していないと思います。

 ≪iTunes 10≫(エラー訂正なし) VS ≪dBpoweramp R14.4≫(Burst Mode) を行います。

 前者がリップしたファイルの音が悪いと定評ある(失礼!)リッパーの代表、後者が良い代表です(私の評価ではなく誰の評価でもなく、ナントナクそう言われてるんじゃないかな~という意味で)。
 前述した通りビット品質を良くするにはリッパーの負荷を下げた方がいい気がするので、PerfectMode&BurstModeにしています。ただし、≪dBpoweramp≫はデフォルト設定で使われるのが一般的のように思いますのでそのようにしました(のでフッタが付いてます)。

 ≪WaveCompare≫結果はもちろん一致。ていうか「ゼロサンプル」の部分まで完全一致でした(オフセットも同じということですね)。

 左右同時再生による比較のため、“非破壊型波形編集ソフト”たる≪TWE≫にて「L側に≪iTunes≫、R側に≪dBpoweramp≫でリップしたデータのL側をセット」したファイルを作成。≪TWE≫の出力はもちろんプレーンWAVです。
 上述の通り「ゼロサンプル」まで一致でしたので、時間軸上の編集は不要でした。
 なお、≪dBpoweramp≫データはリッピング第一世代を使っていますから、複数回コピーした≪iTunes≫データより有利なハズです。

 念のため≪iTunes≫データのL側をR側にコピーしたモノラルデータも準備(フォーマット的にはステレオファイルですが本稿ではモノラルと記します)。

 これらをUSBメモリ経由でプレーヤ専用PCの内蔵HDDにコピー。30GBに切ってあるパーティションで、書いたり消したりはほとんどしていないので断片化は酷くはないと思います。まあ、万一酷くても今回比較するのは「同じファイルの中のLとR(ストレージ上でも近接しているハズ)」ですから影響はほぼ無視できるでしょう。

 さて、まずは普通に「≪iTunes≫ VS ≪dBpoweramp≫」対決です。試聴としてはもちろんこちらが本命です。
 プレーヤソフトは≪PlayPcmWin≫を使用。最近常用しているので。メモリに全展開してから再生するプレーヤですが、リッピング時に発生したビット品質差はどこまでも影響する前提ですから問題ないでしょう。

 …スイマセン違い判りません。

 次にいよいよ「Lはi≪Tunes≫、Rは≪dBpoweramp ≫」のファイルです。もちろんヘッドホンを使います。HD700にて。
 LとRで音質が異なるなら“何らかのステレオ感のようなもの”が感じられるのではないかと思います。

 …フツーにモノラルな気が。

 「Rの方が音が小さく聴こえる」とか「R側の方からだけ細かい音が聴こえる」といったこともなく、バッチリ“脳内定位”してました。
 念のため、≪iTunes≫のL側をR側にコピーしただけで作った“フツーのモノラルファイル”とも連続繰り返し試聴で比較してみましたが、やっぱり違いは判らず。

 もし違いを感じたら波形編集ソフトでLとRを入れ替えたりヘッドホン逆にかぶったりして確認続行しようと思って始めたのですが、その必要性は感じませんでした。
 ちなみに、ファイルデータの0/1はHDD上にそのまま記録されているワケではなくECC処理などのエンコードされていますので、LとRのビット品質は“ブレンド”されちゃってるかも知れません。ですのでこれはあくまでもオマケ的実験ということでヨロシクです。


 以上、「リッパーによるビット品質説」は私的には“現象としても”確認できませんでした。
 ということで、やっぱり、ERI的には(少なくとも楽曲部分の)バイナリが同じならファイルとしての音質差は考慮しなくていいことにします。

 「もしかしたらビット品質差はあるかも知れないけれど通常システムの通常運用においては影響をほぼ無視できると判断する」という意味です。再生環境差違の影響に埋もれるレベルではないか、ということで。


 もちろん試聴結果は主観ですし、耳とかシステムのせいかも知れないことは言うまでもありません。


 ハード環境も含めた「リッピング・ゴースト」編に続く!


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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