Search options (Page 12 of 32)

It's still on the TODO list - http://forum.redump.org/topic/7446/data … o-shedule/
iR0b0t is the only site coder, so no idea if or when this will be implemented.

http://redump.org/disc/42279/
http://redump.org/disc/43333/
http://redump.org/disc/43270/

These dumps all have ~462 error sectors. This is the number that you should aim for with these discs.

You basically start by getting a "rough" dump of the data track. I prefer to use CloneCD with Intelligent Bad Sector Scanner and Sector Skip set to 500.
The problem also is that you will still need DIC for the audio tracks, cuesheet etc.. Currently the only way that I know to get DIC to skip through the ring without taking forever is to press the eject button of the drive when it starts retrying sectors, then wait until it filled enough sectors with dummy data, and then pause the command prompt by right clicking into it. Then when the program is paused, press the eject button again and when the disc is loaded again, let command prompt resume and it will continue reading the remaining post-ring area of the disc.
Ideally sarami could implement some kind of smart sector skip function that skips x sectors after x read errors, maybe for a preset range.

When you have a dump of the data track with a wide error range, the next step is to try and read as many sectors as possible before and after the ring, and inject them into the image.
Reentrant made a tool to help automate this process. The tool lacks any documentation / help text, so it's better not to share it for now. Maybe he can make a more "release friendly" version. The tool lets you specify the range that you want to read, the direction (back / forward or both), number of retries for each sector, etc. It looks at the reference image to determine if a sector is corrupt, and then saves any readable sectors to a folder. The tool can then be used to inject the readable sectors into the image.

For the 2 dumps that I did, I used a combination of drives (Optiarc + Samsung + Plextor) to get as many readable sectors as possible. It's a trial and error process that can take several hours. OptiArc drives are well suited for reading most sectors, but keep in mind that you would still need a Plextor drive to dump the rest of the disc (including the audio tracks) properly with DIC.

There should only be a handful of games with this particular protection (maybe only Blue Byte ones). They can be identified by the ring with spikes, that is also visible on the label side. Also, the errors start at around 94% of the data track IIRC, so comradesean's disc might be a different protection.

"308558-->308560 isn't readable.
Track 3 is recognized as Audio mode in IsoBuster."

I guess the shift is caused by data > audio transition?

How to find out? Gamecopyworld lists it as 'Read errors'.

use CDmage

Did you guys even do a search? http://redump.org/disc/18800/

MSF: 01:41:62 Q-Data: 410101 01:39:62 00 01:41:62 89a9

This one shouldn't be included (not SecuROM data)

Problem with disc: http://redump.org/disc/42666/

This is a clear case where 00:00:00 Track02 pregap causes audio data to be moved into the data track.

From previous discussion: http://forum.redump.org/topic/15992/abo … or-sector/

"If sync doesn't exist in the sector of mastering error, this sector shouldn't be descrambled. Because no sync = not a valid data sector."

However, DIC is descrambling these sectors. This is wrong.

https://uk.webuy.com/product.php?sku=4005209081641

Store    In Stock
Clydebank    1
Guildford    1
Hull    1
North Shields    1
Nuneaton    1
Poole    1

Thx.. the read errors are in different positions really, so I guess they are both caused by scratches.

@JayFoxRox: I got Excel to calculate the first 16 error ranges (just to see if that was possible ), but the remaining values in rows 17-23 don't look like they are start + end PSN's at all (and they are not in sequence with the previous 16 rows). Did you find any info about what these bytes might be?

Our dumping method revolves around the idea that security placeholders are simply ranges of readable/unreadable sectors with random padding that were placed on the disc as a copy protection mechanism. These unreadable ranges were witnessed by examining DVD2Xbox logs and dumps, and IIRC also by "hot"swapping DVD9's by Xbox discs, to fool a drive into reading the Xbox disc.

If this theory is correct, then it would mean that "clean" ranges were replaced with zeroes and actual security ranges were included in the dump? In any case, we haven't encountered any unreadable sectors that were outside the first 16 ranges, with the 1654 Xbox1 discs dumped so far, even though IIRC all security placeholders contain unreadable sectors.

One of the admins should take care of that.

Feel free to keep posting your findings and contribute any dump info. If our dumping methods prove to be wrong or inadequate, we will do our best to fix that, but so far there is no evidence to suggest that anything is wrong with the dumps.

Hi and welcome,

Here's a link to the source code of our tool ss_sector_range. I don't have the one for the latest version, but nonetheless this should help you with your research: http://www.mediafire.com/file/7046l9s2h … ha_src.zip

From what I can recall from our research, Xbox360 has 23 security sector ranges, but Xbox1 only has 16. This was also evident from the error log that dvd2xbox created when creating dumps on the actual console, and the Xbox SDK also contained a tool for creating Xbox Game Discs, where you had to position the game data between 16 (8 for each layer) security placeholder ranges.

From the .cpp:

As for the lack of information: We now merely list the CRC32 of the SS to identify between different sectors that are known for each game. We could also add new fields for any data from the SS that might be crucial, but seeing as to how it's possible to extract files from personal backups, transfer them to the console and play, I guess that emulators will also be able to play games without having to rely on the PFI/DMI/SS (correct me if I'm wrong).