Need some help detecting write offset/track 2 pregap

[ssjkakaroto]

Your math is fine, so which offset should I use for this game? The px_d8 (760) or the Isobuster (865)?

[themabus]

IsoBuster should be correct, i guess, since it's always the same on 3 drives. but why d8 doesn't work i really don't know. maybe it just doesn't on your drive. maybe Vigi can help you with this, he would for sure know a lot more.

[Jackal]

I'm not sure what to make of this either.. are you sure you executed px_d8 without the subchannel command? so 'px_d8 d 0 0'.. if not, there's a chance the sector offset is reported wrongly.. Also, you have to disable subchannel reading in cdtool when reading the sector.

So if both px_d8 and cdreader were used without subchannel reading and it still gives you the same scrambled header in sector -1, the maths of 270+588-98 (I suppose you're sure the read offset is correct?) = +760 is correct

And is 1.00 also the gap that perfectrip reports?

And you should notice the sync/header in the track02 pregap output.. it indicates the same offset of +760 (if you're sure about the +588) for all drives! So it's best to use this value for dumping.. I have no idea why the isobuster offset is this big, but it may be a mastering error.. have you tried cdtool instead to read the same sector? or try going back -73 first and then one more (I also don't think that d8 will ever give you a write offset that isn't a full number in samples, but let's wait what themabus has to say on this)

The only time d8 and the classic method don't provide identical results is when the data track doesn't have a write offset (it will only show the read offset with d8) but the audio does... this time you see a sync/header in the track02 pregap scrambled data output which normally doesn't show, so for some reason you'll also have to use the sync position this time, like in the d8 method..

I just hope there aren't any other discs with the same problems.. the write offset for those might have been calculated wrongly already (if the scrambled data output has a sync/header it's best to use its position instead of the amount of scrambled data).

[themabus]

I also don't think that d8 will ever give you a write offset that isn't a full number in samples

it didn't to me, so far. this zero at the end of IsoBuster logs: A1 AD B8 00, i think it's maybe because it xors with the same value (0x7d).

[ssjkakaroto]

Yes, I always use px_d8 with 0 0, and I also disable subchannel in cdreader.
Here's the output with cdreader using the plextor

Code: Select all

D59D9F29A81EFE884066B02AF41F0748  ...)....@f.*...H
02B681B6E076C826D69ADEEB184F4AB4  .....v.&.....OJ.
37375696BEEEF04C4435F35705FE8300  77V....LD5.W....
61C028501EBC0871C6A452FB7D8361A1  a.(P...q..R.}.a.
E8784EA2B479B762F6A986FEE2C04990  .xN..y.b......I.
36EC16CDCED5945F2F781C2289D9A6DA  6......_/x."....
FADB031B41CB7057643EAB507F7C2021  ....A.pWd>.P.|.!
D8185A8ABB27335A95FB2F035C01F9C0  ..Z..'3Z../.\...
42D0319C1469CF6ED42C5F5DF8398292  B.1..i.n.,_].9..
E1AD887DA6A1BAF87302A5C1BB10734C  ...}....s.....sL
25F5DB071B428B71A7647AAB633F69D0  %....B.q.dz.c?i.
2EDC1C59C9FAD6C31ED1C85C56B9FEF2  ...Y.......\V...
C04590332C15DDCF19940AEF470C3285  .E.3,.......G.2.
D5A31F39C812D68D9EE5A84B3EB75076  ...9.......K>.Pv
BC26F1DAC45B137B4DE37589E726CA9A  .&...[.{M.u..&..
D72B1E9F486836AE96FC6EC1EC504DFC  .+..Hh6...n..PM.
3581D7205E98386A92AF2DBC1DB1C9B4  5...^.8j..-.....
56F77EC6A052F83D8291A1AC787DE2A1  V.~..R.=....x}..
89B866F2AAC5BF13300DD4059F432831  ..f.....0....C(1
DE94586F7AAC233DD9D19ADC6B19EF4A  ..Xoz.#=....k..J
CC3715D68F1EE4084B46B772F6A586FB  .7......KF.r....
22C35991FAEC430DF1C58453237DD9E1  ".Y...C....S#}..
9AC86B16AF4EFC3441D7705EA4387B52  ..k..N.4A.p^.8{R
A37DB9E1B2C87596A72EFA9C4329F1DE  .}....u.....C)..
C458537ABDE33189D466DF6AD82F1A9C  .XSz..1..f.j./..
0B29C75ED2B85DB2B9B5B2F735869722  .).^..].....5.."
EE998C6AE5EF0B0C0745C2B311B5CC77  ...j.....E.....w
15E68F0AE4070B428771A2A479BB62F3  .......B.q..y.b.
6985EEE30C49C5F6D306DDC2D9919AEC  i....I..........
6B0DEF458C3325D5DB1F1B480B768766  k..E.3%....H.v.f
E2AAC9BF16F00EC40453437DF1E18448  .........SC}...H
6376A9E6FECAC057103E8C1065CC2B15  cv.....W.>..e.+.
DF4F18340A97472EB29C75A9E73ECA90  .O.4..G...u..>..
572C3E9DD0699C2EE9DC4ED9F45AC77B  W,>..i....N..Z.{
12A34DB9F5B2C73592972DAE9DBC69B1  ..M....5..-...i.
EEF44C4775F2A705BA833321D5D85F1A  ..LGu.....3!.._.
B80B328755A2BF39B012F40D8745A2B3  ..2.U..9.....E..
39B5D2F71D8689A2E6F98AC2E7118A8C  9...............
6725EA9B0F2B441F734825F69B06EB42  g%...+D.sH%....B
CF7194246F5B6C3B6DD36D9DEDA98DBE  .q.$o[l;m.m.....
E5B04B34375756BEBEF0704424335B55  ..K47WV...pD$3[U
FB7F036001E8004E80346017680EAE84  ...`...N.4`.h...
7C6361E9E84ECEB454777F66A02AF81F  |ca..N..Tw.f.*..
028801A6807AE0230819C68AD2E71D8A  .....z.#........
89A726FA9AC32B11DF4C5835FA97032E  ..&...+..LX5....
81DC6059E83ACE93146DCF6D942DAF5D  ..`Y.:...m.m.-.]
BC39B1D2F45D8779A2A2F9B982F2E185  .9...].y........
886326A9DAFEDB005B403B7013640DEB  .c&.....[@;p.d..
458F732425DB5B1B7B4B637769E6AECA  E.s$%.[.{Kcwi...
FC5701FE804060306141D6B8486436AB  .W...@`0aA..Hd6.
56FF7EC0FBAB00C90A91C72C529DFDA9  V.~........,R...
81BEE0704824369B56EB7ECF6054283F  ...pH$6.V.~.`T(?
5E90386C12ADCDBD95B1AF347C1761CE  ^.8l.......4|.a.
A8547EBF607028241E9B486B76AF66FC  .T~.`p($..Hkv.f.
2AC1DF10580C3A85D3231DD9C99A0D14  *...X.:..#......
5B96485436BF56F03EC4F3A040C9F5D1  [.HT6.V.>...@...
871C6289E9A6CEFAD4431F71C824569B  ..b......C.q.$V.
7EEB604F68342E975C6EB9EC72CDE595  ~.`Oh4..\n..r...
8B2F275C1AB9CB32D7559EBF28701EA4  ./'\...2.U..(p..
087B46A372F9E582CB2197586EBAAC73  .{F.r....!.Xn..s
3DE5D18B8ECDC484B6CF36D416DF4ED8  =.........6...N.
7B43977B2EA35C79F9E2C2C99196EC6E  {C.{..\y.......n
CDEC558DFF25E8C28EF6B2285689A321  ..U..%.....(V..!
B9D872DAA59B3B2B535F7DF821820F04  ..r...;+S_}.!...
EEF1E31BD701780C2285D9A31AF9CB02  ......x.".......
D7419EB068742EA75C7A190D90386928  .A..ht..\z...8i(
618FD81C5A89FB26C35AD1FB1C4349F1  a...Z..&.Z...CI.
F6C4C943E18B8E4E00FFFFFFFFFFFFFF  ...C...N........
FFFFFF00018000600028001E80086006  .......`.(....`.
A802FE8180606028281E9E886866AEAA  .....``((...hf..
FC7F01E0004800368016E00EC8045683  .....H.6......V.
7EE1E0484836B696F6EEC6CC52D5FD9F  ~..HH6......R...
01A8007E80206018280A9E8728629EA9  ...~..`.(...(b..
A87EFEA0407830229419AF4AFC3701D6  .~..@x0"...J.7..
805EE0384812B68DB6E5B6CB36D756DE  .^.8H.......6.V.
BED8705AA43B3B53537DFDE181886066  ..pZ.;;SS}....`f
A82AFE9F0068002E801C6009E806CE82  .*...h....`.....
D4619F68682EAE9C7C69E1EEC84C56B5  .a.hh...|i...LV.
FEF700468032E015880F26841AE34B09  ...F.2....&...K.
F746C6B2D2F59D8729A29EF9A842FEB1  .F......)....B..
80746027681AAE8B3C6751EABC4F31F4  .t`'h...<gQ..O1.
14474F72B425B75B36BB56F37EC5E053  .GOr.%.[6.V.~..S
083DC69192EC6D8DEDA58DBB25B35B35  .=....m.....%.[5
FB57037E81E0604828369E96E86ECEAC  .W.~..`H(6...n..
547DFF618028601EA8087E86A062F829  T}.a.(`...~..b.)
829EE1A8487EB6A076F826C29AD1AB1C  ....H~..v.&.....
7F49E036C816D68EDEE4584B7AB76336  .I.6......XKz.c6
A9D6FEDEC058503ABC1331CDD4559F7F  .....XP:..1..U..
28201E98086A86AF22FC1981CAE05708  (....j..".....W.
3E869062EC298DDEE5984B2AB75F36B8  >..b.)....K*._6.
16F28EC5A4533B7DD3619DE8698EAEE4  .....S;}.a..i...
7C4B61F76846AEB2FC7581E7204A9837  |Ka.hF...u...J.7
2A969F2EE81C4E89F466C76AD2AF1DBC  *.....N..f.j....
09B1C6F452C77D92A1ADB80000000000  ....R.}.........
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................

and perfectrip also detects a 1.00 pregap

[themabus]

i think it's maybe because it xors with the same value (0x7d).

no, no this is wrong

And you should notice the sync/header in the track02 pregap output.. it indicates the same offset of +760 (if you're sure about the +588) for all drives! So it's best to use this value for dumping..

i understand now what you meant to say, IsoBuster data, it cuts off at the middle of sector, this can't be right.

[ssjkakaroto]

So it's really +760?

[themabus]

yes, it was silly of me not to see sync in between data. if i understand, what Vigi wrote, i think this offset is always the same, and if you'd read further with d8 and IB, the first meaningful audio byte, it would be at the same position from last sync. but IB scrambles a part of audio sector for some reason, as if it partly would be data. well honestly, i don't understand that, how is that even possible. but if Vigi says it's ok, should be ok

The only time d8 and the classic method don't provide identical results is when the data track doesn't have a write offset (it will only show the read offset with d8) but the audio does...

Vigi, can you help, please?, i'm totally lost on this, how can this happen? is it like tracks are physicaly on variable distance, wouldn't audio collide with datatrack when offset is negative, and what's between them, when offset is positive?

[Jackal]

but if Vigi says it's ok, should be ok

No, no.. I also have no idea what's going on.. I'm just saying that the +760 offset makes more sense than the other one.

Vigi, can you help, please?, i'm totally lost on this, how can this happen? is it like tracks are physicaly on variable distance, wouldn't audio collide with datatrack when offset is negative, and what's between them, when offset is positive?

I don't know what causes it.. I only know that I have some IBM discs that show +30 in D8 on the data track and a different offset with the old method.. so I felt it was safe to conclude that the data track didn't show the write offset, but only the read offset.