What is your recommended DumpTool?
- Yuki
- New member
- Offline
Welcome Yuki!!!
I really appreciated your work at UG! I hope you can contribute here with many rare japanese games for Sega Saturn, PSX and PC Engine!
For DC I don't know, I'm waiting for a proper DC dumping guide to perfect dump my disc collection (not so big, around 20 games). Surely a moderator such as vigi can help with a more competent answer!
- Yuki
- New member
- Offline
Thanks xenogears
I am using following Tool now.
http://www.gotwalls.com/
http://dumpcast.thekickback.com/
Is this method BAD?
Yuki wrote:
Thanks xenogears
I am using following Tool now.http://www.gotwalls.com/
http://dumpcast.thekickback.com/Is this method BAD?
This method is bad in one thing: it doesn't consider combined read+write offset. 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.
- Yuki
- New member
- Offline
Thank you.
It is little BAD news.
Because I have already resold DC of 100 or more. 
- Yuki
- New member
- Offline
It is another one question.
I am personally collecting 3DO.
How does 3DO do Dump?
3DO is single DATA TRACK CD.
Yuki wrote:
It is another one question.
I am personally collecting 3DO.
How does 3DO do Dump?
3DO is single DATA TRACK CD.
You just 'Right mouse button on Track 01 -> Extract Track 01 -> Extract RAW Data (2352 bytes/block) (*.bin, *.iso);' in IsoBuster..
- Yuki
- New member
- Offline
Are not you permitted excluding IsoBuster?
I am preserving everything with MODE1/2048.ISO.
And, most 3DO has been resold.
3DO that remains at hand is about 50.
Yuki wrote:
Are not you permitted excluding IsoBuster?
I am preserving everything with MODE1/2048.ISO.
And, most 3DO has been resold.
3DO that remains at hand is about 50.
Sorry, we only dump in RAW 2352.. MODE1/2048 is used by TOSEC already so there's no point in doing the same.
- Yuki
- New member
- Offline
OK!
However, 3DO of TOSEC is very few.
Is it meaningless to convert MODE1/2048 into 2352?
Only for confirmation of existing dumps — there may be mastering errors which should be preserved. Though even those 50 discs would be a very good start 
- Yuki
- New member
- Offline
OK!
The title that I have already resold is given up.
Neo Geo CD would be waaay more interesting for now If it were your backups on UG, of course..
- pnkiller78
- Dumper
- Offline
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?
- pnkiller78
- Dumper
- Offline
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?
pnkiller, I noticed that for Soul Calibur the track02 audio checksum isn't the same as the other 2 dumps, could you check plz? edit: sega rally 2 has the same issue.. maybe it's normal after all..
Anyway, it's nice to see that you're dumping dreamcast using our method (if you want to be completely sure about the data track integrity you could compare against dumpcast/tosec's dat (which dumping method are you using?).. so far Star Wars Ep1 Racer data matches: http://dumpcast.thekickback.com/ 
).. It's strange to see that all NTSC discs have a different write offset, because my PAL discs all had the same write offset.. (calculated using track02 pregap).
ps. how many dc discs do you have?
- pnkiller78
- Dumper
- Offline
I have 15-20 discs, I bough 'em on December and until today opened the boxes.
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.binAs 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 )
)20 2008-02-25 00:19:32 (edited by pnkiller78 2008-02-25 00:20:50)
- pnkiller78
- Dumper
- Offline
Oh, I think I couldn't explain myself well 
, 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.binPlease correct it...
pnkiller78 wrote:
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.
Can you please post tracks sizes and gdi from httpd-ack dump (without any manual corrections) of Sega Rally 2?
pnkiller78 wrote:
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
Fixed.
22 2008-02-25 00:33:30 (edited by pnkiller78 2008-02-25 00:44:10)
- pnkiller78
- Dumper
- Offline
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 0Also, here it is a screenshot of the first session of the disc and the disc properties windows on ISOBuster.
Ok, now I see... httpd-ack makes not full dumps: tracks 2, 4 and 3rd data track (if exists) are missing pregaps (150 sectors). So we should use track 2 from EAC, 150 sectors should be added to the beginning of track 4. The only question is: what's the contents of 3rd data track pregap? I hope Vigi can answer it — he has dumped several GD-ROMs using PC drive.
- pnkiller78
- Dumper
- Offline
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.
pnkiller78 wrote:
* Added the pregap from the 3rd data track (track 21) to the end of last audio track (track 20).
I think it's wrong; 150 sectors are missing from here, so moving data from one track to another won't help, it needs to be generated.