Redump Forum

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.

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.

I know this has nothing to do with Sega CD games but it does have some relivence to this topic. I understand what you are trying to say Snake but there are games like Tomb Raider for PSX whre the last track (track 57) is nothing but silence except for one byte of data near the end of the last sector that can't be read in drives that can't overread into the lead out and that are not reading based on corrected offsets. This one byte also makes a completly different checksum compared to if you just read that track as is and assumed that because you see no more data (or no data at all in this case) that there really is no more data to read.

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: https://redump.info/disc/469/ + https://redump.info/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: https://redump.info/disc/447/ https://redump.info/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: /viewtopic.php?t=937). 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).

themabus wrote: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.

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.

No, it's got nothing to do with community politics, and I don't think I'm going in circles.

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.

Eidolon wrote: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.

Vigi wrote: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...

Vigi wrote: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.

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.

Vigi wrote:Besides, you will always need a drive that supports certain features (overreading, C2, etc) if you want to be sure that the output is correct.

Correct.

Vigi wrote:I'm still waiting for the PerfectRip successor myself.

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.

Vigi wrote:In the meanwhile, I'll have my eyes open for the stuff that you and Snake come up with.

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.

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

Vigi wrote:(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.