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スリム)だとやっぱり連続補間も発生(補間値の算出に補間値が使われている)していましたので、「連続しないことが保証される」というレベルではないようです。


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

・補間結果が同じでもセキュアに読めるのか
 さて、普通は平均値だとすると、正しく読めたサンプルに挟まれたエラーサンプルの補間値は何回読んでも同じになるハズです。
 とすると、セキュアリッパーの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

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


 このデータのCRC値は正常データと異なりますから、データベース照合すれば補間発生を認識できます。
 が、逆に、データベース照合は必須で、リッピング結果だけでは認識できないとも言えます。

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

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

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

 「セキュアリッパーにとってはCRC値照合こそ本命」と記しましたが、タイトルのCRC値がデータベースにないと話は始まりません。
 しかし、同じタイトルなのに物理的に違うディスクではサンプル位置が異なることがある=データベースにタイトルがあってもCRC値が一致しないことがあるということで、これってどう対応してるんですかね?
 もしかしてそういうタイトルとして区別する機能あるのでしょうか(どうやって?)。それはそれでCRC値集めるってことでしょうか。
 ウチに2タイトルある“同タイトル2枚”では両方ともズレてましたけど…

 つまり「ノーエラーディスクでもプレスによって(?)CRC値は異なることに留意する必要がある」ってことですね。

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


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


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

・アフィリエイトはAmazonのみです

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

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