The video data is definitely present and accounted for in a Redump dump. Redump XBOX 1 and 360 dumps are basically SplitVid ONLY. The layer 1 half of the video data is only present on layer 1 of the dump (after the game partition). This matches the physical layout of the data on the disc. XDVDMulleter is not expecting this, and wants the layer 1 half of the video data to be copied into layer 0 (appended to the end of layer 0 video data). Redump doesn't do that because it doesn't match the original disc, and that's what we're interested in recording. But, if you patch in the SS, PFI, and DMI files and your drive firmware understands SplitVid, you should be able to do what you want with the dump regardless of what XDVDMulleter says about the video data. I have done it before.
no random padding
This is not true. Redump XBOX 1 dumps do retain the random padding.
Isn't layerbreak standard for all the Xbox discs (1913776)?
Security sector range is a problem, but 0800 dumps don't use them, you just count, whether a number of errors is 65536 or not?
0800 dumps do get the security sector ranges, just like Kreon dumps. Verifying the count is just a consistency check for dumps made with XBC instead of Freecell (Freecell has no 0800 drive support).
Could someone enlighten me about why do we need Kreon drives for dumping the Xbox discs and what's wrong with all the 'regular' drives? "Invisible" Xbox partition is the only problem?
That's correct. Special drive firmware (either Kreon on a supported drive, or 0800 firmware on a real 360 drive) is needed to gain access to the game partition. All regular drives are fooled by the video partition and think that is all that is on the disc.
Forgive my lateness, I just now noticed this thread but I think I can chime in.
The disc_key is very much needed, because Redump stores the hashes of encrypted PS3 ISOs. In other words, the data that is physically present on the disc. In order to make an encrypted ISO useful, it must be decrypted with the disc_key. The dumping method that PixelButts is espousing would give an already decrypted ISO. An argument could be made that Redump storing the decrypted ISO hash instead would be more convenient in a number of ways. But in terms of strictly disc preservation, the current way works well.
The disc_id is not quite as interesting, especially since the unique-per-disc part is blanked out. But since it can be dumped at the same time as the key and is needed for making IRDs, it's included.
PIC is also needed for IRDs, but it also has value as an authoritative indicator of the layerbreak location.
3k3y keydumper only works on 3.55 CFW. You'll have to downgrade to a 3.55 CFW to dump your 3Dump.bin file. After that you can upgrade back to 4.82 and use GetKey from linux just fine.
my opinion, but i think disc proof should be provided on new dumps since you can rebuild a jb rip with an ird and then get the metadata with getkeyfrom3k3y tool
Doesn't submitting the ringcode count as a disc proof?
Mega link for Getkey-r2 appears to be down for me, can anyone confirm please?
It just worked for me. Try a different browser maybe?
I just noticed that links to the 3k3y tools are dead, since the 3k3y site is gone. Here are mirrors.
3k3y Keydumper: https://mega.co.nz/#!ZoZ20CAL!fIOlwHWMr … g83xBXeRT4
3k3y Ripper A.K.A. IsoTools: https://mega.co.nz/#!EpI1hYTL!xSs9XGHKC … IWhLkoTIVU
Edit: So was the link to GetKey: https://mega.co.nz/#!stYVGTpR!Qp1WMye6a … d0Jb0KMYvE