Ripping GDR's

[Quzar]

Standard DCload IP is configured without an IP, which basically means you have to simply bind whatever it is to the BBA's mac address (or at least that's how I used to do it).

DCLoad does not look at the flashrom at all for IP info. The way I used to do it (and still typically do), is add an arp entry binding the DC's mac to whatever IP I want. That way, if you switch networks, or need a different IP, you don't have to burn a new disc.

[l_oliveira]

Standard DCload IP is configured without an IP, which basically means you have to simply bind whatever it is to the BBA's mac address (or at least that's how I used to do it).

DCLoad does not look at the flashrom at all for IP info. The way I used to do it (and still typically do), is add an arp entry binding the DC's mac to whatever IP I want. That way, if you switch networks, or need a different IP, you don't have to burn a new disc.

It allows for an IP setting, but it's embedded into the program. If it's set to 0.0.0.0 the only way to connect to it is doing what you said (connect through ARP using the BBA mac address)

I got a modified version of it which is set to 192.168.0.10 instead of 0.0.0.0 at the author page, I think... (It's been a long time since I got it)

[alf717]

I've always used HTTPD-AK to rip DC games. Is the DC load IP method better in any way? I've never really gotten it to work at so I just decided to use HTTP-AK since I could just set my IP address using XDP and access the DC through my PC web browser.

[-=FamilyGuy=-]

I've always used HTTPD-AK to rip DC games. Is the DC load IP method better in any way? I've never really gotten it to work at so I just decided to use HTTP-AK since I could just set my IP address using XDP and access the DC through my PC web browser.

DC-Load-IP and BBRIP can be used to dump beta gd-r with CDDA tracks, as I can be fooled by a cd-r to get the toc of a disc. (then you can swap for the beta gd-r and rip it out)

To rip "normal" TOSEC images you should prefer http-ack (BBA) or DCSDRIP (SD-Cable).

FG

[C.Badfurday]

Hi to all, this is my first post here.
Since nobody mentioned it clearly in this thread yet: HTTPD-Ack (2007-11-23) does dump GD-Rs, at least some, as it states in the readme.
I used Dot50Cal's & -=FamilyGuy=-'s non-CDDA method with success on the first 3 games I tried, then gave HTTPD-Ack a shot and found all tracks were dumped 100% identical; so I decided to stick with Ack if possible simply because it's what I use for normal GD dumps too. Also I personally find the idea of burning a trap disc for every GD-R a bit much for people with bigger collections, with Ack you (apparently) only need a retail game.

I am having problems with some multitrack CDDA games though, which (for example) only let me dump the first 8 tracks (.bin & .raw) of 15. The 15th track was a .bin and dumped fine again... however when trying to dump tracks 9 to 14, the DC tried reading, spinned down the disc, spinned it up again, tried reading again - 5 times in total, on every track I tried.
Some of the discs I tried had essentially the same problems, except that I could dump ~30-50% of one of the audio tracks and then none of the following audio tracks - i was again able to dump the very last track though, a .bin.

I used Sega Extreme Sports (Whitelabel, ~40 tracks) to dump ~20 GD-Rs, of which ~5 work on NullDC without modification, some show errors about memory mapping (?), others error with no clear messages - and ~50% of them are missing multiple audio tracks so I didn't bother trying them in NullDC.
I recently got 'Rainbow Six - Rogue Spear + Mission Pack: Urban Operations' which should (according to TOSEC) have ~100 Tracks that might perhaps be helpful with dumping... but I'm only guessing here, I'll try around more in a few days.

Also I got myself a LTD-165H drive off eBay, turns out they're quite easy to find... 3 were on eBay ending the day I looked, got one for 6€ shipped. Just started reading into -=FamilyGuy=-'s & RobbyW's tuts.

[Dot50Cal]

Ill probably be updating the PDF in a little bit. I just got into the CDDA bits myself and found a few things confusing (+ not working with Vista 64). So expect a slight revision soon, maybe with some new pics and such :thumbsup:

[raylyd]

hi could i load system disc 2
and then put in dc load and then put in a gd-r

[-=FamilyGuy=-]

I'm not 100% sure, but since the System Disc 2 reboots the DC in order to load the gd-r, I can't see how you'd make DC-Load IP or http-ack to read the gd-r TOC instead of the SD2 one. In fact when you'll insert the SD2, the ripping program won't execute the bins on it and thus the disc you load the gd-r.

Short answer, I REALLY don't think so, sorry :P

FG

[Ryo Suzuki]

I have a problem when I try to rip GD-rs with CDDA.

When I make the trap disc my CDRecorder don't make the disc working because change 150 the LBAs...

For example, I want to create a trap disc to emulate this track layout:

HD area TOC:
HD tracks : 3 to 5
track 3 : Start LBA 45000 , End LBA 328477, ctrl 0x4
track 4 : Start LBA 328627 , End LBA 329078, ctrl 0x0
track 5 : Start LBA 329228 , End LBA 549300, ctrl 0x4
Last Sector : LBA 549150

But when I burn the CD Trap, cdrecord give me this mistake:



As you can see startsec should be 0, but it uses -150.

At first I even noticed this warning, but when I burn the final trap CD and I'm riping the disc never can finish the last data track.

Then I realized the 150 lba problem, looking at the info of the trap disc in BBRIP:



The 150 LBA difference :-( (150 should be 0, 45150 should be 45000, 328777 should be 328627 and 329378 should be 329228)

How can fix this problem? I tried with 2 different recorders and I get the same bad result...

Maybe can I burn the trap disc with another software faithful to the real LBAs?

What can I do??

I need to rip some interesting sfuff...

THANKS!

[-=FamilyGuy=-]

The problem is with the burner, it doesn't seem to support DAO (Disc-At-Once) reading mode. Or it uses a microsoftware (aspi) this old version of cd-record doesn't like at all.

Try removing 150 sectors to the first track (307,200 bytes), it should fix it.
track01 should then be 91,545,600 bytes.
Remove this amount of bytes only on the first track! The other ones are ok in lenght, and their address will be shifted correctly using this trick, I hope.

If it still doesn't work, try removing -dao from trapit.bat in the recording command.

Gimme news aobut this !

FG

[Ryo Suzuki]

I remove it but don't works.

This time the GD-R spins but the Dreamcast can't read it, even the first tracks.



Do you mean edit the trapit.bat? Isn't? I did this:

@dummy session1.bin 91545600
@dummy track03.bin 580345856
@dummy track04.raw 813792
@dummy track05.bin 614400

And no success...

I will try burn it with the original @dummy session1.bin 91852800 but without -dao comand.

thks!

[-=FamilyGuy=-]

HEY !

I just re-read my old tutorial, and the 150+ problem using BBRIP is NORMAL.

The way CD are made, the image you burn to them doesn't really starts at LBA0, but rather a 150. Most softwares labels the first 150 sectors from -150 to 0, so the real user-data starts at 0.

BBRIP, however, reads the cd in low-level mode and sees 45000 as what it really is, 45150.

So for the first track, 0 is the Logical Block Address, while 150 is the Physical Block Address.

You were doing things fine!

Run BBRIP on a retila and you'll see 1st track as LBA150 and 3rd one as 45150.


Your first dumps were just OK!

FG

[Ryo Suzuki]

Ooooh mate! You're right, the same 150 thing with the retail :dance:

But still don't works, the last track always stop here:



I have this tracks log:

#,Lba,Sectors,Downloaded,Time,State
1,150,45000,,,
2,45150,283627,,,
3,328777,601,,,
4,329378,219922,235.1/429.5MB,13:08:47 > 13:15:07,ERROR CODE:040a0100


I don't understand. I was trying with another prototype with audio tracks and have the same problem...

In the last track always in the same one position the Dreamcast don't continues reading the disc, then stop and return to spin the disc again and enter in a loop (stops, spin again, can't read and return to stop again...etc)

Then I can't extract the files in the data track of the disc because several files is missing...

Can you make a trap disc for me and upload it to megaupload? Please. I think is dummy files stuff then you can compress it in a few of megas...

Then I can rule out if maybe I are making something wrong :evil:

The info of the disc is:

Disk Info:
Hardware Identifier : "SEGA SEGAKATANA"
Hardware Vender ID : "SEGA ENTERPRISES"
Media ID : "4749"
Media Information : "GD-ROM1/1"
Compatible area symbols : "JUE"
Peripheral Information : "0799800"
Product number : "MK0000"
Version number : "V0.800"
Release date (dd/mm/yyyy): 24/08/1999
First read file : "1ST_READ.BIN"
Maker Identifier : "SEGA ENTERPRISES"
Game Title : "THIS IS A SAMPLE DISK FOR USE IN THE OFFICE ONLY DO NOT SELL DO NOT CARRY OUT FROM THE OFFICE"

HD area TOC:
HD tracks : 3 to 5
track 3 : Start LBA 45000 , End LBA 328477, ctrl 0x4
track 4 : Start LBA 328627 , End LBA 329078, ctrl 0x0
track 5 : Start LBA 329228 , End LBA 549300, ctrl 0x4
Last Sector : LBA 549150

Thanks for help me, I become crazy with this!! xD

[-=FamilyGuy=-]

Did you forgot to hack the TOC of teh disc to make it 122minutes long ?
It'd explain this problem ...

Once you burn the first disc, you got to make a CloneCD image of it then hack the ccd file then burn it back ...

It's all written in the guide.

Gimme news!

FG

[Ryo Suzuki]

No friend.

I understand, I have to made 2 trap disc. The first is for make the second and true one, and the second before burn it I edit the 122 min and the other values in Section 2.

I have to test in another console. This one is a PAL with Samsung reader, is in good condition... but I have to find what can be the source of this mistake reading...

thks!

[-=FamilyGuy=-]

Well, all you're doing seems fine, maybe your disc is scratched or something. If you can upload your hacked ccd image of your trap disc I might check it out to see if there's any problem with it.

Sorry not to be able to fix your problems fast.

FG

[unclejun]

I have the same issue as Ryo Suzuki, after dumping around 790MB, I get the same error code.
I followed your very well made tutorial, I used CloneCD (4.something) and Alcohol120%, I get some errors (at the end of the ripping) while making the image of the first disc (I assume those aren't the cause of the DC Backup utility error).
I bought 900MB CDs to check if they would work best as trap discs, but my Dreamcast refuses to read them, it makes a rapid clicking noise iirc and stop trying after 15-30 seconds or so...

Is there anyway you can think of to make the ripping work, besides finding someone with a dev unit?

Thanks.

[raylyd]

i have a gdx gd rom ripper no pc needed well needed to give you the files ripped lol just me if you need me to do this ?

[Dreamcast]

I have never been able to get DC Backup Utility to work (either version). Have you tried HTTPD-ACK?

[unclejun]

No I haven't yet...
Any differences with the DC Backup Utility method?