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単位になる点など、照会や修復用のデータをディスク全体として見ているところにミソがありそうです。

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

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


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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