FILLED GTA_San_Andreas_Pal_Multi5_Ps2dvd-CHRONIC

[kasten]

GTA_San_Andreas_Pal_Multi5_Ps2dvd-CHRONIC
srrDB

 

[formeruser]

[2004-10-27] GTA_San_Andreas_Pal_Multi5_Ps2dvd-CHRONIC

You do not have permission to view link Log in or register now.

Password: gNs7synOXRi1BrqgxlHz

You could have just used

You do not have permission to view link Log in or register now.

with 2004-11-02_rar341.exe to recreate this release from the easily accessible

You do not have permission to view link Log in or register now.

Grand Theft Auto - San Andreas (Europe, Australia) (En,Fr,De,Es,It) (v1.03).iso.

 

[rappunzel]

[2004-10-27] GTA_San_Andreas_Pal_Multi5_Ps2dvd-CHRONIC

You do not have permission to view link Log in or register now.

Password: gNs7synOXRi1BrqgxlHz

You could have just used

You do not have permission to view link Log in or register now.

with 2004-11-02_rar341.exe to recreate this release from the easily accessible

You do not have permission to view link Log in or register now.

Grand Theft Auto - San Andreas (Europe, Australia) (En,Fr,De,Es,It) (v1.03).iso.

That is super nice about easily accessible Redump-verified. But how many of those releases could be recreated with pyRescene? Or where i can download those dumps ?

 

[Yamato]

But how many of those releases could be recreated with pyRescene?

A successful ReScene depends on a release and it is hard to give you the clear answer to this question without actually trying to do it first. However, I still assume that there may be an existing DataBase containing the information on such tests as ReScene Status (e.g. Succesful/Unsuccesful) and a goodRAR version needed for each release. The latter is needed to save your time and prevent the ReScene tool from guessing which RAR version is the best goodRAR one by picking them one by one during the ReScene process. However, I have not seen such web-sites/DataBases yet.

Based on my personal experience of ReScening PC releases, the actual process is very inconsistent in terms of a success rate:
- some releases can be ReScened in a matter of minutes
- and some releases may take up to 3-5 hours to be ReScened

For example, it takes for the tool about 5 hours to completely ReScene "Dishonored.GOTY.PAL.XBOX360-iNSOMNi" given there is already picked a goodRAR version. If using all the available RAR versions, the process of guessing a goodRAR version will take even longer.

So, I think you should try it by yourself to get better understanding of how it works. While I was ReScenening my own PC releases (I have around 20TB of unrared Scene Releases), I made some notes for only a few ones:

Dragon.Age.Origins-SKIDROW	ReScene successful	goodRAR: 2009-11-16_rar391b1
Spider-Man_3	ReScene successful	goodRAR: 2007-04-16_rar370b7
Dead.Space.3-RELOADED	ReScene successful	goodRAR: DVD1-2012-06-09_rar420 // DVD2-2012-02-17_rar411
Dead.Space.3.Awakened.DLC-PLAZA	Completed but incorrect CRC	goodRAR: 2016-08-15_rar540
SYNDICATE.MULTI-POSTMORTEM	ReScene successful	goodRAR: 2012-02-17_rar411
Hitman.REPACK-CPY	ReScene successful	goodRAR: 2016-08-15_rar540
Dishonored.Game.of.The.Year.Edition-HI2U	ReScene successful	goodRAR: 2013-11-13_rar501b1
Mark.of.the.Ninja.Special.Edition-SKIDROW	ReScene successful	goodRAR: 2012-02-17_rar411
Quantum.Break-SKIDROW	Completed - incorrect CRC for 'sr-quantumbreak.s82'	goodRAR: 2016-08-15_rar540
NARUTO.SHIPPUDEN.Ultimate.Ninja.STORM.4.MULTi11-PROPHET	ReScene successful	goodRAR: 2016-08-15_rar540

It is worth mentioning that some releases cannot be ReScened due to imperfections of the software even if you have all the correct scene files (e.g. "Assassins.Creed.Freedom.Cry.MULTi19-PROPHET" for which the ReScene tool fails to match CRC at the very end of the process and ends up with a failure) and the only way to get scene RARs is to re-download the original release. Hopefully, we will see newer iterrations of the ReScene tool in the future where such bugs will be fixed and RAR versions above 5.5 will be supported.

As you may guess, the ReScene process may be very timeconsuming, however, where one is limited with options, it is better than nothing. And last but not the least, some Data Hoarders rely on the information from DATs to make sure that they have all the correct files. However, such files as NFOs and SVFs may be different from time to time and you may not get the same CRC32 checksums for NFOs and SVFs as a result of ReScenening. Еhe situation may be partially saved by using the method described by @formeruser in this thread, however, EOF conversion via Notepad++ does not for me in 100% cases.

Or where i can download those dumps ?

You can find a CRC32 checksum for a particular unarchived release at srrDB and use this information to narrow down your search on the Internet. Specifically, some web-sites may provide CRC32 checksums for ROMs before the download so that you would be sure you have a correct one.

As for PS2 releases, you can definitely check 'emuparadise' as it seems to have original PS2 release in ISO format that can be potentially ReScened. At least, I was able to recgonize 43 releases by their CRC32 checksums and I would try to ReScene them at some point in the future.

Hope all this information helps.

 

[formeruser]

Spoiler: Dead.Space.3.Awakened.DLC-PLAZA

Let us take a look at the output of trying to rescene this release with default settings (irrelevant lines removed):

Spoiler: Log

:: srr -q Dead.Space.3.Awakened.DLC-PLAZA.srr
File OK: PLAZA\deadspace3.exe.
File OK: setup.exe.
File OK: setup-1.bin.
File OK: DLC_Bonus\ds3_v1_slot_01.sav.
All files OK!

:: srr -z RARDIR -o Dead.Space.3.Awakened.DLC-PLAZA Dead.Space.3.Awakened.DLC-PLAZA.srr
Re-creating RAR file: plaza-dead.space.3.awakened.dlc.rar

RAR [...] -mt5 [...] PLAZA\deadspace3.exe
RAR [...] -mt1 [...] setup.exe
RAR [...] -mt1 [...] setup-1.bin
1161598138
1161598081
Still not fine :(.

RAR [...] -mt1 [...] SRR-XXXXXXXX\pyReScene_method2.rar ALL_FILES
RAR [...] -mt2 [...] SRR-XXXXXXXX\pyReScene_method2.rar ALL_FILES
[...]
RAR [...] -mt12 [...] SRR-XXXXXXXX\pyReScene_method2.rar ALL_FILES

Re-creating RAR file: plaza-dead.space.3.awakened.dlc.rar
[...]
Re-creating RAR file: plaza-dead.space.3.awakened.dlc.r22

As you can see, pyReScene naturally started with the main RAR volume and added files in the order they had originally been archived in by compressing them separately. This seemed to work fine for the two executables but threw a completely unhelpful error message for the .bin because its compressed size did not match the value in the original RAR header stored in and read from the SRR. Thus pyReScene switched to "method2", which is just compressing all files at once, hence the very long command. After having increased the amount of threads with -mt until the checksum matched, it finally recreated the RARs and exited without apparent issue. But, like you mentioned, the main volume has the wrong hash.

By trying to rescene releases long enough one will find many for which a good RAR version is detected and that may even finish without error message only to have one or more corrupted files in the end. After having run into this problem myself a few years ago, I searched online for a possible cause and came across Da Fox's very useful comments on pyReScene's old

You do not have permission to view link Log in or register now.

. I will not rehash them here but the most important point is the thread count used during compression. Notice how it changes in the above log from 5 for PLAZA\deadspace3.exe to 1 for setup.exe and finally 12 for the alternative method.

After compressing the two executables and writing this data to the main RAR in the output directory, pyReScene keeps a handle to it while brute-forcing the right thread count in the temporary folder, which is why it cannot be opened directly. However, one can just create a copy of that incomplete .rar (8.8 MiB) and wait for the rescening process to complete "successfully". Comparing this file to the same amount of bytes at the beginning of the correct main RAR with valid hash (CRC32: 78787214) in a hex editor shows that starting at an offset of around 1.5 MiB the stored data is completely different, except for some small chunks inbetween, until setup.exe after which both archives are identical to the end. The corrupted data always is exactly the same even across entirely separate recreation attempts.
Since pyReScene switched to the alternative method to compress all files together with twelve threads, it should have produced the correct output, yet this was not the case. Therefore it must have purged only the temporary folder after each try but did not delete or overwrite the partial RAR in the output directory, that already contained the incorrectly compressed executable, before writing the proper data. Taking a look at the

You do not have permission to view link Log in or register now.

confirms this rather silly oversight as the cause of the wrong hash.

Because the first archived file is relatively small (18.8 MiB) the right thread count could be brute-forced within seconds. Here is the command that successfully rescened this release with 2016-08-15_rar540.exe to match the

You do not have permission to view link Log in or register now.

:

srr -z RARDIR --mt-set=12 -o Dead.Space.3.Awakened.DLC-PLAZA Dead.Space.3.Awakened.DLC-PLAZA.srr

Spoiler: Quantum.Break-SKIDROW

This time pyReScene detected the same correct RAR version and compressed the ISO with one thread but .r82 has the wrong hash, again, like you said.
Interestingly, despite the corrupt last volume, an SRR created from this broken release differs from the one on srrDB only by a single byte at offset 0x1A, the pyReScene version number (0.6 vs. 0.7). Since SRR files only store the header and footer of each RAR file but obviously not its content, this confirms an issue with the compressed data having the expected size but not the right hash, as mentioned by Da Fox.

Trying to recreate only the last volume using the -m option failed with "No good RAR version found" for all 32 -mt values. Having to brute-force a large release can quickly become a pain but luckily this one only uses "fastest" compression (-m1) so it did not take long to find the right value.

The following command successfully rescened this release with 2016-08-15_rar540.exe, though you will need to change the EOL format of the NFO to Windows to match the

You do not have permission to view link Log in or register now.

:

srr -z RARDIR --mt-set=8 -o Quantum.Break-SKIDROW Quantum.Break-SKIDROW.srr

Spoiler: General rescening advice

While this method does not guarantee success, in my experience it has worked many times and is clearly better than just giving up. That is why I mentioned it repeatedly, for example here and here.

Over time I have collected a long list of releases that only correctly rescene with a specific RAR version and thread count(s). While I unfortunately cannot give you the full file for hopefully understandable reasons, what I can share is some statistical data to try to help you out at least a little bit.
All releases use an -mt value of either just 1 or a common amount of CPU cores/threads, which makes sense when you think about it, so all other uneven numbers should be tried last.
Because most of the PREs are relatively recent, the most common values by far are 8 and 12 with the overwhelming majority of releases using 2016-08-15_rar540.exe, since that is the last version to create RAR4 instead of RAR5 format archives by default which older pyReScene builds relied on to function correctly. Also keep in mind that setting the thread count was only introduced with 2006-03-29_rar360b1.exe (

You do not have permission to view link Log in or register now.

, 0-16) and extended to the current range in 2012-05-03_rar420b1.exe (

You do not have permission to view link Log in or register now.

, 1-32).
Update PREs released close to each other tend to use the same thread count so try to quickly find it with the smallest release first then use that for the larger ones.

However, you obviously should not start with this method because the default settings work fine most of the time. The "Grabbing large enough data piece size for testing" step can also take a very long time for some releases and will have to be performed for every -mt value you try. I recommend the following process instead.

Download the SRR from srrDB and get the release date from

You do not have permission to view link Log in or register now.

(games-only) or a PreDB of your choice. Select all RAR binaries from the oldest (within reason) to the very next one after the scene release date and copy them to a rar folder inside of your rescene directory.
In case you are wondering about the odd RAR version selection, this is done because the scene group could have used a beta which may have produced different output than the latest stable release at that time, hence why pyReScene always starts with one version newer than expected. But after looping through older RAR executables in reverse chronological order it also tries all the newer ones which could not possibly have been used by the scene group unless they are time travellers. That is why you should not just use your global RAR directory but create a custom one for each release to save a lot of otherwise wasted time and also make it easier to remove versions in case they can be ruled out early.
A first script should verify your extracted files against the SRR and attempt to rescene the release using the default settings. If this fails to even find a good RAR version you can still try the next part but expect the probability of success to be very low. You have a much better chance if the reconstruction appears to have worked but there are a few hash mismatches.

Create a copy of the original SFV file that only contains the parts with incorrect hashes such as the first and last volume, then use a brute-force script to loop over all possible thread counts. On each attempt it should verify the hashes listed in the modified SFV and stop if they match, else try the next -mt value until all options are exhausted.

Here are commented example batch scripts:

You do not have permission to view link Log in or register now.

You do not have permission to view link Log in or register now.

They are rather simple with little error handling, since cmd absolutely sucks to "program" in, but should do the job in most cases.

Password: gNs7synOXRi1BrqgxlHz

Anyway, the correct QB .s82 was filled for you elsewhere some time ago and SHITROW's release was obsoleted by CODEX, but I have posted all relevant releases in their own threads in case others are interested.