redump.info Forum

Eidolon wrote:'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?

PlayStation, for one Some PC games also have falsified EDC/ECC data for rudimentary copy protection (granted this does protect against the ripping-only-user-data method as was common for bypassing copy protections).

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.

I think our problem is a language problem tbh... earlier you were saying it increased the chance of the data being wrong, and now you're saying it decreases it? Other than that, I see no issues with this quote

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.

Which is why redump.org encourages people to dump CDs of their own even if it's already in the database. You might verify a previous dump, you might find it to be wrong, maybe both are wrong (though if two different CDs produce identical data, it's extremely unlikely both of them are wrong). You might even find out that you have a CD from a completely different manufacture!

Heya Snake.. Welcome to the forums.. I have to say you defended yourself quite well there. Here's my feedback

Snake wrote:Again, this doesn't apply to SegaCD. The first audio track pregap will contain silence.

Theoretically yes, but there's a chance that data was moved into the pregap when mastering, so if you don't correct the write offset, there's a chance that data is cut off if the pregap isn't included. (We've seen data in the pregap before write offset correction several times by now, just so you know)

Snake wrote:Out of interest - is there any reason why you guys are NOT doing this?

Separate tracks have proven to be more convenient - at least for our project. There are a lot of games that have the same audio tracks across different regions and versions, and this wouldn't be visible if we would only list combined images. We've considered adding the combined checksums a couple of times, but we never got around doing that.

Anyway, you got our reasons for dumping 2352 - full main channel, same size for all sector types, easier to combine.. You're right that CDMage should be used to check RAW tracks for errors (except maybe when the checksum matches after dumping twice).

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

Vigi wrote:Separate tracks have proven to be more convenient - at least for our project. There are a lot of games that have the same audio tracks across different regions and versions, and this wouldn't be visible if we would only list combined images

This I think will bring to parent/clone relationship structure, which is another fair reason to get tracks separated.

Snake wrote:

The dumps Themabus and I verified together had no such problems at all, and they're full raw dumps. Our dumps matched perfectly

Yes, but what he's saying is that there is a higher chance of errors, and this is absolutely correct. By reading the data as 2048 bytes/sector it allows your drive to use the extra data to actually verify that the user data is correct and/or fix it on the fly. So if the drive reads it and does not report an error, you can guarantee that your data track is correct. By reading as 2352 bytes/sector this is not the case. Running the resulting image through CDmage will inform you of such errors and allow you to attempt to fix them, but why not let your drive do that for you? Your drive can also attempt to re-read the sector if needed - CDmage can't do that.

Does IsoBuster not already re-read problem sectors? I haven't used it on discs with problem sectors yet, but I know that cdrdao in raw-reading mode (btw it can read the subchannel data, if it's of any interest) *will* re-read problem sectors multiple times until it gets a good copy (or correctable, either way...).

chungy wrote:Does IsoBuster not already re-read problem sectors? I haven't used it on discs with problem sectors yet, but I know that cdrdao in raw-reading mode (btw it can read the subchannel data, if it's of any interest) *will* re-read problem sectors multiple times until it gets a good copy (or correctable, either way...).

It appears that some drives do this and some don't. I know that my Plextor drive does it.

Vigi wrote:It appears that some drives do this and some don't. I know that my Plextor drive does it.

Which return us to the point that a good CD-rom drive is needed. A good drive is a prerequisite of proper dumping. A good drive has (and not "should have") no problem reading data in raw mode. No problem at all. If not your drive is not good for the task.

You've never had to re-insert a cartridge before a game system recognised it? I'd find that hard to believe (this message was to Snake...)

Snake wrote:Really, the only thing we don't agree on is whether the audio offset is important. *Provided all the data is there*, I don't think it is - because the time between issuing the 'read' command and the drive actually playing the audio is going to vary WAY more than any audio offset anyway. Plus, if all the data is there, it can be corrected any way you like afterwards.

If I'm not mistaken, the issue is that the method we dislike returns 1/75 of second wrong. You say this data is so little it doesn't matter, we say that this data matters, and that a proper dump should include it.

If it all reduces to that I can safely says that Redump.org will continue the dumping the way it does now.

we want full proper dump -> we care about offsets -> we use EAC... it's pretty simple, really

I understand what you say, but there's A DIFFERENCE IN MENTALITY AT THE START OF THE DISCUSSION. That can't be worked out. Redump.org cares about things you don't care about. It's fine but it doesn't change what we think of our method of dumping.


And BTW, in cart dumping you have to take into account dirty contacts. Rust is a bitch

Snake wrote:

chungy wrote:You've never had to re-insert a cartridge before a game system recognised it? I'd find that hard to believe (this message was to Snake...)

Not 15% of the time, no

You're good at keeping your carts clean then. 10 years of foggy basement have wrecked mine. Not to the point they're unreadable toe