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

(； ･`д･´) ﾅ､ﾅﾝﾀﾞｯﾃｰ !! (`･д´･ (`･д´･ ;)

eac [at] exactaudiocopy [dot] orgに連絡したことある人いる？

リバースエンジニアリングっていうか逆アセンブルは禁止じゃなかったか

少々論点ずれるが、逆アセンブルやら解析やら自体は禁止出来ない
この辺保護するのは著作権や特許だが、知ること自体には制限を掛けられないし掛けていない。知った内容の利用を禁じているだけ（私的利用はＯＫ）
だから逆アセンブルしてコードを見たり、理解すること自体は問題ない。改造しても、自分で使うだけなら問題ない
>>110はここに書いてしまったので私的利用ではなくなっていてNG

小説を読んでパクリ小説を書いたらＮＧだが、小説を読むこと自体がＮＧにはならないのと一緒
一口で言うと、プログラムについてもパクリやら改造したものの公開禁止ってこと

なお、暗号化して通常の手段では逆アセンブル出来ないようにしてあるのをどうにかした場合には、技術的保護手段の回避ということで別枠で問題になる

著作権は表現を保護する法律だから、パッチとかは著作権の侵害にはあたらないよ
>>110がこの修正を加えた本体をまるごと配布したらその限りではなくなるけど

作者にメールで要望を送りたいけどIMEのことを説明するのが難しい

それかなり昔にスレ民がメールして作者から「環境無いのと分かんないから対応出来ない」みたいな返事来たってレス無かったか？

>>116
そうともいえるが、同一性保持権を侵害するための情報またはツールともいえるので、幇助になる
技術的保護手段の回避のための情報を公開するだけで、幇助として違法となるのと一緒じゃない？

一応言っておくけど、親告罪だから著作者本人ではない自分がどうこう言うべきことではないし、これは悪用でもない
けどもだからと言って好き放題やっていいわけでもないと思うので、やっぱり作者に詳しい説明して修正方法教えたらどう？と思う
パッチ作れる＝元のコードを推測出来ている＝どう変えればいいかわかっている

途中送信済まぬ

だと思うから、多分こんな感じのコードが該当機能周辺にあると思うんだけど、こうしてみて？確認はこっちでやるから送ってくれれば試して結果送る
こんな感じでやれば、対応してくれる可能性はある
言葉は通じなくてもソースコードでは語り合えるんだからさ

>>118
過去ログ見てくるか
でも実際作者の環境だと試せないよね
わざわざIMEをインストールしてもらうのも気が引けるしなあ

> ID:0aZlqpaW0
ここでグダグダ言ってる暇あるならおまえがメールすりゃいいだろ
> 親告罪だから著作者本人ではない自分がどうこう言うべきことではないし
じゃあ黙ってろ

>>116
ときめも裁判とかDoA裁判とか、一種の映像作品としてのゲームを改変する
データの配布がアウトだったから、パッチだから大丈夫とも言い切れない
これは幇助ではなかったと思うけど？ >>119

>>115
逆アセンブル自体は禁止されていないけど、
逆アセンブルに伴うプログラムの複製は私的使用の範囲内に限られる

なんで110とは関係なさそうな123に口汚くののしられなきゃならないのかわからない
こちらは逆アセンブルしてコード復元＆修正をしたわけじゃないので報告しようがない

こちらは別ソフトで海外の人にパッチ勝手に配られて迷惑してる側だから、作者側の気持ちを考えてあげてくれと言いたかった
勝手に作って配られているだけでも気持ち悪いのに、パッチ自体の不具合を報告してきたり、バージョン違いのパッチを当てたことによって発生した不具合の報告が無視できない数ある
そしてパッチを当てているということが判明するのがたいていの場合遅い。使ってる側にはそれでおかしくなるという発想がないから
はっきり言って無駄な時間であり迷惑でしかない
言語が通じなければなおさら
ならソースコードレベルでどこをどうして欲しいと具体的に要望くれたほうがまし

はっきり言って自分が使ってない機能のところだから、この不具合が治ろうが治るまいがどうでもいいし、110がパッチを書くこと自体は自分にとっては何の迷惑でもない
ただ見ていて作者可哀想だと思うし、123みたいなやつを見ていると吐き気がする。それだけ

123が黙ってろと言うからではないが、ID替えつつ多数派を装い、また口汚くののしってくるだけだと思うので、これ以上この件については何も言わない

えーと実は自分は>>107に書いた通り最初にアレを書いた者なのですが(スレβ16の27ですね)、何というか申し訳ないです
>>107にも書きましたが自分はv1.1用を最後に書くのはやめましたし、今後も書くつもりはないです
他の住人ももうアレを書いたり要求したりするのはやめたほうがいいかと思います
作者へのメールは頑張って送ってみるつもりです

>>125
なんか、ID替えつつとか被害妄想じみてるないかい？
お茶でも飲んで、落ち着いていこうよ
私なら日本語以外のサポートなんてしませんと言ってばっさり切る
Google翻訳とかで日本語でメールよこすヤツには自分のHP(?)から直で落としたヤツ
いがいのサポートはしない、パッチ作ったやつのとこ行けでお仕舞いにしちゃうかな

ゲームのパッチの件はそもそも映像・演出とかの同一性の保持がなされていない点が
著作者人格権の侵害にあたるって事になったぽいけど、EACに>>110の改変おこなう事が
EACを作った作者のプログラムの使用意図から外れるのかっていうとそうにはならんだろうしねぇ

俺が作ったソフトの無断パッチで俺が迷惑してるから
EACの作者もきっと迷惑に思ってるに違いない！というのはちょっとね

それはEACには全く関係ない愚痴だから
スレの趣旨的にはあなたが迷惑をかける側になってますよ

そういう話を続けたいなら、無断パッチの可否／功罪について語ろう
みたいなスレを別に立ててそこで語ってくれた方が前向き

Easy Audio Copyは、業界標準であるExact Audio Copyの兄弟製品です。
Easy Audio Copyは抽出機能に集中しており、スピードと品質でExact Audio Copyを凌駕しています。

Exact Audio Copyはプロのユーザーにはより多くの機能を提供しますが、使いこなすのが非常に複雑なのが難点です。
良い結果を得るためには、ユーザーはまず、利用可能な多くのオプションを熟知し、それぞれの状況に最適なものを選択する必要があります。
例えば、Exact Audio Copyには、メインウィンドウに34のグラフィカルユーザーインターフェース要素があり、160以上の全体的な設定があります。

ほとんどの人は、それほど複雑さを求めていません。ハードウェアに特別な調整を必要とせず、
追加のコンポーネントをダウンロードする必要もなく、簡単に使えるプログラムを求めています。
このニーズに応えるために、Easy Audio Copyが開発されました。
経験の浅いユーザーでも、優れた結果を得ることができます。予備知識は必要ありません。

初期設定は、インストール言語と1つ以上の圧縮形式を選択するだけです。
Easy Audio Copyは自動的にインターネットからCD情報を取得し、その後直接抽出を開始します。

過去スレ見てて思い出したけど、v0.99系には日本語が二重に入力されるというバグがあったんだったな

https://docs.google.com/document/d/1b1JJsuZj2TdiXs--XDvuKdhFUdKCdB_1qrmOMGkyveg

なんかみつけた

うむ

what is this

this is a pen

this is a an apple

uh apple pen

読み込みオフセットがリッピング時で書き込みオフセットが焼き時なのは分かるんだけど
結合オフセット(combined read/write offset!は何の時に使うの？

同じドライブで読んで焼く時
読み込みオフセットが不明のドライブでもズレの無いコピーが出来る

そもそもオフセットとは、初代CIRCエンコーダからの相対値であって、
初代で作ったわけではないCDに、オフセットゼロ化はむしろ害悪。
書き込むときに差分だけ適用すべきもんだ。

未だにオフセットとは何なのか理解できないままだ…

>>138
読み込みオフセットが不明なのに何故分かるの？
読み込みと書き込みオフセットを足したのが結合オフセットの値でしょ？

書いて、読んだら、その差分が結合オフセット。
読み書きオフセット知る必要なし。

そもそも、昔のCDは、初代エンコーダしかなくて
オフセットゼロで作られていたと考えられるから
オフセットゼロ化が意味がある。
どこからなんて、明確な区別は出来ないが、
目安として、全米の出荷音源でCDが過半数をとった
1991年以降は、いろんなオフセットで作られた
CDがあると見た方が良い。

そして出来上がったCDからは、
どんなオフセットで作ったかなんか分からない。
あきらめて、何も考えてないドライブメーカーもあるんだろうけど、
平均を考えた結果、ドライブ毎に
バラティ豊かな読み込みオフセットになったんだと俺は思うよ。
オフセット調整なんて、バッファに貯めて、後から先頭決めるだけなんで、造作もない。
ドライブメーカー雁首そろえて、わざと不正確にするわけないもの。

業界からの圧力

そんなもんがあったら、
そこを売りにした中華製品が
ちまたに溢れてるだろうよ。

>>142
それはEACで算出出来る？

どんなソフトでもいいんじゃない。
持ってるイメージ、そのまま書き込んで、
そして読み込み直す。イメージにしなおす。
その差だもの。

>>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の言う通りデータトラック分の行の追加と行頭のトラック番号=の削除は必要だけど
範囲選択して正規表現で加工して、クリップボードにコピー → 変更を保存せずに終了で少しは楽になるかな