[ Closed ] Relation to tosec.org (Page 2 of 3)

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

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?

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.

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).

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

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!

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

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...).

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.

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

but, Snake, it's not just that. be it even 1 byte - you'll get different crc. and besides all cds have already an factory offset, sum that with drive offset, multiply with 4 and you will get the amount of bytes you'll miss. and the thing with Sega cds is that this factory offset can be huge so it's rather an exception if you get to align audio right and can get crcs to mach on some drives - but for this to happen on many drives it would have to be like a ...miracle
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... only 1 cd from 5 has little offset and a lot of silence, but if you don't belive you can teset by yourself - make the images with cdrwin and see if last byte in image is still data, it will often be.

In the end it all seems to come down to keeping the first and last audio samples, which is what CDRWin appears to fail at (because there's no offset correction).

@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).

Eidolon, the discussion seems to me a bit like a dog trying to bite his own tail now.

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.

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.

I do like CDRWin, I've first used it maybe 6 or 7 years ago (if not longer) and I also used it to dump the gdrom discs that are in the database. However, I don't see how CDRWin is any better than other cue/bin tools like IsoBuster, Fireburner, etc., because they all seem to create the same output.. they're all pretty basic and don't have the features that EAC has when it comes to dealing with errors. (Your Burai disc for instance. It doesn't have 100% track quality everywhere, does it still give the same 'intelligent' audio checksum as EAC?)