Redump Forum

The dumps Themabus and I verified together had no such problems at all, and they're full raw dumps. Our dumps matched perfectly, and we live thousands of miles from each other using completely different PCs and CD-rom drives :B

You can see them all in the Mega-CD section.

gigadeath wrote:The dumps Themabus and I verified together had no such problems at all, and they're full raw dumps. Our dumps matched perfectly, and we live thousands of miles from each other using completely different PCs and CD-rom drives :B
You can see them all in the Mega-CD section.

That is fine - but it doesn't answer my question! WHY dump the raw data if it is not user data?

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

gigadeath wrote:-to achieve consistency between systems

You consistently dump RAW data tracks for every system, but you do not consistently dump just the user data for every system.

gigadeath wrote:-to get full raw dumps (data+audio) and not frankenstein dumps

I would not consider calling the audio data RAW, because in case of audio data, RAW data is really the user data. In case of data tracks, RAW does not equal user data.

gigadeath wrote:-because if you really hate raw dumps you can convert them later but you can't do the other way around with 100% reliability

I don't "really hate" them, I just question their usefulness for systems which do not require the EDC/ECC data as user data. For these systems, it just produces data overhead and increases the chance for getting bad dumps as explained in my previous post.

gigadeath wrote:-because dumping raw takes only 10 seconds more and not 10 hours

See above, usefulness and data overhead.

I can't compel you to dump raw data, you can do as you wish. Who put up this site made the choice to have full raw dumps for every system, a choice I agree with. Even if there are empty sectors, there's consistency for the whole dump lenght. And as I said, you can convert raw dumps later but you can't do the other way around with 100% reliability. It's a strong reason to me.

Then it's up to you. I think the line followed by Redump.org won't be changed.

I think the most important reasons for dumping data tracks in RAW 2352 are:

- no Frankenstein dumps like gigadeath said.. the full main channel is dumped.
- you can easily combine the tracks of a dump that were done using the Redump method into a single image using copy /b. Then you have a proper image of the complete cd with correct gaps and offset. This wouldn't be possible with 2048 tracks without converting them to 2352 first.
- the extra error correction data can be used to verify that the track data is correct (without having to dump the track twice).

I really don't know why 2048 would be better than 2352 (it's smaller yes, but what else?). Maybe you could include both 2352 and 2048 checksums in your database, but this would only take you more time.

Vigi wrote:I really don't know why 2048 would be better than 2352 (it's smaller yes, but what else?). Maybe you could include both 2352 and 2048 checksums in your database, but this would only take you more time.

That would be a feature request to ClrMame then, wouldn't it...

Eidolon wrote:

gigadeath wrote:-to achieve consistency between systems

You consistently dump RAW data tracks for every system, but you do not consistently dump just the user data for every system.

redump.org doesn't "just dump the user data" for any system, so it's a null point. If they did, it will have to be looked on a case-by-case basis on weather a system and/or game needs the extra data. Dumping the raw sectors for anything and everything is simple; the rules don't change for different systems or games.

Eidolon wrote:

gigadeath wrote:-because if you really hate raw dumps you can convert them later but you can't do the other way around with 100% reliability

I don't "really hate" them, I just question their usefulness for systems which do not require the EDC/ECC data as user data. For these systems, it just produces data overhead and increases the chance for getting bad dumps as explained in my previous post.

I have no idea where you got the idea that it increases the chance of bad dumps, this doesn't make sense. Either the CD drive is just giving you the raw data (redump.org) for you to store, or it's just sending back the user data, but it's still reading it all to do internal checking/correction.

Eidolon wrote:

gigadeath wrote:-because dumping raw takes only 10 seconds more and not 10 hours

See above, usefulness and data overhead.

The increased time is purely a limitation of your hard disc. The CD drive spins the disc at exactly the same speed (as said above, it's reading the same amount of data) weather you're dumping just user data or all data.

chungy wrote:redump.org doesn't "just dump the user data" for any system, so it's a null point. If they did, it will have to be looked on a case-by-case basis on weather a system and/or game needs the extra data. Dumping the raw sectors for anything and everything is simple; the rules don't change for different systems or games.

That is an acceptable answer. You should mention it in the mission statement of your website. From redump.org multi-system point of view, this makes sense. I'm just curious though; which systems have MODE1 data tracks where the game actually makes use of the additional EDC/ECC data in that MODE1 track?

chungy wrote:I have no idea where you got the idea that it increases the chance of bad dumps, this doesn't make sense. Either the CD drive is just giving you the raw data (redump.org) for you to store, or it's just sending back the user data, but it's still reading it all to do internal checking/correction.

Oh, it does make sense. It is very simple when you look at the different layers of error correction.
- for audio tracks as well as MODE2 data tracks (user data = 2352 bytes), there is the CD drive's internal C1/C2 correction mechanisms.
- for MODE1 data tracks (user data = 2048 bytes), there is the drive's internal C1/C2 correction mechanisms PLUS the 304 bytes of EDC/ECC data contained in each RAW sector of 2352 bytes.

So, the more error correction you have available for your chunk of user data, the less chance there is that the user data is wrong.

Of course, the discussion is a bit theoretical:
- If you have a good condition CD, you get reliable RAW data.
- If a drive's internal C1/C2 error correction cannot compensate for read errors in the RAW data, the resulting dump would not be usable for the redump database anyway.

If you have a horrible drive/destroyed CD, you're going to have a bad result even dumping, let's say, 32 bytes large sectors.

If your drive/disc are good enough to dump 2048 sectors correctly, then they're good enough to dump 2352 sectors correctly too. A reliable drive does the same multipass checking on raw sector as it does on cooked sectors.


As analogy, if you're good at making paper planes you'll do them good either making 23 paper planes or 25 paper planes. If you're horrible at making paper planes, you'll screw up even if you make a single one.