[SOLVED] Help dumping PSX games with audio tracks.

[Jackal]

EAC is known to work in Wine, but i'd rather stick to native/free software if possible.

Well, there's your problem.. You're not using the appropriate tools.. Rubyripper appears to have problems.. Perfectrip won't do you any good without a plextor drive.. So your only real option is Wine + EAC.. Then there's also the trurip 0.43 source code but I don't know if it has all the files that are needed for compiling into a native linux binary (I don't think anybody else has tried it yet): http://vigi.dremora.com/trurip_v0_43_alpha_source.rar

[pablogm123]

It seems that EAC is the only realistic option, and another program to extract the data track.

Generally speaking, there is no way to determinate the exact write offset of pure audio CDs, because audio lacks of syncs header. However, it is possible that many audio CDs have -12, 0 and +222 write offset. I own two CDs protected by Key2Audio, which has scrambled data sectors in pregap of first track, but marked as audio, and I have to apply -12 write offset so that scrambled sectors are aligned. Also, I have CDs whose non-zeroed sample is the last of image with 0 write offset, and other with a data track, with +222.

The clever approach is apply standard offset correction of AccurateRip, and apply a customized offset correction only if needed to rescue non-zeroed samples pushed to lead-out zone or pregap zone. For example, the miniCD bundled with Tenbu - Mega-CD, the correct offset correction to apply is the standard + [+13].

[MikuroK]

Alright, I've installed and setup EAC, dumped track 2 with my SOHW-1213S.

It matches.. but EAC put the pregap at the *end* of the track, I looked around but couldn't find a way to make it preprend gaps (how does this even happen when I don't let it detect gaps?).

I verified it by stripping 2 seconds from the end of the track, appending 2 seconds to the start, then checking the md5.

The drive supports C2 error reporting, so that's nice.

[pablogm123]

But very likely caches audio, and that slows down the secure ripping of EAC. The ideal is a drive which doesn't cache audio data and reports C2 errors, or a real Plextor drive which can use FUA to defeat fastly and easily the drive cache.

You have to detect gaps (F4 hotkey), and after detect gaps choose append gap to next track. Try the three modes of detection offered by EAC, and choose the one which is faster and detect proper and expected gaps.

[MikuroK]

Yes, it caches audio, but it's going at ~6.4x, which is fine with me.

I found the setting you mentioned a moment ago, and so far things are going well, but track 2 still has the pregap at the end of the file.

Edit: finished the disc, tracks 2, 13, and 14 are non-matching, less than before, but 2 is only wrong because the pregap is in the wrong place, and it somehow messed up 14.. which is a blank track...

[pablogm123]

What gaps are detecting EAC? The vast majority of PS1 discs has only 2:00 pregaps.

[MikuroK]

What gaps are detecting EAC? The vast majority of PS1 discs has only 2:00 pregaps.

All 2 seconds, same as the DB

I edited my last post, you might miss it since we're on a new page, now

edit: actually.. it shows a 2sec pregap on the data track, but the db shows 0sec

[pablogm123]

The DB ignores the standard and imperative pregap, of at least 150 sectors, of first track, which separes lead-in zone from program area.

http://img22.imageshack.us/img22/6715/pregaps.png Have your disc the same layout?

[MikuroK]

The DB ignores the standard and imperative pregap, of at least 150 sectors, of first track, which separes lead-in zone from program area.

http://img22.imageshack.us/img22/6715/pregaps.png Have your disc the same layout?

Looks like the same disc.

[pablogm123]

You are getting CRC mismatches. Try ripping without C2 pointers, because EAC cannot handle very well: It uses on first read in order to not to read everything twice and defeating the cache, but once detected an error, EAC re-reads without taking into C2 pointers, and fails to detect constant errors which C2 pointers would detect, because a suspicious zone could return, at least 8 of 16 tries, the same erronous data. The Achilles' heel of EAC and C2.

Redump doesn't support this, in no way, but for your personal dumps you could try to rip in burst mode, playing with the read speeds. In a few of cases, burst mode works better than secure mode with these Lite-On drives.