FC2ブログ

リッパーの「DB照合サービス」とは何か

19/09/14初稿

 本稿、ドライブオフセットやディスクオフセットやギャップやINDEXに関してはこちらの記事を前提にしています。


■「DB照合サービス」とは何か

・セキュアモードの限界
 複数回読みで補間結果が同じになり、エラー発生を認識できないことがあります。

 ≪EAC≫には自動的にCD全体のリッピングを2度行ってトラックごとのCRC値を2度生成して比較する機能もあります。Copy(本番)とTestのふたつのCRC値とその比較結果欄がそれです。ですが、TestとCopyの“2回”では一致してしまう可能性もそれなりに高いでしょう。
 これを異なるドライブで行うのなら、その補間結果が全く同一になる可能性は低いかもしれません。けれど、その場合はドライブオフセット補正は必須です(*)。何より、ドライブ変えて2回リッピングしてその結果を比較するのはメンドクサイですよね。
 ですので、複数のドライブで比較することは考えないことにします。

*:あるCDのトラック02をドライブオフセット補正せず異なるドライブ(補正値異なる)でリッピングし、WAVEコンペア結果は一致しますが異なるCRC値になることを念のため確認しました。
 また、同じドライブに入れたまま続けて補正値0と+1でリッピングしても、全く異なるCRC値になりました。

 なお、ここで言っている「≪EAC≫のCRC値」はローカルなもので、以下に記すAccurateRipなどの「DB上の照合データ」とは関係ありません。

・“n=1”の限界をオンラインデータベースで突破する
 つまり、リッピングする同一タイトルの枚数が“n=1”では限界があるということです。
 といって「CDは必ず2枚ずつ買う」などというのは非現実的です。
 そこで、インターネット環境を活かし、「複数ユーザのリップ結果から生成した照合用コードをDB化する」ことでn数を増やすサービスが開発されたのですね。本Blogでは、それを「DB照合サービス」と呼ぶことにします。
 代表的なのが「AccurateRip」です。「CUETools-DataBase(CTDB)」というサービスもあります。
 それぞれ、特定リッパー専用サービスではありません。例えば≪EAC≫では両方採用しており、リッピング結果ログに両方が記録されます。

 なお、≪EAC≫では、ドライブとの相性により、設定によってはセキュアモードだとかえって正しく読めないことがあります。正確に活用するには非常に注意を要するということであり、これも「限界」の一種と考えられるでしょう。


 ということで、以下、オンラインDB照合サービスについて見ていきます。


■AccurateRip(AR)

 まずはこちら。≪dBpoweramp≫のベンダillustrate社が提供しているものです。
 オーディオ用NASにも搭載されているんですね。アイ・オー・データ製NAS:RAHF-S1の解説を引用しておきます。

※1 本商品で採用しているAccurateRip™は、英国Illustrate Limited社のCDリッピングデータ照合サービスであり、将来予告なくサービス提供が終了する場合があります。サービス終了後も、照合機能以外のリッピング機能はご利用いただけます。
出典:https://www.iodata.jp/product/nas/personal/rahf-s1/

 V2もあります。ていうか現在はV2がメイン?

 ちなみに、DBに登録される「リップ結果データ」は、AccurateRipでは以下引用にある通り「チェックコード」と呼ばれています。

ARチェックコードとドライブオフセット
 ところで、AccurateRipで比較に用いるチェックコードは“ドライブオフセット”が違うと異なる値になります(上述した≪EAC≫のCRC値と同じ理屈です)。ですので、ドライブオフセットを補正して読み出し位置を一定にしないと、ドライブごと(オフセット仕様ごと)のチェックコードになってしまうワケです。
 それを確認するため、補正値を手動で変更できる≪CUERipper≫を用いて(*)、異なる補正値でARチェックコードがどうなるか見てみました。
 ドライブオフセット補正した場合と補正しない場合では、ARチェックコード値はV1もV2も異なる値になりました。
 具体的には、オフセット補正が+667と提示されるドライブの補正値を+667に設定した場合と0にした場合です。

*:≪EAC≫では、AccurateRipは補正前提でないと機能しないようです(ARを選ぶとオフセット値は所定の値が入って変更できないことから)。≪CUERipper≫では補正値は自動設定されますが、変更できます。メインとする照合サービスのCTDBはオフセットを気にしない故でしょうか。

 ≪EAC≫のドライブオフセット検出用リファレンスタイトルリストは以下です。同タイトルでも日本語版は別CDと認識されるようですので、製品番号まで合ってないとダメっぽいです。
http://www.exactaudiocopy.de/en/index.php/overview/basic-technology/list-of-included-reference-cds/

ARチェックコードとディスクオフセット
 ディスクオフセットというものもあります。これが違っても、ドライブオフセットと同じ理屈でARチェックコードは変化します。ですので、同じIDのCDでも複数のディスクオフセットバージョンがある場合は複数のARチェックコード値が存在することになりますが、それらは(結果的に?)それとして保存されているように見受けられます。
 そこで、同タイトル(同商品番号)でディスクオフセットが異なる2枚を持っているタイトルでARチェックコードを確認してみました(トラック01にエラーが出るディスクと出ないディスクです)。
 トラック02(2枚ともエラーしません)の≪EAC≫でのリッピング結果を以下に示します。1トラックだけのリッピングです。

 ・E2:エラーあり盤のトラック02
   Copy CRC B66BB840
   Accurately ripped (confidence 11) [392FCBB0] (AR v2)

 ・N2:エラーなし盤のトラック02
   Copy CRC 5E15B169
   Accurately ripped (confidence 4) [EC5B8D8A] (AR v2)

 確かに、同じタイトルの同じトラックなのにCRC値もARチェックコード値も異なります。
 そしてconfidence数も異なりますので、ディスクオフセットバージョン数の“Confidence Group”があると理解していいでしょう。

 なお、トラック01の結果は以下の通り。

 ・E1:エラーあり盤のトラック01(エラーするトラック)
   Copy CRC E6EC38E6
   Cannot be verified as accurate (confidence 12) [C4CCD74F],
   AccurateRip returned [95FCEBCB] (AR v2)

 ・N1:エラーなし盤のトラック01
   Copy CRC B28537DA
   Accurately ripped (confidence 3) [006F8261] (AR v2)

 さて、これをどう理解すればよいのでしょうか。
 illustrate社のページには次のようにあります。

Overtime AccurateRip can become like a wise-friend, someone you can rely on and trust. It works by storing peoples ripping results and comparing your result with theirs. For example 100 people rip Madonnas latest CD, of those 100 twenty have errors, the other 80 all have identical rips. If you were to rip your Madonna CD there are 2 possibilities, AccurateRip would report that 80 other people agree with your rip (confidence of 80), or that 80 disagree if your had errors. What are the odds of 80 people agreeing with your rip, but they really had a bad rip (ie those 80 people had bad rips which happened to give the same check code)? the odds are 4 billion x 4 billion (repeated 80 times), an astronomical number. If more than 3 people agree with your rip, it is 100% certainty it is accurate.
出典:http://cd-ripper.com/secure-ripper.htm

 ARチェックコードの一致は、ディスクオフセットバージョン数だけ存在するハズです。つまり、「confidence」は、いくつかのグループの中で、今回のリッピングと一致するコードのグループの一致数だと思います。
 そして、エラーがあってARチェックコードと一致しない「Cannot be verified as accurate (confidence 12)」の場合でも、confidence数12は「一致したARチェックコード数」を示しており、それと一致しなかったと言っていると理解していいようです。

 しかし、エラーによって変質しているARチェックコード値でディスクオフセットバージョンは解らないでしょう。今回は1トラックだけのリッピングですから、エラーしていない他トラックの情報からバージョンを割り出す、といったこともできないハズです。
 とすると、エラーがあった場合のconfidence数はどのディスクオフセットバージョンのものを表示しているのでしょう?
 ちなみに≪CUETools≫でE1トラックをリペアしたV2値は「5aabfc50」でした。その時E2トラックは「392fcbb0」になってましたので、エラーありディスクのディスクオフセットバージョンにおけるトラック01のエラーなしARチェックコードはリペアして得た「5aabfc50」でいいでしょう。リペア時、confidenceは11でした。しかし上記E1で一致しなかったconfidenceとして提示しているのは12です。リペアの方が後ですので減るのは変ですし、そもそもARチェックコードも違います。やはり12は別バージョンでの一致数と思われます。不一致の場合は「最多一致数グループ」のconfidence数・チェックコードを表示するのでしょうか?

 ちなみに、当タイトルの≪CUERipper≫による「AccurateRip found」数は、この時点で40(CTDBは125)でした(2枚とも)。ディスクオフセットバージョン違いも含め、登録された全数だと思われます。ARチェックコードはトラック単位で登録でき、この表示はDisk-ID単位なので、登録されたトラックの数はこの数以下であり、トラックごとにバラツキがあるのでしょう。

・confidence数は大きいほどリッピング精度が高いのか
 引用では「3個以上一致すれば100%安心」と言ってますから、3以上なら100%でドンツキなワケです。
 つまり「confidenceが3以上のAcucrateなら安心していい」という意味であって、「多ければ多いほど“Accurateレベルが高い=リッピング品質が高い”といった意味ではありません。もちろん、天文学的確率まで考えて“超正確”に言えばどれだけ多く一致しても100%ではありませんから多い方が安心ではありますが、実際にはひとつでも一致すればまず大丈夫でしょう。

・ARチェックコードと「+30補正しすぎじゃないか」問題
 ドライブのオフセット補正値はDB(*)に集められています。これは物理的なトラックの一番頭から読み出し開始するべく設定された値の“ハズ”でした。しかし、実は+30補正しすぎだったという疑義が提起され、どうも事実のようです。
 それはリッピングにどう影響するのでしょうか?

*:http://www.accuraterip.com/driveoffsets.htm

 仮にオフセット補正を“しすぎている”としましょう。とすると、例えば+667補正の場合は+637補正が正しい、ということになりますが、+637補正で得たARチェックコードは、もちろん+667補正した場合とは違う値になります。
 しかし、DB照合サービスにおける照合値は、「ドライブごとのオフセット違いを無くす」という一定のルールに基づいて集められればよいもので、“真のトラック先頭”から読んだ場合の値である必要はありません。
 すでに問題発覚前の補正値(+30補正しすぎだが、すべてのドライブで共通)で大量のチェックコードを集めたのですから、+637で改めて集めなおす必要はなく、そのままでいいと思います。

 なお、+30するしないでリッピングしたファイルは当然異なるものになりますが、30サンプル多めに“後ろ倒し”しても、トラックの頭が30サンプル減りおしりがその分増える=トラックとしては前後の切れ目が変わるだけ(タイトルとしてはリードアウトの30サンプルを読むことになる)ですので、事実上問題にはならないでしょう。そもそもアルバムの順番通り再生する場合は減った分は前トラックのおしりにくっついていますので、トラック01の頭と最終トラックのおしり以外は問題になりません。

 ではなぜ結構問題になっているように見えるのでしょう? それは、ディスクの完全コピー“Exact Audio Copy”のためには(ライティング時のオフセットも含めて)無視できないからだと思われます。
 単にファイル化する場合の影響は上述の通りですので、混同しないようにすべきでしょう。

・ARチェックコードとプリギャップ
 フレーム数をMSFの概念で*m*s*fで表します。ドライブはPureReadオフのBDR-S09Jです。

(1)プリギャップを「前トラック末尾につける」
 デフォルトです。普通です。問題ありません。

(2)プリギャップを「自トラック先頭につける」
 ≪EAC≫では「自トラック先頭につける」こともできます。
 プリギャップがあるCD2枚でそれをやってみたところ、チェックコードは同じになりAR判定できました。くっつける場所は違ってもプリギャップは読みだしているのですから、おそらく生成するファイルとは別にデフォルト状態と同じようにギャップを扱ってチェックコードを生成しているのでしょう。

(3)プリギャップを削除する
 ≪EAC≫では削除することもできます。
 同じく2タイトルでやってみると、「もともとプリギャップが存在しなかったので関係ないトラック」以外は「Track not fully ripped for AccurateRip lookup」と出ます。削除の場合はチェックコード生成プロセスに渡る前に削除されちゃうので通常にみたてた計算できないってことでしょうか(≪MusicBee≫のギャップ削除でもAR不一致になりました)。

 例として、プリギャップが00m00s58fあるトラック04(トラック05のプリギャップは00m01s35f)のリッピング結果ログを提示しておきます。1トラックのみのリッピングです。

・前トラック末尾に付ける(デフォルト)&ARなし
 =ドライブオフセット補正なし
  Copy CRC E0BC3C35
  (AR結果なし)

・前トラック末尾に付ける(デフォルト)
 =トラック04+00m01s35f
  Copy CRC D3A19A2F
  Accurately ripped (confidence 12) [768A9CA4] (AR v2)

・自トラック先頭に付ける(Gap解析しないとできない)
 =00m00s58f+トラック04
  Copy CRC 1F535ED2
  Accurately ripped (confidence 12) [768A9CA4] (AR v2)

・プリギャップを削除する(Gap解析しないとできない)
  Copy CRC FF00E783
  Track not fully ripped for AccurateRip lookup

 しかし、もう一方のタイトル(上記のエラー入りとなしの2枚持っているタイトル)では、エラーなしトラック02(トラック03のプリギャップは00m01s49f)では以下のようになりました。

・自トラック先頭に付ける(Gap解析しないとできない)
 =00m02s25f+トラック02
  Copy CRC 6B5C9164
  Track not fully ripped for AccurateRip lookup

 このタイトルでは、1トラックじゃなくて数トラック同時でもダメなことがあります。
 「CDまるごとリッピングじゃないとAR判定できないことがある」ということですね。GGC-H20Nでもダメでしたので「≪EAC≫のクセ」でしょうか。
 いろいろな事情がありそうですので、AccurateRipを使う場合は、ギャップ処理は無難にデフォルト(前トラック末尾に付ける)が良さそうです。

 ちなみに、補間発生してミスマッチした場合は「Cannot be verified as accurate (confidence 13) [5AAA3BC6], AccurateRip returned [95FCEBCB] (AR v2)」といったログになります。チェックコード不一致ということです。「Track not fully ripped for AccurateRip lookup」は「ARと照合するために十分なリッピングができなかった」ということですので、不一致以前の問題ですね。

 なお、当ログから、≪EAC≫のCRC値はギャップの扱いを変えると変化することが解ります。


■CUETools-DataBase(CTDB)

 AccurateRipと同じ「“チェックコード”のDB照合」技術ですが別物です。≪CUETools≫が展開しているものです。
 「リップ結果の照合データ」はこちらでは「チェックサム」と呼んでいるようです。

You probably heard about AccurateRip, a wonderful database of CD rip checksums, which helps you make sure your CD rip is an exact copy of original CD. What it can tell you is how many other people got the same data when copying this CD.CUETools Database (CTDB) is an extension of this idea.
出典:http://cue.tools/wiki/CUETools_Database

 CD全体として扱っている(トラック単位のリッピングはできない)のがミソのようで、ドライブオフセット・ディスクオフセットらに影響を受けないようですね。

CTDB is free of the offset problems. You don't even need to set up offset correction for your CD drive to be able to verify and what's more important, submit rips to the database. Different pressings of the same CD are treated as the same disc by the database; it doesn't care.
出典:http://cue.tools/wiki/CUETools_Database (ボールドは筆者)

 プリギャップの影響もありません。
 というか、そもそもギャップ処理を選択できません。CD全体で見ているので選択する概念がないのだと推察しています。


■「DB照合サービス」は完璧か

・そのまえに「セキュアモードの現在の立ち位置」
 登場当時のセキュアリッパーは「自分で補間発生を認識して発生しないように読むもの」でしたので、「SecureモードやParanoidモードを使うためのもの」だったと言えます。
 しかし、何度読んでも平均値が入る補間が同じ個所で発生する場合、エラー発生は認識できません。が、その場合照合値はDB上の値とは一致しませんから、“DB上に照合値があれば”エラー発生を検出できます。
 ですので、「DB照合サービス」を実装した現在では

「Burstモードでリッピングして照合できたら終了。できなかったら補間発生をなくすためSecureなモードでがんばる」

という手順が効率的になったと言えるでしょう。
 なお、「これでもかとしつこく読む元祖(by illustrate社(*))」たる≪EAC≫でも、Secureモードの中でもよりしつこく読むParanoidモードはすでに推奨されていません。

What is “Paranoid Mode” and why is it not recommended?
This mode is the oldest read mode in EAC, it exists from version 0.1b on. It will read every sector twice, but in very small blocks. This will slow down extraction, no drive features are used. If the drive does caching the option below should be activated, but this could create problems on some drives. This mode is stressing the drive very much and should not be used, if one of the other secure modes works ok. The “disable CD-ROM drive cache” will disable the drive cache when using Paranoid mode, by resetting the drive after a read command. On some drives this will take several seconds and should not be used in that case.

出典:http://www.exactaudiocopy.de/en/index.php/support/faq/extraction-questions/

*:The next method is the rip-rerip way, the idea is if there is a scratch the re-rip might get a different result so that area of the CD can be ripped many times until there are matches. EAC pioneered this method (the work of PlexTools and dBpoweramp are based on EACs work, we stand on the shoulders of giants, or a giant). This method is to be really put to the test and highlights dBpoweramp’s new way of doing it.
出典:http://cd-ripper.com/secure-ripper.htm

 では、「DB照合サービス」を使えば補間発生の検出は盤石なのでしょうか?

・タイトルがDBにないと機能しない
 当然ですけれど、まずはこの問題があります。マイナーなタイトルだと危ない? また、新譜は“仲間ができるまで”ちょっと時間がかかる可能性はありますね。
 AccurateRipサイトからの引用では「3個以上一致したら(確率的に)絶対大丈夫」と言っています。まあ、違う環境で同じ照合値になるようなエラーが発生することはまずないので、現実的には、一致するものがひとつでもあれば大丈夫だとは思います。
 万一DB上にひとつも無かったらもう一枚自分で買えば解決できる?(笑)

・ディスクオフセットが一致するバージョンのタイトルがないと機能しない
 同タイトルでも表題を満たす必要があります。
 余談ですが、「DBに無かったのでもう一枚買ったらバージョン違いだった」なんて可能性もあり得ますね。
 なお、AccurateRipでは同バージョンが必要ですが、上述の通りCTDBはドライブオフセットだけでなくディスクオフセットにも影響を受けないとのこと。

・ギャップをどうリップするかに制約あり
 上記の通り、AccurateRipを利用するなら無難に「前トラックに付ける(デフォルト)」でリップした方がよさそうです。
 CTDBを利用したい場合は、そもそもギャップ処理は選べません。

・HTOAは照合できない
 細かい点&レアケースですが、AccurateRipでもCTDBでもトラック01の前にある隠しトラック(HTOA)の照合には非対応とのこと。

No verification or recovery of HTOA (Hidden Track One Audio).
出典:http://cue.tools/wiki/CUETools_Database

Spoon (Administrator):Yes sorry, HTOA is not in AccurateRip.
出典:https://forum.dbpoweramp.com/showthread.php?16725-HTOA-and-Accuraterip

・CTDBでカットされるディスクの最初と最後のエラーは検出できない?
 CTDBのチェックサムは“最初と最後の5880サンプル(10フレーム)”を除いて生成するらしいので、ここにエラー(2度読みでは認識できないようなエラー)があった場合は、チェックサムに影響を与えず照合できてしまうかも知れません。ただし、この場合でも、≪CUERipper≫はドライブからのC2Error情報を参照しているようなので照合前にエラーを認識するとは思います。が、「ドライブからC2エラー情報が確実に取れている」という条件は付くでしょう。

If there's a match, you can be certain it's really a match, because in addition to a recovery record, the database uses a well-known CRC32 checksum of the whole CD image (except for 10×588 offset samples in the first and last seconds of the disc). This checksum is used as a rip ID (CTDBID) in CTDB.
出典:http://cue.tools/wiki/CUETools_Database

 チェックサム生成のためにカットされるサンプル部分はほぼ無音のハズですので、そこにエラーがあっても事実上の音質には影響与えないでしょうけれど。が、本Blogではそういう点も含めてノーエラーでのリッピングを考えていますので、敢えて挙げています。

・オフセット補正値が判明しているドライブじゃないと機能しない
 AccurateRipではオフセット補正必須ですので、ドライブを認識して自動的に設定されます。逆に言うと、オフセット補正値情報があるドライブを用いる必要があるということです。
 DBには多くのドライブが登録されていますのでまず大丈夫だとは思いますが、一応条件にはなるでしょう。

・オフセット補正すると「サンプル欠損・変質」してしまうソフト設定やドライブがある
 AccurateRipでは「オフセット補正」は必須ですが、実施には注意が必要です。
 オフセット補正すると≪EAC≫で言うところのOverreadすることになります。実際、Overreadしないとサンプル取りこぼすようです。
 といってOverreadできないドライブでOverreadするとサンプル値をゼロ書き換えることがあるようです。末尾や先頭で発生しますので実サンプル値もゼロのことが多いと思いますが、そうでない場合は問題になります。

・「汎用性があるミスリード結果のチェックコード」が蓄積されているかもしれない
 ところで、上記のオフセット補正に関する注意事項の現象は、特殊な環境のみで発生するものではありません。結果も一定の規則性を持ちます。つまり、使用ドライブやリッパーの条件を満たせば同様のリッピング結果となり、そのチェックコード値がDBに蓄積されるとそれなりのconfidence数になる可能性もあります。そのconfidenceと一致しても、実際には不完全リッピングです。
 ただ、AccurateRipではそれを容認というか利用している気もします。「オフセット補正によってサンプル欠損したチェックコードは有効とする」としないと、問題が解決できなそうですから。補間発生の有無は検出できるんだからいいじゃん、と。
 なお、欠けたりゼロに置き換えられたりした部分は先頭や末尾の微小時間で通常は無音でしょうから聴いて判るような不完全さではありませんが、「完璧ではない事例」とは言えるでしょう。

・自分の「エラー入り照合コード」と照合しないよう気を付ける必要あり
 非常にまれなケースだとは思いますが、エラー入りコードをDBに登録してしまい、もう一度リッピングした時に同じ補間結果になって(冒頭のリンク記事の通り可能性あり)同じコードになった場合、DB上の自分のコードと一致してしまうかも知れません。
 特に「コード登録がひとつもなかった」のを見た気がした後は、“セルフ照合”しないように気を付けた方がよいでしょう。一度めの照合やドライブ変更した場合は(補間結果が同じになる可能性はまずないので)関係ありませんけれど。
 もちろん、照合DBに登録するデータにはリッピング環境によるIDが埋め込まれており、セルフ照合しないように考慮されています。以下はCTDBの説明です。

Submission log, including user's ip addresses and CD drive model, which is used to eliminate erroneous submissions, virtual/faulty drives, and to verify if a submission by one user is independently confirmed.
出典:http://cue.tools/wiki/CUETools_Database

 ≪EAC≫にはAccurateRipへのresult提出項に「Computer Identification」数値があります。これで判定していると思われます。

 ですが、例えば「ドライブ以外全とっかえ(IPアドレスなども)」でも同じ環境だと見抜けるのでしょうか。この場合は「平均値補間」で同じリップ結果=チェックコードを結果を返す可能性はあると思います。
 もしかしてセルフ照合の可能性も含めて「3個以上なら安心」なのかな?
 いずれにしても、こういう可能性についても覚えておいた方がよいでしょう。

 なお、エラーがあるCDを異なるドライブ(同じ型番でも)でリッピングした場合、全く同じエラーになる可能性はほぼないと言っていいでしょう。ですので、レンタルCDのエラー入りチェックコード(チェックサム)が複数の環境から登録された場合でも同じ値になることはまずありません。

・セキュアモード結果と不整合になる可能性はゼロではない
 2度読みした結果(平均値などで)補間結果が同じになったら(C2Flagを使わない)セキュアモードではエラー認識できません。が、AR照合結果はNGになるでしょう。
 一方、セキュアモードがエラー検出~リトライした結果選択された値がたまたま正しいサンプル値になったら、エラーレポートされたのにDB照合結果はOKになるでしょう。
 後者はまず発生しないと推定されますし最終的には正しい結果を得ていますからDB照合の問題点ではないと思いますが、万一そのような現象に遭遇したときに混乱しないよう、覚えておいてソンはないでしょう。

・サービスが永続する保証はない
 元も子もない話&杞憂でしょうけれど念のため。アイ・オー・データ社が言っている通りです。
 もっと言うと、サービスが続いていても、「利用者=リッピング人口」が減っていくとチェックサム(コード)の蓄積も減りますから、新譜などはうまく照合できなくなる可能性もないとは言えません。


 以上より、CTDBなら「C2エラー情報取得問題がないドライブで」「データベースにチェックサムがありさえすれば」「HTOA以外は」盤石と言えそうです。
 CTDBが使える≪CUERipper≫なら、≪CUETools≫でエラーを修復できるかもしれませんしね。


 なお、本稿で用いたリッパーのバージョンは以下の通りです。
  ≪EAC V1.3 from 2 September 2016≫
  ≪CUERipper 2.1.6≫
  ≪MusicBee 3.3.7165≫


#本稿は、セキュアリッパーに関する考察記事への追記(19/02/28)を独立させたものです。


メインメニューへ

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

最新記事
ERIへようこそ

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

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

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

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

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

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

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

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

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