Vigi wrote:
pepsidrinker wrote:

Hey Vigi, does this work with just audio cds? When I get my plextors I want to retry dumping the Jaguar games and it would also be nice to dump properly video game sound tracks and such.

- Works on all discs with data tracks (no audio tracks needed)
- All data track sectors can be used to detect (in the old method it was only possible to use the first track02 pregap sector for this)

So you can't use it soundtracks if they don't have a data track. There has to be a data track for it to work.

Is not being able to find the correct offset for audio only a technical limitation or a software tool limitation? I mean if there is no possible way to find the offset so it can be corrected I won't worry about it but if it's just because we don't have a tool capable to do it, I wouldn't mind taking the time to research and that to find a way.

pepsidrinker wrote:
Vigi wrote:
pepsidrinker wrote:

Hey Vigi, does this work with just audio cds? When I get my plextors I want to retry dumping the Jaguar games and it would also be nice to dump properly video game sound tracks and such.

- Works on all discs with data tracks (no audio tracks needed)
- All data track sectors can be used to detect (in the old method it was only possible to use the first track02 pregap sector for this)

So you can't use it soundtracks if they don't have a data track. There has to be a data track for it to work.

Is not being able to find the correct offset for audio only a technical limitation or a software tool limitation? I mean if there is no possible way to find the offset so it can be corrected I won't worry about it but if it's just because we don't have a tool capable to do it, I wouldn't mind taking the time to research and that to find a way.

it's a technical limitation.. it will never be possible sad

28 (edited by pepsidrinker 2008-01-26 20:03:16)

Damn, so Atari Jaguar games will never be properly dumped and verified? sad

I wonder if Atari will give up the offsets for it's games? They released the encryption program so people can make homebrew run on actual machines.

pepsidrinker wrote:

Damn, so Atari Jaguar games will never be properly dumped and verified? sad

I wonder if Atari will give up the offsets for it's games? They released the encryption program so people can make homebrew run on actual machines.

Atari Jaguar games have no data track? yikes

No, they made it all in audio so they can store more on the cd or something.

Jaguar CD games could include as much as 790MB of data, considerably more than conventional CD-ROMs. The designers chose to ignore established CD-ROM formats and instead created their own based on the audio CD format. While allowing for dramatically more storage on the disc and foiling casual piracy, the format only provided limited error correction.  --- http://en.wikipedia.org/wiki/Atari_Jaguar_CD

Vigi wrote:
pnkiller78 wrote:

The sector in CDReader with the same sync/header that in px_d8 is sector 2.. look at this screenshoot, what that means, did I my calculations wrong?

edit: I just remember something.. older plextor drives have a bug where the normal read mode outputs a different sector offset than d8 mode.. I'm pretty sure that +222 is the correct write offset after all.. but if possible try confirming the offset using the old method..

I hope this doesn't affect any other users and any current dumps in the database..

I tried with other drives using old method and all of them show me zeros, even my LG +667 drive offset can see garbage on this disc, that makes me think that in fact this game has that big negative offset, if I had a bigger positive offset drive I could confirm this.. the game is Creature Shock for PC... sad

pepsidrinker wrote:

No, they made it all in audio so they can store more on the cd or something.

Jaguar CD games could include as much as 790MB of data, considerably more than conventional CD-ROMs. The designers chose to ignore established CD-ROM formats and instead created their own based on the audio CD format. While allowing for dramatically more storage on the disc and foiling casual piracy, the format only provided limited error correction.  --- http://en.wikipedia.org/wiki/Atari_Jaguar_CD

Common CD-ROM format was also based on Audio CD. The main difference between audio and data tracks is sync, which helps to find the beginning of sector. Atari Jaguar CDs should also have some kind of sync.

33 (edited by pepsidrinker 2008-01-27 04:18:17)

A little comforting, I hope so... Though it kinda looks like a tool has to be written to dump them as I put one in and EAC saw all the tracks but most was Zero in size (Maybe that doesn't matter) ISOBuster displayed the size correctly I believe. Its multi session, I assume track 1 (Only track in first session) is the data, anyways looking forward to trying the D8 command can give some usable results.

If it's audio, you don't need D8. Data is already descrambled.

Well I guess I got a lot of research to do, as I am completely unfamiliar with anything to do with optical technologies. Hex, what have you. Here's to finding the rainbow books somewhere...

Vigi wrote:
pnkiller78 wrote:

The sector in CDReader with the same sync/header that in px_d8 is sector 2.. look at this screenshoot, what that means, did I my calculations wrong?

edit: I just remember something.. older plextor drives have a bug where the normal read mode outputs a different sector offset than d8 mode.. I'm pretty sure that +222 is the correct write offset after all.. but if possible try confirming the offset using the old method..

I hope this doesn't affect any other users and any current dumps in the database..

Ok I found out the issue again.. it happens when you read with subchannels enabled.. so when you use px_d8 or cdreader to compare syncs, make sure you disable subchannel reading! the output that you get then should be reliable.. if it still gives you a large negative then it should be correct..

One other thing you can try is reading the last audio sector in d8, so the sector before the track02 pregap.. you should see a certain amount of zeroes at the end of the data track (if you count the amount you get the offset), which also indicates a negative offset.

Hello!
I'm trying to calculate the offset of the game Aris Adventure (SS).
Track 2 pregap is 2.00 sec but I'm not able to calculate the offset with the traditional method (my drive offsets are +48 and +30, probably disc factory offset is very high). Here's the output of D8 command...
I can't understand the offset with this kind of output. Any help?
Thanks


D:\Controllo>px_d8 e: 0 0
CF7194246F5B6C3B6DD36D9DEDA98DBE
E5B04B34375756BEBEF0704424335B55
FB7F036001E8004E80346017680EAE84
7C6361E9E84ECEB454777F66A02AF81F
028801A6807AE0230819C68AD2E71D8A
89A726FA9AC32B11DF4C5835FA97032E
81DC6059E83ACE93146DCF6D942DAF5D
BC39B1D2F45D8779A2A2F9B982F2E185
886326A9DAFEDB005B403B7013640DEB
458F732425DB5B1B7B4B637769E6AECA
FC5701FE80406030A325E867486436AB
56FF7EC020A5B1C90A91C72C529DFDA9
81BEE0704824369B56EB7ECF6054283F
5E90386C12ADCDBD95B1AF347C1761CE
A8547EBF607028241E9B486B76AF66FC
2AC1DF10580C3A85D3231DD9C99A56B8
19EA485436BF56F03EC410A796C9F5D1
871C6289E9A6CEFAD4431F71C824569B
7EEB604F68342E975C6EB9EC72CDE595
8B2F275C1AB9CB32D7559EBF28701EA4
087B46A372F9E582CB2197586EBAAC73
3DE5D18B1705B827B6CF36D416DF4ED8
34F4977B2EA35C79F9E2C2C99196EC6E
CDEC558DFF25EBC0B2FCFF382491A321
B9D872DAA59B3B2B535F7DF821826D04
5E2B7E76A0BF780C2285D9A31AF9CB02
D7419EB068742EA75C7A24D02C2A0337
8A5FD81C5A89FB26C35AD1FB1C4349F1
F6C41A435C5F972400FFFFFFFFFFFFFF
FFFFFF00018174610028001E80086006
A802FE8180606028281E9E886866AEAA
FC7F01E0004800368016E00EC8045683
7EE1E0484836B696F6EEC6CC52D5FD9F
01A8007E80206018280A9E8728629EA9
A87EFEA0407830229419AF4AFC3701D6
805EE0384812B68DB6E5B6CB36D756DE
BED8705AA43B3B53537DFDE181886066
A82AFE9F0068002E801C6009E806CE82
D4619F68682EAE9C7C69E1EEC84C56B5
FEF700468032E015880F26841AE34B09
F746C6B2D2F59D8729A29EF9A842FEB1
80746027681AAE8B3C6751EABC4F31F4
14474F72B425B75B36BB56F37EC5E053
083DC69192EC6D8DEDA58DBB25B35B35
FB57037E81E0604828369E96E86ECEAC
547DFF618028601EA8087E86A062F829
829EE1A8487EB6A076F826C29AD1AB1C
7F49E036C816D68EDEE4584B7AB76336
A9D6FEDEC058503ABC1331CDD4559F7F
28201E98086A86AF22FC1981CAE05708
3E869062EC298DDEE5984B2AB75F36B8
16F28EC5A4533B7DD3619DE8698EAEE4
7C4B61F76846AEB2FC7581E7204A9837
2A969F2EE81C4E89F466C76AD2AF1DBC
09B1C6F452C77D92A1ADB87DB2A1B5B8
7732A695BAEF330C15C5CF13140DCF45
94332F55DC3F19D00ADC0719C28AD1A7
1C7A89E326C9DAD6DB1EDB485B76BB66
F36AC5EF130C0DC5C593132DCDDD9599
AF2AFC1F01C80056803EE010480C3685
D6E31EC9C856D6BEDEF058443AB35335
FDD7019E8068602EA81C7E89E066C82A
D69F1EE8084E86B462F76986AEE2FC49
81F6E046C832D6959EEF284C1EB5C877
16A68EFAE4430B71C76452AB7DBF61B0
28741EA7487AB6A336F9D6C2DED1985C
6AB9EF32CC1595CF2F141C0F49C436D3
56DDFED9805AE03B0813468DF2E5858B
232759DABADB331B55CB7F17600EA804
7E836061E8284E9EB468776EA6AC7AFD
E30189C066D02ADC1F19C80AD6871EE2
8849A6B6FAF6C306D1C2DC5199FC6AC1
EF104C0C35C5D7131E8DC86596AB2EFF
5C4039F012C40D9345ADF33D85D1A31C
79C9E2D6C99ED6E85ECEB85472BF65B0
2B341F57483EB69076EC26CDDAD59B1F
2B481F768826E69ACAEB170F4E843463
5769FEAEC07C5021FC1841CAB057343E
97506EBC2C71DDE4598B7AE7630AA9C7
3ED2905DAC39BDD2F19D8469A36EF9EC
42CDF195846F236C19EDCACD9715AE8F
3C6411EB4C4F75F427075A82BB21B358
75FAA7033A81D3205DD8399A92EB2D8F
5DA439BB52F37D85E1A30879C6A2D2F9
9D82E9A18EF86442AB71BF64702B641F
6B482F769C26E9DACEDB145B4F7B7423
6759EABACF331415CF4F14340F57443E
B35075FC2701DA805B203B58137A8DE3
2589DB26DB5ADB7B1B634B69F76EC6AC
52FDFD8181A0607828229E99A86AFEAF
007C0021C018500ABC0731C29451AF7C
7C21E1D8485AB6BB36F356C5FED3005D
C0399012EC0D8DC5A5933B2DD35D9DF9
A982FEE180486036A816FE8EC064502B
7C1F61C828569EBEE8704EA4347B5763
7EA9E07EC82056983EEA904F2C341DD7
499EB6E876CEA6D47ADF631829CA9ED7
285E9EB86872AEA5BC7B31E35449FF76
C026D01ADC0B19C74AD2B71DB689B6E6
F6CAC6D712DE8D9865AAAB3F3F50103C
0C11C5CC5315FDCF0194006F402C301D
D4099F46E832CE95946F2F6C1C2DC9DD
96D9AEDAFC5B01FB40437031E4144B4F
777426A75AFABB033341D5F05F043803
5281FDA041B830729425AF5B3C3B51D3
7C5DE1F98842E6B18AF467076A82AF21
BC1871CAA4573B7E93606DE82D8E9DA4
69BB6EF36C45EDF30D85C5A31339CDD2
D59D9F29A81EFE884066B02AF41F0748
02B681B6E076C826D69ADEEB184F4AB4
37375696BEEEF04C4435F35705FE8300
61C028501EBC0871C6A452FB7D8361A1
E8784EA2B479B762F6A986FEE2C04990
36EC16CDCED5945F2F781C2289D9A6DA
FADB031B41CB7057643EAB507F7C2021
D8185A8ABB27335A95FB2F035C01F9C0
42D0319C1469CF6ED42C5F5DF8398292
E1AD887DA6A1BAF87302A5C1BB10734C
25F5DB071B428B71A7647AAB633F69D0
2EDC1C59C9FAD6C31ED1C85C56B9FEF2
C04590332C15DDCF19940AEF470C3285
D5A31F39C812D68D9EE5A84B3EB75076
BC26F1DAC45B137B4DE37589E726CA9A
D72B1E9F486836AE96FC6EC1EC504DFC
3581D7205E98386A92AF2DBC1DB1C9B4
56F77EC6A052F83D8291A1AC787DE2A1
89B866F2AAC5BF13300DD4059F432831
DE94586F7AAC233DD9D19ADC6B19EF4A
CC3715D68F1EE4084B46B772F6A586FB
22C35991FAEC430DF1C58453237DD9E1
9AC86B16AF4EFC3441D7705EA4387B52
A37DB9E1B2C87596A72EFA9C4329F1DE
C458537ABDE33189D466DF6AD82F1A9C
0B29C75ED2B85DB2B9B5B2F735869722
EE998C6AE5EF0B0C0745C2B311B5CC77
15E68F0AE4070B428771A2A479BB62F3
6985EEE30C49C5F6D306DDC2D9919AEC
6B0DEF458C3325D5DB1F1B480B768766
E2AAC9BF16F00EC40453437DF1E18448
6376A9E6FECAC057103E8C1065CC2B15
DF4F18340A97472EB29C75A9E73ECA90
572C3E9DD0699C2EE9DC4ED9F45AC77B
12A34DB9F5B2C73592972DAE9DBC69B1
EEF44C4775F2A705BA833321D5D85F1A
B80B328755A2BF39B012F40D8745A2B3
39B5D2F71D8689A2E6F98AC2E7118A8C
6725EA9B0F2B441F734825F69B06EB42

38 (edited by xenogears 2008-02-08 18:29:52)

I dumped the game and as combined read+write offset I put +702.
In the previous post I copy-pasted the output of the command
D:\Controllo>px_d8 e: 0 0

here's the output of the command shifted by 1 sector:

D:\Controllo>px_d8 e: 1 0

D:\Controllo>px_d8 e: 1 0
CF7194246F5B6C3B6DD36D9DEDA98DBE
E5B04B34375756BEBEF0704424335B55
FB7F036001E8004E80346017680EAE84
7C6361E9E84ECEB454777F66A02AF81F
028801A6807AE0230819C68AD2E71D8A
89A726FA9AC32B11DF4C5835FA97032E
81DC6059E83ACE93146DCF6D942DAF5D
BC39B1D2F45D8779A2A2F9B982F2E185
886326A9DAFEDB005B403B7013640DEB
458F732425DB5B1B7B4B637769E6AECA
FC5701FE80406030571D1AEF486436AB
56FF7EC020A540C90A91C72C529DFDA9
81BEE0704824369B56EB7ECF6054283F
5E90386C12ADCDBD95B1AF347C1761CE
A8547EBF607028241E9B486B76AF66FC
2AC1DF10580C3A85D3231DD9C99A57F0
126F485436BF56F03EC410A760C9F5D1
871C6289E9A6CEFAD4431F71C824569B
7EEB604F68342E975C6EB9EC72CDE595
8B2F275C1AB9CB32D7559EBF28701EA4
087B46A372F9E582CB2197586EBAAC73
3DE5D18BE275412AB6CF36D416DF4ED8
34F4977B2EA35C79F9E2C2C99196EC6E
CDEC558DFF257CD3C8EEB37785DFA321
B9D872DAA59B3B2B535F7DF821824B04
4D2B4B76A0BF780C2285D9A31AF9CB02
D7419EB068742EA75C7A414BA985B73D
DE61D81C5A89FB26C35AD1FB1C4349F1
F6C4CD43B95FA52400FFFFFFFFFFFFFF
FFFFFF0001820061536D475FA05B2541
..................
...........etc

In sector 1 I found the string 00018200 so I did the following calculations:

sector 0 is 588 samples, sector 1 has the following number of samples before synchro string:
28,5 * 4 = 114

So in the end: 588 + 114 = 702
I used 702 as correction value in perfectrip and I got the dump.
I checked the tracks with CD Mage, 0 errors.

I wait for confirmation on my offset calculation to submit the dump data.
Thank in advance

39 (edited by pnkiller78 2008-02-08 19:03:25)

xenogears wrote:

So in the end: 588 + 114 = 702
I used 702 as correction value in perfectrip and I got the dump.
I checked the tracks with CD Mage, 0 errors.

I wait for confirmation on my offset calculation to submit the dump data.
Thank in advance

Ok, I'm assuming you used the +30 offset drive to get your px_d8 data in your first post, you calculations would be
[(28.5*16)/4]-(-1*588)-(30)=672, you must subtract the drive offset to that value to get the disc offset and dump the disc, that would be 702-(30) = +672

Isn't the drive offset subtraction only necessary to get the absolute write offset of the disc? He should dump with +702 in EAC / -702 PerfectRip

gigadeath wrote:

Isn't the drive offset subtraction only necessary to get the absolute write offset of the disc? He should dump with +702 in EAC / -702 PerfectRip

Yeah, you are right, it was a typo. I corrected my redaction.

Thanks but I need the confirmation that +702 EAC / -702 Perfectrip (the one I used) is correct.
I know that the disc factory write offset would be +672 (I did the calculations with the px-760a, drive offset +30).
From the previous posts I assume that 702 is correct, I'll submit dump data tomorrow in the morning!
Thanks for the collaboration!

43 (edited by themabus 2008-02-08 21:28:14)

it's ok
018174:
01 xor 01 = 00
81 xor 80 = 01
74 xor 00 = 74
MSF=00:01:74
when you requested LBA 0 (MSF 00:02:00), previous sector with 28,5*16 bytes offset was returned, so it's as if data was shifted to the outside of cd by more than a sector, and you now see it's scrambled header, so +1 sector
(2352+(28*16)+8)/4=702 samples
ok

44 (edited by pepsidrinker 2008-02-14 08:17:09)

Ok, I did the d8 command there is 8 rows of data so 32, accurate rip says my offset is 30, so write is +2, I wonder why my other drive and ISObuster wouldn't show that info? In the header or whatever it's 200, so I don't have to do anything extra correct?

Just to make sure I did this right... This is for Shining Force CD for the Sega-CD

F6A986FEE2C0499036EC16CDCED5945F -1
2F781C2289D9A6DAFADB031B41CB7057 -2
643EAB507F7C2021D8185A8ABB27335A -3
95FB2F035C01F9C042D0319C1469CF6E -4
D42C5F5DF8398292E1AD887DA6A1BAF8 -5
7302A5C1BB10734C25F5DB071B428B71 -6
A7647AAB633F69D02EDC1C59C9FAD6C3 -7
1ED1C85C56B9FEF2C04590332C15DDCF -8
19940AEF470C3285D5A31F39C812D68D -9
9EE5A84B3EB75076BC26F1DAC45B137B -10
4DE37589E726CA9AD72B1E9F486836AE -11
96FC6EC1EC504DFC3581D7205E98386A -12
92AF2DBC1DB1C9B456F77EC6A052F83D -13
8291A1AC787DE2A189B866F2AAC5BF13 -14
300DD4059F432831DE94586F7AAC233D -15
D9D19ADC6B19EF4ACC3715D68F1EE408 -16
4B46B772F6A586FB22C35991FAEC430D -17
F1C58453237DD9E19AC86B16AF4EFC34 -18
41D7705EA4387B52A37DB9E1B2C87596 -19
A72EFA9C4329F1DEC458537ABDE33189 -20
D466DF6AD82F1A9C0B29C75ED2B85DB2 -21
B9B5B2F735869722EE998C6AE5EF0B0C -22
0745C2B311B5CC7715E68F0AE4070B42 -23
8771A2A479BB62F36985EEE30C49C5F6 -24
D306DDC2D9919AEC6B0DEF458C3325D5 -25
DB1F1B480B768766E2AAC9BF16F00EC4 -26
0453437DF1E184486376A9E6FECAC057 -27
103E8C1065CC2B15DF4F18340A97472E -28
B29C75A9E73ECA90572C3E9DD0699C2E -29
E9DC4ED9F45AC77B12A34DB9F5B2C735 -30
92972DAE9DBC69B1EEF44C4775F2A705 -31
BA833321D5D85F1AB80B328755A2BF39 -32
B012F40D8745A2B339B5D2F71D8689A2 -33
E6F98AC2E7118A8C6725EA9B0F2B441F -34
734825F69B06EB42CF7194246F5B6C3B -35
6DD36D9DEDA98DBEE5B04B34375756BE -36
BEF0704424335B55FB7F036001E8004E -37
80346017680EAE847C6361E9E84ECEB4 -38
54777F66A02AF81F028801A6807AE023 -39
0819C68AD2E71D8A89A726FA9AC32B11 -40
DF4C5835FA97032E81DC6059E83ACE93 -41
146DCF6D942DAF5DBC39B1D2F45D8779 -42
A2A2F9B982F2E185886326A9DAFEDB00 -43
5B403B7013640DEB458F732425DB5B1B -44
7B4B637769E6AECAFC5701FE80406030 -45
571D1AEF486436AB56FF7EC020A540C9 -46
0A91C72C529DFDA981BEE0704824369B -47
56EB7ECF6054283F5E90386C12ADCDBD -48
95B1AF347C1761CEA8547EBF60702824 -49
1E9B486B76AF66FC2AC1DF10580C3A85 -50
D3231DD9C99A57F0126F485436BF56F0 -51
3EC410A760C9F5D1871C6289E9A6CEFA -52
D4431F71C824569B7EEB604F68342E97 -53
5C6EB9EC72CDE5958B2F275C1AB9CB32 -54
D7559EBF28701EA4087B46A372F9E582 -55
CB2197586EBAAC733DE5D18BE275412A -56
B6CF36D416DF4ED834F4977B2EA35C79 -57
F9E2C2C99196EC6ECDEC558DFF257CD3 -58
C8EEB37785DFA321B9D872DAA59B3B2B -59
535F7DF821824B044D2B4B76A0BF780C -60
2285D9A31AF9CB02D7419EB068742EA7 -61
5C7A414BA985B73DDE61D81C5A89FB26 -62
C35AD1FB1C4349F1F6C4CD43B95FA524 -63
00FFFFFFFFFFFFFFFFFFFF0001820061

There is 63 * 16 = 1008 /4 = 252(Fixed Read) - 30 = 222(Write Offset)

Is that correct?

what is the read offset for 2nd drive? if it is larger negative than -1,  then it won't show in IsoBuster.

My other drive was +102 offset. Is my post above correct?

it's correct,
but about +102 - i don't know... does it show junk for other cds? maybe it just won't...

49 (edited by pepsidrinker 2008-02-14 08:44:04)

Yeah, it showed junk for other cds, with the new plextor when I tried to dump it I got read errors so maybe that is why it didn't show before for the +102 drive I have to try and get it resurfaced.

I have another question, for the shining force cd at the 99% point I got read errors in the guide it says to fill with user data does that go for sega-cd games also?

EAC gives a gap of 1.74 for track 2, when I try sector view with ISO buster 150 sector has ff ff on top and 149 sector back gives a device read error, do you happen to have perfectrip so i can try that gap detection?

i'm sorry, i don't have a perfectrip, i hope somebody can answer that