1 Topic by Jackal (edited by Jackal 2014-02-26 12:48:05)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

With certain drives it's possible to dump the high density area of a gd-rom disc using the escape eject button. The low density area (the first 2 tracks which are always visible) can be dumped the normal way (without hotswapping) on any drive using the cd dumping guide found here: http://redump.org/guide/cddumping/ .

Software needed:

- dctools, audio trap disc

Instructions:

The high density area (sector 45000-549150) can be dumped as follows:

- insert the audio trap disc (a disc with a hacked TOC of 99 mins audio, burn it with CloneCD or Alcohol).
- use 'startstop.exe driveletter 1' to stop the drive motor.
- use a pin to press the escape eject button, so the tray will eject (or remove the drive cover).. insert the gdrom and gently push the tray back (or put the drive cover back on).
- Now extract sector 44990 (to be sure that the offset doesn't cut off any data) - 549150 using CDRWin 'Select Sectors' with the following settings: CD Audio (2352), File Format INTEL, Error Recovery Abort, Audio Speed 1x, Read Retry Count 1.
- When it's done extracting, use 'ice.exe dumpfile.bin 44990 > ice.log.txt' to descramble, split the dump data and get the ice log file.

If everything went well, the dump is ready to be submitted.

If you get any errors during extraction or if your drive fails to read the gdrom disc after swapping, then this most likely means that your drive isn't suitable for dumping gdrom discs. Read the next post to see if your drive which drives are supported/unsupported.

  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

SUPPORTED DRIVES big_smile

Lite-On LH-18A1H
Lite-On SOHD-167T
NEC CDR-1901A
Plextor PX-W4824TA
Samsung TSSTCorp SH-D162C
Samsung TSSTCorp SH-D162D
Lite-On LTD-165H
Lite-On SOHD-16P9S
TSSTCorp TS-H353B
GCR-8522B
Plextor PX-708A
Plextor PX-755SA
Plextor PX-W4824TU
TSSTCorp TS-H353A, TS-H352C, TS-H192C ???

Note: If it doesn't work after some retries, then first read ahead a bit (sector 60.000-x) and then (re)try normal range again. Or try to remove the cover.


If you have any supported/unsupported drives, let us know and they will be added to the list!
UNSUPPORTED DRIVES (tested by):

ASUS CRW-5224A (axisleon)
ASUS DRW-24B1ST a (Enker)
LG BD-RE GGW-H20L (Teancum)
LG CED-8120B (iR0b0t)
LG GCC4482B (Enker)
LG GDR-8164B (iR0b0t, Rocknroms)
LG GSA-H10N (Enker)
LG GSA-H42L (iR0b0t)
Lite-On iHAS324-32 B (axisleon)
Lite-On iHBS112 2 (Enker)
Lite-On iHDP118 4 (Enker)
Pioneer DVD-129P (axisleon)
Pioneer DVR-103 (iR0b0t)
Pioneer DVR-111 (axisleon)
Pioneer DVR-216 (axisleon)
Plextor PX-116A (axisleon)
Plextor PX-760A (iR0b0t, Rocknroms, Jackal)
SONY CRX140S (axisleon)
SONY CRX230E (nrl_quaker)
TEAC CD-532S (axisleon)
Toshiba SD-M1502 (iR0b0t)
Lite-On COMBO SOHC-5236V (axisleon)
NEC ND-4550A (nrl_quaker)
Samsung TSSTcorp SH-S202J (nrl_quaker)
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

To avoid errors on offset detection, make a check with this (thanks to Dremora) if you have a plextor and use px_d8. The mod should report right combined offset and you can check it with the standard px_d8.

My patch requests thread
--------------------------------
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

This is something common. By the way this thread has a lot of messages deleted that could have helped you (expecially alternative dump method with cdtools that in my opinion is better and speeder).

1) Sometimes you need to try more than once the process (insert - starstop - eject).

2) Try this way. Begin it at 70000 (for example, if it fails go back to 80000 and so on), if it starts stop it and try at 65000, again if it starts stop and try to 60000 until it starts at 44990.

3) If method 1/2 failed, simply try to dump it in multi parts: if it starts at 70000 dump it until end, then dump from 44990 to 69999 (it could be you need to dump it in more multi parts). At the end "copy /b" the parts according to sector sequence to get a full dump.

My patch requests thread
--------------------------------
  • Registered: 2008-09-29
  • Posts: 2,193

I'll rephrase the question.

Q: Why is ice.exe giving the wrong combined offset vales, when I unscramble discs with negative offset.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

please do not use write offset from high density area on low density tracks !

these two areas were mastered on different ways, probably on the same machine but "maybe" with 2 different offsets.

determine the write offset from low density area using the standard cd dumping guide, and dont care about high density offset, ICE is shifting it automatically to the correct position.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • Registered: 2008-09-29
  • Posts: 2,193

Thats understood.

Thanks.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.
  • Registered: 2010-08-01
  • Posts: 4

My drive is on the unsupported list, so I tried httpd-ack. To test it I dumped ChuChu Rocket and Sonic Adventure, but only track 1 and track 3 match. Is there a way to produce good dumps with httpd-ack?

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

TPSNT wrote:

My drive is on the unsupported list, so I tried httpd-ack. To test it I dumped ChuChu Rocket and Sonic Adventure, but only track 1 and track 3 match. Is there a way to produce good dumps with httpd-ack?

!!! Nope.. httpd-ack is not supported !!!

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

To all people who cannot dump DC with any drive:

1) which error does CDRwin report?

2) does dump starts and then stopped with errors after dumping a bit?

If those errors are not referring to sectors then your problem is simply a bad media used for trap disc.

My patch requests thread
--------------------------------
  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

If everything went well, the dump is ready to be submitted.

I think this info should be added because someone could not understand if ice reports errors or not:

Good dump

---------------------------------
hd.bin
---------------------------------
Accessing                       : ok
Seeking 1st valid Mode1 sector  : ok
 LBA found                      : 44991
 @file offset                   : $00000840
 Scrambled                      : TRUE
Seeking LBA 45000               : ok
 Combined offset (samples)      : 5820
Parsing IP.BIN                  : ok
 Writting 'ip.txt'              : ok
Parsing TOC                     : ok
 TOC entries                    : 4
 Writting 'redump.cue'          : ok
---------------------------------
03  Mode1   45000  549149  504150 ok
---------------------------------
done

Bad dump

---------------------------------
hd.bin
---------------------------------
Accessing                       : ok
Seeking 1st valid Mode1 sector  : ok
 LBA found                      : 44991
 @file offset                   : $00000840
 Scrambled                      : TRUE
Seeking LBA 45000               : ok
 Combined offset (samples)      : 5820
Parsing IP.BIN                  : ok
 Writting 'ip.txt'              : ok
Parsing TOC                     : ok
 TOC entries                    : 4
 Writting 'redump.cue'          : ok
---------------------------------
03  Mode1   45000  549149  504150 ok (46)
---------------------------------
done

This is an example with a "one track" high density disc, if you got something within "(...)" after a track "ok", those are errors so that track is bad!

My patch requests thread
--------------------------------
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

ICE output is also needed to determine the high density area write offset, as some discs can have different write offsets on LDA & HDA !!!

here is an example http://redump.org/disc/16727

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

so, for everybody using Lite-On SOHD-167T

be warned to NOT to use values OVER 440000 when extracting ranges partially, try to stay below 400000
(the firmware has a bug)

you may use extractions from 44990-400000 and then 400001-549150, then it will be fine.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: Underworld
  • Registered: 2008-05-28
  • Posts: 386

I have been dumping many games using the NEC CDR-1901A drive lately, and to my surprice it is working byfar the best compared to all other drives I have tested, dumping starts right away always.. and mostly I can dump scratched games on 8x speed and completely new discs at 16x speed.. my drive that I have suffers from a tiny mechanical failure though (Needs to put the disc in many times before it loads it up), so I have ordered a new one aswell, these drives are beginning to be realy old my drive that I have right know is from 1998.. they are very cheap on ebay in general aswell which is a big + ..

Lite-On SOHD-167T, NEC CDR-1901A, Plextor PX-712A, PX-716A, PX-760SA, Samsung TSSTCorp SH-D162D.
:: www.rawdump.net :: 2448 byte CD Preservation ::

gorelord4e's Website

  • Registered: 2011-03-23
  • Posts: 56

Dreamcast HIT-0400 Jap Broadband tutorial dumping:
http://forum.redump.org/topic/8558/gdro … -by-gdrom/


Note: GD-ROMs with a single high density track only, Track02 still needs to be dumped with a standard drive !!!

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

As I posted in the other thread...

Another solution could be the SD adapter and tools to dump HD area.
If someone wants to try something, here are a pair of links
http://f17.aaa.livedoor.jp/~takotako/dc … php#sdcard ---> How to and tools (Japanese)
http://item.taobao.com/item.htm?id=7818275499 ---> Chinese seller for a ready to use adapter
Tolls can dump full disc as I understand so if it dumps it raw I think it could be parsed by ICE. Someone with knowledge could try to edit source code of that tool to dump all HD area in raw audio.

My patch requests thread
--------------------------------
  • Registered: 2011-06-26
  • Posts: 70

I have this adapter !
I dump several game with it, all except 2 games (for now) are identical to your Db.. But I suspect bad sectors into SD card.

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

TailS_tff wrote:

I have this adapter !
I dump several game with it, all except 2 games (for now) are identical to your Db

Both data and audio tracks?
So it takes correct gaps?
You don't have to fix anything manually to get same checksum of our DB?
Can you provide infos about the games that don't check DB?

My patch requests thread
--------------------------------
  • Registered: 2011-06-26
  • Posts: 70

The SD method can rip first and second session tracks, both audio and data.
(Data in bin, audio in raw)
All games match, except floigan brother and SonicAdv2 : I try to dump floigan about 8 times, always the same hash (on different sd card) and the game was purshased on 2008 and factory sealed.
Otherwise nothing have to be manually fixed to match with your DB (for others games I've try).

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

If those 2 aren't matching they are most likely different versions?

  • From: Hyrule
  • Registered: 2008-01-16
  • Posts: 1,440

TailS_tff wrote:

The SD method can rip first and second session tracks, both audio and data.
(Data in bin, audio in raw)
All games match...

Just to be sure:
So it takes correct gaps for audio/data tracks?
You don't have to fix anything manually to get same checksum of our DB?
You got exactly the same tracks checksum on tracks freshly dumped?

As Jackal said the other discs could be different revisions, you can see it in the header.

My patch requests thread
--------------------------------
  • Registered: 2011-06-26
  • Posts: 70

Jackal : I search on google md5 or sha1 but without succes.
Rocknroms : yes, there is nothing to correct to extact match with DB.
Exemple : I just dump SAdv JAP (HDR-0001), here the result :

file info.txt :
SEGA SEGAKATANA
SEGA ENTERPRISES
72A3 GD-ROM1/1 
J       0781A10
HDR-0001  V1.007
19981210       
1ST_READ.BIN   
SEGA ENTERPRISES
SONIC ADVENTURE

file track.txt :
[SONIC ADVENTURE]
no type   start(physical)  size    MB
session 1:
1 RDATA      0 (   150)  11705   27M
2 AUDIO  11855 ( 12005)    866    2M
session 2:
3 RDATA  45000 ( 45150) 504150 1185M
-------------------------------------

track01.bin:
C58B5D08
1824BFA6A7670CDCBA15526D0FC21376
3723997027355996F4E281CA373163400E900D10

track02.raw:
4ABDA3D9
32320AB58B40F44E66694DB64D2A7CF5
34AFDB35D2D6B05995B24580DB657F671C31052A

track03.bin:
4E7E341A
DFA7A7DF2B6C22128F3AFE4697CC4433
C98509D77792BE67791B15F762A2019AA85CFBBA

track02 seems not to be matching with redump DB but it was found on dumpcast DB, ring code was different from you (HDR-0001-0017 1MM1 C 8Z)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

That one must have a different write offset, so audio is shifted compared to the other ring.

Could you post the headers of SA2 and Floigan Brothers?

  • Registered: 2011-06-26
  • Posts: 70

Here for MK-51114-50 - FLOIGAN BROS. EPISODE 1 MOIGLE'S SECRET PROJECT - PAL-E :

Ring: HDR-0001-0017 1MM1 C 8Z

disc.gdi:
5
1 0 4 2352 track01.bin 0
2 756 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0
4 314080 0 2352 track04.raw 0
5 314681 4 2352 track05.bin 0

info.txt:
SEGA SEGAKATANA
SEGA ENTERPRISES
6093 GD-ROM1/1 
  E     0799810
MK-51114  V1.002
20010920       
1ST_READ.BIN   
SEGA ENTERPRISES
FLOIGAN BROS. EPISODE 1: MOIGLE'S SECRET PROJECT

track.txt:
[FLOIGAN BROS. EPISODE 1: MOIGLE'S SECRET PROJECT]
no type   start(physical)  size    MB
session 1:
1 RDATA      0 (   150)    606    1M
2 AUDIO    756 (   906)    526    1M
session 2:
3 RDATA  45000 ( 45150) 268930  632M
4 AUDIO 314080 (314230)    451    1M
5 RDATA 314681 (314831) 234469  551M
-------------------------------------

track01.bin:
CAC5A9CC
2118799A81F481BD40ED433E8846F9CA
00A4890BE3B86DABAF79D58B7073B71C83EE8DDC

track02.raw:
48FFF429
87AF6D21A8B10AEFFB90874118531E29
B0D28980A64765C022B4B3E47244AAD32A345270

track03.bin:
69F8C299
81B3CDC5AB89DB8237A8F9277AA95917
D6B060ED19D0C6559CB94972789F4073DA9E3993


track04.raw:
CRC32: A44276F4
MD5: 3A892DB029C4B1BA6ED24CCDAF5CFF62
SHA-1: 36B69EE3A5DD70637228FEAA14528AC23F848EE7

track05.bin:
CRC32: F9AA8AB4
MD5: C2B0F9049D1018E9030B181323FD51A7
SHA-1: 3680A9ACC58A717DF2415BF8ED32FDE9BB9436F1

SA2 will follow soon

  • Registered: 2008-09-26
  • Posts: 875

That's easy. Your dumps match dumpcast perfectly, which means that only your tracks 1 & 3 can possibly match redump (since they're identical on redump and dumpcast). Dumpcast uses a different gap layout and offset handling.

Therefore, all your tracks are missing the factory offset correction. Additionally, track02 is missing the 352800 bytes (2 seconds) pregap. Furthermore, your track05 pregap is 1 second smaller than it should be.

I don't want to imply anything, but it's completely impossible that all your other dumps matched redump, unless you used different settings for Sonic Adventure and Floigan. The fact that they match dumpcast proves that your gap handling is completely different than redump's smile