You are not logged in. Please login or register.
Redump Forum → General discussion → Sega CD 32X questions
I bought one of them today and am in the process of dumping it. Do you think I should put it under the mega-cd section with 32X in the version or edition or what? There is only 5 so I don't think it needs it's own part of the database what you guys think?
Just to make sure also I got the offset correct...
63 lines with the d8 method
63 X 16 = 1008 /4 = 252
252 - 1176 = -924 - +30 = -954 (write offset)
63 lines with the d8 method
63 X 16 = 1008 /4 = 252
252 - 1176 = -924 - +30 = -954 (write offset)
Is +1176 your drive reading offset? What's +30?
+30 is my drives read offset.. I was following the directions for the D8 method.
This time there is 2236 bytes before the sync/header, or 513 samples.
However, this time the sync/header is slightly different from our previous example (00FFFFFFFFFFFFFFFFFFFF00018202...).
This difference in the header (18202 instead of 18200) indicates that the data is read from sector 2 instead of sector 0 (see post below for more info).A full sector is 2352 bytes or 588 samples of data, so the difference is 2*588 samples.
Combined read+write offset = 513 - (2*588) = -617. Because the drive that we used is +30 read offset, the factory write offset is -647.
I guess I don't understand the math... how in the example does it become -617?
2 X 588 = 1176 right
so 513 - 1176 would = -663 right? What am I missing?
I think Dremora is asking that because in both EAC and PerfectRip logs you posted above I see a +252 offset correction. Why that? Using your calcs the write offset is -954, and if combined offset is -924, you should use that to dump. +252 is completely wrong.
Moreover are you sure you have to subtract -1176 for this disc? The part of the guide you cited is only an example, you don't have to always subtract 2 sectors to get the offset. What number do you get after the sync? Is it really 018202? Or is it 18200? SegaCD discs shouldn't have big negative offsets.
Can you post here the D8 info?
I think Dremora is asking that because in both EAC and PerfectRip logs you posted above I see a +252 offset correction. Why that? Using your calcs the write offset is -954, and if combined offset is -924, you should use that to dump. +252 is completely wrong.
Moreover are you sure you have to subtract -1176 for this disc? The part of the guide you cited is only an example, you don't have to always subtract 2 sectors to get the offset. What number do you get after the sync? Is it really 018202? Or is it 18200? SegaCD discs shouldn't have big negative offsets.
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
3453BFD6486436AB56FF7EC0D702EDB3
C124C7F4A5EDFD9C4AFEAA58B0A54BB1
56DEB57A608C35A65EA5F3665609B910
54B78334C91761C28FDF3AE4A7915C89
E5B5486B769AADF69B65FF3E5839F14E
040D1DEC02A6210CE011836C129156C5
F50BEFFAB8B21ECBAFF39DC1E9322514
D99292FAA6F2560F95F148A03BD92E03
B76B9BBE48150B969D2FF35C1ABF56F9
F5F6734112A8EDB3087B463799FC33D0
DB3697CC855149643D713A95C3FE16CC
5DD324C3164BA531A86909079111221D
78AC27433F98BA77E578E7F8243CACD9
E220DD7CB682EE8E669EB0A2170F2B2F
DBCAC48BCEB6F975C51FE46EC9200959
B2005CF894F1D682CF496807DA56D023
0E39D0F49CCA3B53AA49371FE400D080
6EB82BBEC2202273766D19C9E538077A
00FFFFFFFFFFFFFFFFFFFF0001820261There is 63 lines...
Yes the combined offset is -924. That's the number to use (in PerfectRip it's +924)
EAC doesn't detect track02 pregap, so the resulting file has should have no pregap.
Try manually adding a 2.00 pregap to EAC's track02, and see if it matches PerfectRip's track02 in size and CRC.
I did add the pregap. it matches in size but not crc.. I can upload with the new offset 2nd track audio if someone wants to look at it.
Yes if you can 
What about data track? Do PerfectRip's and IsoBuster's match?
Yes, they match.
Actually PerfectRip's track02 you uploaded has less than 2 second of pregap, and EAC's has exactly 352800 bytes of pregap (which are the ones you added), so it's probable that EAC cut some data at the beginning. I prefer to hear what Vigi/Dremora/Themabus have to say. A -924 offset is exceptional, maybe there's an issue with that.
Yes, EAC's track02 definitely miss data at the beginning, data that's present in PerfectRip's, which in turn has definitely less than 2 seconds of pregap silence
It could be wrong offset messing things up or gap being different than 2 secs. Can you post PerfectRip cue?
Ok, why would it be less than 2 second of pregap? The cue says 2 seconds.
REM Tool: PerfectRip
REM Date & time: 3/1/2008 6:13:41 PM
REM Drive: PLEXTOR DVDR PX-712A 1.09
CATALOG 0000000000000
FILE "01.- cd.track.pcm" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
FILE "02.- cd.track.pcm" BINARY
TRACK 02 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:00The game was brand new factory sealed.
The first two tracks you've uploaded have difference only in pregap, the tracks dumped with -924 are completely different. Are you sure you've dumped them with the same offset?
No, sorry it was -954 with EAC...
I just dumped track 2 with pr with out dumping track 1 with it and it gave the same md5 as EAC with offset -924.
Could all the sub-channel errors that perfectrip gets effect the gap and make it messed up?
Gigadeath...
When you said if the perfectrip track 01 matches the one with ISOBuster and I said yes. It does match but I resized the ISO buster image of a 2 second gap and I didn't touch the Perfectrip track 01.... It seems to me somewhere Perfectrip is screwing up the gap?
here is the -924 EAC and PR track 02..
AFAIK PerfectRip should give right size track01 without resizing. If PerfectRip's untouched and IsoBuster's resized match, then it's right.
Track02 still has issues, I see that PerfectRip file still has less than 2.00 pregap, and EAC file still misses data at the beginning.
Can you look at actual disc lenght in sectors with IsoBuster?
I will do that. But I messed up and I am going to see if that is the problem. I am redumping them now. I never took out the - in Perfectrip so that it was a positive.
In EAC I have it set to positive, which is correct right? Or do you put it as -924?
-924 in EAC and +924 in PerfectRip.
EAC -> exact combined offset
PerfectRip -> inverted sign
Thanks.. but even with that fixed it's still not matching.
266474 is the amount of sectors ISOBuster gives for the cd...
Daemon doesn't let me load the cue from perfectrip.
I had to fix the cue perfectrip made... It matches the cd.
ISOBuster and EAC + added gap matches the cd also.
Are you always detecting gaps before dumpigng with EAC? Even if it returns 0.00 it's necessary to hit F4 before dumping. Even without manually adding pregap, EAC resulting file shouldn't begin directly with data.
Yes, I hit F4.
Can you please upload
1) EAC track02 dumped with -924 WITHOUT added pregap
2) PerfectRip track02 dumped with +924 (dumped by itself, without dumping track01 in the same session)
Here it is...
http://rapidshare.com/files/96336264/track.rar.html
EAC misses very few data this time. But there seems to be something definitely wrong with offsets, both tracks are cut off at the end. My guess is the offset isn't really that huge negative one we use now. Have you tried detecting the offset with good ol' IsoBuster method? Take track02 LBA, go back 150 sectors and see what's there.
No hurry, going to bed now
Doesn't display any garbage data when I go back 150 sectors.
Hopefully Vigi has a suggestion.
EDIT: How can you tell if it's been cut off at the end?
I compared the two in hex workshop. This is what is missing from the beginning of the EAC dump.
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 C104 7004
9205 B404 AA08 AE06 5A0C A609 880E 9F0B E20F E10C 6510 A00D 2B0E 580C
BE09 1609 B705 9505 0D03 E402 7C02 CE01 6405 4903 270B 6C07 6610 2B0CI wonder why EAC didn't dump that?
Redump Forum → General discussion → Sega CD 32X questions
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.