1 Topic by Jackal (edited by Jackal 2019-04-01 20:28:57)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

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.

  • user7
  • Moderator
  • Offline
  • Registered: 2009-03-14
  • Posts: 2,621

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

All my posts and submission data are released into Public Domain / CC0.

3 Reply by Jackal (edited by Jackal 2019-04-01 20:34:47)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

"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

  • Registered: 2011-02-20
  • Posts: 1,747

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

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2006-12-24
  • Posts: 3,847

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?

  • Registered: 2014-10-06
  • Posts: 704

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

7 Reply by user7 (edited by user7 2019-04-02 18:31:03)

  • user7
  • Moderator
  • Offline
  • Registered: 2009-03-14
  • Posts: 2,621

>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.

All my posts and submission data are released into Public Domain / CC0.
  • Registered: 2006-12-24
  • Posts: 3,847

reentrant wrote:

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

You do - http://forum.redump.org/topic/3808/raw- … 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.

  • user7
  • Moderator
  • Offline
  • Registered: 2009-03-14
  • Posts: 2,621

>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.

All my posts and submission data are released into Public Domain / CC0.
  • Registered: 2014-10-06
  • Posts: 704

F1ReB4LL wrote:
reentrant wrote:

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

You do - http://forum.redump.org/topic/3808/raw- … iscussion/

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

11 Reply by Jackal (edited by Jackal 2019-04-03 17:43:41)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

user7 wrote:

>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.

There are yellow Xbox 360 dumps that nobody cares to fix, and many Xbox NTSC discs that nobody wants to buy - http://wiki.redump.org/index.php?title= … sing_Dumps (because the PAL discs are already dumped). So, don't expect anyone to to buy and redump 4.000 discs, even if it's confirmed that the missing data can be dumped/verified.

  • Registered: 2006-12-24
  • Posts: 3,847

As I've said, there should be a mechanism to dump and add the discs properly for those who want it so. Nobody says about marking the existing ones as bad.

  • Registered: 2007-04-28
  • Posts: 34

I tend to be in the camp of "scan everything with an electron microscope and simulate lasers", but honestly there is a point where a decision has to be made.

Now, it's important to be _sure_ there isn't any useful data, even just silly intentional data, in that space… but from what I've learnt reading around, it would seem that its genuinely "useless" and unused. As long as the beginning and end of these sectors are well known are documented, I see no harm with the current method which ignores those bits.

  • Registered: 2006-12-24
  • Posts: 3,847

emuLOAD wrote:

As long as the beginning and end of these sectors are well known are documented, I see no harm with the current method which ignores those bits.

If these sectors are somehow generatable, then, yes (and even then it's better not to ignore them, but to generate, similar to how the "injected" last sector was added on PSX NoEDC images back in the days) otherwise - no, these bits shouldn't be ignored, if they contain unique data.

15 Reply by Jackal (edited by Jackal 2019-04-05 11:50:12)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

Did a first test on Kreon drive today with CloneCD. It would skip through the first couple error sectors, but would stop reading and start making noises as soon as it reached the first ring. So a different drive or custom tools would be needed to dump this data. Will try some other drives later with disc swap.

  • Registered: 2006-12-24
  • Posts: 3,847

Jackal wrote:

Did a first test on Kreon drive today with CloneCD. It would skip through the first couple error sectors, but would stop reading and start making noises as soon as it reached the first ring. So a different drive or custom tools would be needed to dump this data. Will try some other drives later with disc swap.

I'd recommend to try IsoBuster to manually find the truly unreadable ranges and to dump everything else skipping those sections. The logic is described above (to skip around 300 sectors after the first 1-2 unreadable ones, then to search for the first readable one after the skipped ones).

  • Registered: 2011-02-20
  • Posts: 1,747

F1ReB4LL wrote:

have you tried to implement that?

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: /nss flag in xbox, xboxswap and xgd2swap

DiscImageCreator.exe xbox <drive> <filename> <speed> /nss 10
'10' is a max rereading value per sector
DiscImageCreator.exe xbox <drive> <filename> <speed> /nss
If value is omitted, '100' is set automatically.

I've not tested yet xboxswap and xgd2swap
Give me a comment, plz.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2006-12-24
  • Posts: 3,847

Doesn't work?

DiscImageCreator.exe xboxswap F: dump 8 /nss 2
AppVersion
        x86, AnsiBuild, 20190407 215226
Invalid argument
Usage
        cd <DriveLetter> <Filename> <DriveSpeed(0-72)> [/q] [/a (val)]
...

DiscImageCreator.exe xboxswap F: dump 8 /nss 2
AppVersion
        x86, AnsiBuild, 20190413 103735
Invalid argument
Usage
        cd <DriveLetter> <Filename> <DriveSpeed(0-72)> [/q] [/a (val)]
...

  • Registered: 2011-02-20
  • Posts: 1,747

16 ss is needed.

        xboxswap <DriveLetter> <Filename> <DriveSpeed(0-16)>
                                          <StartLBAOfSecuritySector_1>
                                          <StartLBAOfSecuritySector_2>
                                                         :
                                          <StartLBAOfSecuritySector_16> [/f (val)] [/q]
                Dump a Xbox disc from A to Z using swap trick
DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2006-12-24
  • Posts: 3,847

But if it reads all the sectors, why does it need the SS ranges? smile

DiscImageCreator.exe xboxswap F: dump 8 290540 445728 603308 759356 912208 1298824 1449692 1610286 1979736 2289920 2448012 2601336 2836428 2990638 3298528 3456316 /nss 2
AppVersion
        x86, AnsiBuild, 20190413 103735
/nss val is omitted. set [100]
Unknown option: [2]
Usage
        cd <DriveLetter> <Filename> <DriveSpeed(0-72)> [/q] [/a (val)]
...

DiscImageCreator.exe xboxswap F: dump 8 /nss 2 290540 445728 603308 759356 912208 1298824 1449692 1610286 1979736 2289920 2448012 2601336 2836428 2990638 3298528 3456316
AppVersion
        x86, AnsiBuild, 20190413 103735
[/nss] is invalid argument. Please input integer.
Usage
        cd <DriveLetter> <Filename> <DriveSpeed(0-72)> [/q] [/a (val)]
...

Still doesn't work.

  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

Because it should not skip any sectors besides those in ss ranges, i would say.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

Requiring manual input of ss ranges is silly, it should allow input from ss_sector_range txt or from ss.bin directly.

  • From: North East UK
  • Registered: 2016-06-15
  • Posts: 1,063

Is there a way to try this by manually adjusting the sector ranges (in the txt file generated from the SS.bin) with freecell?

  • Registered: 2011-02-20
  • Posts: 1,747

F1ReB4LL wrote:

Still doesn't work.

Sorry, fixed. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

iR0b0t wrote:

Because it should not skip any sectors besides those in ss ranges, i would say.

Yes. if reading error occurs out of the ss ranges, its sector is bad.

Jackal wrote:

Requiring manual input of ss ranges is silly

I think so too. Btw I found this https://web.archive.org/web/20081221213 … ng_pref=en

where ss.bin is a raw dump (2064 bytes) of data @PSN 0xFD21E

We may get the ss.bin by xbox raw dumping without kreon drive... I'll try it.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

25 Reply by Jackal (edited by Jackal 2019-04-14 10:28:18)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

sarami wrote:
where ss.bin is a raw dump (2064 bytes) of data @PSN 0xFD21E

We may get the ss.bin by xbox raw dumping without kreon drive... I'll try it.

Yeah I guess we never tried that before.. Can PSN 0xFD021E be approached as a sector number?