You are not logged in. Please login or register.
Redump Forum → General discussion → Simplified dumping method using CDRWIN?
I would like to hear your thoughts on my following findings:
Differences between REDUMP and CDRWIN methods
If that can be consistently reproduced, and it can be determined how CDRWIN behaves when an audio track has non-zero values until the very end, that would greatly simplify the preservation process.
I like your researches. But...
Problem is that once you start memorizing the procedure, the IsoBuster+EAC procedure we follow now takes so little time that it makes the switch to CDRWin useless, because there's no real saving of time when you learn the passes and do them automatically.
Probably today it took you much time to dump a single disc, but what you did in half an hour I can do in 7 minutes:
-1 minute finding offsets
-1 minute ripping data track and resizing it
-5 minutes ripping audio tracks
Basically the same time you spend with CDRWin ripping and then shifting the data till you find the correct position.
I guess someone already said it, but there's not real time saving in using CDRWin, and you risk to lose data with it.
You only need to get practical with the dumping procedure. I wasn't fast at dumping at first either.
I like your researches. But...
I like to do some research before I start such a project as GoodSegaCD or GoodSaturn, or join a project like redump or tosec. 
Problem is that once you start memorizing the procedure, the IsoBuster+EAC procedure we follow now takes so little time that it makes the switch to CDRWin useless, because there's no real saving of time when you learn the passes and do them automatically.
Of course, every method is a matter of getting used to it. But I still dispute your argument that it couldn't be done faster with the method I propose above.
Probably today it took you much time to dump a single disc, but what you did in half an hour I can do in 7 minutes:
-1 minute finding offsets
-1 minute ripping data track and resizing it
-5 minutes ripping audio tracks
I guess someone already said it, but there's not real time saving in using CDRWin, and you risk to lose data with it.
Well, that is what I put up for discussion here, I haven't heard sufficient arguments. Look at my proposed method, if it is true then it could be something like this:
-1 minute finding offsets
-5 minute ripping complete CD (cue, data, audio)
-1 minute running the rip through the fixing tool
Well you see that the time may be the same, but the amount of manual work you have to do is significantly less.
I guess it comes down to the following questions:
- Is EAC's pregap detection really that much better than CDRWIN's?
- Can someone write the "image normalization and checksumming" tool I proposed on the Inn?
- Is EAC's pregap detection really that much better than CDRWIN's?
Others might answer better, I'll choose the easy one: yes. Much better. I know Themabus is a gap guru, he can give a deeper answer.
- Can someone write the "image normalization and checksumming" tool I proposed on the Inn?
I hope so, the more tools, the better (assuming they work right, of course). But we have to decide how to define "normalization". The reference for normalization should be full dumps only.
Yeah, I don't see any talks about gaps. CDRWIN doesn't split tracks, but can it detect all gaps correctly?
Anyway, nice job on comparing the methods. If you can come up with an easier/faster way of getting identical results as our current method, this would be really nice I guess.
Eidolon wrote:- Is EAC's pregap detection really that much better than CDRWIN's?
Others might answer better, I'll choose the easy one: yes. Much better. I know Themabus is a gap guru, he can give a deeper answer.
Hey Themabus, can you please comment? That would be really interesting to know! Because as I wrote in my Inn article, it seems that both EAC and CDRWIN detect the pregaps just fine.
I hope so, the more tools, the better (assuming they work right, of course). But we have to decide how to define "normalization". The reference for normalization should be full dumps only.
CDRWIN dump is a full dump (with one exception see last sentence)
Well, as I wrote in the Inn article - in this case, it would be very easy to shift the audio data again by 11016 bytes "left" as you do in the current redump process to come to exactly the same image.
EDIT: And that can even be done automatically by the analyzer tool, because this offset you currently detect cumbersomely, manually using ISOBuster can be easily detected in a CDRWIN image. It is the difference between the start of the first non-zero audio byte of the first audio track and the end of the data track.
Mind you, this method only workds with the prerequisite there should be an ample amount of zero's at the end of the dumped CDRWIN image.
A method which needs exceptions correction to give proper results is not what we want. Our method don't comprehend exceptions. It works with all discs and handle them all the same way with proper results. I don't want to dump a disc first and THEN have to check if it falls in the exceptions category or not. I'll dump with IsoBuster+EAC directly and all will be fine.
A method which needs exceptions correction to give proper results is not what we want. Our method don't comprehend exceptions. It works with all discs and handle them all the same way with proper results. I don't want to dump a disc first and THEN have to check if it falls in the exceptions category or not. I'll dump with IsoBuster+EAC directly and all will be fine.
Well, it hasn't been proven yet that CDRWIN definitely cuts of data from the last audio track. That could easily be checked by one of you guys, taking one of the example Sega CDs (e.g. Winning Post) where you say that they contain audio data until the very last byte.
If you do that, and compare the raw audio data from the Isobuster+EAC dump and the CDRWIN dump using the method I outlined in my Inn post, and then get a difference, then it is proven that CDRWIN behaves faulty and cuts of data. If it is still the same checksum, then it is proof that you do not lose data with CDRWIN.
Finally, with each dump you can take note of the drive read offset, detect the sample offset and from that calculate the factory write offset using one single tool analyzing the dumped CDRWIN image. Together with the cue sheet, you can also calculate checksums for all tracks, even choosing different methods (with or without offset correction, with or without pre- or postgap zeros).
Also, I'm still waiting for a sufficiently good statement about CDRWIN's and EAC's pregap detection. Is there any particularily "difficult" CD with which that can be tested and see if both tools come up with different results?
You cannot always detect the offset in a CDRWIN image; This is the reason some of us use multiple drives on specific discs (those that "appear" to have an offset of 0, i.e. first data sector of 2-second gap is completely filled with zeroes). You'd need a drive with a large offset to properly detect the factory write offset on these (for instance, discs such as http://redump.org/disc/1348/ will have problems unless your drive read offset is > +647); such drives generally can't read subchannel data though, and probably don't have C2 error reporting, either -- so multiple drives to dump the same disc are needed.
As for pregap-detection : Neither cdrwin nor EAC behaved too well here thus far. I've had both of them give me nonsensical results (and inconsistent with themselves, too); So far, PerfectRip had the best detection, and I suppose the cd xpert tools would probably have the same.
GoodSaturn?
CDRWin is not able to define correctly gap between 2 date tracks in many games SS.
Nights Into Dreams for example
GoodSaturn?
CDRWin is not able to define correctly gap between 2 date tracks in many games SS.
Nights Into Dreams for example
Thanks for the tip. I have the EU version of that game, so I'll check it.
Anyway, Saturn dumping is an issue which I still have to get into - knowing that Saturn games, unlike Sega CD games, have copy protection, this might become more difficult and may even lead me to dropping the GoodSaturn project in favour of redump.org
CDRWin has issues with other systems as well - Dreamcast, Jaguar CD, CD-i in some cases, etc.
Redump Forum → General discussion → Simplified dumping method using CDRWIN?
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.