it needs /sf and edit C2ErrorProtect.txt. But it seems intentional C2 errors of Skidoo are unstable.
Does it take multiple files now? It only took one before and the disc has 7 files.
What do you mean unstable?
You are not logged in. Please login or register.
Redump Forum → Posts by Nexy
it needs /sf and edit C2ErrorProtect.txt. But it seems intentional C2 errors of Skidoo are unstable.
Does it take multiple files now? It only took one before and the disc has 7 files.
What do you mean unstable?
Hey sarami, did that Skidoo game arrive yet?
I tested the Yamaha CRW-F1 a bit. It seems to have D8 support (according to EAC) and can read the track 01 pre gap up to 150 sectors. It reports being able to read the lead out but not sure if this is valid or not. It either doesn't support C2 or EAC is unable to determine the format they are returned in.
I am unable to test it with DIC as it hangs my system when the disc read speed is set. I did try 0 as the speed as suggested before. Drive is quite rare and expensive, so I don't expect you to pick one up. I figured I would post my findings anyways.
You haven't been paying attention I guess, there is a buffer read command that bypasses this issue and was implemented. However it needs to read more than 1 sector, which still needs to be addressed.
The entire pregap is 0?
Should probably check the sector mode too? I've gotten this on a few discs.
edc/ecc check is reporting wrong error count again, treating track 02 pregap as data mode when it's audio.
It's a 6, that's my discalculia, sorry.
I just checked ebay, there is 4 copies https://www.ebay.com/sch/1249/i.html?_f … eam+racing
sarami did you pick up that Ski-doo X team racing disc yet? I'm curious, would like to be able to dump this one.
Total agreement.
UTC is the standard and should be followed, local times mean nothing. The moderators should have disc images and can spend the time fixing the things that were added incorrectly, it will take ages, but it should be done. It could possibly even be automated, but... I'm not going into that.
Define different hashes, different from previous dumps or different from multiple dumps you made.
Do we know what the pattern really is? For that and for safedisc?
Failed to get read offset with ASUS drive. Logs attached for ASUS and plextor.
Sweet, now we just need the rest.
There's no such thing as "abandonware", this term has no legal standing. Copyright expires 70 years after the expiration of the author, if a company holds the copyright, it's likely to never expire as IP changes hands when companies fold.
There's nothing wrong with us, what is wrong with you?
It is, the first sector usually has something other than 00 in it.
Discussion of piracy is not allowed.
F1reb4ll please close this topic.
Some luck on some more sectors for ASUS BW-16D1HT ?
I tested this drive a bit now, it's not really good at C2 errors, I think it caches and doesn't ever re-read. Could you look into that sarami?
They should be yellow imo, they are bad dumps. I have redumped my SmartE discs and reminded others to do the same. If we need to re-collect some discs due to people selling them, then they should be added to whichever spreadsheet and marked high priority.
RibShark wrote:I reverse engineered the firmware myself.
If possible, please tell me how to reverse engineer the firmware. I'm interested.
IDA?
Also tested ASUS-BW-16D1HT with 3.02 firmware, looking forward to bigger positive offset support. Too bad the drive doesn't have better C2 correction, maybe a buffer flush is needed for re-reads.
I just haven't done any testing yet to see if SafeDisc is reliably dumpable and verifyable, I suspect the single byte (312) is like CDS and an intentional weak sector that the hardware can't read correctly. I can test this with some of my Need For Speed games as I have several copies of the same disc and I now have 10 plextors to do testing with.
I mean that would be a huge pain to redump all safedisc, I'm not opposed to this but I think some people would be. I am more interested in dumping correctly though. It causes a lot of heated argument but we're getting on the same page mostly now. This is not an issue for me because I keep all discs, but this presents a problem where large parts of the db would be instantly invalidated, however I don't have issue with that. I do understand that others will. However I am in favor of as accurate as possible dumping, regardless of having to go do stuff again if it's found wrong. I have been redumping already my entire collection with DIC without a single complaint, and glad to do it. SafeDisc protection does not check for the bad sectors at all, they are just there to prevent copying easily,which is a bit silly since it's been easily defeated since early 2000's, so I don't think it really matters much when it comes to using the images, but is that preservation?
I guess we will have to work with what he have, and we can change things in the future when we have methods and hardware to do better. Eventually we *will* have means to dump entire discs linearly and we'll need a special image format for it. Until then we keep going as we are now.
Anyways back on topic, there should be no "correction" or "fixing" things imo, and that includes subchannel data. Too many discs have intentional errors, and too many drives/windows do not fix these errors when reading the disc, particularly edc/ecc errors.
I doubt anyone will bother with audio swap disc method, they want a simple and easy solution.
Redump Forum → Posts by Nexy
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.