Moreover, in your process you're forgetting to run the data tracks through CDMage to confirm correctness - something which wouldn't be necessary at all if you only dumped the MODE1/2048 user data.

We are not forgetting anything - some discs have mastering EDC/ECC errors which shouldn't be fixed (either accidental or intentionally made by the developers). Not only PSX, but even some Sega CD discs have these errors, so by ripping data tracks in cooked mode or fixing them with CDmage you'll lose data.

Now the thread can be closed.

You read my thoughts. This discussion is getting out of hand.

I respect Eidolon's/Snake's input to this matter. We should all wait until they come with a tool to postprocess the cdrwin output data before we can do any real comparisons between both methods. I hope they can also let this tool check if the last audio sectors indicate if the data is cut off.

Because there is no such tool yet, my current conclusion is that our method is still the most reliable one, because EAC will warn you when there is a problem and data is cut off. CDRWin doesn't do this, and there is no supplementary tool yet that does. And this has to be automated, because you can't expect people to manually check each disc to see if there's any data cut off. Also, keep in mind that if a drive doesn't support overreading, the dump should at least be verified using 2 drives. I'm not sure if at the end the CDRWin method will be any faster. I'm looking forward to the results.

Topic closed.

I disagree. Even on a "bad drive" as I seem to have, CDRWIN dumps give you EXACTLY THE SAME RESULTS and EXACTLY THE SAME METADATA (write offset value) as the redump method. Of course, only for the unproblematic discs (the ones where the last audio track doesn't run into the lead-out).

Moreover, in your process you're forgetting to run the data tracks through CDMage to confirm correctness - something which wouldn't be necessary at all if you only dumped the MODE1/2048 user data.

Also, none of your dumpers have proven to me that EAC is "more accurate" than CDRWIN (see my Burai ripping experience - EAC was even less accurate with my bad drive).

But as a conclusion:

Apart from bad discs (as Snake said, easily identifiable through their non-zero data at the end of the resulting BIN file), there is no reason at all to use the complicated ISObuster+EAC method outlined in the redump guide!

You can simply dump the CD twice with CDRWIN, and if the resulting BIN files match you can be reasonably sure that it is a good dump.
After that, you check if the resulting dump contains an ample amount of 00's at the end. If it does, you have a good dump.

Concluding:
-you can dump the way you like
-we care about offsets and having full audio
-we won't change our dumping method
-we think our dumping method is better
-everybody is happy

Basically, we're at the same point we were 3 days and 60 posts ago. Good luck with your work

Now the thread can be closed. It should be linked to whomever comes here in the future and asks why we don't want CDRWin

2Eidolon:
Didn't want to make any comments - I thought you would understand that your method is wrong after a couple of answers from our dumpers. Looks like I've been mistaken...
I see absolutely no point in using Cdrwin. It offers no benefits comparing to the current method. Dumping using EAC takes less time and is more accurate. And Cdrwin can't even properly dump audio - this should be quite enough to stop anyone from using it in attempt to make perfect dumps. It is just a waste of time and efforts.

I disagree. Even on a "bad drive" as I seem to have, CDRWIN dumps give you EXACTLY THE SAME RESULTS and EXACTLY THE SAME METADATA (write offset value) as the redump method. Of course, only for the unproblematic discs (the ones where the last audio track doesn't run into the lead-out).

Moreover, in your process you're forgetting to run the data tracks through CDMage to confirm correctness - something which wouldn't be necessary at all if you only dumped the MODE1/2048 user data.

Also, none of your dumpers have proven to me that EAC is "more accurate" than CDRWIN (see my Burai ripping experience - EAC was even less accurate with my bad drive).

But as a conclusion:

Apart from bad discs (as Snake said, easily identifiable through their non-zero data at the end of the resulting BIN file), there is no reason at all to use the complicated ISObuster+EAC method outlined in the redump guide!

You can simply dump the CD twice with CDRWIN, and if the resulting BIN files match you can be reasonably sure that it is a good dump.
After that, you check if the resulting dump contains an ample amount of 00's at the end. If it does, you have a good dump.

Didn't want to make any comments - I thought you would understand that your method is wrong after a couple of answers from our dumpers. Looks like I've been mistaken...

I see absolutely no point in using Cdrwin. It offers no benefits comparing to the current method. Dumping using EAC takes less time and is more accurate. And Cdrwin can't even properly dump audio - this should be quite enough to stop anyone from using it in attempt to make perfect dumps. It is just a waste of time and efforts.

(Your Burai disc for instance. It doesn't have 100% track quality everywhere, does it still give the same 'intelligent' audio checksum as EAC?)

That is a good question. I will check that.

Of course it would be nice to have a faster and more reliable dumping method, but I don't see how an obsolete tool like cdrwin (can it even detect proper gaps?) can improve things.

I wouldn't call CDRWIN obsolete. It is an actively maintained program just as Isobuster and EAC are. And my comparison proves that in theory it is easy to convert a CDRWIN dump to the REDUMP format (and vice versa), because the offset value you get from your Isobuster-clicking-around-between-tracks-1-and-2 is easily calculable with the CDRWIN dump. From that, you can derive the write offset.
It seems noone here in this community has bothered to actually check out CDRWIN properly (maybe my statement is a little premature, let's give your other community members some time to answer...).
And hey I'm NOT working for Goldenhawk technology, before anyone asks...

How much time you save in the end depends on the availability and intelligence of the analysis tool I outlined. Of course, the redump disc submission process may have to be adapted as well in order to parse different files.

Correct.

Depending on how my research goes, the first step towards that that could be a one-click CDRWIN image dump, plus running it once through that "analysis tool".

Of course, one single tool would be better.

Yeah, let's all keep open minds on the matter.

We disagree on the importance of RAW data for systems which don't need it, and the practical importance of normalizing the audio data offset using measured/calculated read/write offset values.

But we agree on the importance of not losing data, have proper pregap detection (ensures proper start of audio tracks) and of individual track checksums to be able to make comparisons.

That's enough common ground, I say.

If I find out that there is an easier way to achieve the same goals, and it can be proven that it works just as reliably, and it even provides the same results and checksums as the REDUMP method (and thus could be used to submit data to both redump, tosec and whatever else) why not pursue it?

TOSEC won't change their dumping method. Why would you care about submitting data to them if almost all of their dumps are flawed? (isn't that what we agreed about?)

Of course it would be nice to have a faster and more reliable dumping method, but I don't see how an obsolete tool like cdrwin (can it even detect proper gaps?) can improve things. Even though I like the results of your test, I would still like to see a time comparison that includes splitting the tracks and creating a proper cuesheet etc. until the output it identical to Redump's. Besides, you will always need a drive that supports certain features (overreading, etc) if you want to be sure that the output is correct. I'm still waiting for the PerfectRip successor myself. In the meanwhile, I'll keep my eyes open for an improved method from you and Snake.

Like in every discussion, when I get new information (like the comparison I did yesterday between Isobuster+EAC and CDRWIN methods), I have to question again the premise of the REDUMP guide.

For the new questions I have posed now (especially pregap detection), I still did not get sufficient answers, but hope to get them.

I have understood your goals now (or I think I do)
- treat all CDs equal, i.e. RAW mode dumps not caring wether its MODE1/MODE2/CDI/whatever, to have the guide as simple as possible
- normalize audio data by adjusting for the read/write offsets and shifting them in the track dump accordingly
- store data and audio tracks in seperate files and checksum them seperately to provide comparability between different game releases
- anything else I forgot?

If I find out that there is an easier way to achieve the same goals, and it can be proven that it works just as reliably, and it even provides the same results and checksums as the REDUMP method (and thus could be used to submit data to both redump, tosec and whatever else) why not pursue it?

Please understand I am not trying to "rip apart" (no pun intended, hehe) the redump.org project, I am merely joining the discussion.

It's not a matter of choice, it's a matter of how to collaborate.

We gave you PLENTY of reasons why Redump.org method is preferable to others, in IRC, Redump forums and your own forums. Now that you know these reasons, you only have to decide. You're in the dumpers category now, if you want to submit dumps here I'll be the first being happy, if you choose another way fine, I wish you good luck, but we won't support what we consider an inferior method. If settling to an inferior method was fine to us, we would have settled to dumping for TOSEC ages ago. At the time I didn't consider TOSEC to be a good way and I waited 'till Redump.org gave me the opportunity to do thing the better way. I had to choose too.

As I told you in IRC, for the love of God I only hope all of this isn't an emu politics issue. Maybe you want your own project to attract people to your community, I'm cool with that, but even if you decide to keep the dump info on your site only, I think it would be better to follow Redump.org method. We won't "steal" anything. Using CDRWin only to have it "your own way" sure isn't beneficial to the community.

here, i did some more math:
name|offset(bytes)|silence(b)|difference(b) -you'll miss that on 0 offset drive
nostalgia|7800|1864|~6k
sangokushi 3|3880|1344|~2.5k
jangou w c|19|lucky
cosmic fantasy|7208|676|a lot
gambler j.|1823*4|1760|4x
...i just walked up directories sorted by serial skipping winning post...

Too bad, I don't have any of these games to test them with CDRWIN. Would be nice if one of you could check and see if CDRWIN really cuts of the last audio data bytes, or simply reads a few sectors into the postgap until there are only zeros.

@Snake.. I understand from your posts on Eidolon's Inn how offsets aren't really important for your projects, but you have to understand why they are important to us.

First of all it's for documentation. We like the idea of having the audio tracks put back into the position they were before mastering. Even though in the end it only comes down to a few shifted bytes, if you split dumps into separate tracks and store them this way, there can be great benefits to it. For instance for 600mb games with 550mb of identical audio tracks, you can just get the data track and import the audio from another file, without even having to touch a patch tool.

If we would be using TOSEC's method we wouldn't be able to know if a 600 mb game has 550 mb of identical audio in the PAL version compared to the NTSC version (example: http://redump.org/disc/469/ + http://redump.org/disc/475/). Of course you could try to make a patch, but you loose some insight on how these dumps actually differ.

You could just assume that all dumps are different if the disc isn't exactly the same, but at the end that won't help you (at least not if you want to store the cd-images of the dumps somewhere), and here's why: There are plenty of games that only have one difference: the offset. If you would dump these games using TOSEC's method, you would have 2 separate dumps and need 2 dump entries. Using our method there's just 1 dump and 1 entry: http://redump.org/disc/447/ http://redump.org/disc/1777/

If you're planning to include 'intelligent checksums' for both data and audio in your database then I guess you will have the same advantages as our method for games where all audio tracks are identical, but there are also a lot of games where 1 or 2 audio don't match and all the others do. This is why we prefer offset correction and separate tracks. If you don't care about seeing the similarities between two dumps, you can just go ahead with your proposed method, but if you're planning on keeping the cd-images or spreading them around OR if you decide to care about showing people the similarities between dumps, you now know the advantages of our method.

It's not about good or bad. If you actually pay attention to the offsets instead of ignoring them, you are able to remove all the irrelevant differences between a dump and get an ideal dump. Let the offsets help you by separating them from the dump and by storing them as values, not by ignoring that they are there! (the factory write offset is a relevant piece of information about the CD that should be stored in the db).

All tracks have a factory write offset. The only difference is that you don't see them on data tracks, because data isn't read in audio mode (you can still do that and detect the write offset for information purposes using this method: http://forum.redump.org/viewtopic.php?id=2057). The point I'm trying to make here is that what we are really doing here is treating audio the same way the drives are treating data (by removing the offsets that aren't affecting the data track).