redump.info Forum

F1ReB4LL started a discussion on discord about Xbox / Xbox 360 dumping.

Our current dumping method skips through the full range of every security sector range and fills this data with zeroes.
For Xbox1 discs, it's 16 x 4096 sectors and for Xbox 360 it's 2 x 4096? with each sector being 2048 bytes.

The argument is that this is not in line with the "redump dumping method" and that all data within the main reading area of the disc should be preserved.

Arguments against the current method:
- Fails to preserve all the (readable) data that is located in the security sector ranges.

Arguments in favor of the current method:
- It might be difficult or impossible to dump the missing data. Reading through the physical rings could take a lot of time, and different drives and/or discs could give different results (with some drives being able to read more sectors at the start and end of each ring than others), meaning it could be difficult to verify a dump that is done this way.
- The Xbox console itself blocks out access to the full range of every security sector. Dumping a game on an actual console (using dvd2xbox) results in the drive giving read errors in the the same sectors that are currently skipped on the PC dumping method.
- The data inside the security sector ranges seems to be random garbage that has no meaning or purpose.

I'm aiming to do some tests soon to see how long it would take to do a full dump using different drives and if the results are different between different drives. I only have 1 Xbox1 disc here ATM and it seems to have 5 physical rings, whereas the Xbox 360 discs that I have all seem to have 2 rings (one close to the center and one near the outer edge of the disc). It remains to be seen if all Xbox1 discs have 5 physical rings.

Its pointless, the data is not useful, its not fully retrievable, and the result will be no dumps verify.

"the data is not useful" - agreed
"its not fully retrievable" - yes, if you're talking about the physical rings that are unreadable, but we don't know yet how many sectors can't be retrieved because of this.
"and the result will be no dumps verify" - tests need to be done in order to confirm this

- The data inside the security sector ranges seems to be random garbage that has no meaning or purpose.

Its pointless, the data is not useful, its not fully retrievable, and the result will be no dumps verify.

How can we prove that data has no meaning or purpose? Do you read machine/assambly code? Doesn't easter egg exist in the security sector?

But it would be nice to add an option into DIC to read the SS contents fully. As far as I've understand, the first 1270..1285 sectors of each SS area are usually readable, then we have 305..320 unredable sectors, then we have good sectors upto the very end again. If you add the "xboxswap" mode for the method described above, I don't see a reason why not to dump these sectors at least optionally. As for the reading algorithm: you read until a read error, then you check the next 1 or 2 sectors, if they aren't readable as well - you skip 300 sectors. If that sector is readable, you start to read backwards until you find another errorneous sector, then you read forward again, dumping the contents; if that sector isn't readable, you check the next sectors one by one until you find a readable sector, then you continue to dump.

sarami wrote:But if there are some real error sectors, it's difficult to distinguish the unreadable sector of SS and the real error sectors.

Yes. But, again, it would be as good dump as possible, since the tool would test 2-3 sectors, if they are bad, it would skip 300 sectors and would look for the first readable one, either forward or backwards.
As far as I see, the real SS sectors have around 305-320 unreadable sectors per 4096 area, if the amount of unreadable sectors for a single sequence differ, that should mean read errors

Sarami, have you tried to implement that?

Don't forget that even if you succeed at dumping few more sectors you'd still get unverified data. You don't have access to low level read commands that return DVD correction codes.

In CD terms it's like you would be trying to read more sectors from unreabable range but in 2048 mode. Your drive firmware tries to correct all mastering errors + data tracks defects which are in turn "masked" by ECC/EDC.

How can you be sure that the data you read is the data on the disc? Without correction codes it's not deterministic to dump such sectors.

Do you expect that people should rerip all those 2400 discs?
Maybe another dat should be created solely for those SS ranges (similar to DMI, PFI dats)?

>Maybe another dat should be created solely for those SS ranges (similar to DMI, PFI dats)?

Or that additional data should be included as an "extra" download, similar to cues.

But again, i don't see why this is necessary at all.

reentrant wrote:You don't have access to low level read commands that return DVD correction codes.

You do - /viewtopic.php?t=2199 … iscussion/

reentrant wrote:In CD terms it's like you would be trying to read more sectors from unreabable range but in 2048 mode. Your drive firmware tries to correct all mastering errors + data tracks defects which are in turn "masked" by ECC/EDC.

How can you be sure that the data you read is the data on the disc? Without correction codes it's not deterministic to dump such sectors.

I don't understand your question. Those are normal stable sectors, why should they be damaged? It's just XBOX drives are locked to not to read them, but they are mostly readable (and there are also unreadable sectors are unreadable). A couple of test dumps of the same discs from different drives should show everything.

reentrant wrote:Do you expect that people should rerip all those 2400 discs?
Maybe another dat should be created solely for those SS ranges (similar to DMI, PFI dats)?

An additional status flag would be enough. Preservation enthusiasts will do the needed dumps sooner or later, but there should be a proper software for that.

>Preservation enthusiasts will do the needed dumps sooner or later, but there should be a proper software for that.

Ha. HAHAHAHAHAHA!!

Not everyone wants to waste time and cash for pointless, unverifiable sectors.

F1ReB4LL wrote:

reentrant wrote:You don't have access to low level read commands that return DVD correction codes.

You do - /viewtopic.php?t=2199 … iscussion/

I meant something like that: https://debugmo.de/2007/07/read-your-dvds-the-raw-way/