Search options (Page 4 of 6)

I still don't see how raw dumping has to contain errors. Eidolon today matched a dump of mine the first time he dumped it. And he probably never used EAC. Dumps I made for both SegaCD and PC matched no problem, even if the discs and the drives are from totally different parts of the world.

Of course there's a probability to get errors, but if the probability to get errors with cooked sectors is 2%, and the probability to get errors with raw sectors is 3%, it doesn't change much. If you compare, cart reading failure is around 15%, yet that didn't stop us (No-Intro) in our cart dumping process.

Note that:
- every dump will need a successive verification anyway, which would sweep away the probability of error; the verification process has to happen no matter the method, even if we'd dump using carrots as disc readers
- as I said cart reading has a much bigger rate of failure than any CD reading method; note that the principle of dumping carts is to read them at least 3 times each, which is more than we require for CDs; CD dumping is relatively safe, and as much safe in raw mode as it is in cooked mode

AFAIK the pregap is there to give the drive the time to start spinning and gain full speed before reading data, if the drive reads a track from a disc not at full speed there's a chance it misses the initial data. The gap is a no-data slice of time in which the drive prepare itself to reading.

So the gap is functional to the track who follows it, not the track that comes before it.

That's the point of gaps. If there was no such problem we won't have gaps between tracks at all today.

Even old magnetic tapes had gaps between sectors who had the same function.

I like your researches. But...

Problem is that once you start memorizing the procedure, the IsoBuster+EAC procedure we follow now takes so little time that it makes the switch to CDRWin useless, because there's no real saving of time when you learn the passes and do them automatically.

Probably today it took you much time to dump a single disc, but what you did in half an hour I can do in 7 minutes:
-1 minute finding offsets
-1 minute ripping data track and resizing it
-5 minutes ripping audio tracks

Basically the same time you spend with CDRWin ripping and then shifting the data till you find the correct position.

I guess someone already said it, but there's not real time saving in using CDRWin, and you risk to lose data with it.

You only need to get practical with the dumping procedure. I wasn't fast at dumping at first either.

I never had problems making my dumps working in Kega, but I load the cuesheet in Daemon Tools first and run the dump directly from them as I would with a real CD, through Kega "Boot CD drive" function, I don't use Kega internal parser.

Choose your answer:
-to achieve consistency between systems
-to get full raw dumps (data+audio) and not frankenstein dumps
-because if you really hate raw dumps you can convert them later but you can't do the other way around with 100% reliability
-because dumping raw takes only 10 seconds more and not 10 hours

Another thing, even if you don't have the time to rip CDs the byte-perfect way, maybe someone in your community would have no problem doing it, IMO it's a way to force them to settle for an inferior dumping method, without letting them choose. You could tell your community members that there are alternatives like PSXDB who strive for a greater level of accuracy. After all cart dumps users are accustomed to perfect dumps, why would you force your community to renounce to them?

Finding offsets and dumping CDs with EAC takes me the same time of opening and dumping carts... 5-10 minutes of waiting haven't been a problem for the last 10 years of worldwide cart dumping, why should they suddenly become an unbearable wait now?

And it's not an ease of emulation matter either, PSXDB rips works perfectly under Daemon Tools and Kega

Same thing it happened to me when dumping 2-tracks SegaCD games, it's cd-rom drive fault, you can add the pregap manually, just be sure to check that total sector number of the dump matches total sector number of the actual disc (with IsoBuster).

PCE first tracks are doubtful too. They have 3366 sectors when they come before a 2.74 gap, and 3365 sectors when they come before a 3.00 gap. Aren't those first tracks all the same audio sample? They should be all either 3366->2.74 or 3365->3.00.

The way it is now is strange.

And what about Human Sports Festival 2.74 data tracks pregap? That a 99,99999% 3.00 pregap misjudged by EAC.

I'm really starting to think we must edit those strange MegaCD and PCE gaps by hand. Why would we have to keep clearly wrong info in the database? Whoever is going to dump discs has to post them here or as wip first anyway, so we can pre-check their new info before confirmation.

EAC guys seem nice, but I'm pessimist by nature and I think there's no real chance EAC errors will be corrected, since EAC gap detection algo has been the same for many years and I don't think they're going to change it now.

The console discs we dump here are funky exceptions to the rule, as you said it's a matter of strange mastering, and EAC was born primarily for plain old audio CDs, not to dump funky exceptions.

And your posts on EAC forums have gone unanswered for weeks now.

The dumps match, I hope Dremora will make the PCE section public so everybody can see it

Only Human Sports Festival. That's the only disc I have.

http://www.rfgeneration.com/cgi-bin/get … -S-00230-A

No! I only said that track2 should have 2.00 pregap because you said that the end of the data track was 150 sectors back instead of 75 sectors back like EAC reports (isn't it what you said?)

The following audio tracks can have a different pregap than 2.00. I see many 1.74 and a few 1.73 in your dump, it would be better to double-check with PerfectRip, if you can't use PerfectRip then we have to keep EAC pregaps.