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

>>553
なるほど

ヤマハ盤のデータはおそらく↓だろう
http://db.cuetools.net/lookup2.php?version=3&;ctdb=1&metadata=extensive&fuzzy=1&toc=0:22705:48455:72715:97197:121647:143627:171457:197247:219410:258722:277455

http://www.accuraterip.com/accuraterip/d/a/1/dBAR-011-0018e1ad-00d8f809-9e0e730b.bin

AccurateRipのほうは、トラック11の場合
0xb32d66af Confidence=2
0x03d081e2 Confidence=2
0x00000000 Confidence=0
の3件のCRCが提出されているようだ
Confidence=2だし、そこまで気にしなくていいかもしれん

C2エラー検出の設定を今の設定と逆にしてリッピング→CRCが一致するか試してみるとかどうかな
オーバーリードはoffにしてあるよね？

0xb32d66af Confidence=2
0x03d081e2 Confidence=2
片方がARv1のCRCで、もう片方がARv2のCRCかもしれないな

>>554
うちじゃオーバーリードON/OFFで結果は変わらなかった
それからEACのログじゃわからないけど、CUEToolsのログ見ると
ヤマハ盤はAR基準オフセット+86と+459の結果も登録されていて
+86でverifyするとトラック11はAccurately rippedになるが代わりにトラック8がNo match
+459でverifyすると全トラックAccurately ripped
+86はLGとかの+86ドライブ使ってCUERipperでオフセット付けずに吸って登録したのかもしれないな
+459もそうかもしれないが、ARドライブDBにオフセット+459のドライブは無い。よくわからん

まぁポニーキャニオン盤と同じバイナリになる今の結果でよさげなので
ARDBにsubmitした。あと2週間ぐらいしたら照会できると思う
YCCW-25持ってる人は現状と3週間後にAccurateRipしてみてほしいｗ

オーバーリードを有効にすると逆に読めなくなる場合があるので注意が必要

チェックを入れた方が良い場合

オフセットがAccurateRip基準で＋29、実験室基準で−1以下の場合でLead-in(リードインのみ可)と判定された場合

オフセットがAccurateRip基準で＋31、実験室基準で＋1以上の場合でLead-out(リードアウトのみ可)と判定された場合

オフセット値関係なくBoth(両方)と判定された場合

これ以外はオーバーリードのチェックは外した方がいい
もちろんNone(なし)と判定された場合も

〜　SONY CDU948Sでの位置ずれのない焼きについて　〜

SONY CDU948Sは、EACで作ったOffset Test CDで「Read sample offset correction」を検出すると、検出するたびに値が異なってしまいます。

また、非MMCドライブのため「Write samples offset」も求めにくくなっています。ただ、他の多くのドライブのOffset値が判明しているため、実際に948Sでライティングをして、他ドライブで吸って比較・・・といったことをすれば「Write samples offset」は検出可能です。
（詳しいやり方は省きますが、948Sの「Write samples offset」は「+24」です）

さて、実際に948Sで（位置ずれのない）音楽CD焼きを行うにはどうすればいいのか？ですが、


１． 「Combined read/write sample offset correction」に適切な値を入れて、948S以外で読む。（EAC + 948Sでリッピングすると、読むたびに位置ずれがおきるため）
２． できたCUEシートをCDRWINまたはnero5.5等に読ませて焼く。


となります。
ポイントはEACで設定するの「Combined read/write sample offset correction」の求め方ですが、

例）PLEXTOR PX-40TSを読みに使用する場合
646 + 24 = 670

例）PLEXTOR PX-W4012Aを読みに使用する場合
68 + 24 = 92

例）TEAC CD-532Sを読みに使用する場合
62 + 24 = 86

です。

>>559
ちなみに、プレクの自社ドライブと現行のドライブで「Combined read/write sample offset correction」を設定する場合は

プレクの自社ドライブ(PX-708A、PX-712A、PX-716A、PX-755A、PX-760A、Premium、Premium2)を読みに使用する場合
0 + 24 = 24

パイオニアのBDドライブ(基本全機種)を読みに使用する場合
637 + 24 = 661

例）現行のライトンやLG、つまりMediaTekのチップを積んだドライブを読みに使用する場合
-24 + 24 = 0

となります。

>>559-560応用編
ヤマハのCRW-F1で、AudioMasterを使ってB's Recorder GOLDで焼く場合は

プレクの自社ドライブの場合
0 + 36 = 36

パイオニアのBDドライブの場合
637 + 36 = 673

ライトンやLGの現行ドライブで、チップがMediaTekの場合
-24 + 36 = 12

未確認だが多分あってるはず

ちなみにB's Recorder GOLDは最新版(現在17)でもAudioMasterが使用可能

流石にCDRに焼いてる人ってもうおらんやろ？
リッピング目的のドライブであり聴いたり保存はフラッシュメモリかHDDだよな

車もファイルでOKだしCDDAで焼く必要性を感じない

最近のカーオーディオなんかドライブレスのファイル再生専用が増えてるもんな
ディスプレイオーディオもドライブレスだしUSBさして再生さすのが当たり前になってる
自作PCやBTO、メーカー製もドライブレスが当たり前になってきてる
自分もわざわざパイオニアの内蔵用BDドライブを買ってきてベアボーンで外付け化して使ってるけど
焼いたりはもう一切してないな

ドライブ付けようにも付けるベイがないんだからつらいよね

CDをリッピングしたいので、プレクスターのドライブが欲しい。
今買うならどれがいい？

結論
Premium、PX-755A、PX-760Aで。
使いこなせるならPremium2もあり。
PlexTools Professional(以下純正ソフト)でのエラー計測などの特殊機能が不要なら、PX-708AやPX-W4824TA、PX-W5224Aもあり。
PX-712A、PX-716Aはやめとけ。(特に後者)

理由
一番の理由はピックアップの流用が効くかどうか。
PremiumはW4824TAとW5224A、755Aと760AはNEC中期の一部ドライブのと互換性がある。
PX-712Aは設計上の都合で、読みだけでもピックアップを大きく消耗する。
その為、あまり書き込んでないのにピックアップがダメになるという・・・
ただ、ピックアップはPX-708AやNEC初期の一部ドライブと互換性があるのでまだマシな方。
PX-716Aは欠陥品。個体差が非常に大きく、良個体は基本存在しない。また、ピックアップの消耗も早く、他のドライブから流用も効かないというから最悪。
Premium2は、高価でgigarec0.9xやエラー計測をしないという人には勿体無い。AudioMasterが使いたいというならヤマハのCRW-F1で充分。また、相性の良いCD-Rが少ないというのもある。他にもCD-RWの書き込みに不具合ありというのも。

接続について
IDEのドライブなので、今のマザーにはIDEポートがないので物理的に取り付けられない。
なのでIDE増設ボードやIDE-USB変換基板が搭載されている外付けケースを買うことになる。
前者はCIF-IDEというボードがおすすめ。
後者は、2005年以降に発売されたI-O DATAの16倍速以上18倍速までの外付けドライブの中身を入れ替えて使うのがおすすめ。付属のACアダプターは電源が弱いので、TAS0046というのに交換した方が安心。それでもちょっと足りないドライブもあるけど

最近使い始めた初心者なんだけど、端的に

”選択したトラックをエンコードせずコピー”
”選択したトラックをエンコードしてコピー”

はどっちが良いの？親父の古いCDを焼く予定

いい悪いじゃなくて目的に合わせて決めるといい
flacとかは半分弱しか縮まないが可逆でビットパーフェクトでwavに戻せる
mp3とかm4aとかは320Kでも1/5ぐらいになるが非可逆で元には戻せない
wavはエンコードしない分リッピングが最も速いが当然サイズが一番大きい

自分で聴くだけのリッピングは全部ofrのmaxにしてる

久しぶりに使ったらCD一枚に一時間弱掛かるんだが、おま環？前は精々15分だったと記憶してるが・・・

15分もおかしいけどなｗ
ディスクにもよりけりだけど精々、数分だよ

うちの最初のドライブはR4倍速RW2倍速だった

>>571だけど、他のソフトを全部閉じたら10分弱で終わった
因みにCDはレンタルしたビートルズで98年盤とかそんなの

OSはSSDだし保存場所は別のHDD
となると、遅延の遠因はCPU使用率・・・？

てか10分もおかしいけどな
CDのリッピングなんて早いディスクなら2分とかそんなぐらいよ
どんなドライブ使ってんの？
速度規制かかってるファームのドライブなんだろうね

おかしいとか言ってるのはお前だけだけどな

ギャップ検出だけで2分なんて過ぎ去るだろ

CDビュンビュン早くてうれちいでちゅね〜

ゴミみたいな煽りかました時点で負けやぞ

結局は対物なんだから、速けりゃ良いって訳でも無い気がするがな
馬鹿は速けりゃ何でも良いと思っちまうからなあ

やめたれｗｗｗ

こらこら、ビュンビュン大好きな発達障害者君を虐めてやるなよ＾

>>545追記
TEACからOEM版出てた

DV-W516GD
DV-W516GDM

>>567
TAS0046の代わりに、TAS0072を使っても良い。

またACアダプター発見
でも、使えるかどうか微妙(ピン配置、極性は同じだと思うけど)
っていうかケースGNDって何？

5V 1.5A/12V 1.5A版・・・UEA325D-0512-A
5V 2.0A/12V 2.0A版・・・UEA136D-0512-A

エラーが出たけど疑わしい箇所を聞いても
ノイズも音飛びも確認できず
自然な時ってどうしてますか？

昨日からAccurateRipのデータベースにつながらなくて
[database access error: リモート サーバーに接続できません。.]
ってメッセージが出るんですけど、CTDBのほうはつながっているので
AccurateRip側の問題でしょうか？

>>586
新品・レンタルなら「聴けねえぞゴルァ！」って叩き返す。中古ジャンクCDなら
・ちょっとしたエラーならCUEToolsでrepairでAccurately Rippedなwav作れるかも
・別個体を借りてくるなりして吸い直す
・ポリカボネートの傷ならエラー無くなるまで磨く。レーベル面(記録層)の傷なら諦めろ
・ノイズが気にならないなら割りきってそのまま聴く
エラー出ても化けてるのはLSB付近で聴いても分からない事が少なくない

ACアダプタースレ？

accurateripのデータベースか何か
https://www.daefeatures.co.uk/search

何？

ARDBの検索かと期待したら
ドライブの検索でがっかりだぜ

すごい初歩的な質問だが範囲取り込み品質ってなんだ？

光学ドライブのデータベース集みたいなもの
http://wiki.redump.org/index.php?title=TEMP_Wiki_page_by_olofolleola4

EACのwav取り込みでタグ付けるのって無理？
色々調べてみたけど情弱過ぎて全く分からん

wavにはタグ付けられない。ことは無いけど付けられないと思っておいた方が良い
flac(VorbisComment) や MP3(ID3) みたいに決まった規格が無いからソフトによって対応バラバラ、らしい

リードインリードアウトをオーバーリードするにチェックしてたけど、チェックしてもしなくてもファイルの大きさ変わらなかった。変わらないという事は、チェックはどちらでもいいってことかな？
このことについて毎日ググってるけど、だれか助けて。。。

>>597
ドライブ何使ってる？

まずはドライブオプションの読み込みサンプルオフセットの検出をやってみて
オーバーリードの可否をチェックするだけなら普通の音楽CDでできるから

あ、サンプルオフセットの検出は3〜4回程やって変わらないかどうか確認した方がいいかも？

オーバーリードのチェック早見表(ドライブのオフセットはAccurateRip基準から30を引いた数字の場合)

Both(両方)
入れる

Only Lead In(リードインのみ)
オフセット値がプラス→入れない
オフセット値がマイナス→入れる

Only Lead Out(リードアウトのみ)
オフセット値がプラス→入れる
オフセット値がマイナス→入れない

None(不可)
入れない

>>598-600
教えていただきありがとうございます。
bdr-xd05bkとbdr-xd07を使用してます。
+667

>>601
オフセットはプラスの値でオーバーリードはリードアウトのみなので、チェックする

>>602
ありがとうございます。

>>596
RIFF-SIFは決まった規格なんだが……
MSが公式に大昔から用意してるもの
Winampとかの初期のプレイヤーソフト作った奴らがその存在を知らなかったために対応せず、他の人たちにも知られなかっただけ
https://docs.microsoft.com/en-us/previous-versions//ms713231(v=vs.85)
項目についても、Windows の SDK で公式に定義されている（ヘッダーファイルに書いてある)
決まった規格がなかった〜、という話は、トラック番号についてのこと
元々 AVI とかでの利用を想定していたのか、トラック番号の項目がないから、それだけは各ソフトの独自規格となっていた

訂正
トラック番号についても、今は公式にも存在するのかもしれない
uLilithで変換したwavファイルのトラック番号、エクスプローラで表示されるわ
トラック番号についてはいつからか知らんけど、Windows XP 以降、標準でエクスプローラで表示されるのに、何故対応しないソフトが多いのか理解出来ないな

決まった規格って何だよ
決まってない規格もあるのか？

LIST INFOチャンクは位置や文字エンコーディングがソフトウェアによってバラバラなのが厄介

PLEXTORとCS対応チューナー会社のPLEXって関係あんの？
前それっぽい書き込みがあったけど
両方品質には定評があるけど

PLEXは低品質で有名だけどな

インスタントカメラのInstax持ってたら若い子に
「このアナログカメラインスタ意識した名前つけてるｗ」って笑われた

Portable版出してくれ

外部エンコーダの圧縮率は5に設定してるけどビットレートの数値は
どうしたらいいの

M1 ProのMacbook Pro + Parallels Desktop + Windows11 (ARM) の環境の中で
EAC v1.6を使うと外部エンコーダでのflacへのエンコードがされず、wavだけが出力されます。
これの解消方法わかるひといませんか。

flacは1.3.2、32bit版も64bit版も試してダメでした。
コマンドラインオプションは「-8 %source%」だけで、test encodeでエラーは出ません。
またコマンドプロンプトでflac.exeを使うと32/64にかかわらず正常にエンコードされます。
外部エンコーダにlameを指定してのmp3変換はできましたが、wavの削除はされませんでした。

Process Monitor でも使って、eacがflac.exeを起動しようとしているかどうか、どんなコマンドラインを指定しているか、エラーは起きていないか確認しよう
そんな特殊な環境使ってる人少ないだろうし、同様の問題に遭遇して対処できた人なんて、そうそう見つかるもんでもないから自力で頑張れ

>>613
MACの持ち前ってシンプルな所じゃないの？

613ですが解決しました。
ファイルの保存先を仮想WindowsのCドライブ直下のフォルダに変更すると正常にエンコードされました。
これまではミュージックフォルダ（Macとの共有フォルダ）を保存先としていたのが悪かったようです。

614の方が書いてくれたProcess Monitorというのは初めて知ったのですが
これで見てみると通常(純正Windows)は
wavの作成 -> wavを0!tmp.wavのような名前にリネーム -> 0!tmp.wavのファイル名を引数に使用してflacのプロセスを作成
Macとの共有フォルダを保存先とするとリネーム処理が抜けてしまうようです。
そのためflacのProcess Createでは正しいコマンドラインが指定されているものの、
実際は0!tmp.wavという指定されたファイルが存在せず処理が行われない状態となっていました。

ミュージックフォルダ（Macとの共有フォルダ）ってのネットワークフォルダじゃない？
パスの表記が変わるので対応してないんでしょ
APIによっては使えない(引数替えなきゃいけない)こともあるし、そのリネームってのがファイル名だけじゃなくパスも変える場合、論理ドライブまたいでの移動となってると失敗する

今日突然困惑した。ちょっとおかしな状況になってる。

昼間のその時間まで何の問題もなかったが。。。PlayerでGracenoteのDBもらってきたが、タイトルにスラッシュが3つあったのが少し気になるのだが、そして、EACを起動して曲名が入っているのを確認してWAV CUE IMG変換ボタンを押すも落ちてまう。

もう、昼の15時から格闘してるんやが、Exact Audio CopyのWAV CUEのIMG変換のボタンを押すと落ちてしまう。
ただ、シングルWAV変換、CMP圧縮変換ボタンの操作は生きてて、変換進む。。

また、EACのファイルメニューのProfile lioad / saveを選択すると同じように落ちてしまう(´・ω・｀)　→　Unhandlled exception at xxxx -> ACCESS_VIOLATION ,

EAC v1.3のところ、EAC v1.6も同じ。

「Exact Audio Copy 不調」で検索してみると、Windows7時分その頃のバージョンではアプリ右クリックの互換性タブから視覚テーマを無効にする　で同じようなトラブルがあってそれに倣ってWindows8.1ですが、カラーモードを制限する＞8ビット(256)カラーにすることにより、何とか今WAV CUE IMG変換を押しても落ちずに進むようになりますた＼(^o^)／

Windows 8.1 / Ryzen 7 2700X / X370 taichi / Radeon RX580 - software 19.12.3
SFC /SCANNOW DISMでチェック。仮想メモリサイズ変更、RAMディスクサイズ変更などしてみたが、REGEDITでのフィルタードライバーの削除とか全く関係なかった模様。

長文すまんが、同じようなトラブルあった方おられたら助言求めたい。

>>618
自己レス失礼します。
無い知恵搾ってWindows側のどこかのフラグの設定をどうにかリセットできそうなWindowsUpdateをかけてみたところ、EAC動作正常に復帰しました。
ありがとうございますm(_ _)m

HDD整理してたら昔調べたデータあった
まあ今更ですが
ttps://i.imgur.com/nF0tdgC.gif

Windows10（Rocket Lake）で使ってはみたけどドライブ測定とかでフリーズする
開発終了はもったいないね
代替ソフトとしてはMusicBee？

同じ作者の後継はEasy Audio Copyなんじゃないの？

あけましておめでとうございます
ごめんなさいwiki確認したら13か月前に更新されてた

CUERipperじゃない？

Music Beeはリッパーってよりプレーヤーだな
リッピング能力は知らない

レミオロメンの朝顔(CCCD)をDVR-A12で吸ったのだが
EACが作るcuesheetとCDManipulatorの全セクタサーチで作ったcuesheetを比べると
CDManipulatorはトラック1,3除いてINDEX 00が1フレーム後ろなんだけど
どっちが本当なんかなあ？
こういう違いはこのCDに限った事じゃないのかもしれないけど
ちなみにAccurate Ripはどっちのcuesheetでも通ってる

>>626 過去に一度だけ同じようなCDに遭遇したことがある
確かEACとCUERipperでは全てのトラックでINDEX 0はなし、という結果になったのにCDMではINDEX 0が1フレームだけ存在する、という結果になった
どちらが正しいのかはわからん
ふと思ったけどドライブの読み込みオフセットサンプルの値が588以上または-588以下の場合、INDEX 0の位置の解析結果に影響が出たりするのだろうか？

我々が見ることが出来るCDのリッピングデータ(メインチャネル)の1セクタ(1フレーム)は、
言わば仮想的なセクタで物理的な3セクタを摘まみ食いして再構成されたもの。
摘まみ食いの間隔は決まっているけど、開始位置が決まってない
という規格上のあやふやさがCDにはあるので、いわゆるオフセット問題が生ずる宿命にある。
これはメインチャネルの話で、今回のINDEXの判定に関わるサブチャネル(のQチャネル)には無関係な話。
サブチャネルは物理セクタの値そのままなんで、通常なら解釈の違いが生じない。
今回、サブチャネルの値が具体的にどういう値になってるかは分からないが
該当部分が例えばすべてゼロになってるとか、判断に困るような値になってるんじゃないかと思う。
それだと、どっちが正解とも言えないだろうね。

>>627
複数回ギャップ取得してみたらどうやらINDEX 0は
DVR-A12最高速だと±1フレーム結構ブレブレみたいよ
πは最高速一択だけど静音ユーティリティで24xに落としたら比較的安定したわ
なのでプリギャップをなるべく安定させたいなら少し落とした方がいいかも
ただ、その安定値が正確な値なのかは分からない
まぁギャップ頭が前曲の終端に絡んでるわけじゃないしどっちでもええわって気も

>>628
なるほど
サブチャンネルの値を直接覗いてみたほうが良さそうやね

>>629
そういうこともあるのか

ちなみに>>627のCDはポケモンXYのサントラ
当時のリッピングメモやログが残っていたから確認してきた
ドライブはLGのGSA-4082B
ディスク4のみEACとCDMとCDRWINの解析結果が完全一致、ほとんどのトラックでプリギャップが1フレームのみ存在するという結果になった
CUERipperはトラック78以降の結果のみEAC等と一致
dBpowerampは全てのトラックでプリギャップなし

ディスク1と2の解析結果
EACとCUERipperとdBpoweramp → 完全一致、全てのトラックでプリギャップなし
CDMとCDRWIN → 完全一致、ほとんどのトラックでプリギャップが1フレームのみ存在

ディスク3の解析結果
CDMとCDRWIN → 完全一致、プリギャップはトラック6では1秒1フレーム、トラック31では3秒1フレーム、トラック32では4秒1フレーム、他のほとんどのトラックでは1フレームのみ
EAC → トラック6では1秒、トラック31では3秒、トラック32では4秒、他のトラックではプリギャップなし
CUERipper → トラック6では1秒1フレーム、トラック31では3秒1フレーム、トラック32では4秒1フレーム、他のトラックではプリギャップなし
dBpoweramp → 全てのトラックでプリギャップなし

>>630
すまん、俺の書き込みは忘れてくれ
EACの設定見直したらギャップ検出が不精密になってて
安全(セキュア)にしたら40xと24xの5回読みとも全一致
CDManipulatorとも一致した

それにしても1フレームのみのプリギャップなんてあるのか
Subcode analyzerで見てもINDEX0が1フレームしかないん？(.subを残してればだけど)

>>631
.subは保存してなかった
他のドライブでも同じ結果になるかどうかも気になるんだよな
気が向いたらもう一度レンタルするか

>>609
高品質の間違いだろw

質問です。
HL-DT-ST BD-RE BH10NS30 を使っています。オフセットは、R=667, W=0 としています。

あるCDを画面左のIMGで wav+cue として読み込み、それを2通りのcueでWRI でCD-Rに焼きました。

最初はそのままのcueでCD-Rを作りました。こんな感じです。
REM DATE 1999
REM DISCID B60CB90C
REM COMMENT "ExactAudioCopy v1.6"
CATALOG 4988006158764
PERFORMER "宇多田ヒカル"
TITLE "First Love"
REM COMPOSER ""
FILE "宇多田ヒカル - First Love.wav" WAVE
TRACK 01 AUDIO
TITLE "Automatic -Album Edit-"
PERFORMER "宇多田ヒカル"
REM COMPOSER ""
ISRC JPTO09901640
INDEX 01 00:00:00
（以下略）

次は必要最小限にしたものです。
FILE "宇多田ヒカル - First Love.wav" WAVE
TRACK 01 AUDIO
INDEX 01 00:00:00
（以下略）

（続く）

634です。続きです。

両者のCD-Rを再びIMGでwav+cueで読み取り、バイナリエディタで比べると、
後者は元のwavと同じだったのに、前者は元のに比べ0x2DF0バイト下にずれており、
空いた部分が0で埋められていました。ファイル末尾の0フィルもその分少なく、
ファイルサイズは同じでした。

作業時にネットを切断し、設定ファイル~\AppData\Roaming\EAC\CDDB.sdfも
削除してから作業し、データベースにアクセスできないようにしています。

2つのCD-Rを作るとき、オフセットは変えていないのに、どうしてずれるのでしょうか。

performer とかを徐々にremでコメントアウトしていって同様の処理をし、悪さの箇所を特定すればいいんでない。
なんとなく漢字が偶然悪さしたみたいな

0x2DF0 = 11760 / 667 = 17 余0
オフセットが何か関係してそうではあるが
cueの文字コードは？

>>637
はい、Shift-JISです。

直後の636で的確なアドバイス既に出てんじゃん。解散案件だよ。

>>637
多分プログラマーモードで計算したんだろ。
667x17の下一桁は9と暗算できるんだから、すぐに気付かないとダメ。
単純に5セクタ（フレーム）だよ

634, 635 です。
前者のPERFORMERとTITLEを
REM COMMENT "PERFORMER 宇多田ヒカル"
REM COMMENT "TITLE First Love"
のようにコメント化すると、後者のようにずれなくなりました。
どうしてこれらが影響するのかわかりません。
どなたか理由がわかる方、教えていただけますでしょうか。
EACのバージョンは1.6、日本語化パッチは使用していません。

とりあえず、他のCDでも試してみます。

徐々に
って書いてあるだろ。
performerなのか
titleなのか
複合なのかを特定しな

634, 635 です。
今度は別のCDで、入力はすべてASCII文字で試してみました。
そのまま（PERFORMERとTITLEあり）→0x2DF0バイト下にずれる
片方のみ削除→どちらの場合でも、CD-R作成中に「Writing Lead-In」のまま止まる（経過時間のみ変化）ので、中止せざるを得ない
両方削除→ずれることなく、元のwavと同じものが作成される
となりました。

CDTEXTの書き込みに対応しているドライブなら
上手くいくのかもしれないけど、
この結果からの結論としては
EACの書き込みってポンコツなんだなぁ
ということだな。
予想外にためになる事例だったよ。
書き込みは他でやるべし。

634, 635 です。
あれから外付けドライブを持っていたことを思い出し、それで試してみました。
なんということでしょう。642のように試すと、一切ずれは生じませんでした
（PERFORMERとTITLE、どちらを削除しようとしまいと）。
どうやら、内蔵のBH10NS30の問題のようです。

ちなみに、外付けのは、
MATSHITA BD-MLT UJ272で、R=103、W=30としています。
どうもお騒がせしました。

cdtext書き込む設定にしてた？
cdtextオフにしてもcueにPERFORMERあったらバグる？
PERFORMERが空文字だったら？

>>645
ははー、cdtext ですか。意識していなかったなー。よし、これから調べてみます。
少々時間がかかりますが、後ほどお返事します。

1つだけ先にお答えします。
cdtext の書き込む設定はオンになっていました。

>>645
まさしく cdtext が原因でした！

これをオフにし、642と同様の実験しました。
PERFORMERとTITLEをそれぞれ削除するしない関係なく、正常に作成され、
しかも、ずれは一切ありませんでした。
さらに、PERFORMER "" としても、ずれは発生しませんでした。

また、644で述べた外付けに関しては、元からcdtextがオフになっていました。

ということで、内蔵ドライブがおかしいのかと思っていましたが、設定が不適切だったようです。
645様、心から感謝します。

また、636様のおっしゃる通り、私も徐々にコメント化は思いついたのですが、
なにしろEACは読み書きが遅いので（だからこそ正確に読み取れて素晴らしいのですが）、
なかなかその方法を使う気になれず、なにかご存じの方がいないかな、と思った次第です。

さらに、636, 637様の指摘にあるように、漢字コードが原因の可能性も否定できず、
別のCDはASCII文字だけにして、「これでどうだ」と思ったのですが、解決できず、失望しておりました。

まさか、cdtext が原因とは思ってもいませんでした。それを含んだCDなんて見たことがないので、考えもしなかったです。

ともかく、ご回答いただいたみなさま、本当にありがとうございました。

>>647
ＧＪ

ズレてるかはPCMで比較しないとな。wavごと比べたらメタ情報の有無で変わってくるし
wav比較だとタグをID3で保存する設定なんかも影響してくると思う
俺はCD-TEXTは焼かないようにしてる。(ほとんどの)CDに入ってないし

>前者は元のに比べ0x2DF0バイト下にずれており、
空いた部分が0で埋められていました。ファイル末尾の0フィルもその分少なく、
ファイルサイズは同じでした。
とのことなのでタグは関係ないんじゃないか
EAC側のバグかどうかを調べるには他の書き込みソフトでCD-TEXTを書き込む設定にして焼いたCDと比較する必要があるな

ID3保存はflacとかにする時か。失礼しやした

単純に興味なんだが、
リードインにおいて、P,Qを除いたR,S,T,U,V,Wの合計は
(12*6)*150 = 10800 = 4.6セクタ分
なんで、狭義のCD-TEXT用に送ったデータそのまま先に音声データとして書き込まれたのかな
って想像するんだけど、ズレた5セクタ分って、本当に0だけだった？
途中に意味不明なデータがなかったりしない？
まぁEACのCRC計算無視区間も5セクタなんで、その数値が回り回ってなのかもしれないけど。

634, 635 です。

>>648
いえいえ、GJは645さんですよ。この方のアイディアがなければ「機械が悪い」で片づけてしまうところでした。

>>652
はい。0だけでした。
バイナリエディタはStirlingを使用しております。
ヘッダーの0x2Cバイト以降をどこか選択し、メニューから「不一致検索」で、
初めて0でない箇所を探したので、間違いありません。