ReScene is a mechanism for backing up and restoring the metadata from "scene" released RAR/music files. It was created to support the x264 community, but we have found that it works for many of the other "scenes" out there too.
How it works
Most of the various scene groups out there distribute their releases packed in RAR files. These RAR files, while useful for distribution, must be unpacked before the goodies inside can be used. Traditionally, this left us with a quandry. Do we unpack the files so we can use the goodies? Or do we keep the RAR files intact so we can trade them on one of those popular file sharing sites/services the kids are using nowadays? Or do we do both?
Well, with ReScene, you don't have to choose!
What's that you say? If you unpack and delete the RARs, there's no way to get back to the originals? Not true, my friends! You see, a RAR file is made up of two things: the data that we want to get out of them, and metadata that describes that data (file names, dates, and attributes) or that supports some of RAR's many other features (comments, authenticity verification, recovery records, etc.) While it is true that if you were to unpack a RAR archive and then try to re-create it exactly by just re-RARing it, you'd have VERY little chance of succeeding, if you back up all that metadata, you CAN re-create those rars EXACTLY as they were.
A typical RAR file looks something like this:
In this representation, the D's represent the data that is stored in the RAR file. The other characters represent blocks of metadata. If we were to unpack that RAR, this is what we'd have:
That's nice, because it's the data we're most interested in, but what about all that other stuff? We have no way of getting it back if we delete that RAR file. Even if we duplicate the settings originally used to create the RAR *exactly*, there's still a good chance the new RAR will be different than the old one. Did you know, for example, that RAR files include a byte that indicates what platform they were created on? So, if a RAR set was originally created on Linux, there would be no way to create that same RAR in Windows (without some hacking, anyway…). But what if we made a backup of the metadata before we delete those RARs? Something like this:
The X here represents the data that we extracted, and the rest of the blocks are copied exactly as they were in the original file. Now if we want to re-create that RAR, all we have to do is replace the X with the file data (D's), and we have the exact same file we started with.
How to use it
In its current version ReScene is pretty simple to use. The first thing you'll need is one of the scene releases I've been talking about. They will typically come with one or more RAR files and an SFV file that contains CRC values for those RAR files.
If you run the ReScene command-line utility (srr.exe) and pass the SFV file in as a parameter, it will read the SFV and locate all the RAR files from the release. The utility then creates a .srr file. The SRR file contains a copy of the SFV you specified as well as a backup of all those metadata blocks I mentioned earlier. It's typically a very small file (maybe 10-20KB depending on the number of RARs), and it is created very quickly (typically <1 second). Once you have that .srr file, you can extract the archive and delete the RAR and SFV files.
To re-create the original release files, all you need is the .srr and the files you extracted from the archive. Pass the .srr file in to the utility to start the reconstruction. The SFV file will be restored from the SRR file, and then each orginal RAR will be painstakingly (but quickly) reconstructed from the data files and the backed-up blocks in the SRR file. As a final step, you can validate the files against the SFV to make sure they came through the process unscathed.
You knew there had to be a catch, right? Ok, there is one, but it's small. This process only works on RAR files created with "Store" mode (otherwise known as -m0 or No Compression). That's not too much of a restriction, though, as most scene releases use this mode anyway. Also, I think it goes without saying that ReScene doesn't support encrypted RARs.
pyReScene had already the capability to create an SRR file of compressed RARs, but since version 0.4 there is support to reconstruct compressed RAR files. To accomplish this task it uses various WinRAR executables. It doesn't work yet for all compressed archives.
MKV/AVI ReSample is a companion to ReScene, and it does for samples what ReScene does for RARs. You can use MKV/AVI ReSample to build a blueprint of an MKV or AVI sample, and then use that blueprint with the full release to recreate that sample
How it works
Scene rules for x264 and xvid require that all releases be accompanied by a sample. That sample must be cut from the full release and not encoded separately. This rule leads us to conclude that the audio/video/subtitle data from the sample must exist somewhere in the full MKV or AVI file.
Now, if you ask me, keeping a copy of said sample is rather pointless if you already have the release. It's the same data, after all. But some people are sticklers for completeness, and to balance between their point of view and mine, I [umlaut] created MKV Resample.
The ReSample process is simple in principle (if not in practice). The principle is very similar to ReScene. We know the full release contains the bulk of the data for the sample; it's just missing the metadata. For example, time codes in the sample are different from those in the full MKV.
MKV files (both the samples and the full releases) are just containers that wrap up A/V tracks. There should be a track for video, one or more for audio, and zero or more for subtitles. ReSample identifies these tracks in the sample, and builds a signature for each track so that that portion of the track can be located in the full MKV. It then backs up the metadata from the sample MKV along with those track signatures into a SRS file.
With the SRS file and the full MKV, we can recreate the sample. ReSample scans the full MKV looking for those track signatures, and when it finds them, it extracts the correct amount of data for each track. Then, using that extracted track data and the metadata backed up in the SRS file, the sample is rebuilt. As a final step, a CRC check is done to verify that the rebuilt sample is bit-for-bit identical to the original.
pyReSample also supports MP4 and WMV sample files and MP3 and FLAC music files. For the music files it takes a backup of the meta data so it can be restored later. This meta data includes tags such as ID3v1, ID3v2, Lyrics3, Lyrics3v2 and APE. Upon SRS creation an AcoustID fingerprint is generated and included. The SRS file is similar to those for samples, so it includes information like the file name and CRC32 hash. It is strongly suggested to use pyrescene.py to generate music SRRs because it won't add any SRS files for which the music file doesn't match the SFV.
There is currently no tool yet that can fix the tagging for a whole music release at once. Each bad track must be fixed separately by srs.py.
What others say about ReScene:
- SRR Files, What are they, How to use them - Ghacks
- SRR Files Explained in Plain English - TechSono Engineering, Inc.
- ReScene - Rebuild Extracted Scene Releases Into Rars - FileShareFreak
- Don’t Repack it, ReScene it! - Scene Lingo
TorrentZip is a replacement for MameZip. The goal of the program is to use standard values when creating zips to create identical files over multiple systems.
The problem was that on each PC the zipping does not create 100% identical files, so it was useless for using it with BitTorrent. If you use this torrentzip-tool, it creates always the same file with the same size and checksum (it doesn't matter on what PC you have done it). It does so by exactly specifying the order of the files, timestamps and values for several fields in the zip headers. In that case you can join a torrent and it does recognize your ROMs as the same as the seeder has. You can recognize these ZIP files by the TORRENTZIPPED-XXXXXXXX comment.