【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/

>>147
ドライブオプション・書き込み→オフセットテストCD作成

>>149
ありがとう
ちなみにaccurateripには読み込みオフセットしか無いけど書き込みオフセットや結合オフセットのデータベースって無いの？

いまだにオリジナルディスクの完全コピーを作りたいって人、いるんだねぇ
俺はリップしてmp3化するダケなんでオフセットをきにしたことないや

古いディスクはオフセットゼロで作られてるだろうから、やる意味あるけど、
90年代で既にあやしいし、今のディスクは
まずオフセットゼロで作られないと言われてるのでむしろ害悪だし
どんなオフセットで作られたかわからないんだから、
今完全コピーは無理。
実情をしらない人の宗教儀式と化してるよ。
ただ無知からか、デマを広めるサイトが9割超えてる印象だから
仕方ないね。

無理ってのは、イメージファイルとしてはってことで、
差分ほどずらし戻して書き込めば、元に戻る。

ただ完全コピーにこだわるくせに、
サブチャネルを捨てるフォーマットを選んでる時点でダメだけどね。
MCN,ISRCを何処におくとか個性あるから。

サブコードまで拘る時点でEACなぞ使わん
DiscImageCreatorがあるからな

Key DiscとリファレンスCDの違いって何？

CDmanipulatorはどう？

>>155
keydiscは市販のプレスCD使ってリードオフセットをAR基準値に合わせるもの
合わせる事で他のドライブのリッピングデータと同じハッシュ値になるので
ARハッシュデータベースに照会してリッピングデータの整合性を確認できる

リファレンスCDはドライブの読みと焼きの位置ズレを調べるためのもの
(PLEXTORなんかは読みも焼きも同じ位置だがPIONEERとか多くのドライブは違う)
ズレを無くす事でそのドライブで吸って焼いたCDはオリジナルCDとズレがなくなる

>>157
KeyDiscでオフセット設定してもリファレンスCD使わないとリッピングしてもズレる？

君のようなのは楽ちんなリッパー使っとけ

>>159
頼むから教えて

>>160
リファレンスCDのListにないCD、どうすると思うのよｗ
だいたい、リストにあるのと同じアルバムでも日本国内盤じゃあかんから、入手難易度も高いし

たまたま海外盤のCD持ってたからいけたわ

全世界で何百万も売れたようなアルバムの輸入版は案外中古屋で格安で売られていたりする
自分はリストにあるアルバムいくつか持ってるけど、どれも100円以下で買ったわ

クイーンとかabbaとか結構引っかかるよな

Listにのってる洋楽CD、ウチにあるタイトルのヤツは全部型番違うんだよねぇ
Eurythmicsのとかドイツ製なのに型番が違うっていう

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

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

じゃあズレないの？

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

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

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

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

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

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

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

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

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

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

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

[_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][___][___][___][___][___][___]

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

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

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

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

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

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あるんですね。