26

(39 replies, posted in General discussion)

Oh, I see, sad
What do you think we could do by now?
Is there a way do dump the pregap for that track?

27

(39 replies, posted in General discussion)

Yeah, I agree with you, apparently httpd-ack doesn't dump pregap of the data tracks, that's why track 2 have 150 sectors less, and track 20 too. In the case of track 2 it's easy to fix because it's readable by EAC and PC drives, but in the other case we must guess.

I have not moved any data, I generated 'em using hex-editor (150 sectors filled with zeros), the dump from the last data track (track 21) start with info from files, not pause... and the end of track 20 ends with audio, I'm assuming that what it's missing is the track 21 pregap, so I generate it and inserted at the end of the previous track (track 20).

28

(39 replies, posted in General discussion)

Well, basically that's what I did..
* Fixed track 2 according to EAC
* Added the pregap to the track 4
* Added the pregap from the 3rd data track (track 21) to the end of last audio track (track 20).

Hope we can discover more soon, anyway, fix any error is easy cause everything here is about pregap info.

29

(39 replies, posted in General discussion)

Dremora wrote:

Can you please post tracks sizes and gdi from httpd-ack dump (without any manual corrections) of Sega Rally 2?

Sure, here...

GDI file...

21
1 0 4 2352 track01.bin 0
2 450 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0
4 123919 0 2352 track04.raw 0
5 128587 0 2352 track05.raw 0
6 145534 0 2352 track06.raw 0
7 160030 0 2352 track07.raw 0
8 178106 0 2352 track08.raw 0
9 194991 0 2352 track09.raw 0
10 213656 0 2352 track10.raw 0
11 231089 0 2352 track11.raw 0
12 250919 0 2352 track12.raw 0
13 267807 0 2352 track13.raw 0
14 280771 0 2352 track14.raw 0
15 297479 0 2352 track15.raw 0
16 312001 0 2352 track16.raw 0
17 312698 0 2352 track17.raw 0
18 314348 0 2352 track18.raw 0
19 319124 0 2352 track19.raw 0
20 323678 0 2352 track20.raw 0
21 337311 4 2352 track21.bin 0

Also, here it is a screenshot of the first session of the disc and the disc properties windows on ISOBuster.

30

(39 replies, posted in General discussion)

Oh, I think I couldn't explain myself well sad, also on all the other dump (Soul Calibur and and Sword of the Berserk) the second audio track is the same

Size : 1,589,952 bytes
8557fcaa ?CRC32*track02.bin
824ff123fbce45b5883962eb3fa43cab *track02.bin
a3705cb0ce53c7adf906c5af76887406984de6a9 ?SHA1*track02.bin

Please correct it...

31

(39 replies, posted in General discussion)

I have 15-20 discs, I bough 'em on December and until today opened the boxes. smile

OK, now you mentioned about the second track, actually I dumped 'em using httpd-ack (I was being lazy to open ISOBuster, open EAC, and everything else just to dump those 2 small tracks) but I did it today, and noticed that the second audio track is the same on all the discs I have dumped so far, but also noticed something else that happens even on PSX games, when the disc only have 1 audio track after the 1st data track (1st session on all Dreamcast discs) EAC reports 0 seconds pregap, which is wrong... so dumped on EAC the audio track, and then added manually the pregap to the beginning of file, and after that the file was 150 sector bigger that my actual dumps so far on httdp-ack... the info section matched by the files dumped with httdp-ack were missing 150 sectors at the end comparing with the files dumped using EAC and corrected manually, I think that it maybe a bug on httpd-ack.

the info for the second tracks is this

Size : 1,589,952 bytes
8557fcaa ?CRC32*track02.bin
824ff123fbce45b5883962eb3fa43cab *track02.bin
a3705cb0ce53c7adf906c5af76887406984de6a9 ?SHA1*track02.bin

As far as the disc offset refers, I checked using ISOBuster and px_d8, the results were the same, I'm 110% sure the offsets are correct.

Well, I think that we have problems with the games with audio tracks, I noticed that with the current info submitted to the database, the last data track starting position doesn't match the same number as the gdi provided by httpd-ack and by using the redump.org gdi file the game doesn't start in nullDC.
In httpd-ack's gdi file the starting position is 150 sectors ahead that the calculated using the tracks sizes currently in the database, I think that this have to do with same issue observed on the first session of the disc, httpd-ack eats 150 sectors at the end of the last audio track, if I manually append 150 at the last audio track the position match and the game start.
So, I think that, at least by now, until somebody comes with better solution or explanation, that for games with audio tracks, the last audio track must have 150 appended to the end of the file, so start position of the last track match with the gdi script and the dump effectively runs on nullDC.

Also, I found this thread on ngemu.com, I think that the script should consider the control field (third parameter) in the gdi files

ctrl : 4 -> data , 0 -> audio

Correnting audio track for Star Wars the clrmame info would be

game (
    rom ( name Track01.bin size 1418256 crc 0adcec33 md5 af6f5e254c04cbe76a4164d023484900 sha1 3ed8fdc065f212ed093bc9548198dd0597529dc3 )
    rom ( name Track02.bin size 1589952 crc 8557fcaa md5 824ff123fbce45b5883962eb3fa43cab sha1 a3705cb0ce53c7adf906c5af76887406984de6a9 )
    rom ( name Track03.bin size 732187008 crc 8a116162 md5 f686c207f9b676b4bcc08fbc23b833e6 sha1 e701e39e41d709e0c98f508ee3b97364743cd015 )
    rom ( name Track04.bin size 1766352 crc 7aa0aa80 md5 87db69092b2b0bdf3e880db319864724 sha1 66885f84d4b15218754158b2c1928dc6dee05119 )
    rom ( name Track05.bin size 451807440 crc bd7efcaa md5 04d1d99cfbaf6621deb64a9cdae54ca8 sha1 2ac01e7d3bc529af1948b2cc6b91814766ba5b00 )
)

for Slave Zero the info would be

game (
    rom ( name Track01.bin size 1430016 crc c5b61528 md5 443fa3427f0ac12dc6c898e76cd3f6b6 sha1 d5d440ff94bffcb5bb978dfcc1f696f6242bfa0e )
    rom ( name Track02.bin size 1589952 crc 8557fcaa md5 824ff123fbce45b5883962eb3fa43cab sha1 a3705cb0ce53c7adf906c5af76887406984de6a9 )
    rom ( name Track03.bin size 841329216 crc c3d99865 md5 b966999cf16599296a8cd756d7dd1152 sha1 801ebe652f2de36fad1ba770ed2ddb3ac4a606ab )
    rom ( name Track04.bin size 1766352 crc 7aa0aa80 md5 87db69092b2b0bdf3e880db319864724 sha1 66885f84d4b15218754158b2c1928dc6dee05119 )
    rom ( name Track05.bin size 342665232 crc 1b8068d0 md5 df46a4796965cea58032a9efa5acb845 sha1 91164265021ea7ee0e5fb4d61fbf70c9405acf2c )
)

and for Sega Rally 2...

game (
    rom ( name Track01.bin size 705600 crc 294f0495 md5 3ce64896d6800de568c54afa3ca68a17 sha1 55e613230ca66bcdddcf58f69301d6f92b318059 )
    rom ( name Track02.bin size 1589952 crc 8557fcaa md5 824ff123fbce45b5883962eb3fa43cab sha1 a3705cb0ce53c7adf906c5af76887406984de6a9 )
    rom ( name Track03.bin size 185264688 crc 25242337 md5 9c7c92e17458ccbaca62ae842ff50602 sha1 26aff7db54c590e512bb7e18ff6941cc31b7dde1 )
    rom ( name Track04.bin size 10979136 crc 072b4c39 md5 6ab3a6902a30ec9a5ad23f0c4857b769 sha1 555ee0f0029de36383f9a04154543ea474cee35c )
    rom ( name Track05.bin size 39859344 crc 42adfd68 md5 9f24bfa85566d5f5426bf4ede629578d sha1 0d61f678d1aa2b8fae9d1db111b8f748a0d50d73 )
    rom ( name Track06.bin size 34094592 crc 757f13a6 md5 9405340ac56448e1ea68bd666200b273 sha1 2ce0ac9cd6c433f739068c7dedd4b60a500c8c65 )
    rom ( name Track07.bin size 42514752 crc af67fda8 md5 8c156775b7f458c57bf71f2c314f1484 sha1 812717cb5e91a75951e40adf53ca990c288e35b9 )
    rom ( name Track08.bin size 39713520 crc 00656b4d md5 71d2709f7979e2f0710789f182697fe0 sha1 3e3267355e4d0abc5841c1cbd1c41889d5748d02 )
    rom ( name Track09.bin size 43900080 crc 11468a12 md5 fbbc6567842b65d88215de925bdf5f6c sha1 a89d739235bf0cdc9767318548c8bc5b03cd76b0 )
    rom ( name Track10.bin size 41002416 crc 48293e62 md5 d9a351b7013b2356a4f57d454cc6c05b sha1 829766e36e32768564c89c40dfa20c5e05ecdf06 )
    rom ( name Track11.bin size 46640160 crc c1be560e md5 3627495a30f2f636e80d64f60ca2f4ae sha1 84810174387ae98a73def54243c5445eaed392f5 )
    rom ( name Track12.bin size 39720576 crc 6a0f9aa1 md5 1921abfebb2b8ae6266fc872cd5ad593 sha1 e769c91d7416ee8ee2571571d969b744f97479fc )
    rom ( name Track13.bin size 30491328 crc 3a8a3167 md5 6462709f5df3429d4dd48e68a612e4e2 sha1 cdbb3dcadd2373b87dbe55b25d11c88004c6e71d )
    rom ( name Track14.bin size 39297216 crc 1e219b18 md5 9d01af8d80e3233b811b259d48b65ac4 sha1 3fdf3a6093fc95e1c94c655632bf24a57b15d149 )
    rom ( name Track15.bin size 34155744 crc 82f2a2b9 md5 115b79159e0e32fea18300fca5e23a92 sha1 e4e005132aec17f601e223c34e08f5d505cacbd9 )
    rom ( name Track16.bin size 1639344 crc bc260087 md5 2dfaf26b2c2374fbb0b2048f99ff9969 sha1 e906c31c9ff65829ed54e4614c452f870750632d )
    rom ( name Track17.bin size 3880800 crc d5a3d008 md5 3f519f5f8abc030bb2a2da93acfdafca sha1 06fdaf74ebcabad0a39227628eb3412fefc8ee46 )
    rom ( name Track18.bin size 11233152 crc 20428766 md5 97b0408be138f2b084ad449a45020829 sha1 48ee7fa72e60cb32c7a75ca9081501d036378a93 )
    rom ( name Track19.bin size 10711008 crc 5a9311f4 md5 8774cc32339b8b2a159e70423de6a3ee sha1 87db6629dfbd0db1550ad9d399ac1b10d355d37c )
    rom ( name Track20.bin size 32417616 crc ee7987d8 md5 38c9ba0312389f8c1c334f740dd8eef7 sha1 4e69e42bb2909a1f64d82ae29290a08f258ebe1a )
    rom ( name Track21.bin size 498245328 crc 57be9544 md5 d0a1f89e0dd36b12e7a058535e5cf53d sha1 c4a208166652cac70aa95334fbca5599c365570f )
)

32

(39 replies, posted in General discussion)

Dremora wrote:

Well, if you are sure, then yes.

Yeah, I'm sure, if I hex-edit the track the info start to appear at the very beginning of the file.
Also, if go back 150 sectors from the end of the track, a start to go back from that point I can see the end of the audio info.

Another question, do I have to post a cue.sheet for the dumps that I submit to the database or just the GDI file?

33

(39 replies, posted in General discussion)

Dremora wrote:

Though it's relatively easy to fix these dumps: combined offset can be calculated by dumping 1st session using our guide and then comparing it with dump made from the console. Then all audio tracks in 2nd session should be shifted by the combined offset.

I noticed that using httpd-ack the audio tracks doesn't have the pregap at the beginning of the tracks, instead they have the pre-gap of the next track appended at the end of the current track.
Should I fix this by cutting the last 150 sector on the audio tracks and pasting them at the beginning?

I found those kind of problem with one of my drives on data tracks, my solution was to dump always at low speed, if I dump on this drive letting the drive control the speed 90% of the times it ends up with one or two errors on sectors, so I use nero speedrive tool, set it at low speed 4x-8x.. and the resulting image is good, match my other drives. Don't know if it's your case but at least with me it works that way. hope it helps you smile

35

(43 replies, posted in General discussion)

Vigi wrote:

Done.. so pnkiller's last track has cut off data? yikes I still think this is kind of odd.. pnkiller, have you tried checking the last sector in cdtool instead of isobuster?

It the same, this is a screenshot of the lead-out area on CDReader, I definitely think that that's all the info in the track.

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.

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

38

(43 replies, posted in General discussion)

I tried themabus suggestion, these were the results:
* None of my drives saw more info that the info dumped by EAC with the LiteOn drive
* LG drive couldn't retrieve info beyond the leadout in ISOBuster
* In ISOBuster the Plextor drive was able to retrieve the info dumped by the LiteOn on EAC, that's good, but after the same position were the LiteOn showed data, in the Plextor there were just zeros.

I think I could say that at least in this version of the disc, that all the audio in the disc, the LiteOn drive retrieve all the info it can on EAC, the Plextor confirmed that info using themabus method on ISOBuster, none other of my drives retrieve more data after that.

39

(43 replies, posted in General discussion)

ssjkakaroto wrote:

"the plextor drive even loose data before that position without sync errors"
what did you mean here? tongue

I was trying to say that the plextor drive could not read the entire track at the end and didn't throw any sync errors.. so if indeed there's data beyond the position specified in my post, the drive could not retrieve it.

Will try the sugestion from themabus today and see what I can find..

40

(43 replies, posted in General discussion)

It's funny, it's exactly 0x930 bytes, 1 sector... the amount of data that you have in your track it's one sector... even if my dump was made with a big negative offset drive, I tried playing with the offset correction on EAC, but no luck, the LiteOn drive can see any data after 0x14B40A0, in your dump the data end at 0x14B49D0; maybe it was manufactured that way, I don't know... the plextor drive even loose data before that position without sync errors.. in  the LiteOn if I increment the offset it 2 sectors it start to show sync errors.

41

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Hey pnkiller78, here's a remotediff for track 11 can you make a patch for me?
http://www.speedyshare.com/136917703.html
Edit:
Also if possible for track 1: http://www.speedyshare.com/650245949.html

Sure, here they are both

42

(43 replies, posted in General discussion)

Vigi, these are my findings with Hexen II, I was able to get all your tracks, but the offset was weird on every track, I dumped the disc on single bin file using the plextor drive (+30 drive offset) using ISOBuster, the used the track method using a starting position for the first audio track the size of the american version first data track, this is my script

psxt001z --track "HexenII.bin" 188910288 33313728 05f0680d + s "Hexen II (E) (Track 02).bin"
psxt001z --track "HexenII.bin" 222224016 32953872 76b661be + s "Hexen II (E) (Track 03).bin"
psxt001z --track "HexenII.bin" 255177888 32662224 02fdee8d + s "Hexen II (E) (Track 04).bin"
psxt001z --track "HexenII.bin" 287840112 32986800 d093b474 + s "Hexen II (E) (Track 05).bin"
psxt001z --track "HexenII.bin" 320826912 31904880 2697ac40 + s "Hexen II (E) (Track 06).bin"
psxt001z --track "HexenII.bin" 352731792 34226304 2a8801ba + s "Hexen II (E) (Track 07).bin"
psxt001z --track "HexenII.bin" 386958096 32833920 554bdc16 + s "Hexen II (E) (Track 08).bin"
psxt001z --track "HexenII.bin" 419792016 32297664 952aa595 + s "Hexen II (E) (Track 09).bin"
psxt001z --track "HexenII.bin" 452089680 34132224 60b124d2 + s "Hexen II (E) (Track 10).bin"
psxt001z --track "HexenII.bin" 486221904 32895072 8c5a0fcf + s "Hexen II (E) (Track 11).bin"
psxt001z --track "HexenII.bin" 519116976 33744144 172e836a + s "Hexen II (E) (Track 12).bin"
psxt001z --track "HexenII.bin" 552861120 34955424 430ce67e + s "Hexen II (E) (Track 13).bin"
psxt001z --track "HexenII.bin" 587816544 32925648 140e863e + s "Hexen II (E) (Track 14).bin"
psxt001z --track "HexenII.bin" 620742192 32888016 a9c6dbe2 + s "Hexen II (E) (Track 15).bin"
psxt001z --track "HexenII.bin" 653630208 31342752 10644e18 + s "Hexen II (E) (Track 16).bin"
psxt001z --track "HexenII.bin" 684972960 32819808 b79890d2 + s "Hexen II (E) (Track 17).bin"

and here are the results, all the track were found, but the offset correction didn't stay constant, it shifted between track

Track 02 Offset correction: 5832 bytes / 1458 samples
Track 03 Offset correction: 5832 bytes / 1458 samples
Track 04 Offset correction: 5836 bytes / 1459 samples
Track 05 Offset correction: 5824 bytes / 1456 samples
Track 06 Offset correction: 5824 bytes / 1456 samples
Track 07 Offset correction: 5820 bytes / 1455 samples
Track 08 Offset correction: 5820 bytes / 1455 samples
Track 09 Offset correction: 5808 bytes / 1452 samples
Track 10 Offset correction: 5844 bytes / 1461 samples
Track 11 Offset correction: 5852 bytes / 1463 samples
Track 12 Offset correction: 5844 bytes / 1461 samples
Track 13 Offset correction: 5816 bytes / 1454 samples
Track 14 Offset correction: 5828 bytes / 1457 samples
Track 15 Offset correction: 5860 bytes / 1465 samples
Track 16 Offset correction: 5820 bytes / 1455 samples
Track 17 Offset correction: 5820 bytes / 1455 samples

Also, when I examined the bin files, I noticed that some tracks begin earlier in your dump and other got portions of the previous track at the beginning of the dump, look this example of your Track 04, the audio start in the position 0x53C
In my dump the audio start at position 0x0 on all audio track with 0 seconds pregap, and all the track ends with zeros, look in the dump of your Track 05 the audio start at position 0x548, and the track has portions of the previous track, at least compared to my dump.

Also, I included sample tracks of my dump for you to get a better idea of what I'm talking about.
I don't why IdSoftware or Activition mastered this disk like this... it's weird...

43

(43 replies, posted in General discussion)

Vigi wrote:

@pnkiller, what's the offset difference between the 2 Hexen II dumps? are you sure there isn't a sector offset caused by the bug?

Vigi, could you repost track samples for your Hexen II dump, this thing is taking to long sad
I tried to download the ones you posted earlier, but they are not available on the server anymore

44

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Finally I want to know how much do I have to remove from the data track, is it just the 1.73 pregap or the fact that there's a 2 sector correction has some influence?

I removed just the 1.73 pregap, if you hexedit the track, and backtrack the pregap length (1.73 - 148 sectors - 348096 bytes) from the end of the track, you will see the garbage data, 1 byte more and you will see the last sector, sync data, ecc headers, etc. just remove the pregap and you will have your track 1

45

(43 replies, posted in General discussion)

Vigi wrote:

edit: pnkiller, can't you install the plextor into your pc? tongue

Sorry, it's a notebook sad

Vigi wrote:

@pnkiller, what's the offset difference between the 2 Hexen II dumps? are you sure there isn't a sector offset caused by the bug?

I don't know right now, I will dump the entire disk into a bin file and apply the psxt001z track method to obtain your checksums, then will compare against mines and tell you the offset difference.. I post them later

46

(43 replies, posted in General discussion)

sorry for the delay.. the last track I dumped with my LiteOn LTN323 -1164 Drive offset... since the disc had a big positive offset, i give it a try with this drive and in fact it got info after the position were my other drives was throwing just zeros, dumped 3 times, so since the drive didn't show errors on EAC I decided to post the info for the last track dumped with the liteon drive.

EDIT 1
Yes, my LG and plextor drive do overread in the lead-out, but I'm presuming that since these game has huge positives offset, the overread is not enough, with both drives the hashes matched, but comparing against the dump obtained with the LiteOn drive they star showing zeros in the last portion of the dump were the liteon dump showed data.

47

(43 replies, posted in General discussion)

ok, I cannot dump in PerfectRip cause my plextor drive is connected via FireWire, and PRip doesn't see it.
this is command line for dx_d8, no subs, here my output with the px_d8 command.

C:\px_d8 k: 0 0
3DE5D18B6C44C566B6CF36D416DF4ED8
34F4977B2EA35C79F9E2C2C99196EC6E
CDEC558DFF2579E21170DE5F3458A321
B9D872DAA59B3B2B535F7DF82182C204
872B0876A0BF780C2285D9A31AF9CB02
D7419EB068742EA75C7A065CF1E797FE
E1D7D81C5A89FB26C35AD1FB1C4349F1
F6C4B743845FE22400FFFFFFFFFFFFFF
FFFFFF00018171610028001E80086006
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
CF7194246F5B6C3B6DD36D9DEDA98DBE
E5B04B34375756BEBEF0704424335B55
FB7F036001E8004E80346017680EAE84
7C6361E9E84ECEB454777F66A02AF81F
028801A6807AE0230819C68AD2E71D8A
89A726FA9AC32B11DF4C5835FA97032E
81DC6059E83ACE93146DCF6D942DAF5D
BC39B1D2F45D8779A2A2F9B982F2E185
886326A9DAFEDB005B403B7013640DEB
458F732425DB5B1B7B4B637769E6AECA
FC5701FE8040603081EEC8AC486436AB
56FF7EC020A546C90A91C72C529DFDA9
81BEE0704824369B56EB7ECF6054283F
5E90386C12ADCDBD95B1AF347C1761CE
A8547EBF607028241E9B486B76AF66FC
2AC1DF10580C3A85D3231DD9C99A30F8
79AA485436BF56F03EC410A763C9F5D1
871C6289E9A6CEFAD4431F71C824569B
7EEB604F68342E975C6EB9EC72CDE595
8B2F275C1AB9CB32D7559EBF28701EA4
087B46A372F9E582CB2197586EBAAC73

My calculation was =[(7.5*16)/4]-(-4*588)-(30)=2352, my drive is a Plextor PX-760A, this is the screenshoot from CDReader showing 4 sectors behind gap with no subs.

Also, the offset was calculated with the old method and also gave the same results, Gaps were detected on 4 drives using EAC, 3 of them gave me the same result (Plextor PX-760A, LG GDR8164B, LG GSA-4082N) and 1 drive (LiteOn SOHW-1633S) gave 1 sector difference (1.74) on first track, LiteOn LTN-323 doesn't support Method A gap detection on EAC, so it was left behind.

I went with the 1.73 pregap from the 3 drives to calculate offset using ISOBuster method.
I calculated the disc offset on 3 drives using ISOBuster method (Plextor PX-760A, LG GDR8164B & LiteOn LTN-323) and the disc offset gave me the same result, see the screenshots showing the garbage data.

So definitively I think that the offset is right and the gap are OK... although I'm open to suggestions..

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

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 forgot to mention that this game is fact a IBM PC game, mixed disc 1 Data track and 2 audio tracks.. and that using old method ISOBuster doesn't show me garbage data on the beginning of the pregap for the first audio track on any of my drives, just zeros.

Hi, could you please examine this output from px_d8 and correct me if I get it wrong with this method.

F6A986FEE2C0499036EC16CDCED5945F
2F781C2289D9A6DAFADB031B41CB7057
643EAB507F7C2021D8185A8ABB27335A
95FB2F035C01F9C042D0319C1469CF6E
D42C5F5DF8398292E1AD887DA6A1BAF8
7302A5C1BB10734C25F5DB071B428B71
A7647AAB633F69D02EDC1C59C9FAD6C3
1ED1C85C56B9FEF2C04590332C15DDCF
19940AEF470C3285D5A31F39C812D68D
9EE5A84B3EB75076BC26F1DAC45B137B
4DE37589E726CA9AD72B1E9F486836AE
96FC6EC1EC504DFC3581D7205E98386A
92AF2DBC1DB1C9B456F77EC6A052F83D
8291A1AC787DE2A189B866F2AAC5BF13
300DD4059F432831DE94586F7AAC233D
D9D19ADC6B19EF4ACC3715D68F1EE408
4B46B772F6A586FB22C35991FAEC430D
F1C58453237DD9E19AC86B16AF4EFC34
41D7705EA4387B52A37DB9E1B2C87596
A72EFA9C4329F1DEC458537ABDE33189
D466DF6AD82F1A9C0B29C75ED2B85DB2
B9B5B2F735869722EE998C6AE5EF0B0C
0745C2B311B5CC7715E68F0AE4070B42
8771A2A479BB62F36985EEE30C49C5F6
D306DDC2D9919AEC6B0DEF458C3325D5
DB1F1B480B768766E2AAC9BF16F00EC4
0453437DF1E184486376A9E6FECAC057
103E8C1065CC2B15DF4F18340A97472E
B29C75A9E73ECA90572C3E9DD0699C2E
E9DC4ED9F45AC77B12A34DB9F5B2C735
92972DAE9DBC69B1EEF44C4775F2A705
BA833321D5D85F1AB80B328755A2BF39
B012F40D8745A2B339B5D2F71D8689A2
E6F98AC2E7118A8C6725EA9B0F2B441F
734825F69B06EB42CF7194246F5B6C3B
6DD36D9DEDA98DBEE5B04B34375756BE
BEF0704424335B55FB7F036001E8004E
80346017680EAE847C6361E9E84ECEB4
54777F66A02AF81F028801A6807AE023
0819C68AD2E71D8A89A726FA9AC32B11
DF4C5835FA97032E81DC6059E83ACE93
146DCF6D942DAF5DBC39B1D2F45D8779
A2A2F9B982F2E185886326A9DAFEDB00
5B403B7013640DEB458F732425DB5B1B
7B4B637769E6AECAFC5701FE80406030
7C62E6C1486436AB56FF7EC020A7EDC9
0A91C72C529DFDA981BEE0704824369B
56EB7ECF6054283F5E90386C12ADCDBD
95B1AF347C1761CEA8547EBF60702824
1E9B486B76AF66FC2AC1DF10580C3A85
D3231DD9C99A2A710B1D485436BF56F0
3EC410A6B8C9F5D1871C6289E9A6CEFA
D4431F71C824569B7EEB604F68342E97
5C6EB9EC72CDE5958B2F275C1AB9CB32
D7559EBF28701EA4087B46A372F9E582
CB2197586EBAAC733DE5D18BB48BA476
B6CF36D416DF4ED8341B977B2EA35C79
F9E2C2C99196EC6ECDEC558DFF258C07
C07E41CC8F20A321B9D872DAA59B3B2B
535F7DF82182FD04166AA6D8A053780C
2285D9A31AF9CB02D7419EB068742EA7
5C7A4DB19318DD5B8260D81C5A89FB26
C35AD1FB1C4349F1F6C4D6433A1C3D8B
00FFFFFFFFFFFFFFFFFFFF0001820261
0028001E80086006A802FE8180606028
281E9E886866AEAAFC7F01E000480036
8016E00EC80456837EE1E0484836B696
F6EEC6CC52D5FD9F01A8007E80206018
280A9E8728629EA9A87EFEA040783022
9419AF4AFC3701D6805EE0384812B68D
B6E5B6CB36D756DEBED8705AA43B3B53
537DFDE181886066A82AFE9F0068002E
801C6009E806CE82D4619F68682EAE9C
7C69E1EEC84C56B5FEF700468032E015
880F26841AE34B09F746C6B2D2F59D87
29A29EF9A842FEB180746027681AAE8B
3C6751EABC4F31F414474F72B425B75B
36BB56F37EC5E053083DC69192EC6D8D
EDA58DBB25B35B35FB57037E81E06048
28369E96E86ECEAC547DFF618028601E
A8087E86A062F829829EE1A8487EB6A0
76F826C29AD1AB1C7F49E036C816D68E
DEE4584B7AB76336A9D6FEDEC058503A
BC1331CDD4559F7F28201E98086A86AF
22FC1981CAE057083E869062EC298DDE
E5984B2AB75F36B816F28EC5A4533B7D
D3619DE8698EAEE47C4B61F76846AEB2
FC7581E7204A98372A969F2EE81C4E89
F466C76AD2AF1DBC09B1C6F452C77D92
A1ADB87DB2A1B5B87732A695BAEF330C
15C5CF13140DCF4594332F55DC3F19D0
0ADC0719C28AD1A71C7A89E326C9DAD6
DB1EDB485B76BB66F36AC5EF130C0DC5
C593132DCDDD9599AF2AFC1F01C80056
803EE010480C3685D6E31EC9C856D6BE
DEF058443AB35335FDD7019E8068602E
A81C7E89E066C82AD69F1EE8084E86B4
62F76986AEE2FC4981F6E046C832D695
9EEF284C1EB5C87716A68EFAE4430B71
C76452AB7DBF61B028741EA7487AB6A3
36F9D6C2DED1985C6AB9EF32CC1595CF
2F141C0F49C436D356DDFED9805AE03B
0813468DF2E5858B232759DABADB331B
55CB7F17600EA8047E836061E8284E9E
B468776EA6AC7AFDE30189C066D02ADC
1F19C80AD6871EE28849A6B6FAF6C306
D1C2DC5199FC6AC1EF104C0C35C5D713
1E8DC86596AB2EFF5C4039F012C40D93
45ADF33D85D1A31C79C9E2D6C99ED6E8
5ECEB85472BF65B02B341F57483EB690
76EC26CDDAD59B1F2B481F768826E69A
CAEB170F4E8434635769FEAEC07C5021
FC1841CAB057343E97506EBC2C71DDE4
598B7AE7630AA9C73ED2905DAC39BDD2
F19D8469A36EF9EC42CDF195846F236C
19EDCACD9715AE8F3C6411EB4C4F75F4
27075A82BB21B35875FAA7033A81D320
5DD8399A92EB2D8F5DA439BB52F37D85
E1A30879C6A2D2F99D82E9A18EF86442
AB71BF64702B641F6B482F769C26E9DA
CEDB145B4F7B74236759EABACF331415
CF4F14340F57443EB35075FC2701DA80
5B203B58137A8DE32589DB26DB5ADB7B
1B634B69F76EC6AC52FDFD8181A06078
28229E99A86AFEAF007C0021C018500A
BC0731C29451AF7C7C21E1D8485AB6BB
36F356C5FED3005DC0399012EC0D8DC5
A5933B2DD35D9DF9A982FEE180486036
A816FE8EC064502B7C1F61C828569EBE
E8704EA4347B57637EA9E07EC8205698
3EEA904F2C341DD7499EB6E876CEA6D4
7ADF631829CA9ED7285E9EB86872AEA5
BC7B31E35449FF76C026D01ADC0B19C7
4AD2B71DB689B6E6F6CAC6D712DE8D98
65AAAB3F3F50103C0C11C5CC5315FDCF
0194006F402C301DD4099F46E832CE95
946F2F6C1C2DC9DD96D9AEDAFC5B01FB
40437031E4144B4F777426A75AFABB03
3341D5F05F0438035281FDA041B83072
9425AF5B3C3B51D37C5DE1F98842E6B1
8AF467076A82AF21BC1871CAA4573B7E
93606DE82D8E9DA469BB6EF36C45EDF3
0D85C5A31339CDD2D59D9F29A81EFE88
4066B02AF41F074802B681B6E076C826
D69ADEEB184F4AB437375696BEEEF04C
4435F35705FE830061C028501EBC0871
C6A452FB7D8361A1E8784EA2B479B762

Here the sync header start at row 63
that would be 63*4 = 252
In the sync header (00FFFFFFFFFFFFFFFFFFFF00018202) the data is read from sector 2 , so this would be
252 - (588*2) = -924 and the drive offset is +30, so the disc would be -954??