【EAC】Exact Audio Copy β19

**名無しさん＠お腹いっぱい。** · 2020/07/28(火) 00:17:58.66

CD-DA (オーディオ CD) をほぼ完璧に読み取ることができる Windows 向けの多機能で強力なリッピングアプリ、"Exact Audio Copy (EAC)" および兄弟アプリ "Easy Audio Copy" のスレです。
兄弟アプリの Easy Audio Copy は Exact Audio Copy と同じくらい信頼性が高く、正確でありながら、非常にシンプルなインターフェイスで、専門知識がなくても利用できます。

Exact Audio Copy は非商業目的での利用は無料です。しかし、PayPal 経由での寄付は非常に感謝されます。Easy Audio Copy は有償ですが、14 日間の無料評価版を利用できます。

Exact Audio Copy
http://exactaudiocopy.de/
Easy Audio Copy
http://www.easyaudiocopy.com/

日本語ファイル
メニューバーの [EAC]、[EAC Options...]、[General]、[EAC language selection] の [Use language] で [Japanese] を選択、[OK] をクリックで日本語に切り替え
[メモ] Exact Audio Copy Version 1.0 Beta 4の自分用の日本語化ファイルを作成: Nice Disport
https://nice-disport.seesaa.net/article/411484047.html

前スレ
Exact Audio Copy β18 [無断転載禁止]©2ch.net
https://egg.5ch.net/test/read.cgi/software/1496658487/

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 06:21:16.40

>>161
つまりズレるということ？

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 08:03:15.44

ズレるの意味分かってるのか？

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 10:07:41.29

じゃあズレないの？

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 18:57:37.61

>>165
たとえ型番同じでもプレス違いでズレてる事あるから型番だけじゃ特定できない
円盤に刻まれてるIFPIの刻印まで同じなら大丈夫と思うけど

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 19:06:52.44

http://www.accuraterip.com/driveoffsets.htm
におけるCorrection Offsetがプラスの場合に限定されるけど、
初代プレステのデータとCD-DAが混在してるゲームがあると
Correction Offsetが容易に分かる。
タイトルが沢山あるから、多分一番入手しやすいんじゃないかな。

データとCD-DAの境界、つまり
トラック2のプリギャップの先頭にデータの残骸が残るんで
(残骸の長さ(バイト)/4)-2がCorrection Offsetになる

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 20:26:22.37

最近のパイオニアはみんな+667なのか

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 20:28:46.89

>>171
というかパニオニアのBDはほぼ全て+637 +30 +667なんだけど
根本的なところはあまり変わってないのかな？

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 20:29:50.01

昔からだよ。BDのドライブは

**名無しさん＠お腹いっぱい。** · 2021/02/22(月) 23:57:18.17

0にする必然性はないし変わらないことが大事なんだよ
統一されればモアベターだけども

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 01:13:57.34

>>173
ということは基本設計は変わっていないということ？

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 02:20:22.64

でも+100兆とかじゃ困るんでしょ？

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 07:45:52.86

分かってない人が多そうなので解説しとく。
多分、CD上に、イメージファイルほぼそのままの形で記録されてると
考えてるんじゃないかな。
その誤解が元凶だと俺は思う。

本当は1フレーム24バイトで分散範囲も広いんだけど、
それだと書けないので、3文字で代表してニュアンスを示すと、
イメージへの出力として
[ABC][DEF][GHI]
となる場合、CDからの入力は
[A__][D__][GB_][_E_][_HC][__F][__I]
みたいな感じで記録されてるわけ。
[ABC]と[A__]の位置関係をどう変えても、ほとんどは、ずれてるわけよ。

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 07:46:33.71

[_HC]が入力されて直ぐ[ABC]を出力するのは
プレーヤーに厳しいから
初代エンコーダ、すなわちオフセットゼロは以下の位置関係にしたとしよう。
入力[___][A__][D__][GB_][_E_][_HC][__F][__I][___][___]
出力[___][___][___][___][___][___][ABC][DEF][GHI][___]

音飛びの抑制から、ほどなくプレーヤーのバッファが大きくなると
データを未来からとってきても問題もくなる、そうすると

末尾を一致させよう
入力[___][A__][D__][GB_][_E_][_HC][__F][__I][___][___]
出力[___][___][___][___][___][ABC][DEF][GHI][___][___]

中心を一致させよう
入力[___][A__][D__][GB_][_E_][_HC][__F][__I][___][___]
出力[___][___][___][ABC][DEF][GHI][___][___][___][___]

先頭を一致させよう
入力[___][A__][D__][GB_][_E_][_HC][__F][__I][___][___]
出力[___][ABC][DEF][GHI][___][___][___][___][___][___]

といったエンコーダが出てくるのが必然。
規格で決められてないので、どれも正当なのね。

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 10:37:03.43

パイオニアのドライブがオフセット+637でリードアウトのみオーバーリード可能っていうのは、本来のオフセット位置より637サンプル前から読み始めて、後ろはオーバーリードに対応したソフトなら既定の時間よりも先まで読めるようになってるって認識であってる？
で、パイオニア的にはオーバーリード非対応のソフトでも637サンプル(0.014秒)なら最後が切れても問題ない、と判断してるってこと？

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 12:12:48.55

「本来の」って認識がおかしいって話をしてるんだが、まあいいや。

667サンプルってのが、まさにCIRCの分散範囲で、>>178の先頭を合わせるケースのCDで、読み落としがないように、って思想だと示唆される。

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 12:34:11.88

みんなすごい事考えて使ってるんですね。

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 13:18:36.76

CDはスクランブルとデスクランブルもあるからなあ

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 13:59:18.49

正しくオフセット設定すればリファレンスCD使わなくてリッピングしてもズレない？

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 14:35:42.44

読み込みオフセット訂正値はずっとAR基準にしてるわ
両方向にオーバーリードできるドライブは持っていないし、持っていたとしても面倒なことはやりたくないし、完全バックアップを目指すならEACよりDICを使ったほうがいいみたいだし

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 15:24:11.13

EACは変なDiscからでもちゃんとwaveの吸い出しをしようってのが存在意義であって
変なDiscを変なまんま複製する方向のソフトじゃないからねぇ

**名無しさん＠お腹いっぱい。** · 2021/02/23(火) 19:51:25.44

>>179
すまん、逆で説明してた。

エンコーダは
[ABC][DEF][GHI]...という入力に対し
[A__][D__][GB_][_E_][_HC][__F][__I]...というふうにCDに記録する。

初代エンコーダ(オフセットゼロ)は、[ABC]が入力されて、直ぐには[A__]を出せないから

オフセットゼロ相当
入力[ABC][DEF][GHI][___][___][___][___][___][___]
記録[___][A__][D__][GB_][_E_][_HC][__F][__I][___]

エンコーダのバッファが豊富になって

オフセット+6相当(フレーム先頭のA,D,Gがずれない)
入力[___][ABC][DEF][GHI][___][___][___][___][___]
記録[___][A__][D__][GB_][_E_][_HC][__F][__I][___]

オフセット+666？相当(フレーム末尾のC,F,Iがずれない)
入力[___][___][___][___][___][ABC][DEF][GHI][___]
記録[___][A__][D__][GB_][_E_][_HC][__F][__I][___]

1フレーム6サンプルなので、基本的に6の倍数になるはず。
πの667の+1が何を意図したものかは分からんわ

**名無しさん＠お腹いっぱい。** · 2021/02/24(水) 02:21:13.65

賢い人は、πの数字にどのような意味があるかを考えるがよい。数字はオフセットを指している。そして、数字は六百六十七である。

**名無しさん＠お腹いっぱい。** · 2021/02/24(水) 06:34:56.25

まぁπとしては、リサーチしたCDの中に、
そこまでやらないと、最初を読み落とすCDがあったから
そうせざるをえなかっただけだろう。

**名無しさん＠お腹いっぱい。** · 2021/02/24(水) 07:30:46.99

オフセット値が小さいドライブの方が優秀じゃないのか？
冒頭に音が入っててもパイオニアのドライブだと読めないんじゃない？

**名無しさん＠お腹いっぱい。** · 2021/02/24(水) 07:43:56.01

ARのオフセットのプラス方向は、時系的に古い領域を読んでることを意味する。
だから君の認識と逆だと思うよ。
リードインを読めないのであれば、
オフセットが大きくないと、読み落とすCDがあるんだろう。
繰り返すが、昔のCDぐらいしかオフセットゼロと言い切れない。

**名無しさん＠お腹いっぱい。** · 2021/02/24(水) 07:54:49.46

値がどうであれオーバーリードさえできればそれで良いんじゃないの？

**名無しさん＠お腹いっぱい。** · 2021/02/24(水) 09:28:46.55

外部サイトへのアドレスデータとか入ってるCDを読ませると音楽以外もトラックとして取り込んじゃうのって回避できる？

**名無しさん＠お腹いっぱい。** · 2021/02/25(木) 01:03:20.09

外部サイトへのアドレスデータって何

**名無しさん＠お腹いっぱい。** · 2021/02/25(木) 01:17:42.11

そのままなんだけど楽曲以外にオマケをDLするためのサイトへショートカットのデータが入ってる
他にもMVとかが入ってるCDもデータ部分が余分なトラックとして読み込まれちゃって、playerで作ったcdplayer.iniが反映されないんだよね

**名無しさん＠お腹いっぱい。** · 2021/02/25(木) 07:39:02.69

よく知らんけど、予想としては、トラック数の不一致で弾かれてるとか？
データトラックの分だけnumtracksの増加と
=曲名の行の追加を手作業でとか？

**名無しさん＠お腹いっぱい。** · 2021/02/25(木) 10:24:13.77

>>191
リードインの方向へのオーバーリードもできるのであればね。
直近話に出たπは、リードアウトへのオーバーリードに限定されてるわけ。
それは、リードイン方向のオーバーリードはリードオフセットによって十分確保されてるって判断からだと思うよ。
オフセットゼロの視点から見れば、ARの補正オフセットがプラスのドライブは、それだけリードインをオーバーリードしてるってことだから。

**名無しさん＠お腹いっぱい。** · 2021/02/25(木) 16:33:52.36

ためになるスレだ
読んでるだけでなんかわかった気になってきた

**名無しさん＠お腹いっぱい。** · 2021/02/26(金) 01:19:22.77

>>195
駄目だった
2000~2010年頃に直接オマケ入れるみたいなのが流行ったのかわからないけど、date cdとaudio cdのハイブリッドは面倒だな

**名無しさん＠お腹いっぱい。** · 2021/02/26(金) 20:13:11.10

CDをリッピングする前にギャップ検出ってやっておいたほうがいいですか？

**名無しさん＠お腹いっぱい。** · 2021/02/26(金) 23:51:38.37

どうでしょうかね

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 00:02:31.93

どうなんだろう

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 01:18:12.09

>>198
cdplayer.iniのCDエントリ頭[1234567]みたいなのがキーになっていて
データトラックが存在する関係でEACが要求するキーと
cdplayerが吐き出すキーが不一致を生じて読み込めないとか
cdplayer.iniの値をEACの要求値に合わせたら読めそうな気するけど
でもそれで対処できたとしてもメンドイな

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 08:33:15.12

それは、ありそうだな。
おそらくTOCのバイナリデータのCRC32かなにかを計算してて
データトラックの行を無視するか、しないかの違い

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 09:14:35.04

CRC32じゃなかったわ
musicbrainz.org/doc/Disc_ID_Calculation
作者マターだな。

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 10:03:22.28

間違った。
あの数字、WindowsScriptingHostで
Scripting.FileSystemObject使って
Windowsシステムから教えてもらう感じの数値みたいで
ブラックボックスだわ。
CD EXTRAやミックスモードCDだと出ないこともあるらしく、
そもそもPlayerがどうやって数値化できてるのか
ってレベルの問題だわ。

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 10:36:25.67

以下を拡張子.vbsのファイルとして保存して実行すれば
EACの要求する数値が分かると思う。
3行目は各自のドライブに書き換え

Dim FSO, DRV
Set FSO = WScript.CreateObject("Scripting.FileSystemObject")
Set DRV = FSO.GetDrive("Q:\")
WScript.Echo(Hex(DRV.SerialNumber))

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 16:37:45.48

ダメだな
cdplayer.iniのCDボリュームIDはHex(FSOobj.SerialNumber)の値と違う
cddbが使う(cuesheetに書かれてる)DISCIDとも違う
Track01.cdaのオフセット+18h(4byte)がボリュームIDみたいだけど
肝心のCD-ExtraとかデータトラックありCDだとTrack01.cdaは見えない

playerとEACでcdplayer.iniを出力すると2つのエントリが追加されるだろうから
EACが出力した[data track]行以外の中身をplayerの中身に置換すればいけるかも

**名無しさん＠お腹いっぱい。** · 2021/02/27(土) 23:01:22.48

なんかよくわからんけどテキストエディタでcdplayer.iniを開いてそのCDのトラック情報を矩形選択→コピーしてクリップボード経由でEACに貼り付けでは駄目なの？

**名無しさん＠お腹いっぱい。** · 2021/02/28(日) 01:47:30.04

>>208
playerでcdplayer.ini作ってdate track分行追加して先頭の「数字=」部分削除してコピペでいけたけどメンドイ…

**名無しさん＠お腹いっぱい。** · 2021/02/28(日) 03:34:19.36

>>208
それでもいいけど曲名とか項目の数だけ範囲指定してコピペしないといけないので痺れる

**名無しさん＠お腹いっぱい。** · 2021/02/28(日) 11:56:19.96

>>208は説明不足だった
>クリップボード経由でEACに貼り付け
これはEAC側でCD情報取得→クリップボード
を選ぶということね
まあ>>209の言う通りデータトラック分の行の追加と行頭のトラック番号=の削除は必要だけど
範囲選択して正規表現で加工して、クリップボードにコピー → 変更を保存せずに終了で少しは楽になるかな

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 13:25:30.12

『範囲取り込み品質 100.0 %』『エラーは発生しませんでした』なのに
AccurateRipが『トラックが正確であるかどうか全く確認できませんでした。データーベースと異なったコピーができます。』
の場合、正確性は判断したらいい？
一応有名なアルバムだからデータが少ないということはないと思うのだけど

**212** · 2021/03/05(金) 14:33:01.82

×正確性は判断したらいい？
〇正確性はどう判断したらいい？
スマン

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 14:43:16.50

2つ目、もの凄い偶然を疑って安心できないなら3つ目のコピーを作成して、それらが一致するか確認。
コマンドラインでfc /bなり、bkhashesなどのハッシュ計算ツール使うなりは自由。

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 14:57:04.77

別のドライブでも吸い出して同一かどうか比較するしか無い

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 15:05:18.25

有名アーティストなのにデータベースと一致しないのは
設定の問題じゃないの？

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 16:13:19.39

日本で有名でも、海外わからないし、大半の人はCD聴かないしリップもiTunesなので、君が一番最初なのかも

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 19:23:28.99

>>212
CTDBのほうも不一致だったの？

**212** · 2021/03/05(金) 19:47:38.06

スマン…EAC使い始めて数年になるのにCTDBが何なのかまったく考えずに使ってた。
全曲『(25/25) Accurately ripped』と書かれてるから問題なしということなのか。
てっきりAccurateRipだけで比較してるのかと思ってた。
正直スマンかった。みんなありがとう。

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 20:48:19.22

>>219
CTDBは一致したのか
https://www.axfc.net/u/4033696
ctdbeac
こちらのCTDBプラグインも使ってみるといいよ
これはAccurateRipとも照合するように設定してビルドしたCTDBプラグインなんだけど、AccurateRip v1のオフセット違いのデータとも照合できる

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 20:52:14.64

ああごめん、既にリップ済みならCUEToolsで照合したほうが早いね

**212** · 2021/03/05(金) 22:10:51.71

ありがとう
自分はどうやら照合の仕組みを理解できていないみたいだから、これからちょっと勉強するわ
あとCTDBの見方について質問したいんだけど、別のCDの１つの曲（CDの１１曲目）のリッピング結果で

11 | (965/1472) Differs in 2956 samples @02:48:56-02:48:60, or
　　　(3/1472) differs in 2956 samples @02:48:56-02:48:60, or
　　　(3/1472) differs in 582 samples @02:48:55-02:48:56, or
　　　 (2/1472) differs in 660 samples @02:48:55-02:48:56, or
　　　(4/1472) differs in 2140 samples @02:48:56-02:48:59, or
　　　(6/1472) differs in 1990 samples @02:48:56-02:48:59

っていうのがあったんだけど、これってどう判断したらいいんや…。
大体02:48:55-02:48:60のところでサンプルデータと違う部分が見つかったってことなんだろうけど…

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 22:29:07.16

11曲目にAccurately rippedという表示がないなら失敗してるんじゃないの？
965人の所に入ってたら下記のようになると思う
11 | (965/1472) Accurately ripped, or

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 22:44:12.54

(965/1472)という数字からすると癖のあるCDっぽいね

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 23:24:57.64

>>222
提出されたデータは全部で1472件
そのうち965件とは02:48:56-02:48:60の部分で不一致
そのうち3件とは02:48:56-02:48:60の部分で不一致...以下略
ということになるね

提出されたデータのうち完全一致しているものが1件以上ある場合は
Track | CTDB Status
11 | ( 1/1472) Accurately ripped, or (965/1472) differs in 2956 samples @...
という風に表示される
>>223の言うとおり、1件もAccurately rippedと表示されていないのなら、正確にリップできていない可能性が高い
AccuratelyRipのほうはどうなってる？

**名無しさん＠お腹いっぱい。** · 2021/03/05(金) 23:37:47.91

orて何ぞ

**212** · 2021/03/05(金) 23:56:43.36

ありがとう
AccuratelyRipは
『トラック 11 正確であるか確認できませんでした (正確に 200) 』
となってるけど、これたまにあるアルバムの最後の部分に同期エラーが出るやつだと思う。
実際、疑いのある位置はアルバムの最後の部分だし。
それで、CTDBの結果で不一致の部分を確認したら、実際アルバムの最後の部分だったわ。
でもアルバムの最後の部分に同期エラーが出ることはよくあるけど、
それがCTDBのほうにも出てるのは、他のログを確認してもこのCDだけだった。他の同種のエラーと何が違うんだろう。

さっき２回リッピングし直したら、内１回が
( 1/1476) Accurately ripped, or
になった。

アルバムの最後の部分にエラーが出た場合、聴いて問題なければ気にしなくていいと書いてあって、
実際聴いてみても特に問題は感じられないから、これも気にしなくていいってこと？

ちなみに範囲取り込み品質は99.9 %。
CDはクイーンの2ndアルバムで2011年に出たSHM-CDのやつ。

>>226
すまん、読みやすくなるように文章を改稿した。実際は
11 | (965/1472) Differs in 2956 samples @02:48:56-02:48:60, or (3/1472) differs in 2956 samples @02:48:56-02:48:60, or...
という感じで１行で続く。

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 01:24:51.86

>>227
AccurateRipとも不一致か
>でもアルバムの最後の部分に同期エラーが出ることはよくあるけど、
>それがCTDBのほうにも出てるのは、他のログを確認してもこのCDだけだった。
うーむ謎だな
ドライブと相性が悪いCDなのかねえ

>さっき２回リッピングし直したら、内１回が
>( 1/1476) Accurately ripped, or
>になった。
これ、もしかすると212がそのCDを初めてリップしたときに提出したデータと一致してるのかもね

ところでドライブオプションで
ドライブがC2エラー情報を検出できる
というオプションのチェックはON/OFFどちらにしてる？

**212** · 2021/03/06(土) 04:14:11.52

>>228
>これ、もしかすると212がそのCDを初めてリップしたときに提出したデータと一致してるのかもね
あ、なるほどそういうことか。
最初の２回はC2エラーチェックONでやって、３回目がOFF。
２回目が( 1/1476) Accurately ripped, orで
３回目は(967/1476) Differs in 3648 samples @02:48:55-02:48:60, or。
ということは、もう１回OFFでやったら( 1/1476) Accurately ripped, orが出るってことか。

２、３回目も範囲取り込み品質は99.9 %。
エラーはやっぱりアルバムの最後の部分。

ドライブ自体１０年くらい前のものなので、正確性は期待しないほうがいいのかな。
一応ドライブの正確性ははいだったんだけど。

とりあえず、エラーの部分はCDと聴き比べても違いがあるようには感じない。

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 04:14:15.79

>>227
2:48ってTrack11「Seven Seas Of Rhye」の終端部分だな
終端部分はオフセット量とドライブがオーバーリードできるかできないかで
ハッシュ違ってくる事あるんじゃないか？
例えばオーバーリードできないドライブでオフセット+6と+48のドライブじゃ末尾切れる量が42サンプル違うから
そこに音入ってるCDだと違うハッシュになると思う
なので同じドライブ(オフセット量)で登録された結果が登録されてないと一致しないかもしれん

**212** · 2021/03/06(土) 06:55:08.90

>>230
オフセットとかの話は今の自分には難解…。
データが一致してなくてもちゃんとリッピングできてる場合もあるんだよね？
このケースは妥協点ということで問題なしでいいのだろうか…。

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 07:25:09.96

これを問題無しとするならもうEAC使う必要無いだろ
お手軽リップソフト使っとけ

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 10:03:16.98

オフセット関係あるのかな？
30サンプル訂正したりしなかったりするけどどっちでもこんなおかしなことになったことはないけどなあ

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 10:30:04.80

データベースとの比較なんて文字通りの意味しかない
自分を信じるか他人を信じるか
同じ環境同じ設定でエラーが出たり出なかったりするのなら設定見直すか
どう足掻いても同じような結果になるならファイルのバイナリ比較して判断するしかない

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 10:39:34.71

無音の長さにきまりはない。
聞こえないレベルの音量ということで、
気にせず、無音を全く追加しないエンジニアもいるだろう。
そうなると、オーバーリードした上で
無音でない範囲を切り取る以外になく、
それができないのであれば、当然オフセットでデータの落ち方が変わる。
というか、そういう場合、
CDが作られたオフセットとドライブの読み取りオフセットが一致するという偶然がないかぎり
どうやってもデータは落ちる。

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 11:11:28.44

ただ、ものは考えようで、
そういうCDの場合、「オーバーリードができるのであれば」、
CDが作られたときのオフセットが分かることを意味するわけで、
吸いだしイメージとして完璧なものができる幸運もある

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 11:16:00.77

>>231
条件変えてもバイナリ一緒ならOKとするとか。てか同一ドライブでそれ以上の事はできんだろう
ソフト変えても変わらんと思う。読みが安定しないウンコリッパーでもない限り
宅配レンタルとかで別個体のUICY-15010借りてバイナリ一致ならもうそのドライブはそうなんだ
CUEToolsでrepairすればAccurate Rippedになるかもしれんけど、ドライブとかで変わる円盤だと
それがモアベターかは分からんな

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 11:38:09.25

>>229
>最初の２回はC2エラーチェックONでやって、３回目がOFF。
>２回目が( 1/1476) Accurately ripped, orで
>３回目は(967/1476) Differs in 3648 samples @02:48:55-02:48:60, or。
ON/OFFで結果が変わってしまったか
厄介だなこれ

ちなみにAccurateRipもCTDBもディスクの冒頭と末尾の数セクターは計算に使用しないから、オーバーリードできるかどうかは気にしなくていいよ

自分だったらもう
テストしてからCDイメージをコピーしCUEシートを作成
を実行して、CRCが一致したらそれでよしとするかな

**212** · 2021/03/06(土) 18:23:03.00

みんなありがとう。
とりあえずもう少し勉強して仕組みを理解してからどうするか考えることにするわ。

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 19:26:14.30

まあ全体の2/3しか一致してないから普通のCDではないね

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 19:42:01.48

最近リップしたログを見てみた
https://i.imgur.com/gZUTrLU.png
マイナーなものを好むからDBの件数が少ないわｗ
ただ、どれも大多数が一致している
リップ結果に不安を感じる人がほぼ居ない優しいCDたち

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 22:42:17.85

CDというものは曖昧な規格なんだという事を忘れなければ、残念なリップ結果にも優しくなれるんじゃないかなあ
各ドライブのオフセット値の違いを気にしてるのとかを見ると特にそう思う

どんなCDにも、ドライブにも、それぞれズレはあるわけだから
なにより聴いてみて違和感がなくて、設定を変えればAccurately rippedになる環境でさえあればそれでいいんじゃないのかなあ
前後の取りこぼしなんて実際のところどうでもいい物なんだよ

**名無しさん＠お腹いっぱい。** · 2021/03/06(土) 22:47:49.56

EACは別にズレなくリッピングするためソフトじゃなくて、CDのデータを正確に読み取れてその検証もできるからこそ有用なツールなんじゃないかと

**名無しさん＠お腹いっぱい。** · 2021/03/07(日) 10:35:34.23

そういう理解が進めばいいけど、
現状サイトの9割以上は間違った認識を植え付けるようになってる

**名無しさん＠お腹いっぱい。** · 2021/03/07(日) 10:54:29.13

何度読み直してもAccurately rippedにならないけど毎回バイナリは一致するのは諦めていいの？
数十枚に1枚くらいこういうCDあんだけど

**名無しさん＠お腹いっぱい。** · 2021/03/07(日) 12:22:46.33

何回も言われてるように
人が決めることじゃねぇ。
自分で決めな

**名無しさん＠お腹いっぱい。** · 2021/03/07(日) 12:42:07.62

メーカー違いの3台の別ドライブで一致したら、同じCD買うかレンタルして、そのCDとも全て一致したらおk

**名無しさん＠お腹いっぱい。** · 2021/03/07(日) 13:08:57.46

そんな変なCDあるんですね。

**名無しさん＠お腹いっぱい。** · 2021/03/08(月) 20:59:55.47

以前リッピングしたflacをいくつかCUEToolsでverifyしてみたけど、
約600/1700 Accurate rippedになるCDと約3000/5000 Accurate rippedになるCDがあった
CTDBだけでなくAccurateRipとも一致したから正しくリッピング出来ていると思うけど、こういうのは少し気持ち悪いな

**名無しさん＠お腹いっぱい。** · 2021/03/10(水) 09:59:53.06

期間不明だけど、いくつかのドライブのDrive OptionのDrive caches audio dataのチェックが入っているべきのところが外れていたわ！

**名無しさん＠お腹いっぱい。** · 2021/03/12(金) 20:32:16.75

AccurateRipとCTDBのサンプルとの比較ってどういう基準でやってるの。
たとえばドライブの不具合でノイズが入った音楽ファイルが出来上がってしまったとしても、
AccurateRipとCTDBのサンプルと完全に一致したと判断される場合もある？

**名無しさん＠お腹いっぱい。** · 2021/03/13(土) 03:13:02.87

CTDBでは
http://cue.tools/wiki/CUETools_Database
によると
CRC32チェックサムが使用されているらしい(ただし冒頭と末尾の10x588サンプルは計算に使用されない)
CRC32が偶然一致する確率は約4億分の1らしい

AccurateRipのほうは
https://forum.dbpoweramp.com/showthread.php?20641
に書いてある
AccurateRipCRCはサンプルポジションxサンプルデータ(4バイト)の和のようだ
https://wiki.hydrogenaud.io/index.php?title=AccurateRip
によると最初のトラックの冒頭2939サンプルと最後のトラックの末尾2940サンプルは計算に使用しないらしい
偶然一致する確率がどの程度なのかはわからないが、
https://hydrogenaud.io/index.php?topic=66233.msg755995#msg755995
のCUETools作者による書き込みによると、誤り検出精度はCRC32のほうが高そうだ

当たり前だが、CTDBもAccurateRipもチェックサムの計算に使用されない部分で発生したエラーは検出できない

**名無しさん＠お腹いっぱい。** · 2021/03/13(土) 08:29:03.91

なるほどなあ

**名無しさん＠お腹いっぱい。** · 2021/03/13(土) 19:33:35.56

オフセットだのオーバーリードだのの部分はそもそもチェック範囲外なのか

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 01:25:39.07

曲の最後の部分まで音が入ってるCDリップしたけど、誰が聴いても普通に分かるくらい最後が途切れてしまってる。
でもAccurateRip、CTDB共に完全に一致してる。
EACのオフセットずれ問題って気にする程じゃないとよく言われるけど、実は結構深刻なくらい切れてるのでは？
iTunesでリップしたらちゃんと最後まで入ってるから自分のドライブがおかしいってことは無いと思うんだけど

**255** · 2021/03/14(日) 02:02:13.56

すまん( ;∀;)
俺の確認ミスだった…
AccurateRipのほうは最後の曲で同期エラーが起きてた。
でもCTDBのほうは(195/199) Accurately ripped, or (2/199) differs in 3539 samples @03:39:08-03:39:11となってる。

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 02:25:46.72

CTDBのチェックサムの計算には使用されないがAccurateRipのチェックサムの計算には使用される部分でエラーが起きているのかもしれない

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 13:53:52.43

オフセットのズレって何万分の1秒とかの世界だから耳では判別不可能な筈
単に傷や汚れでエラーあっただけでしょう

**255** · 2021/03/14(日) 17:37:23.28

んー実を言うとこのアルバム以前違うCDでリッピングしたことがあって、
今回買いなおしでリッピングし直したんだけどどっちも同じ結果なんだわ。
傷とかが原因だとするとiTunesで正しく取り込めたってことは、
iTunesのエラー訂正機能のほうがEACのそれより優れてるってことになっちゃうし。
EACの設定によるのかもしれないけど自分でオフセット+102とかにしても結果は同じだから、このドライブがEACと相性悪いのかもしれん。
正確性はいなのに全然信用ならんなー。

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 18:27:29.61

データが復活するわけじゃないんだから
オーバーリードができないのであれば、
オフセット補正はデータを欠落させる行為なんだから
なんも補正しないようにすればいいんでないの

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 18:38:16.84

https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Options#Drive_has_.27Accurate_Stream.27_feature
に書いてある通り、今時のドライブでAccurate Streamが「いいえ」になることはほぼないだろうな

・オーバーリードをONにしているならOFFにする
・取り込み中の減速許可をOFFにしているならONにする
・バーストモードで吸い出してみる
・CUERipperで吸い出してみる
あと試せそうなのはこれくらいかね

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 18:43:32.00

オフセット+102したところで2ms
誰が聴いても普通に分かるぐらい最後が切れてるなら
元々そういうケツが切れたCDなんだろう

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 19:02:20.09

エラーが出るという話であれば新品のCDなのにセキュアで読むと最初からエラー発生で進まないというのが2連続続いた事があった
ディスクそのものが相性悪いと見切った

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 19:50:44.66

前にlgだとどうして同期エラーが出て駄目で別のパイのドライブなら大丈夫だったって書いた事あるけど、そういう相性があるのでは

**名無しさん＠お腹いっぱい。** · 2021/03/14(日) 23:00:41.72

俺だったら波形編集ソフトでどれだけ削られたのか比較するわ
聞いて分かるくらいなら相当欠落してるはず