You are not logged in. Please login or register.
Redump Forum → General discussion → My GoodSegaCD, GoodSaturn, redump.org conclusion
See here.
I think this constitutes the best of two worlds.
When the tool is finished, it will still be possible to submit valid information (valid according to redump.org method) from my ripping method to the redump.org database. At the same time, we give the Sega community a more flexible way to compare their rips.
Good job on your post, only it would be nice if you could explain the following part, because I don't understand what you mean:
However, for any existing rip where the drive read offset is not known, it can be determined if it originally came from an original CD or not! This is a significant advantage over the redump.org database.
Also, I hope CDRWin is capable of detecting the correct gaps on all drives, because I don't see any mention of it in your post. Gaps can be a real pain (at least with EAC).
Also, have you considered writing your tool in C for crossplatform compatibility?
Good job on your post, only it would be nice if you could explain the following part, because I don't understand what you mean:
However, for any existing rip where the drive read offset is not known, it can be determined if it originally came from an original CD or not! This is a significant advantage over the redump.org database.
Yes I see I have phrased that badly. What I mean is the following: If the Inn database contains intelligent checksums for a particular game, you can test your rip against that. If the checksums are the same, you KNOW that your rip - even if it has a different audio offset - has come from an original CD (i.e. it is a "good" rip which you can keep), or e.g. from a ripped, burnt and re-ripped ISO/MP3 fileset (which is a "bad" rip you should delete immediately ;-).
Also, I hope CDRWin is capable of detecting the correct gaps on all drives, because I don't see any mention of it in your post. Gaps can be a real pain (at least with EAC).
Therefore, we have to define "correct" detection. From my findings so far, it looked that CDRWIN and EAC detected the gaps the same way, even on my "bad" drive. This is one of the questions noone here did answer me yet sufficiently, apart from blunt "CDRWIN sucks" answers.
Also, have you considered writing your tool in C for crossplatform compatibility?
Probably not. Why should I? All ripping is done in Windows anyway. However, I plan to make the C# source freely available so anyone can look at it and improve it.
Yes I see I have phrased that badly. What I mean is the following: If the Inn database contains intelligent checksums for a particular game, you can test your rip against that. If the checksums are the same, you KNOW that your rip - even if it has a different audio offset - has come from an original CD (i.e. it is a "good" rip which you can keep), or e.g. from a ripped, burnt and re-ripped ISO/MP3 fileset (which is a "bad" rip you should delete immediately ;-).
You'd be surprised to see how many cd rips out there have 1 or 2 audio tracks with errors on them. You'd have to be extremely lucky to find an image somewhere that has a matching intelligent checksum. Still, you're right that the 'intelligent' checksum makes it easier because the offsets are ignored.
Anyway, I'm looking forward to your tool, and it's much appreciated that you also choose to add Redump.org support to the tool instead of just going your own direction. I'm sure that if all the issues are ironed out it can become an easy alternative to the current method.
Hi Eidolon, nice to see you're still around :-)
I disagree with the redump.org method on the following points
ripping RAW mode data for all SegaCD and Saturn games is not necessary. The Inn Method will concentrate on USER DATA only
MODE1/2048 for SegaCD games
MODE1/2048 and in some cases MODE2/2352 for Saturn games
Will the ripping contain a check that this data is superfluous ? I.e. even if data is saved in 2048 byte sectors, will a check be performed that verifies that the ECC information can be recreated in the standard way ? (I assume this will have to be done for Saturn games since you mention the possibility of them having to go RAW).
applying any audio data shift to the ripped binary files is not necessary to achieve comparability and maintain playability using virtual drives or emulators. The Inn ripping method will only take note of the drive read offset. Write offset can be calculated from that and the ripped image, but this is done solely to maintain comparability with redump.org database.
Given the case where the offset is not so far in the negative that most drives cannot detect it properly (this is an issue on PSX, no idea whether it comes up on Saturn or SegaCD). So long as this offset is known, however, the data layout on the CD can be recreated exactly as it was on the pressed version, so carrying this metadata is a good thing :-) There's also the issue of positive offsets and shifting of legitimate audio data into the leadout (which may be cut off), though you seem to opt for manual handling of these cases.
handling of separate files for data and audio tracks is unecessary. One single BIN file per CD is the right way to go
On this I'd disagree, but it's a contentious issue to debate. The single-file approach doesn't allow stuff like compressing audio tracks separately with more appropriate methods (i.e. flac vs. 7z), and checksum-verifications are harder on the entire image in some cases. But oh well 
Yes I see I have phrased that badly. What I mean is the following: If the Inn database contains intelligent checksums for a particular game, you can test your rip against that. If the checksums are the same, you KNOW that your rip - even if it has a different audio offset - has come from an original CD (i.e. it is a "good" rip which you can keep), or e.g. from a ripped, burnt and re-ripped ISO/MP3 fileset (which is a "bad" rip you should delete immediately ;-).
We have "psxt001z --track" for the same purpose. It uses full track crc32, not "intelligent" one - that means you can extract tracks from the incorrectly dumped image so their checksums would match DB. As you see, this can be done without "intelligent" checksums.
We have "psxt001z --track" for the same purpose. It uses full track crc32, not "intelligent" one - that means you can extract tracks from the incorrectly dumped image so their checksums would match DB. As you see, this can be done without "intelligent" checksums.
And it let you to extract correct tracks, even if some of them are bad. And "GoodSegaCD" + "GoodSaturn" are going to have checksums for the full audio block only, so, even if one byte is bad, dump will be marked as bad. With redump's checksums you can easily download any image from the net and extract all the correct tracks, if any, you can even request patches for others (if its size is matched to the dat and its checksum is different).
Technically any processing done to get the intelligent checksum cleartext could also be done in patching tools with appropriate metadata (though you'd have to change those tools a fair bit). The tradeoff is between accuracy and convenience, on a sliding scale. Eidolon's proposed method is more convenient but less accurate, and vice versa for the redump.org method; Some people want one, others the other (personally I'm of the opinion that dumping them 100% accurately once is worth the work, instead of having it easier for more people -- the dumping really only needs to be done twice or so to get verified good dumps; others can then use that baseline data to do their dumps in any way they choose (for instance, once the offset is known and confirmed by somebody with a proper drive for it, nobody else needs to figure out that write offset again when they do backups of their own discs).
For PSX the redump.org method is, IMHO, currently the best one known and it's unlikely that a better one will come along any time soon. Same for other "regular" disc formats (such as acd32, segacd, etc.) IMHO -- even though dumping ECC data may not strictly be needed, it does not diminish the quality of the dumps -- and offset detection works just the same. The guide does not really cover more modern copy protections (such as those found on PC games) and how to properly preserve their data; most research in that sector in the past has gone into how to circumvent them, not how to preserve them (unless that circumvention is doable with a 1:1 copy of the protection scheme, but in that case it ain't much of a scheme).
Redump Forum → General discussion → My GoodSegaCD, GoodSaturn, redump.org conclusion
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.