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

**名無しさん＠お腹いっぱい。** · 2022/01/03(月) 23:30:52.57

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

**名無しさん＠お腹いっぱい。** · 2022/01/04(火) 03:37:28.89

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

**名無しさん＠お腹いっぱい。** · 2022/01/04(火) 23:56:31.86

>>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 → 全てのトラックでプリギャップなし

**名無しさん＠お腹いっぱい。** · 2022/01/05(水) 03:50:30.35

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/07(金) 00:30:45.75

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

**名無しさん＠お腹いっぱい。** · 2022/01/10(月) 04:35:04.64

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

**名無しさん＠お腹いっぱい。** · 2022/01/17(月) 13:06:14.45

質問です。
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
（以下略）

（続く）

**名無しさん＠お腹いっぱい。** · 2022/01/17(月) 13:06:41.96

634です。続きです。

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

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/17(月) 14:26:33.66

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 02:10:00.49

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 04:51:32.91

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 08:25:18.70

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 08:47:24.42

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 09:01:05.94

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 10:26:07.94

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 13:03:04.19

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 13:41:24.09

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 23:23:30.13

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

**名無しさん＠お腹いっぱい。** · 2022/01/18(火) 23:43:42.28

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/19(水) 02:24:54.37

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

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

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

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

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/19(水) 21:31:57.49

>>647
ＧＪ

**名無しさん＠お腹いっぱい。** · 2022/01/19(水) 22:39:46.51

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

**名無しさん＠お腹いっぱい。** · 2022/01/19(水) 23:21:34.64

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

**名無しさん＠お腹いっぱい。** · 2022/01/19(水) 23:36:52.38

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

**名無しさん＠お腹いっぱい。** · 2022/01/20(木) 06:46:30.59

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

**名無しさん＠お腹いっぱい。** · 2022/01/20(木) 07:43:08.56

634, 635 です。

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

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

**名無しさん＠お腹いっぱい。** · 2022/01/21(金) 09:03:54.93

当方のドライブはCDTEXT対応みたいなんで、
誰か余裕のあるときに試して欲しいのだけど、
書き込みオフセットをマイナスに大きい値にして、
本来だったら無音ではない先頭部分が大幅に切れちゃうケースにしたらどうなるんだろう。
要するに、補正値として5フレーム分加算されたのでデータは切れないのか、5番の論理ブロックから書き始めたのでデータが切れるのか

**名無しさん＠お腹いっぱい。** · 2022/01/25(火) 15:59:31.44

セキュアモードにしたら読み込み速度が4倍速になって15分もかかって草

**名無しさん＠お腹いっぱい。** · 2022/02/08(火) 19:33:46.34

https://egg.5ch.net/test/read.cgi/software/1496658487/872-
2年近く前ISRCが話題になり874で試すと言ったものの正直忘れてたのとCDリッピング機会が減ったこともあり今頃で申し訳ないが
曲数が多いCDをレンタルしたのでレス

25曲入り「タイムボカン名曲の夕べ」の2枚目(VTCL-60030)
Pioneer BDR-208とSonyOptiarc AD-7200Sの結果は同じで
今回のCDに限ってだけど俺環境のPioneer BDR-208でISRCの取りこぼしは起きなかった

**名無しさん＠お腹いっぱい。** · 2022/02/08(火) 20:04:13.00

ごくろうさんです

**名無しさん＠お腹いっぱい。** · 2022/02/08(火) 20:53:05.68

どういう経緯かは知りませんが、
ISRCはサブチャネルのQチャネル、つまり位置情報のところに記録されるもので、
およそ100ブロック(フレーム)毎に位置情報の代わりに記録されます。
ここが読めないドライブなど存在しません。
Qチャネル用のCRCもあるし、100ブロック毎ということは
10,100と同じデータがあらわれるので、
相当問題がないかぎり取りこぼしはあり得ない性質のものです。

**名無しさん＠お腹いっぱい。** · 2022/02/13(日) 04:36:57.99

小傷が付いたCDのサブコード読み出しは結構脆弱だよ
この前πのDVRで吸ったCDはINDEX0がどのトラックも6～7フレームしかなくISRC取りこぼしが起きた
LITEONやLGだとINDEX0は普通の値で微妙に不安定なトラックがあったがISRCの取りこぼしはなかった
新品に近い別個体のπも同様だったのでパナチップのπはサブの読みがイマイチなのかもしれん
傷がない別個体の同じCDだともπはLITEONやLGと同じINDEX0になりISRC取りこぼしも無かった
πのBlu-rayライタはDVDライタとチップが違うからこうはならないだろうけどね

**名無しさん＠お腹いっぱい。** · 2022/03/11(金) 15:40:52.04

このソフトを導入してLameを入れて192に設定してCMPをやったのですが、
できたファイルがwavで全然圧縮されていませんでした
mp3にするにはどうすればいいでしょう？

**名無しさん＠お腹いっぱい。** · 2022/03/11(金) 15:48:29.99

ggrks

**660** · 2022/03/11(金) 16:51:54.28

>>661
かなり頑張ってググったのですが出てこなかったので教えて下さい

**名無しさん＠お腹いっぱい。** · 2022/04/06(水) 20:35:14.28

>>487
>>491
EACで取り込めないほどひどい盤面だと
音楽用プレイヤーで再生できるわけないんだよな

**名無しさん＠お腹いっぱい。** · 2022/04/18(月) 14:07:57.65

高速リプできるスリムドライブ探してるんだけど
セキュアモードで初速10倍程度以上でるやつ
IDEのは持ってるけどSATAはないのかな

**名無しさん＠お腹いっぱい。** · 2022/04/18(月) 14:55:22.83

ディスクによってスピードが全然違うからなあ（傷がなくても）
SATAとUSB2のドライブでいくつか試したが大差なかった
昔のドライブの方が読み取り性能が高くて早いかもね

**名無しさん＠お腹いっぱい。** · 2022/04/18(月) 15:22:32.88

>>665
そうなんですね
ちなみにセキュアとC2エラーにチェックして初速10倍程度です
ドライブテストでキャッシュはいになるドライブは初速から遅いものばかりでした

**名無しさん＠お腹いっぱい。** · 2022/04/22(金) 22:54:47.96

うちのは大傷がついてるんだよなあ

**名無しさん＠お腹いっぱい。** · 2022/05/18(水) 07:28:24.44

cuedbにもっとCDを登録しろよお前ら

**名無しさん＠お腹いっぱい。** · 2022/05/18(水) 16:10:19.45

CDDBといえば少し前から滅茶苦茶に文字化けしたデータが多くなってる
なぜ？

**名無しさん＠お腹いっぱい。** · 2022/05/19(木) 02:57:24.48

>>668
それだとどこか分からんやろ

http://db.cuetools.net

**名無しさん＠お腹いっぱい。** · 2022/05/21(土) 01:45:32.12

ほう
そんなものがあるのかね

**名無しさん＠お腹いっぱい。** · 2022/05/21(土) 04:53:41.19

>>670
そこのCTDBデータベースにはEAC(のCTDBプラグインが)がリッピングの度登録してる
傷で読み込みが怪しげなCDを何度もリッピングするとその度に登録数がカウントアップするｗ
AccurateRipの方は自分からサブミットしないと登録しないけど

**名無しさん＠お腹いっぱい。** · 2022/05/21(土) 20:30:10.94

俺の失敗情報アップロードしたくないなあ
常時ROMることってできないの

**名無しさん＠お腹いっぱい。** · 2022/05/21(土) 20:58:54.00

成功したらもう一回リッピングしてアップロードすればいい

**名無しさん＠お腹いっぱい。** · 2022/05/21(土) 21:35:28.21

成功するまでCTDBプラグインをオフにして、成功したらCUEToolsでそのデータをスキャンして提出

**名無しさん＠お腹いっぱい。** · 2022/05/22(日) 02:14:54.72

うーむ

**名無しさん＠お腹いっぱい。** · 2022/05/22(日) 03:31:41.40

GracenoteのCD情報の特にジャンル部分がplayer、iTunes、Music Centerと全部バラバラなのはどういう仕組みなんだろうか？
アルバム名やトラック名はどれも見かけ上相違ないから同じデータベースから取ってきてるはずなのに

**名無しさん＠お腹いっぱい。** · 2022/05/22(日) 09:48:12.51

>>677
確かジャンルは同じデータベースに最大3種類まで登録できたはず
（もう今は叩けないが）WebAPI叩くときに何種類まで取得するか選択できた記憶がある

**名無しさん＠お腹いっぱい。** · 2022/05/23(月) 01:15:17.09

ジャンルが複数登録出来ること以外にも、ソフト毎で対応可能なジャンルに違いがあるのも理由の一つなんだろうか
例えばThe BendsはiTunesでは「Indie Rock」、Music Centerでは「Brit Rock」、playerでは「Brit Pop」で全てバラバラ
ただ色んなCD見た限りでは、なんとなくiTunesが一番まともそう
まぁ音楽のジャンルなんてあってないようなものだから、ぶっちゃけどうでもいいんですけどね

**名無しさん＠お腹いっぱい。** · 2022/05/23(月) 13:44:11.78

いいのか

**名無しさん＠お腹いっぱい。** · 2022/05/23(月) 22:33:49.30

ジャンルタグの利用頻度高いなら他のアーティストとかを勘案して
自分として都合がいいのを選ぶ必要はあるけど
そうでなければ複数のジャンルに当てはまる場合とか
考え出してたらきりがないし拘っても面倒なだけだわな

**名無しさん＠お腹いっぱい。** · 2022/05/24(火) 07:44:43.27

>>670のDBってオフセット考慮されてる？

**名無しさん＠お腹いっぱい。** · 2022/05/24(火) 15:55:42.88

オフセットはいまだに自分には理解できない…

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 01:32:42.06

CDは開始位置に自由度があるけど、規格で定められなかったから
バラバラなものが市販されてる。
けど比較のためにはどこかに揃えないといけない。

ところで、先頭・末尾に全く無音が無い、
ここでは目一杯CDと呼ぶことにするけど、
目一杯CDなら、どっちにズレてもデータが欠落するから
開始位置を完全に特定できるのは分かるよね？

もう想像つくだろう？
EAC(AccurateRip)のゼロ地点は
EACの作者が初めて遭遇した目一杯CDの開始位置だ。

そしてプレクスターのゼロ地点は、
当時の原盤作製機を初期設定から全く変えなかった場合の
開始位置だ。

どっちも、そういう開始位置のCDが実在するし、
そういう開始位置のCDに我々が遭遇する確率は
どっちも極めて低い。
ただ他人との比較のためには、どこかに揃える必要があるというだけの話だ。

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 01:37:49.27

それだけだと全部読んで抜き出せば良いじゃん。と、素人は思うんじゃね？

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 01:44:58.95

全部読む
というのが、いわゆるオーバーリードにあたる。
それが出来ない、ユーザーに開放していないドライブが大半だから
現在のようになってる

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 07:26:25.49

>>685
どこから読めば全部読めるのかってのが規格化されてないのよ

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 12:27:27.03

>>684
はい、先生！
結局真のゼロ地点は分かりようがないから
Accurate rip の値で補正した地点が基準ということで理解してよろしいですか？

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 12:35:32.33

それによって、データを欠落させないことを確認した上でなら、それでいいと思うよ。盲目的に揃える、あまつさえ、それが原盤に忠実などと信じ込むお馬鹿が多い気がするけど。

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 12:41:42.43

よろしくないけど分かんないならそれで良い
ARで取りこぼしてtrue0で取りこぼさないなんて稀だしな
でもプレクの読み書き0のドライブ使ってるなら0を薦める
極論、子、孫とコピーしてズレて行かないならOK

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 13:08:25.21

>>690
はい、先生！
日立LG製ドライブ(読み+667 書き+0)で子孫コピーしてもズレてないです
でもプレクは読み+0でズレますが+30が正しいのですか？

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 14:32:53.68

> でもプレクは読み+0でズレますが
プレクのどのドライブだよ
プレクだからって全部+0じゃないぞ
読み書き共に0で良いのはAR基準でのオフセット訂正値が
Read sample offset correction +30
Write samples offset -30
となってるPREMIUMやPX-760Aとかの限られたドライブだけな

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 16:23:54.45

>>692
先生すいません PX-716Aです

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 16:58:06.42

716A今も現役な人いたんだ・・・
このドライブ、壊れやすいし他のプレク自社ドライブのようにピックアップの流用が効かないから好きじゃないんだよね・・・

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 17:01:27.37

とりあえず、プレクの自社ドライブはPX-708A以降は読み書き0でOK

廉価機種を除くと
PX-708A
PX-712A
PX-716A
PX-755A
PX-760A
Premium系
が対象

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 17:03:26.08

何故ならこれらのドライブはAR基準で、読み＋30、書き－30だから

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 21:46:24.75

よく現役で使えてるな
プレクのはPX-712Aを当時25000円ぐらいで買って使ってたが数年で壊れた
検索したらその後結構な人数が故障報告をしてたのでやはり壊れやすいのかなと

SCSI時代のシナノケンシドライブは堅牢だったのだが

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 22:58:07.25

PX-712Aは設計に欠陥があったらしく、読むだけでも焼き並にピックアップの消耗が大きかったという。

**名無しさん＠お腹いっぱい。** · 2022/05/25(水) 23:56:30.67

オフセットで影響を受けるのは最初のトラックと最後のトラックだけなのですか？
それとも全部のトラックが影響を受けるのですか？

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 00:16:38.24

音楽データ自体は一本糞
Trackで区切られている訳じゃない
TOCに従って最初からmm分ss秒のところって風に計算して頭出し
つまり「最初の地点」がズレてると全体がその分だけズレる
曲の先頭末尾の無音部が少ないCDで極端なオフセットを設定してみたら分かるかも

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 00:23:43.31

いうなれば本の目次の
P1
P50
P100
みたいなやつがあるとして、
P1の定義が「1枚目の紙」「題名のページ」「本文の始まるページ」
みたいに解釈が分かれうるから
どれをP1とみなすかによってその後が全部ずれる…みたいなことかな？

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 09:03:10.17

既に他の人も言ってますが、
CDのメインデータ自体はひたすら羅列されてる一つの塊です。
2352文字を1ページにすることだけが決まっていて、
何文字目から第1(150)ページにするかが決まってません。
常識的には物理限界を1文字目とした場合に35万文字目あたりにします。
トラックの情報はページ単位で、別枠のデータとして指定されるので、何文字目を基準にするかが変われば、順次変わります。

一つの理想形として、物理限界を1文字目とした場合に2352×150+1文字目を第1ページにすることが考えられますが、
AccurateRipもプレクスターも、ゼロ地点はそこではありません。
プレクのゼロ地点に拘る人もまた愚かです。

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 09:16:53.43

>>695
話しが逸れてしまうが
Premiumのトレイが開かなくなることを防ぐためディスク入れておくのを忘れてしまい
しばらくして気がついてトレイ押しても出てこなくて焦ったわ
幸い復活してくれ一安心…

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 12:56:32.37

プレク持ってる人が30訂正値にこだわるのは、何かあったときにEAC以外で検証できるってのがある

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 13:00:39.73

自分のドライブのオフセットがわかってれば良い話で、
ただの言い訳である。

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 13:50:02.39

>>703
Premiumのトレイが開かない問題はこれで解決できるから試して見て
保証期間はとっくの昔に切れてるし、メーカー修理も終わってるので剥がすと保証がなくなるシールは躊躇わずに剥がしてしまおう
余談だが708Aや712Aでも同様の問題が起きるので注意
http://town3715.html.xdomain.jp/plex_prem.html

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 18:59:13.01

物理限界の端っこから端っこまで読み取れるやつがあれば解決なんじゃないの？
実質何も入ってない余分な部分があるにしても全確保のほうが安心できる人種でしょ

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 19:10:03.99

極端なことやったって、じゃあcueファイルになんて書くんだって話になる

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 20:33:50.53

「再生時はここまで無視する」とか？

**名無しさん＠お腹いっぱい。** · 2022/05/26(木) 21:47:46.26

久しぶりに盛り上がってるな

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 03:31:05.91

それが無いかあっても業務用の高価な機械なのでEACが生まれたんじゃねーの？
わざわざコピー繰り返せばズレるように作ってるんだろうね。自主規制みたいなもんなんだろうか
読み0書き0のドライブが在ったのに他メーカーはなぜ追従しなかったのか

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 05:04:16.16

0という数字に惑わされ安いが
既に述べられているように
そこに特別な意味はない。
繰り返しで変わらないかどうかは
Combinedが0かどうかなんで、
それは色んなメーカーにもあるだろ。
決まったものがないのだから、単純に、そのメーカーが
その時点で回路設計しやすいものを選択した
結果にすぎないのではないかと思う。

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 07:40:30.57

>>712
これに尽きる
規格化されてなかったのがそもそもの原因なのだから

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 08:46:20.56

>>707
限界である必要はなく、実質ありえんレベルを越えて
オーバーリードできれば良い。
それが当にプレクの一部であり、識者の推奨理由は、プレク基準ゼロでは決してない。

オーバーリードした上で、
まず人数の多いAR基準で内包できるのなら、そう切り出すし、
次にプレク基準で内包できるなら、そう切り出すし、
両方とも内包できなかったら、内包できる最小補正距離で切り出す。

実効レベルで、「全部読んで切り出す」ことを、
知識と道具両方持ってる奴は昔からやってるよ。

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 09:22:33.86

まあ出来るんだろうけど、本当にそれをやってる奴が昔からいるのなら
それを自動化するツールがあっても良いもんだとも思うね

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 09:42:41.26

俺は使わんけど、
DiscImageCreatorが、ほぼ、それに近いことをやってたはず。
PCエンジンとか、トラック２以外、
ほぼほぼ音楽CDなんで、
AR基準でオフセットマイナス800とか
ざらだからね。
πの６６７ですら先頭が切れるという。

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 11:52:10.18

マスタリングエンジニアが作った納品データを正とするなら、ダウンロードで4416のwavやflacを買ってきて、プレスラインとかを特定して数値を決める方法もある
同時期の同じプレスラインなら、他のアルバムにもある程度応用できる
欠点は、ストリーミングもハイレゾになってきたってのにダウンロードはなぜが非可逆ばっかりなこと。現状ototoyくらいか

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 14:03:09.10

みんなすげーな
俺なんて曲が聴ければいいと思ってるから適当だわ

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 16:46:21.94

こんなスレ覗くくらいには神経質だよw

**名無しさん＠お腹いっぱい。** · 2022/05/27(金) 22:07:14.84

>>706
ありがとう
なるほど。根本的に解決できるのか
気力がみなぎってる時にやってみる

**名無しさん＠お腹いっぱい。** · 2022/05/28(土) 05:35:11.44

>>682
CTDBはオフセット値に影響されない検証を行うのがコンセプト
オフセットのズレをDB側で吸収して検証するので
各人なりのオフセットでも問題ない（1秒ずらすとかアホなことしないかぎり）

**名無しさん＠お腹いっぱい。** · 2022/05/28(土) 06:20:23.53

難しい

**名無しさん＠お腹いっぱい。** · 2022/05/28(土) 19:41:58.67

ログの最後のCTDBリストに出てくる
16 | (173/976) Accurately ripped, or (9/976) differs in 6093 samples @05:35:64-05:35:72
ってのは、173/976個マッチしてるけど、05:35:64-05:35:72間の6093サンプル違いで
9/976個マッチするCRCがあるぜ！って意味？

**名無しさん＠お腹いっぱい。** · 2022/05/29(日) 21:19:02.35

はぁい

**名無しさん＠お腹いっぱい。** · 2022/06/21(火) 13:52:13.39

http://db.cuetools.netは冒頭の300オフセットくらいを削ってオフセット差を潰してるから
オフセットに左右されないリッピング検証が可能
そしてCDに入れなくてもwebでCD検索が可能なので持ってないCDのデータを覗くことも出来る
だから、皆ガンガン登録してくれよな
日本語CDの品揃えショボいから

**名無しさん＠お腹いっぱい。** · 2022/06/21(火) 18:44:57.47

理由になってねぇな
>>252
にあるように、汎用データベースは、皆おしなべて
万人が読まるわけじゃない可能性のある範囲は妥協して削ってる。
妥協した部分は正常に読めてる保証がない。

**名無しさん＠お腹いっぱい。** · 2022/06/21(火) 21:03:53.18

まじか