リッピング・ゴースト

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ケーブル:Stereo誌付録の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

 リッピング後、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
           Resampler-V(SoX)で32倍アップサンプリング後DSD256変換(FP64 TypeD)再生
 ・ファイル在処:X220ストレージをX79のチップセットSATA2にミヨシ製SATA-272(20cm)で接続
          電源はシステムSSDの枝分かれ
 ・DAC:TEAC製UD-503 DSD256モードになっています DSDデジタルフィルタは150kHz設定
 ・DAC電源:CSE製RG-50(クリーン電源レギュレータ)
 ・DAC電源ケーブル:同上
 ・USBケーブル:アコリバ製USB-1.0SPS
 ・ヘッドホン:UD-503のアクティブGND駆動にて、SONY製MDR-Z7とSENNHEISER製HD700

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

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

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

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

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


■仮想ドライブ幻想

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

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

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

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

 ・イメージ化:≪ImgBurn 2.5.8.0≫で「BIN+CUE」化 (ISO化は選択できない)
 ・仮想ドライブ化:≪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」ですよね。そこで、表題の比較してみます。
 同じタイトルですが買い直した傷なしディスク(こちらは補間発生はありません)からBINとWAVを生成します。傷ありと同じタイトルである意味はありませんが、流れとして(笑)。

 ・BIN・・・≪ImgBurn≫で「BIN+CUE」化
 ・WAV・・・≪EAC V1.1 from 23.June 2015≫で全トラックをひとつのWAVにリッピングした「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だけ、での結果ですので一般的かどうかまでは解りませんが、補間の実体が少しは解ったかなと思います。

・補間結果が一定でもセキュアに読めるのか
 さて、普通は平均値だとすると、正しく読めたサンプルに挟まれたエラーサンプルの補間値は何回読んでも同じになるハズです。
 とすると、セキュアリッパーの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ゲージ」は一度も点灯していません。
 しかして、このファイルとエラーなしファイルとの≪WaveCompare≫結果は以下の通りです。

S05Jm 補間 EAC

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

 このデータのCRC値は正常データと異なりますから、データベース照合すれば補間発生を認識できます。が、逆に、データベース照合は必須で、リッピング結果だけでは認識できないとも言えます。
 セキュアリッパーのセキュア機能はCRC照合こそが本命で、2度読みによるエラー発見(とリトライ)は補助的機能ということですね。

 念のため、補間の有無でCRC値が異なることを当傷ありディスクのtrack09で確認しました。
 S05J標準モード(傷なしディスクと327相違あり)とS05Jパーフェクトモード(傷なしディスクと一致=補間なし)でリップした結果、CRC値は全く一致しませんでした
 なんで傷なしディスクと比較しないかというと、傷ありディスクと傷なしディスクでは「読み出し位置が101サンプル分ズレてる」ためです。上の≪WaveCompare≫を見ると比較開始点が異なってますよね。WAVに切り出された位置が異なるのでデータとしては異なるファイルとなり、≪WaveCompare≫一致でCRC不一致になります。
 「セキュアリッパーにとってはCRC値照合こそ本命」と記しましたが、タイトルがデータベースにないと話が始まりません。
 しかし、同じタイトルなのにサンプル位置が異なることがある=データベースにタイトルがあってもCRC値が一致しないことがあるということで、これってどう対応してるんですかね?
 もしかしてそういうタイトルとして区別する機能あるのでしょうか。それはそれでCRC値集めるってことでしょうか。
 ウチに2タイトルある“同タイトル2枚”では両方ともズレてましたけど…

 やっぱり補間有無はC2エラー情報で認識した方が確実っぽいです。

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


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


メインメニューへ

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

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

13/11/30初稿

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


■はじめに

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

*:ソフトの影響については特殊事例かと。後述。

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

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

 結論から記します。

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

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


■CD-DAの構造

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

・プリギャップ
 トラック毎に設定されているINDEX情報によって制御される“曲開始前の待ち時間”らしいです。CD再生においてはINDEX01が曲開始タイミングですが、INDEX00をINDEX01より前の時間に設定することで、その差分を“曲間”とするものです。
 「曲間無音部」として利用するのが普通ですのでゼロサンプルが記録されていることが大半ですが、音声データを入れることも可能らしい(MCが入ってるケースがあるとか)のでゼロとは限らない模様。有意な音声ではないのに0000hじゃない場合もあるようですし。

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

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

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


 今回さらに踏み込んで、全15曲のあるCDにて以下を比較してみました。プリギャップ1はありませんがプリギャップ2から15まで全部あるCDです(つまりフツーのCDですね)。ドライブはS05J。

a.iTunes10でトラックごとにリップした15曲を波形編集ソフトSoundEngineでマージしたWAVファイル
b.EAC Ver1.0 beta3でimgとしてCDまるごと取り込んだWAVファイル

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

mergeimg compare

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

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


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

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

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

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

リッピング動作

・オフセット0を理想リッピングとした時の+100と-100の状態
  A・・・トラック1の先頭音声データが100サンプル分欠落する
  B・・・トラック2の先頭音声データ100サンプル分がtrack01の末尾に付加され、track02の先頭から欠落する
  C・・・トラック3の先頭音声データ100サンプル分がtrack02の末尾に付加され、track03の先頭から欠落する
  D・・・リードアウト領域の先頭データ100サンプル分がtrack03の末尾に付加される
     (リードアウトが読めないドライブの場合どうなるかはヨクワカリマセン)
  a・・・150フレーム領域の末尾データ100サンプル分がtrack01の先頭に付加される
     (当該領域が読めないドライブの場合どうなるかはヨクワカリマセン)
  b・・・プリギャップ2末尾の100サンプル分がtrack02の先頭に付加され、track01の末尾から欠落する
  c・・・プリギャップ3末尾の100サンプル分がtrack03の先頭に付加され、track02の末尾から欠落する
  d・・・トラック3の末尾音声データが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(Table Of Contents)などに記録されているためどんなリッピングでもマトモに行えば“サンプル総数”は変わることはないハズです。ていうか実際同じですね(昔は違うこともあったかなぁ…)。
 さて、あるCDのtrack01リッピングにおいて「LITEON製iHES208+iTunes6」に対し「Panasonic製SW-5582+iTunes6」では、後者が96サンプル分後ズレしてました(その分先頭のゼロサンプルが増えており末尾が切れている)。
 この値がオフセット差分のハズです。CD-R実験室さんのオフセット情報(*)によると、208は-24、5584は+72とのこと。5582も+72と仮定すると差分はズバリ96サンプルとなりツジツマが合います(EAC的補正値は+30ですが差分には影響しません)。

*:http://homepage2.nifty.com/yss/eac/eac3.htm 素晴らしいです。ありがとうございます。

 dBpowerampのオフセット検出結果ではそれぞれ+6と+102でしたので、やっぱり差分は96サンプルになります(現環境では何故かEACはiHES208を認識しないのでdBpowerampで追試)。

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

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

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

 iTunes11,EAC,dBpoweramp,Power2Go,WMP12,CD2WAV


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

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

mergeAccuimg compare

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

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

 なお、補正によって増えるトラック1の先頭や最終トラックの末尾はCD上のデータではなくゼロ詰めされるのかも知れません。補正なしで読んだら最後までゼロではなくゼロ近傍だったあるCDの最終トラックにつき、S05Jでプラス補正して読んだら補正値分だけゼロサンプルが増えましたので。
 
 「EAC補正値は+30多すぎるのでは問題」については本稿の本質と無関係ですので触れません。


■ズレの正体:その他編

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

・トラック1のプリギャップ処理
 特殊な事例かとは思いますが。
 トラック1のプリギャップは事実上意味がありません。が、存在はできるようです。
 この仕組みに引っかかるアプリ(ドライブ?)がある? 例えば、track01の前にプリギャップが37フレーム分(0.5secに相当)存在する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プレーヤで再生する時はtrack01からスタートするハズなので、37フレーム分をファイル先頭に含める必要はないでしょう。有意な音声情報があるかも知れないことを考慮したのかも知れませんが、サンプル総数(演奏時間)はTOCなどの情報通りで増えていないため、21,756サンプル分“尻切れ”になっています(track02以降もズレたままです)。ので、“引っかかっている”ように思えますね。
 ちなみにWMP12も同様のリップする模様です。


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

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

・いわゆるギャップレス再生とプリギャップ・ポストギャップは無関係
 詳しくは知らないのですが、いわゆる「ギャップレス再生」とは、例えば同じCDからリップした1曲目のWAVファイルの音声データの最後と2曲目のデータの最初が連続して再生されることと理解しています。
 ここで言う「ギャップ」とは、「CD再生では存在しない“間”」が出来てしまうことを指していると思います。CD規格にあるプリギャップやポストギャップといった「意図的に設けたギャップ」のことではないでしょう。同じく“ギャップ”という名称ですが意味が異なることに注意です。
 前述した通り、プリギャップデータはリッピングによって「前の曲のおしり」に付加されるのが一般的です。ポストギャップはそもそもトラック内の音声データ化しています。リッピングによって曲間サンプルの増減はありません。
 よって、ファイルオーディオにおいては、データの連続再生さえ出来れば「ギャップレス再生=CD再生と同じ曲間時間で再生」出来るということです。プレーヤが新たにギャップを削除したり挿入したりする必要はありません。

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

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

a.PlayPcmWinで連続再生してS/PDIF録音し、ひとつのファイルを生成
b.SoundEngine Freeでマージしてひとつのファイルを生成

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

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

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


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

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

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

*:上記プリギャップ1アリCDのtrack02ですが、たまたま見つけた一例として、です。

0000じゃないプリギャップ

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

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

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

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

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

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

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


■つまるところっ!

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

・ドライブオフセット値、気にする?
 オフセットがマイナスのドライブならトラック1の取りこぼしはありません。
 余計に読むサンプル(トラック1のINDEX01より前)は普通はゼロのようです。
 最終トラックの末尾は欠落しますが聴きとれる時間ではありません。
 トラック間の切れ目がオフセット分ズレますが、CD収録順通り聴いている限り全く問題ありません。

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

 一応、今後はリッピング時にプリギャップ状態を確認するためCUEシートも抽出しておこうかと思っています。

 なお、オフセット値を一致させないとCRC値が異なってしまいますから、セキュアリッパーにおいてCRCチェックする場合は気にする必要があるでしょう。

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

EACdeCUE.png

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


■おまけ

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

  ←知る人ぞ知る(?)オーディオチェック用CD

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

・時間表示
 WaveCompareの時間表示は「分:秒:1/100秒」。EACの表示は「分:秒.フレーム」。秒以下の単位は複数あるのに注意。元になるCDのTOCやINDEX情報の秒以下はフレーム単位。ファイルを扱うソフトは1/100秒、CDを扱うソフトはフレーム単位、が基本でしょうか。
 75フレームで1秒。44100/75=588サンプルで1フレーム。
 CDの音声データ管理はフレーム単位なので、リッピングしたサンプル総数は588で割り切れるハズ。

・CDmanipulatorのTOC解析
 必ず開始時間が00:02.00になります。CDには最初のトラックの前に150フレーム=2秒のエリアが存在するらしいです。助走期間? 当ソフトはCD-DAに限定したものではないので表示する?
 「LBAの起点=CD-DAにおいてはtrack01の起点」は150フレームの後らしく、CD-DA専用ソフトでは通常無視されるためEACなどのCUEシートには出現しません。CDmanipulatorは、track01に37フレームのプリギャップがあるCDの開始時間を00:02.37と表示することから、INDEX00を無視してINDEX01をLBA起点と認識しているようですがそれが一般的かは未確認です。

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

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

  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ソフトプレーヤでも同様の表示されるようです。

・わざと?
 ドライブごとにオフセットは一定です。つまり、設計上固定できるということでしょう。なら、オフセットを敢えて設けている(または敢えて放置している)ということになります。実は「アドレス情報がないからズレる」というのはなんだか解せていません。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度読みなどは発生していないと思います。

 iTunes10(エラー訂正なし) 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はiTunes、RはdBpoweramp」の“あしゅら男爵ファイル”です。もちろんヘッドホンを使います。HD700にて。
 LとRで音質が異なるなら“何らかのステレオ感のようなもの”が感じられるのではないかと思います。

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

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

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


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

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


 もちろん試聴結果は主観ですし、耳とかシステムのせいかも知れないことは言うまでもありません。
 一応「ハープのアルペジオ」は聴こえる状況ではありますが…(苦笑)


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


メインメニューへ

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

CDの「エンファシス」ってナニ?

13/06/02初稿

 記事のつながりを考慮し、「リッピングエラーの正体」から分離独立させました(ので本来の初稿はそちらの日付です)。


・CDにノイズリダクション?
 上記の記事を書くために追試などやってる中で、「エンファシス」なる処理(変調)がかかっているCDがあるということを知りました(今さらでスミマセン…CDクラスの規格でそんな小手先のことするとは思いもよらず)。
 要するにDolbyNRみたいな処理した音声を収録するものらしいです。かける処理を「プリエンファシス」、解除する処理を「ディエンファシス」って言うんですね。
 初期(80年代?)のCDには存在するようです。最近でも絶滅したワケではないとの話もあるようですが…

・どこで処理しているのか
 CD-DA標準規格(*)としてあるワケですから、CDプレーヤでは自動的に処理(デコードというかアナログフィルタというか)されます。

*:CCCDなんかと違い、対象CDにはちゃんと「CompactDisc」のロゴ付いてますし何も注記ありませんので。

 DACブロックで処理するのが基本で、S/PDIFには処理されずにそのまま出力されるようです。そう言われてみると、確かにS/PDIFフォーマットの中に「エンファシスの有無」ビットがありますがな。
 ONKYO製DACで「発売後のアップデートでディエンファシス処理が追加された」って話もありますし。



 問題はPC-Audioにおけるリッピングではどうなっているのかです。エンファシストラックはどこかでディエンファシスしないとリッピングエラーどころではない音質上の大問題ぢゃないですか。

 おそらくPC用ドライブとしては“知ったことではない”でしょうからリッパー以降での対応が必要になりますが、エンファシス処理機能はリッパーというソフトウェアにおいて標準装備ではなさそうです。
 リッピング時の処理に対応しているリッパーとして代表的なのは「CD2WAV32」でしょうか。uLilithのCD取り込みも対応しているようですね。

 では、ERIが主力リッパーとして使っているiTunesはどっちなのでしょう? それって大問題ぢゃん!
 web上の情報では対応しているらしいのですが、これは確実に確かめておかないと…

・調べ方:エンファシスCDはどれか
 リッパーのエンファシスに関する機能を確認するためにはまず「エンファシス処理されたCD」が必要です。それってどれ?
 CD2WAV32でCDを認識させるとポップアップで表示してくれる(EACでも調べられます)のですが、手持ちCDを手当たり次第ってのもうんざりです。
 ふと、

 ・古い
 ・99年にリッピングしたデータと現在リッピングしたデータが全曲“全く”一致しない
 ・どころか、平均音量値なども大きく異なる

ディスクがそれクサイのではないかと思い、CD2WAV32にかけてみたらビンゴでした。86年リリースですが音源自体は79年っぽいCDでした。その他計3枚ほど発見。

CD2WAV.jpg

 ということでエンファシスCD=サンプルCDは特定できました。

・調べ方:リッパーは対応しているか
 次はリッパーがどう処理しているのかを調べる方法です。

 ちょっと考えたところ、明示的に「ディエンファシス処理なし」でリップして得たデータと、調査対象リッパーで得たデータをWAVコンペアするのがよさそうです。“聴いたカンジ”はあくまでも補助的確認手段ということで。

 「CD2WAV32 3.21」は、リッピング時にディエンファシス処理する/しないを切り替えられますので、それによって明示的に「処理しない」リッピングを行って上記“基準データ”を作成しました。
 「エンファシス処理されているCD」を「ディエンファシス処理しない」でリップすると、処理したリップに比べ、確かに高音がシャリシャリして低音が引っ込む“Dolbyかけて録音したカセットをDolbyなしで再生”したような音に聴こえます(な…懐かしい…)。

 ディエンファシス処理なしデータと“全面的にWAVコンペア一致しない”データを作るリッパーはおそらくディエンファシス処理を行っていると推定されます。

・結果
 09年にS02Jとセットで用いたハズのiTunes9と現在利用中のiTunes11は…「全面的に一致しない」でした。つまり演算しているということですね。

 明示されていませんが、「対象を自動的に検出してリッピング時にディエンファシス処理する」という意味で、iTunesは「エンファシスCD対応」しているようです(少なくとも9~11。Offは出来ないようですが)。聴感上も、CD2WAV32で明示的に「ディエンファシスあり」リップしたデータの再生音に近く、自然に聴こえますので間違いなさそうです。
 「対象CDを探し出してリップし直す」作業はとりあえず要らないようでホッと一息です。

 ちなみに、ディエンファシス演算に規格はないでしょうから別リッパーで処理した結果は一致しないでしょう。

 しかし、なにげにiTunesが対応しているということは、もしかしてイマドキのリッパーは対応アタリマエ?
 そこで、メインPCにインストールされていた「WMP 12.0.7.7601.17514」と「Power2Go Ver6.0.0.3408」を試してみたところ、「ディエンファシスなし」とWAVコンペア一致しました。つまり非対応のようです。聴感上も“シャリシャリ”でしたので間違いないでしょう。

 Appleやるぢゃん。MSダメぢゃん。

 ちなみに、非対応リッパーでデータ化してからディエンファシス処理するソフト(*)で変換する対応方法もあります。つまりある種のエンコードされたデータのデコーダを変えるということになりますので、もしかして音質的なメリットとかあるかも知れませんね。

*:http://www.ne.jp/asahi/fa/efu/soft/de/de.html

 再生時にリアルタイム処理する方法もあり得ます。
 14/10/08追記:例えばfoobar2000のプラグイン、「EffectDSP(*)」に同梱されている「IIR Filter」のモードとして「CD De-emphasis Filter」があります。
 実際そのように機能しているようです。

*:http://www.foobar2000.org/components/view/foo_dsp_effect

・おまけ
 あるエンファシスありCDのリップ結果を、09年度のS02J(iTunes9 x86)と現在のS05Jパーフェクトモード(iTunes11 x64)と比較(音くらべにて)した結果、各トラックで1000以上のサンプルにおよそ±3以内の差が発生していました。すべてランダムです。
 つまりiTunes9とiTunes11のディエンファシス演算ロジックは異なっており、その差分ということでしょう。32bitと64bitという差はありますが、演算誤差では±3にはならないとは思います。が、一方でエラーを含む可能性もあります。
 なお、Wikiによると10.5.2でディエンファシス関連の不具合修正したとあり、別の情報では10.5.1だけズッコケてたのを修正とありましたが、ERIとしては未確認です。

 こういう現象を「リッピング時のドライブ性能差見つけたり!」とか勘違いしないようしないといけませんね(スイマセン2日間ほど勘違いしてました)。



メインメニューへ

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

ERIへようこそ

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

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です
・一応、拍手にコメント(非公開)付けられるようにしてあります
・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください
・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください
・引用の考え方については「007:諸事」をご参照ください
・アフィリエイトはAmazonのみです
・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

最新記事
カテゴリ
検索フォーム
FC2カウンター