1 Topic by HwitVlf (edited by HwitVlf 2010-05-03 02:40:25)

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

I'm trying to figure out how to dump CDs with multiple tracks by dumping a copy of Tomb Raider GH (PS1) and matching my results against the redump's database to ensure I'm doing it right. But I have a few questions.

What does psxtool's "fix" command actually do? (I like to understand what I'm doing rather than just follow the steps.)

Is there any definite way to figure out if my drives supports 'over-reading'?

On one of my drives (SONY CD-RW CRX215E1), if I use ISOBuster to 'view sectors' and go backwards from the beginning of track2 to find the end of tack1, initially I see the correct amount of 'garbage' data at the end of track1 (Tomb Raider is +2, the drive is +6, so I see +8 total 'garbage' aka 32 bytes- if I'm thinking correctly). But, if I go back one more sector (to where I'm looking at the data track1) and then go forward again, ISOBuster shows more that 1 sector of garbage data in the same sector that only had 32 bytes a moment ago. Animation below is actual screen shots. Is this normal?
http://i22.photobucket.com/albums/b324/weissvulf/Error.gif

On Tomb Raider (USA- Greatest Hits v1.2), ISOBuster shows the last track (57) having a size of 34,750,800 however my drive dumps 35,103,600 (and redump's database also lists 35,103,600). Is it normal for ISOBuster to report the last track's size incorrectly?

I tried dumping Tomb Raider on two different drives and all the tracks turn out correctly except the last one. EAC doesn't report any errors and my dump's size matches what Redump's database says it should be, but the crc doesn't match. Could I be doing something wrong that's making only the last track dump wrong?

If the CRC mismatch is likely because my drives don't support overreading, can anyone recommend a DVD drive model currently available (from Amazon/Newegg etc) that does support overreading?

One of my copies of Tomb Raider GH isn't listed in redump's database; if I am having an overread error, is there any way to manually fix the last track so I can catalog the new version?

Thanks smile

HwitVlf's Website

2 Reply by Specialt1212 (edited by Specialt1212 2010-05-03 02:59:16)

  • Registered: 2009-05-03
  • Posts: 344

It funny that you mention this because I recently redumped my copy of Tomb Raider and it showed me as having some EAC errors but not on the last track.... anyways even with the errors mine matched the database entry exactly so I'm not sure whats going on?

I dumped it using my HL-DT-STDVD-RAM GSA-H55L Drive

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

Specialt1212 wrote:

It funny that you mention this because I recently redumped my copy of Tomb Raider and it showed me as having some EAC errors but not on the last track.... anyways even with the errors mine matched the database entry exactly so I'm not sure whats going on?

I dumped it using my HL-DT-STDVD-RAM GSA-H55L Drive

Track quality of less than 100% aren't errors.. the dump is fine

What does psxtool's "fix" command actually do? (I like to understand what I'm doing rather than just follow the steps.)

In some cases, the last sector can't be dumped correctly for whatever technical reason, so it's replaced with the correct sector, the same one you would get when dumping scrambled and then unscrambling to circumvent these hardware errors.

..Animation below is actual screen shots. Is this normal?

I guess it is, but that's why we go to this sector from the right side. Just do it as it's described in the guide.

Is it normal for ISOBuster to report the last track's size incorrectly?

IsoBuster has a gap of 352800 bytes appended, so the size doesn't match Redump yes.

If the CRC mismatch is likely because my drives don't support overreading

That seems to be the case..

if I am having an overread error, is there any way to manually fix the last track so I can catalog the new version?

I think someone posted a method with clonecd here some days ago, but I'm unable to find it, so I hope someone can link to it

can anyone recommend a DVD drive model currently available (from Amazon/Newegg etc) that does support overreading?

No idea.. but Specialt1212 bought a cheap Plextor, as did many people, also ones in the US. I guess they got it off ebay, but not sure. Most people don't care about the newer drives, because Plextor is the best brand and they don't make new models anymore.

4 Reply by amarok (edited by amarok 2010-05-03 14:03:17)

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

Jackal wrote:

I think someone posted a method with clonecd here some days ago, but I'm unable to find it, so I hope someone can link to it

I believe Jackal is referring to this topic. That CloneCD method won't work, though, it just prevents EAC from showing a sync error in the overread sectors. That doesn't mean it can actually access any data in the overread sectors. If you are lucky you'll get a match, but only in case the overread sectors are all 00s. Therefore, you can never really be sure whether you've lost any data!

However, that IsoBuster method proposed by velocity37 might actually work. I didn't try it yet but it does sound promising for drives that support it. It's still quite intricate so you should rather buy a decent drive. A Plextor PX-716A is usually quite cheap here on eBay.

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

Thank you all for the great help! I understand what I'm dealing with a lot better now.

If the Playstation's drive can accurately read the last sector, I'm surprised there was never a copy protection scheme that put part of the game's code at the end of the CD to make it inaccessible to many PC drives.

I think I found a drive in my 'stockpile' that supports overreading. It can view past the last sector in ISO buster without any problems and it will dump the last track of Tomb Raider in EAC without any errors. BUT, my dump of the last track still doesn't match the CRC listed in the database. This is especially surprising since it appears to be a totally blank track (all 00) and my dump's size matches the database (seems like the CRC would match too if they're both blank). I tried velocity37's method using ISO buster but just ended up with a track identical to EAC's dump (ie doesn't match database's CRC).

If someone has a few extra minutes, could they send me a copy of track 57 (last music track) from any Tomb Raider game (all versions seem to have identical track 57 except the Japanese version) so I can see what I should be dumping? Since it's mostly 00s, it should compress down to practically nothing and be easy to send.

The new version of TR seems to fall in between the (USA) v1.1 and v1.2 based on the dates on it's files and I've successfully dumped all it's tracks except the last. It would be a shame if I can't add it to the database because I can't get the last track dumped correctly.

HwitVlf's Website

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

Sure, here's the track: http://hotfile.com/dl/41109282/9e8d3e6/ … 7.rar.html

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

Thanks smile  I'll see what I can figure out using it as a reference.

HwitVlf's Website

8 Reply by HwitVlf (edited by HwitVlf 2010-05-04 02:34:53)

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

Ok, I figured out the issues and think I can get it right now.

For some reason, EAC is not properly dumping the last sector even though my drive does support overread. Tomb Raider has a single 1A byte (rest are all 00s) in the last sector of the last track and EAC dumps it as 00. I'll double check my EAC settings against the tutorial again, but does anyone know of a setting in EAC that could cause this to happen?

I finally got it right using velocity37's method with ISOBuster. I failed the first time because I was trying a new hex editor and it was displaying 18 bytes per line instead of the 16 I was used to- so I was deleting the wrong number of bytes- me stupit sad

Thank you everyone (amarok, the comparison file really helped!)

HwitVlf's Website

9 Reply by amarok (edited by amarok 2010-05-04 02:56:21)

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

HwitVlf wrote:

For some reason, EAC is not properly dumping the last sector even though my drive does support overread. Tomb Raider has a single 1A byte (rest are all 00s) in the last sector of the last track and EAC dumps it as 00. I'll double check my EAC settings against the tutorial again, but does anyone know of a setting in EAC that could cause this to happen?

Make sure to check "Overread into Lead-In and Lead-Out" in "Drive Options -> Offset/Speed" and specify the correct read offset sample correction value (i.e. the amount of samples you determined via IsoBuster's sector view for track 02). Other than that there aren't any offset-related options you could change.

To check if your drive is actually capable of overreading with EAC, try the following: Go to the EAC Options (F9), choose the  "Extraction" tab and uncheck "Fill up missing offset samples with silence". Extract the last track again. If EAC fails to read the offset samples, the resulting file will be a few bytes smaller than it should be. In that case you cannot use EAC to dump the last track. You'll have to do it manually with IsoBuster instead.

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

I keep getting an "Error parsing datfile" when I try submitting through the New Disk form.
Below is the format I've been trying to submit:
    rom ( name track01.bin size 310941456 crc 0x33e54465 md5 0xbcfb31943099884a7b96b25b238c6742 sha1 0x61b8e6e134036806c09fa55d1904a850500c1d0b )
    rom ( name track02.bin size 34675536 crc 0x3561d9d7 md5 0x4d9b29532bf6f167fe02bece59baef3b sha1 0xe55d5a6cccd78b87d885c63ff736d300a881af8a )
. . .
    rom ( name track57.bin size 35103600 crc 0x7d46743f md5 0xece4ee4bd7df81a2b2fe09926ab9b67f sha1 0x67f6e8792b15f581d256f99eed66cb724dddb329 )
)

What format should the info be in?

Also, EAC created a CUE sheet with a bunch of information that isn't normally in redump's cues. Is there a way to get it to produce a cue that is closer to what it's supposed to be?

HwitVlf's Website

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

HwitVlf wrote:

What format should the info be in?

That one you used, but without "0x" before all hash values

HwitVlf wrote:

Is there a way to get it to produce a cue that is closer to what it's supposed to be?

You can use EAC created cue sheets to submit them via WIP, they will be parsed properly, the only change you need to do is, to replace MODEx/xxxx with a proper value. The second part is always same = 2352, data type depends on system and/or pressing:

MODE2/2352 -> PSX / PS2 / CD-i / ...
MODE1/2352 -> SAT / SCD / 3DO / DC / Amiga / ...

Systems with "liquid" data type are IBM PC and MACINTOSH (mac is not confimed)

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

Thanks! I got the submission form to work.

HwitVlf's Website