Hey,
You will need at least one of these 2 things to start your journey: an SRR for that release, or one of the original RAR volume, even damaged. Otherwise, you'd better give up, as some of the information will be almost impossible to guess. If you do own this or that, then there is a chance of success, and you may continue your reading. :)
I would also like to give a few corrections to your saying: the level of compression should always be the same, as it's part of the scene rules: releases need to be RARed with "-m1". Actually, to be more accurate, I believe only "-m0" is forbidden, but since all this is supposed to be a race, you will really rarely (never?) see a release done with a bigger/slower level of compression, as it could be enough time loss to loose the race. Then regarding the RAR version, well, I don't know why the creator of ReScene made it such a big thing as it's actually not really. From my experience, the main algorithm didn't change that much, and most of the RAR versions would produce the exact same results. Try yourself, you'll see that if you use the same source file and switches, you'll get the same CRCs with almost every RAR version. I unfortunately lost the details, but from my finding, there was like 10 changes that altered the algorithm results, and thus only 10 main versions to stick on. It's easy to find back though, just script a loop to try them all, then compare the CRCs obtained…
So lets start. First thing to check is the ISO last write timestamp. In your example, "release_name.iso" is probably timestamped to the time you've downloaded it. You need to re-timestamp it to the original ISO last write time. You can do this "easily" by running "srr -e Release_Name.srr | findstr FTIME" to spot out the FTIME value. Once you got the proper last write time, just amend your ISO file. I personally do it with PowerShell. Let say the FTIME you found was "2020-02-02 20:02:00", then you just have to run this command: "(Get-Item .\release_name.iso).LastWriteTime = "2020-02-02 20:02:00".
Then you need to know the dictionary size used to RAR the release. The norm these days is often 4MB (-md4m), but it has changed a lot over the years, so it will depend on when your ISO has been RARed. If you own an SRR file for that release, "srr -e Realease_Name.srr | findstr LHD_WINDOW" should return the dictionary size, if you own one of the original RAR volume, "rar lt release_name.rXX" should return some very useful information, including the compression level and the dictionary size at the last line. For example "RAR 1.5(v29) -m1 -md=4M" means again 4MB.
Then you need to know how many cores got used to RAR the release. In other words, you need to "guess" what was the CPU used by the packager… After repacking some yourself, you'll end up with your own DB of guesses for each release groups and era. But good tries these days are often 16, 24, 32 or even 48. A good thing is that 1, 2, 4 & 8 were/are also common ones, and should all produce the same result than 16 & 32, so I would definitely start by trying 16. By the way, max is 64. RAR can't currently handle more. (didn't try with RAR v7 though, but not relevant for us, will tell you why soon)
And finally, you need to force the use of RAR4 by adding the switch "-ma4". By the way, it's not possible anymore since RAR v7.00, so I would recommend sticking on RAR v6.24 which is probably going to be the most used one, at least on recent releases. They've also removed the "-vn" switch used to force the old style volume naming, what a shame… :(
That's it! This should be enough to recreate 90% of the releases. There is of course some other traps & tricks, but rarely met. You've actually mentioned one, which is the OS used to package the release. it's a more tricky one that you might think… You can find out the OS by running "rar lt" like already done before. It is stored at byte 0x23 of every RAR volume: "02" for Windows, "03" for Unix & "04" for MacOS. You could amend it manually with an hex editor, but you have to know that each segment of a RAR file ends with a CRC check to tell if it has been damaged or not. So if you amend the OS byte manually, you also need to recompute & amend the said CRC… which means you will also need to amend the main CRC contained in the last segment, and computed using all the previous segments… which means you will also need to recompute & amend the CRC of the last segment. Oh, and there is also the file permissions stored from byte 0x2F to 0x32… Erh… In other words, that's probably where we all decide to give up.
There is one last case that I didn't mention. Depending on how the packager scripts are done, it is possible that the ISO file got stream RARed using the "-si" switch. This would change some bytes here and there, and this will always amend the FTIME to current time, so you cannot force the original one anymore. Again, unless you're ready to hex edit and recompute CRC segments etc, better give up.
As a final thought, you should keep in mind that some release groups are using their own modded RAR version. When that's the case, srrDB displays this warning at the end of the release page: "Custom RAR packer detected". In these case, there is nothing you can do to reconstruct, that's a 100% give up.
I wanted to dev something using all the knowledge I managed to gather over the years, but never really had the time. If someone does, please, feel free to use my findings and/or contact me. :)
Hope it helped.
