Frequently Asked Questions

ReScene

What is this .srr file?

The .srr file is the format used by ReScene. It contains backups of all parts of the RAR files that are not the actual archived data. It can also store any other miscellaneous release files (e.g. SFV, NFO, etc). It is also an extensible format that will allow for other uses in the future.
Why does the application pop up and then close as soon as I open it?

You probably double-clicked it. It's a command-line utility. Run it from a command prompt, and it will tell you how to use it.

How big is a typical SRR file?

It depends on a number of factors, including whether or not it contains stored files (like NFO) and how big those files are. But most are less than 50KB. In fact, with no stored files other than the SFV, they can be as small as about 10KB.

Can a 10KB SRR file really recreate 95 100MB RAR files?

Well, not on its own. You still need the extracted data from the original RARs. But as long as you have the extracted data, yes, 10KB is a perfectly reasonable size for an SRR file

What does SRR stand for?

Scene Release Reconstruction. That was its name before a better name was suggested (thx alchemy!)

What happens if I try to rebuild a release and the extracted files are corrupted?

Good question. There are two main possibilities:

1. If the extracted file is not the same size as the the file contained in the original release, ReSecene will give you an error and abort, so you'll know right away.

2. If the extracted file is the correct size but has some corrupted sections, ReScene will not (at least at present) give you any errors or warnings. This is part of the reason it is recommended you test the reconstructed release with SFV before using it. In most cases, the corruption will be limited to a single RAR, and the SFV will help you identify it. You can then replace or repair that RAR from another source. Note that the .srr file actually contains enough CRC data that we could identify errors encountered during the reconstruction process. This feature will most likely make it into a future release.

Do I need to keep the SFV file after I have created the .srr?

No. The .sfv file used to generate the .srr is automatically stored in the .srr. It will be restored from the .srr when the release is reconstructed.

Can I save an NFO file in the .srr?

Yep, just use the -s switch with the srr utility, and give a list of files you'd like to include in your SRR file. It even supports wildcards (e.g. -s *.nfo)

Does ReScene use WinRAR?

No. ReScene is completely self-contained and does all of its own RAR file processing
Since 2013 the rar.exe executables are required for reconstruction of compressed archives.

Why doesn't ReScene work with compressed RARs?

While the RAR file format is open and fairly well documented, RAR compression is proprietary. Since ReScene cannot re-create RAR compression, it can't re-create compressed RAR files.
It does! External executables are needed for this. But there are still bugs though.

I thought it was impossible to re-create scene RARs once they were extracted

First of all, that's not a question. And second, yes you can. See the "How it works" section on the home page.

But surely it can't be perfect. It can't match the original SFV

Again, not a question. And again, yes it can.

Really?

Yes.

Really??

Yes.

Really???

Ok, that's just annoying. I'm leaving now…

A release pred in 2005, but a good rar version that was found is from 2006. This is this a repack for sure?

Not necessarily. Multiple RAR versions can produce the same compressed data. The files can be created with a beta version and the next stable release will be after pre.
In this example however, 2005 would be version 3.51 or older and 2006 would be at least version 3.60 beta 1. Experiments show that 3.40 (and 3.51 too) and 3.60 do not give the same results. However, there is one case where they can be the same: -m1 as compression level.

What dependencies/libs does ReScene need to work on a Linux x64 platform?

You get the following error when trying to reconstruct compressed RARs:

OSError: [Errno 2] No such file or directory
Unexpected Error: [Errno 2] No such file or directory

Make sure you can run the 32 bit rar binaries:
http://askubuntu.com/questions/133389/no-such-file-or-directory-but-the-file-exists

Get libc6-i386, and "got to install lib32stdc++6 too on Ubuntu 14.04"

2003-01-15_rar311: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory

"hmm my system is missing "libstdc++-libc6.2-2.so.3" on Wheezy"

"lib32stdc++6 lib32stdc++6-4.7-dbg libc6-i386" are needed for Debian 7.8

32bit rar binaries on Linux Mint 17.1 64 bit:
http://ubuntuforums.org/showthread.php?t=1517863&page=2&p=9518159#post9518159

"lib32-libstdc++5 from multilib worked" on Arch Linux

Another error possible on Arch Linux with old rar binaries: (quick fix: remove the really old files)

Fatal error: glibc detected an invalid stdio handle

"Could not find installed UnRAR version." error message with preprardir.py

Do what it says: install unrar or rar.
Linux users can move out the .sfx files to avoid having to do this. rarlnx26.sfx and others are actually rar archives, but there's only a small chance you'll ever need them.

How do I create a .srr file?

Use pyReScene Auto. It's a command line tool (pyrescene.exe/py) that can recursively create proper SRR files for various kinds of scene releases (movies and music). The .NET GUI has various bugs and doesn't work for music or compressed releases. It also won't work when the releases are on a read only location (Auto will work just fine). Do pyrescene --help to show all your options. pyrescene --best -r folder will create SRR files for all the releases in folder. With -o path you can add the location to put the SRR files. Otherwise the current folder will be used.

ahhh.. this is just too much. Why not make an easy program.. select a folder and click make .srr

I will be doing the more important stuff first. So far no one has made a GUI (or just a wrapper) for pyReScene yet. In the source there is a script included that will add a menu item when you right click a release. Run ashellextension_setup.bat for the Windows context menu setup. In ashellextension_srrit.bat the actual command can be set up. See the pyReScene Python setup page to run from source.

What is the OSO/ISDb hash?

The OSO hash is a quick hash, based on the first and last 64 KiB of a file, used by opensubtitles.org and tools to quickly find a matching subtitle for a video file. This hash is created and stored by pyReScene in the SRR file. It can potentially give a quicker match of an SRR file to the a video file when batch reconstructing or verifying series. SRR files are all about collecting meta data as much as possible and it enables us to reliably collect these hashes in combination with a matching file size and file name.

The documentation of this hash can be found on opensubtitles.org.

The original algorithm for the ISDb protocol was thought out by Gabest, the author of DirectVobSub and Media Player Classic (guliverkli). ​Gabest's ISDb design was an online distributed subtitle database. A distributed subtitle database was available on isdb.saxtus.gr.
History: http://blog.opensubtitles.eu/opensubtitlesorg/downloading-subtitles-using-mpc
Other protocol: http://trac.opensubtitles.org/projects/opensubtitles/wiki/OSDb
First ISDb subtitle database mirror from Tari in 2004: https://web.archive.org/web/20041112045829/http://sub.sytes.net/mirrors.php

If you look back to opensubtitles history background, you will know, we take hash in MPC, take existing database, make service freely available for everybody and every program, we kept “the standard” of hashes, and thats why you can find the most subtitles on os. -- os on April 19, 2009 at 2:54 am

What's in a name? The OSO name (OpenSubtitles.Org) is chosen by Gfy, the author of pyReScene to name the damn thing. Neither the inventor nor the the opensubtitles admins gave the hash a specific name to call it by. The OpenSubtitles Administrator uses oss hash to refer to it. Looking back researching and writing this entry, ISDb hash would be a better choice.

How do I srr when there are parentheses () in the release name?

syntax error near unexpected token ‘(’

Surround the folder name with double quotes: #linux #bash

pyrescene "Artist-Title-(CDS)-GROUP"

ReSample

What is this .srs file?

The .srs file is the format used by ReSample. It contains backups of all parts of the MKV file that are not the actual track data as well as a signature that helps ReSample locate the missing track data from the full MKV.

How big is a typical SRS file?

Depends on the size and content of the sample. For a 50MB sample with 1 video and 1 audio track, it may be anywhere between 20KB and 50KB. It can be larger for longer samples or samples with more audio or subtitle tracks.

It also depends on the container format (AVI vs. MKV). You can think of the SRS file as a backup of the container 'overhead'. Since MKV is more efficient than AVI, an AVI SRS file will be several times larger than the MKV equivalent.

How long does it take to create an SRR file?

Not long. My testing has shown it usually takes less than 1 second. Somtimes a little longer, but never more than a few seconds.

How long does it take to recreate sample from the SRR file?

That depends mostly on where in the full MKV the sample is cut from. If it's from the first few minutes, it will only take a few seconds. If it comes from near the end of an 8GB MKV, it will take longer to do the search for the signature. I have seen VERY few releases that take more than a minute.

Why does the application pop up and then close as soon as I open it?

You probably double-clicked it. It's a command-line utility. Run it from a command prompt, and it will tell you how to use it.

What does SRS stand for?

(Something) Re-Sample? Nah, it doesn't stand for anything. It's a companion to ReScene, so it has a similar file extension…

Can MKV ReSample detect an incomplete sample file?

It sure can! In fact, if the sample file is incomplete or corrupted, ReSample will return an error and not create an SRS file. If you'd like to use ReSample just for validation of a file, use the -i switch, and it won't save an SRS file.

Retail CD to scene FLAC, is this possible?

Theoretically, but it'll be more practical to find the original files. Here is a write down of the problems involved: CD to FLAC.

Can I reconstruct a .m2ts file?

No. The .srs files for those samples contain only a "fingerprint", the file name, size and CRC32. They are only around half a kilobyte in size. The format is the same as SRS for VOB files, but reconstruction almost never works. It is used as a well structured alternative for this info instead of a text file.

srrDB

I want to know how I can download from srrdb

To anyone asking this question: you can't.

Let's recap: No, you can not download that rare file you are looking for!

There are warnings for this at the top of the first page of the wiki, random srrDB quotes, the chat page, the registration page and my contact page.

Whats the deal with subs? Sometimes only the sfv is stored in the srr, and sometimes there's an additional srr for the subs inside the srr for the release.

Ah, the Russian doll SRRs. Not all releases have been (re)created yet with the latest pyReScene code. Those additional .srr files must be created with pyReScene Auto. It works recursively and adds a languages.diz file with a list of available subtitles from the .idx.

You can create the .srr file of the vobsubs without having the complete release with the --vobsubs=VOBSUBS_SFV option.
Reconstruction isn't automated and will have to be done in steps by extracting and recreating the right files.

There is an ampersand in the release name. How do I upload it?

Remove the strange character (ampersand, comma,…) from the release name. Add a file releasename.txt to a folder with the correct release name. The text file will contain the correct release name again. Some examples:

Archived files in stored files list for reconstruction

The naming convention is as follows:

part1/[part2]/part3/part4.ext
  • part1: the path the containing archive is located at (optional)
  • part2: the name of the containing archive surrounded by square brackets (not optional)
  • part3: internal path (optional)
  • part4: the file name of the archived file

The optional parts are only optional when there are no values for them.

Examples:
http://www.srrdb.com/release/details/Movie.Player.EUR.3DS-CONTRAST
http://www.srrdb.com/release/details/Shadow.Dancer.2012.LiMiTED.BDRip.XviD-NODLABS

Proof/[shadow.dancer.2012.limited.bdrip.xvid-nodlabs.proof.rar]/shadow.dancer.2012.limited.bdrip.xvid-nodlabs.proof.jpg

The RAR file contains a source sample too so the archive volume itself can't be stored. This way the image is still available for viewing and grabbing.

In the future these files won't be shown in the stored files anymore, but at the bottom with the archived files. Tooling will prevent their extraction and will make use of them for reconstruction. A flag in the file format will be added and it will be stored the same as the stored files now.

Why is there this "p2p" release on srrDB?

tl;dr: If it has originally been released in RARs, the SRR is useful, so it can stay.

Generally speaking though because we won't be adding homemade stuff just because it originated from Usenet in RARs. Most real p2p stuff hasn't been released in RARs anyway. But those that do, often look very much like a scene release. Thus they end up in private archives. They will be reuploaded over and over again. Not having those files is just creating a worse problem. You don't want to see them? For now, your problem, don't make it ours. There are barely any compared to the amount of files we have. Eventually we'll start linking to predb data so you can filter/detect and then everyone is happy.

Since we don't do politics, it's not up to us to decide what's scene and what isn't. It'll prevent discussions and memory holes. A post BBS old school scene source (from before the busts) suggests that nukenets are more or less directly tied to p2p/torrents. The nuke networks were created by p2p, but they try to keep those ties hidden. By now things could've faded, so let's not get started…

And then there still is the history aspect of things. Similar issues arise in the demoscene. Here is a quote from ChipFlip:

Well, they are effectively being distanced and erased from the history of the demoscene by not being included in archives like CSDb and HVSC that exclude “irrelevant” things.

Let's try not to do these things for stuff that fits within the scope of SRRs.

SRR X is a misnamed dupe. What should I do? (admins)

An example: http://www.srrdb.com/release/details/Bone_Thugs-N-Harmony is a cut echo from http://www.srrdb.com/release/details/Bone_Thugs-N-Harmony-Art_Of_War_WW_III-2013-H3X

Case 1: it can be found in a predb.

2012-05-03 18:06:13 Bone_Thugs-N-Harmony

Keep. Don't be the cleaning lady!

It indicates it actually existed and was not some predb error/spam. It can also give us a better possibility to give feedback of issues later. Sure, you don't want to have it in your personal collection like that, but for srrDB it has value.

In our specific example, Bone_Thugs-N-Harmony was pred more than a year before our example. It was probably from Bone_Thugs-N-Harmony-The_Collection_Volume_One-READNFO-CD-FLAC-1998-PERFECT. This shows us that actually two different releases have been cut to that same name. How is that possible? I don't know, but it sure is interesting.

What's that about the cleaning lady you ask? Well, it's documented for multiple occasions that a cleaning lady threw away some expensive art. Were they stupid? I can't tell, but it's understandable! It actually looked like trash. Knowing this, let us try to not throw away the valuables with the trash. When in doubt: keep. Problem can be that the less informed do much worse than how they perceive they do it. (Dunning–Kruger effect) This is how things get lost.

When it looks like a human rename pred much later (not a cut), it could be removed to avoid having it confused with the correct original release name. When in doubt: keep.

Case 2: not in a predb.

Many examples of this can be found in the 'List duplicates' admin queue. These we have often com from Usenet. The leading *The.* or *A.* can be missing. It can also be the name used on the post. These files can be removed. Currently we keep a list of bad releasenames on the wiki. All of them have a good SRR on the site.

Make sure the good SRR has all the same files as the file you are about to delete. Download, rename and upload again seems to work best.

Release X is a repack. Why are there SRRs ending on ___repacked?

If we can confirm something is repacked, we will remove or replace it. But sometimes the original RARs are very hard to be found again and everyone has the same old repacks. In this case we reupload the SRR and add ___repacked to the end of the file name. This way we will have the ability to detect reuploads of repacks.

How do I report bugs?

Use one of the many ways to contact us:
https://bitbucket.org/Gfy/pyrescene/issue/32/need-verification-of-sfv-file-before#comment-9477905
https://bitbucket.org/Skalman/srrdb/issues?status=new&status=open

Is this a bad srs?

  • Man.vs.Wild.S07E03.Iceland.Fire.and.Ice.720p.HDTV.x264-MOMENTUM: Unable to locate track signature for track 1. Aborting.
  • Pocahontas.2.Reise.in.eine.neue.Welt.German.1998.DL.1080p.BluRay.x264-AMBASSADOR
  • Fight.Club.1999.REMASTERED.REPACK.1080p.BluRay.x264-WLM
  • …

There should be no such thing as a bad SRS file. There are bad samples though. If samples are broken, no SRS files will be created. The most common reason when a sample fails to reconstruct, is that the sample isn't created from the main video file. An other reason could be that the SRS file is from an other release being propered. In this case, you will need the nuked release to reconstruct the sample.

Samples of the Xvid releases from LOL are known for not being able to reconstruct properly. If someone can tell me what is different, I might be able to fix this issue.

When a sample is checked against a main video file, the offset to that location is included for faster reconstruction. When a sample is verified against itself, it'll fail to reconstruct when trying it on the main video file. The -m parameter on srs can be used to ignore this offset.

How should sample fixes be added to the SRR file?

We try to keep as much as possible from the original meta data. An example: http://www.srrdb.com/release/details/That.70s.Show.S01E04.DVDRip.XviD-RiVER
If the samplefix release contains a Sample subfolder, add it to the path.

How come I can't reconstruct a release with ReScene .NET 1.3.3 GUI (beta)?

  • Because it's old, out of date, closed source beta software. Try the latest pyReScene when stuff doesn't work.
  • The most common reason is that compression is used on the RARs. Reconstruction is only supported by pyReScene. Have a look at one of the tutorials for help.
  • You get the following message: WARNING Unknown Block type (6c) encountered in SRR, consisting of 29 bytes. This block will be skipped. The original RARs were probably not created with WinRAR and have some padding bytes at the end of RAR files. Use pyReScene 0.5 or newer to reconstruct those RARs.

Is there anybody here?

Just ask your question already and wait.

srrdb-uploader

Where can I find the upload scripts?

http://rescene.wikidot.com/upload-scripts

'Release-NAME.srr' already exists. When this happens, does it actually upload and see if things are different or is it skipped?

The upload scripts always upload to the site. Dupe checking and handling occurs there, not in the scripts. Uploading dupes is a good thing because it helps us find errors and missing files in already existing SRRs.

Srrdb-uploader has only two messages: 'was added' and 'already exists'. With the srrdb.com web uploader you see more different messages. The script could also output html if there is some case it doesn't recognize.

On the site: if the meta data is different, it'll end up in the collisions queue (e.g. it has the meta data of a .rar proof file in there too because of a bug in pyReScene Auto 0.5). If the SRR hash matches, new stored files are added to the adds queue; if necessary the OSO hash is copied over the the existing SRR, and the new SRR is discarded.

srr_usenet.py

"Choosing between two same files yEnc." What does this error message mean?

The original output looks like this:

Choosing between two same files yEnc.
Choosing between two same files yEnc.
Choosing between two same files yEnc.
Traceback (most recent call last):
  File "srr_usenet.py", line 1228, in create_srr
    read_retries=read_retries)
  File "F:\Installed\pyrescene\Gfy-pyrescene-817ae49c6aa2\usenet\..\rescene\main
.py", line 607, in create_srr_fh
    raise ValueError("No SFV or RAR file supplied.")
ValueError: No SFV or RAR file supplied.
No SFV: trying again from the first RARs.
No SFV or RAR file supplied.
F:\Downloads\_NZB\28768 altbin.srr
no sfv: 1
result: 0
QUIT sent to main server. NOTHING created.

I was confused about this myself, so I changed the code so it outputs Choosing between two same files: 'yEnc'. In this case yEnc has been detected as filename. This means that all files inside the NZB are detected this way. binsearch.net couldn't detect correct file names either, so they added the following warning to their site:

Warning: this post may be indexed incorrectly.

Binsearch groups files into collections based on their filename.
Because the poster used a non-standard subject line, the system was unable to determine the filename with certainty.
Detected filename: " - rld-rc06"

Fix the NZB yourself by adding " around the file names.

How come…?

Yes, weird stuff can happen for various reasons!

<Gfy> Segment size: 249600B; grabbed    127B (wrg-rs2.rar), segment number: 1
<Gfy> Segment size: 249600B; grabbed  89254B (wrg-rs2.rar), segment number: 199
<Gfy> Segment size: 249600B; grabbed 249600B (wrg-rs2.rar), segment number: 185
<Gfy> dict: {'part_end': 46176000, 'file_name': 'Twilight Zone Ep 120.part6.rar', 'part_begin': 45926401, 'part_size': 249600, 'part_number': 185, 'file_size': 50000000, 'data':
<Gfy> sometimes the server returns something totally different

Scene

What is the difference between RIP and 0day? How does one identify a game RIP?

There is no difference. All rips of ISO games are considered 0-day. The GAME RIP nomenclature isn't scene based because all 0-day releases go into daily folders.
When the scene moved to an FTP based architecture every game went into a dated folder for only about 60-70% of FTPs. The rest had "sections" UTIL(S) and GAMES.[1]

What are the origins of Game ISO scene?

"Game ISO started in August 1997. There were game ISO releasers popping out of the woodwork. They had a meeting in December 1997 to get it more organized. Different groups were releasing ISO's of a bunch of older games because they never were released on ISO. Releases were come out in all different kinds of formats like CIF. File sizes on the archive files were all different sizes also. They didn't even start using sfv files until around May of '98.
Here's some ISO releases you young peeps probably never heard of:
World_Of_Billy-RiSCiSO (Jan '98) (r-billy.rar - r-billy.24 367.02MB)
Bust.A.Move2-RZRISO (Feb '98) (bust2.rar - bust2.r04 62MB)
Star.Trek.Pinball-RiSCiSO (Feb '98) (trekball.001 - trekball.019 265.59MB)
Anastasia-RiSCiSO (Feb. 98) (anastasa.001 - anastasa.017 239.72MB)
Armor.Command-CiFE (Feb '98) (armorcom.001 - armorcom.041 584.97MB)
The_Space_Bar-LEGACY (Feb '98) (multiple cd's)
Alien.Earth-RZRISO (Feb '98) (aebincue.001 - aebincue.049 698.1MB)
MoonChild-CAMELiSO (Mar '98) (moonchild.rar - moonchild.r40 589.44MB)
Ultimate.Race.Pro-ISOCD98 (Mar '98) (ultimrp.rar - ultimrp.r30 460.87MB)
Triple_Play98-RiSCiSO (Mar '98) (triple.rar - triple-r40 592.73MB)

I could go on and on. The problem back then was disk space and cost of CDs. That's why there was very little archived or moved of ISO that started being scene released in 1997, plus why there's very few records of it. You find some oldtime sceners from RiSC, RZR or CiFE and they'll tell you what I'm saying is spot on."

"On AOE.Gold.Edition-CERTiSO: The files for that release were aoegold.rar - aoegold.r36. The last file was 2.67mb. You're not going to find that anywhere. Most people back then just burned the ISO and discarded the RARs because storage was expensive back then. Groups like RiSC had huge archives but RiSC was busted. The common edu scene sites of the day with college kids running servers wouldn't keep anything over a month or so. There were some scene sysops that archived sh1t to tape or CDs but those dudes are long gone.
One of the major problems was that cable ISP connects weren't available across the entire US during that period of time. Canada had a lot of peeps running sites that had cable connects. Most "top" sites were the aforementioned edu sites with lower tier sites at fractional T1 speeds with peeps running sites from a local business connect. All of the edu sites went the way of the dodo because most were busted.
If the FEDs kept the servers from MIT and didn't nuke the contents then you'd have a f*cking gold mine of old game ISO. :D"

http://defacto2.net/wayback/a-primer-to-the-iso-scene-circa-1998/

Bibliography
1. https://commons.wikimedia.org/wiki/File:Pftp-99.png shows /incoming/utils and /incoming/04-28 folders
page revision: 49, last edited: 21 Nov 2022 13:56
Edit Tags History Files Print Site tools + Options
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License