【EAC】Exact Audio Copy β19

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/

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

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

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

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

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

>>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が何を意図したものかは分からんわ

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

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

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

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

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

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

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

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

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

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

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

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

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

どうでしょうかね

どうなんだろう

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

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

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

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

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

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

ダメだな
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の中身に置換すればいけるかも

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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のほうはどうなってる？

orて何ぞ

ありがとう
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...
という感じで１行で続く。

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

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

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

>>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と聴き比べても違いがあるようには感じない。

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

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

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

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

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

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

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

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

>>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が一致したらそれでよしとするかな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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もチェックサムの計算に使用されない部分で発生したエラーは検出できない

なるほどなあ

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

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

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

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

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

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

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

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

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

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

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

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

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

バイナリエディタ等でファイル比較なり差分とるなり
wavecompareなんてwave専用のソフトもあるね。かなり古いけど

このスレで完璧な複製Discを作りたい人にとっては、試聴して判る用だと完全にアウトかと

確かにまずはiTunesで吸ったものと何らかのソフトで比較したほうがいいね

>>256によると「同期エラーが発生した」
「CTDBとは一致したがAccurateRipとは一致しなかった」とのことだし、CTDBがCRC32計算時に切り捨てた部分で正しく吸えていないところがあるんじゃないかなあ
>>252に書いてある通りCTDBはAccurateRipよりも切り捨てるサンプル数が多いからね

比較をやってみたらEACでリッピングした方は最後が0.176秒ほど欠けてる
なんでや…

>>268
関係ないとは思うけどEAC
Optionsの「Delete leading and trailing silent blocks」のチェックは外してある？

>>269
日本語だと「曲の先頭と末端の無音領域を削除する」だよね？
外してある

>>268
「欠落したオフセットサンプルを無音で補完する」がOFFになってない？

多分それだろ

あと「読み込みエラー、または同期エラーが出た場合はトラックの取り込みをスキップする」がONの場合はOFFにする

欠けてるというのは欠落が0で埋められてるのか音声自体短くなってるのか
無音補完含めて全サンプルwav化されてるならEACのステータスバーにある
h:m:s:fからh*158760000+m*2646000+s*44100+f*588サンプルになるはずや

>>271
「欠落したオフセットサンプルを無音で補完する」はチェック入ってる
「読み込みエラー、または同期エラーが出た場合はトラックの取り込みをスキップする」はチェック入ってない
>>274
どうやら音声だけがなくなってるみたいで、再生時間はiTunesのほうと同じみたい

ふーん。音声ファイルには全セクタ記録されてるけど音だけ欠けてるのか
0.19秒切れるって事は8000サンプルぐらい違う(オフセットってレベルじゃない)事になるけど
iTuneの方は末尾まで音入ってるけどEACは末尾8000サンプルぐらい無音になってるのか
それともEACも末尾まで音入ってるけど今回吸ったのは実は再販かプレス違いで
8000サンプルぐらい音が後ろにズレた結果ケツが切れるようになったのかは
気になる所だな。こういうのはたまにある。
宇多田ヒカルのFirst Loveなんかもそう。フェードアウトしきってる所で気にならないけど
音声エディタで2つ開いてみて比べてみたら

>>275
>>261に書いてあることを試してみて

>>277
オーバーリードをOFFにしたらケツ切れてなかった！！
これ対応してないものもあるのか。標準でチェック入ってたからどれでも対応してるんだと思ってた。
結構初歩的なことだったんだな…。みんな正直スマンかった…。
ちなみになんだが、これ以外のCDも色々比較してみたんだが、比較したもの全部ケツ切れてた。
で、その内の１枚をオーバーリードOFFにしたらケツ切れなかった。

解決できて何よりです・・・オキニのCDは吸い直し？ｗ

>>278
解決したか、良かった
再リップ大変だろうが頑張れ
最後のトラックがCTDBやAccurateRipと不一致になるディスクも一致するようになるんじゃないかな
おそらくリードアウト方向のオーバーリードに対応していないドライブなんだろうね

>>279
>>280
ああ、ありがとう
時間掛かっても全部やり直すと思う
あと書き忘れてたけど最後の曲で頻繁に出てた同期エラーもでなくなった。よかった