Re: Need some help detecting write offset/track 2 pregap
Posted: Mon Mar 03, 2008 10:28 am
Your math is fine, so which offset should I use for this game? The px_d8 (760) or the Isobuster (865)?
redump.info Forum
Disc Preservation Community
https://forum.redump.info/
Need some help detecting write offset/track 2 pregap
Page 2 of 2
Re: Need some help detecting write offset/track 2 pregap
Posted: Mon Mar 03, 2008 2:18 pm
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.
Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 4:27 am
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).
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).
Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 5:11 am
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).Vigi wrote:I also don't think that d8 will ever give you a write offset that isn't a full number in samples
Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 8:58 am
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
and perfectrip also detects a 1.00 pregap
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 ................Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 11:18 am
no, no this is wrongthemabus wrote:i think it's maybe because it xors with the same value (0x7d).
i understand now what you meant to say, IsoBuster data, it cuts off at the middle of sector, this can't be right.Vigi wrote: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..
Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 2:04 pm
So it's really +760?
Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 6:12 pm
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 
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?Vigi wrote: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...
Re: Need some help detecting write offset/track 2 pregap
Posted: Tue Mar 04, 2008 6:43 pm
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.themabus wrote:but if Vigi says it's ok, should be ok
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.themabus wrote: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?