Search options (Page 29 of 32)

Ok, after adding track1+2 sizes of both dumps there is a difference, so I guess it's a different region version anyway, but I still think the pnkiller's 2352 offset and gap length are strange and I think all audio tracks should match on both versions..

Those messages only meant that 5 sectors in the pregap, which were empty to begin with, were replaced with empty contents..

I've had this error plenty of times before and my dumps always matched EAC's checksums and other dump's checksums.. the log says 'completed succesfully' and there are no C2 errors, so everything should be ok. And I agree with xenogear's latest post.. the disc is clearly different and there are no dumping issues.

Hi.. all I can say is that the errors that you got are normal and don't affect the dump.. as long as there are 0 Total corrupt symbols (C2 pointers), everything is alright.

Either you have a different version than the current dumps or the offset isn't correct. It's possible that the factory write offset isn't detected on the data track using d8 (then you will only see the read offset = +30 for plextor)! The old offset detection method will give different results then, so be sure to try! (I've also had this problem with several IBM PC discs, and this is also why for a while again we believe that the EAC reference is correct and ipsedixit's offset conclusion isn't)..

You can try if the old offset detection method gives you the same write offset. And be sure to check if EAC gives you the same results. I'm not sure how a version on saturn discs can be checked (maybe it's in the first sector in text format if you browse it using isobuster/hex editor).

Ok I found out the issue again.. it happens when you read with subchannels enabled.. so when you use px_d8 or cdreader to compare syncs, make sure you disable subchannel reading! the output that you get then should be reliable.. if it still gives you a large negative then it should be correct..

One other thing you can try is reading the last audio sector in d8, so the sector before the track02 pregap.. you should see a certain amount of zeroes at the end of the data track (if you count the amount you get the offset), which also indicates a negative offset.

Atari Jaguar games have no data track?

edit: I just remember something.. older plextor drives have a bug where the normal read mode outputs a different sector offset than d8 mode.. I'm pretty sure that +222 is the correct write offset after all.. but if possible try confirming the offset using the old method..

I hope this doesn't affect any other users and any current dumps in the database..

I'm sure you will do what's right.. anyway, maybe existing rip tools like turborip can also be used to rip the subchannels, but they will have to be cleaned so there will be no random errors. I'm looking forward to seeing what kind of scan tool you will come up with.

any thoughts on this?

weren't they red or grey dumps?

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:

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?

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