Showing posts with label Inside The Scene. Show all posts
Showing posts with label Inside The Scene. Show all posts

24.7.10

P2P Elite: P2P Database and Release Group Home



P2P Database and Release Group Home

The idea behind it is:

Giving the P2P a 'Pre' Database, like Scene w/steriods. Not only does it have a full feature database, which release groups can post the title, pictures, nfo, samples of the releases but soon it will feature a voting/ranking system which is being put in to rank release groups. Video, Audio, Compatibility. Voting continues until something better gets released, then the scores get tallied up; for a winner. Example, a CAM gets released by a group. That groups gets points for being first. Then every other group will release theres... members of the site chooses which is best by ranking video, audio, compatibility. Then when a TS gets announced "pre" then the voting automatically stops and the winning CAM gets a green check and the release group gets points (respect points) comments can be left for releases also.

Now with the profile system, release groups get a profile like myspace. Members of the site also get profiles and it has added features like being able to use myspace layouts, post youtube videos on there profile and post them into the system for ranking and comments, PM other users or groups, release group list with ranking, you can have open debates with the community, chatroom built in and soon to be built into the release groups profile pages, built in instant messenger to chat in real time between each other, file sharing, picture sharing with private pictures option.. so much more and more coming.

Current release groups who have helped and bug tested are (members):
Rx, 420Demons (*THC*), PrisM, iMAGiNE, KiNGDOM, FLAWL3SS, MAGNET, n0ir, [NoFS], Blackjesus...
and its only been a week. (going to be featured in nfo files as a contact point)


Site NFO: Here 
PRE Database: Here

9.5.10

OFFiCiAL.NULLED.SCRiPT.RULES.2010

+-----------------------------------------------------------------------------------------------------+
Åš                      OFFiCiAL.NULLED.SCRiPT.RULES.2010-DRAFT2                                       Åš
Åš                                                                                                     Åš
+-----------------------------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------------------------+
Åš     Requirements: Notepad with terminal font or any other ascii viewer.                             Åš
+-----------------------------------------------------------------------------------------------------Åš
Åš Date: 04.05.2010 - 20:00 GMT+1                                                                      Åš
+-----------------------------------------------------------------------------------------------------+
Åš    To all 0Day groups that are interested: This ruleset is only a draft
Åš     if someone wants to fix something, or add a rule then you can
Åš     reach us under our email adress (on the bottom of this NFO)
Åš
Åš    If no one reacts to this Ruleset until 10.05.2010 (DD.MM.YYYY) we will pre it 1:1 as final.
Åš
Åš    PS: Help at translating in other languages (ES/FR i.e.) is always wanted.
+-----------------------------------------------------------------------------------------------------+
Åš
Åš-ENGLiSH-
Åš
ÅšiNDEX:
Åš    0: General Rules
Åš    1: Packaging / NFO
Åš     1.1: Examples
Åš     1.2: NFO
Åš    2: Naming
Åš     2.1: Themes/Addons
Åš     2.2: Updates
Åš    3: NULLiNG Rules
Åš     3.1: KEYGEN Rules
Åš    4: NUKE RULES / REASONS
Åš
Åš    Prolog:
Åš   Since the last PHP Nulling group faded away long time ago there were no rules for PHP scripts...
Åš   So we decided to write new ones so that we, and other groups, can start releasing scripts
Åš   with a basic ruleset that provides help at cracking and releasing.
Åš
Åš   In general the actual 0Day Rules apply for all not discussed themes.
Åš
+-----------------------------------------------------------------------------------------------------+
Åš
Åš     0. General Rules
Åš         -NULLED dupes KEYGEN -NOT- (and vice versa), both has good sides.
Åš           because of this there are 2 releases per script allowed (excluding PROPER/REPACK etc.)
Åš         -BETA/ALPHAs need no INTERNAL tagging
Åš         -CRACK.ONLY / KEYGEN.ONLY / KEYFiLEMAKER.ONLY is only allowed if the software
Åš           (i.e. as Full, Unlockable Demo version)
Åš           is downloadable for free and without registration at the manufacturers website
Åš           Usualy it is better to include the files for Archive reasons, and because it does not
Åš           dupe NULLED anyway.
Åš         -On-the-Fly Patches are allowed if the script needs a system variable (ID i.e.)
Åš           to work, but Pre-Patched (to all IDs for example) is preffered over that.
Åš
Åš           This has to be tagged in the following format:
Åš           
Åš          
+-----------------------------------------------------------------------------------------------------+
Åš
Åš     1. Packaging
Åš         -Standard 0Day Packing, Filenames max. 8.3 Characters (Name.typ - 12345678.123)
Åš          Releases are needed to be RARed - Compression is allowed but not mandatory.
Åš          Each ZIP should be 5000000 Bytes (5Mb).
Åš          Therefore the size per RAR is around the same.
Åš          Bigger filesizes are allowed, look at actual 0Day Rules.
Åš
Åš
Åš       1.1: Example
Åš             12 Files - 26Mb
Åš             -5x 5Mb RAR + 1x 1Mb RAR -> grprls.rXX
Åš             (The RARs can also be only named .rXX)
Åš             --Each RAR in a ZIP
Åš             --5x 5Mb ZIP + 1x 1Mb ZIP -> grprls.zip
Åš             (The actual naming is the groups decision (a|b or 001|002, 01|02, 1|2) )
Åš  
Åš             Each ZIP needs to include:
Åš              xxxx.rXX - file_id.diz - .nfo
Åš
Åš             Wrong naming of RARs/ZIPs is no Nuke reason, unless some other reason applys to:
Åš              (dupe.filenames, special.chars u.a.)
Åš
Åš
Åš        1.2: NFO
Åš              The NFO needs to contain:
Åš              -Release Date
Åš              -Size (or Diskcount)
Åš              -Developer Website
Åš              -Version
Åš              -Short description (Copy & paste)
Åš              -Languages (if MULTi)
Åš              -Short usage description 
Åš
Åš              In the NFO wanted is:
Åš              -Price (Currency does not matter - Copy from website)
Åš
+-----------------------------------------------------------------------------------------------------+
Åš
Åš     2: Naming
Åš         Naming under following scheme:
Åš          <> = needed | [] = additional
Åš         Language tag is only needed on non-english only Releases.
Åš         For the rare case that only 2 languages are available
Åš         it has to be tagged BiLiNGUAL.
Åš
Åš       .[Edition].v.[Language|MULTi|BiLiNGUAL].
Åš       .
Åš       [Beta|Alpha|RETAIL|REAL].[iNTERNAL|iNT|DiRFiX|NFOFiX|PROPER|REPACK|READ.NFO].
Åš       -GRP
Åš
Åš   Examples (fictional):
Åš
Åš   Vbulletin.v5.1.NULLED.PHP-GRP = Vbulletin 5.1 English, Nulled
Åš   Vbulletin.v5.1.KEYGEN.ONLY.PHP-GRP = Vbulletin 5.1 English, Keygen Only
Åš   Vbulletin.v5.1b3.NULLED.BETA.iNTERNAL.PHP-GRP = Vbulletin 5.1 Beta, English, iNTERNAL, Nulled
Åš   Vbulletin.PRO.v5.1.NULLED.PHP-GRP = Vbulletin 5.1, Pro Edition, English, Nulled
Åš   Vbulletin.v5.1.MULTi.incl.KEYGEN.PHP-GRP = Vbulletin 5.1, Multilanguage (Notes in NFO!), Keygen
Åš   Gallerypro.v2.1.GERMAN.NULLED.ASP-GRP = Gallerypro 2.1, German, Nulled, ASP
Åš
Åš
Åš   If the script is sold with no protections at all (no Callbacks or similar)
Åš   then instead of NULLED/KEYGEN there shall be no tag used:
Åš    Somesoftware.v1.5.PHP-GRP
Åš
Åš   In this case even only decoding of protected files (Ioncube for example)
Åš   is counted as NULLED.
Åš   (Better for dupe searches and historical background)
Åš   Releases with Key in NFO and nulled backend (no Callbacks/Security Checks)
Åš   should be labeled as .NULLED.
Åš
Åš
Åš            2.1: Themes/Addons
Åš                  Themes/Addons for Wordpress/Joomla/Vbulletin etc.
Åš                
Åš                 ..for...[Language|MULTi].
Åš                 .[Beta|Alpha|RETAIL].
Åš                 [iNTERNAL|DiRFiX|NFOFiX|PROPER|READ.NFO].-GRP
Åš
Åš                 Examples (fictional):
Åš                 Dark.Theme.v3.for.vBulletin.5.X.GERMAN.NULLED.PHP-GRP
Åš                 = Dark Theme Version 3, for Vbulletin Version 5.X, German, Nulled
Åš                 Sidebar.Rotation.2.for.Wordpress.2.1.incl.KEYGEN.PHP-GRP
Åš                 = Sidebar rotation 2 Addon for Wordpress 2.1, with Keygen
Åš
Åš            2.2.: Updates
Åš                   Updates are allowed 4 weeks after the last Pre
Åš                   (same MU rules as in 0Day Rules)
Åš                  
+-----------------------------------------------------------------------------------------------------+
Åš
Åš
Åš       3: NULLiNG Rules
Åš           -All Callbacks need to be removed or patched
             (i.e. Serial Check over Developer Server)
Åš           -No Group Watermarks (also not in script comments).
Åš           -If files of the release are encoded all files need to be decoded.
Åš             (i.e. Ioncube, Sourceguardian, eval() etc.)
Åš
Åš            3.1: KEYGEN Rules
Åš                  -Keygens need to be in the same format as the Release
Åš                    (Release is PHP - Keygen needs to be in PHP too)
Åš                  -The Language of the keygen needs to be selectable on MULTi (i.e. DE,EN,PL)
Åš                    or the keygen needs to be completely in english.
Åš                    At specific releases (i.e. GERMAN) the keygen can be english or
Åš                    in the language of the release (in this case German)
Åš                  -Group comments in Keygen Sourcecodes are allowed if the group
Åš                    wants to explain the code, but this is in not mandatory.
Åš                  -Encoded Keygen code is allowed, as long is it does not use an external
Åš                   loader (Example: Ioncube is forbidden, eval() is allowed)
Åš                  -ASCii Art / Pictures are allowed but should be used thrifty.
Åš                  -Pictures in keygens shall not affect the code
Åš                    (i.e. Picture missing = Keygen not loading = Nuke/Proper reason)
Åš                  -Pictures need to be included and can not be mapped from websites
Åš                    (Security risk)
Åš
+-----------------------------------------------------------------------------------------------------+
Åš
Åš  4: NUKE and PROPER RULES / REASONS
Åš    NUKEs are possible for:
Åš    -bad.pack (i.e. RARs instead of ZIP) - stolen.from.[web|p2p|etc] - missing.files
Åš    -bad.crack (= bad nulled) - keygen.not.working
Åš    -Common Sense Nukes (dupe.filename, mislabeled.<|>, etc.)
Åš    -This is NOT a complete list.
Åš
Åš   PROPER/DiRFiX/REPACK follows the normal scene rules.
Åš   
Åš   
+-----------------------------------------------------------------------------------------------------+
Åš                                   SiGNED:                                                           Åš
Åš                               YET TO BE SIGNED                                                      Åš
Åš                 CONTACT: contactye@hush.com
+-----------------------------------------------------------------------------------------------------+

8.5.10

Scene Tags

PROPER

Due to scene rules, whoever releases the first Telesync has won that race (for example). But if the quality of that release is fairly poor, if another group has another telesync (or the same source in higher quality) then the tag PROPER is added to the folder to avoid being duped. PROPER is the most subjective tag in the scene, and a lot of people will generally argue whether the PROPER is better than the original release. A lot of groups release PROPERS just out of desperation due to losing the race. A reason for the PROPER should always be included in the NFO.

LIMITED

A limited movie means it has had a limited theater run, generally opening in less than 250 theaters, generally smaller films (such as art house films) are released as limited.

INTERNAL

An internal release is done for several reasons. Classic DVD groups do a lot of INTERNAL releases, as they won't be duped on it. Also lower quality theater rips are done INTERNAL so not to lower the reputation of the group, or due to the amount of rips done already. An INTERNAL release is available as normal on the groups affiliate sites, but they can't be traded to other sites without request from the site ops. Some INTERNAL releases still trickle down to IRC/Newsgroups, it usually depends on the title and the popularity. Earlier in the year people referred to Centropy going "internal". This meant the group were only releasing the movies to their members and site ops. This is in a different context to the usual definition.

STV

Straight To Video. Was never released in theaters, and therefore a lot of sites do not allow these.

ASPECT RATIO TAGS

These are *WS* for widescreen (letterbox) and *FS* for Fullscreen.

REPACK

If a group releases a bad rip, they will release a Repack which will fix the problems.

NUKED

A film can be nuked for various reasons. Individual sites will nuke for breaking their rules (such as "No Telesyncs") but if the film has something extremely wrong with it (no soundtrack for 20mins, CD2 is incorrect film/game etc) then a global nuke will occur, and people trading it across sites will lose their credits. Nuked films can still reach other sources such as p2p/usenet, but its a good idea to check why it was nuked first in case. If a group realise there is something wrong, they can request a nuke.

DUPE

Dupe is quite simply, if something exists already, then theres no reason for it to exist again without proper reason.

6.5.10

Difference Between Scene and P2P

Seems that many in the open and public torrent world do not understand the memorandum or methodology behind Scene and P2P, so perhaps it's time that we explain a little bit about the history of peer to peer, open torrent sites, the "p2p" groups, and "the scene". There is alot of historical context, propaganda, truth, and hidden despise that comes from this mystery, and we'll dig a little deeper now.

For years, peer to peer communication has existed, and a group of teams known as "the scene" dates back to the early 1980's, long before the arrival of the BitTorrent protocol. The methods and means used by the scene have a long and outstanding track record, of overcoming the odds and external warfare of the various forms of file transferring, such as FTP private and public downloads, and the "controversy" behind them, warez sites, and the battles they faced through the years, and http:// protocol as well.

See, "the scene" has always remained as an underground entity all to itself, never once giving in to the demands or urges to release publicly (although there is leaks, but we'll get to that later), and they've remained an ultra-secretive society of competitive groups and teams, all trying to be the first to "pre" (release/premiere) something new. Whether those new release are software, apps, cracks, keygens, patches, games, movies, music, or just about any form of digital media, hard media, or electronic warez which can be transferred, manipulated, or reproduced, "the scene" is always the first to get their hands on it.

From how you may ask? Well, "the scene" has ties which are undisclosed, but they typically get their paws on these items before they are even released for retail in the stores, so I'll let you do the math, and figure out where from. To be serious, "the scene" differs from open p2p in many ways, first of all, it's not about the "peers" to them, they DO NOT release publicly, that's probably the greatest difference between a scene and p2p releaser. So to define them a bit more, not only is it a conspiring difference that "the scene" doesn't release publicly like an open "p2p" group would, but, they have much contempt and lack of respect for "open" BitTorrent and p2p groups.

You see, "the scene" follows release standards, rules and regulations, which are updated frequently. They must follow these rules, or face a "scene ban" which can then remove them from "the scene". If you would like to find out more about "The Scene Rules", then just visit this link The Scene Rules. P2P however has no "rules" per say, except that to be proper you do have "guidelines" which many do not seem to follow.

P2P could not exist in the same way as it does today, without "the scene", and anyone with proper knowledge knows and understands this. Most all sources, are "leaked" from scene groups, onto public or private peer to peer file sharing sites, most publicly, BitTorrent sites. These sources are thus used by p2p groups to encode from, and then released openly on all forms of file sharing networks, again most popular, would be the BitTorrent protocol.

It does not however mean that p2p relies only upon "the scene" in order to gather it's sources. P2P teams and groups have acquired within the last few years, their own sources of direct/line audio for films, hard copy inner distributors or black market sellers of bootlegged pre-retail games, or films, and sometimes, internal connections from within the other industries of entertainment, who have contempt for the company they work for, or take payment for the sources.

In recent years also, p2p groups have headlined the masses with some of the greatest and fastest releases, of some of the best quality material. While the scene is mainly about speed, and competition, p2p has it's own competition, which is defined mainly upon quality. There are so many open and known p2p groups and releasers, that now quality is of the utter most importance. Why would someone download Example.Film.1.DvdRip.Xvid-p2pgroupA , when they also minutes later or even at the same time have Example.Film.2.DvDRiP.XviD-p2pgroupB , and the p2pgroupB release is ten times better in quality? That's just an example, although most of us even with nooblar knowledge realize there are so many different p2p groups and releasers now, that there is quite a selection for everyone to choose from.

If in fact, everyone were informed of this, we would not see actions which we see often which misrepresent or disrespect both the scene and p2p. You'll see totally new groups, doing improper resolutions for movies, wrong aspect ratios, which will not play in some standalone players, and even those whom choose to re-encode a public release. Some of these re-encodes, are more like re-re-re-re-encodes, because the original source for example came from a Russian warez group, then traveled to the Chinese BT sites, then made it's way onto Spanish releasers, then finally was re-encoded again in English. Re-encoding reduces quality, regardless of how much you filter and modify the appearance of a release. This is a fact that cannot be changed, direct sources will always be better than any imitation, period.

Most users do not know about "copyrights" and dated "copyrights" on a release. For most all releases, you can open VirtualDub or VirtualDubMod, and insert copyrights, for whatever you would like about the film, or even view them about a download. Recently however, some noob groups (sic) have decided to rename releases and put them on the BitTorrent protocol, and a select few, have figured out how to change/modify the copyrights in VDub or VDubMod. This is not appreciated, and doing so is extremely looked down upon in the world of releasing in general, and that's something that both p2p and the scene groups agree upon.

There however is a way, that some of use with "real" knowledge of the releases, know that something has been renamed, mislabeled, or retagged. There are applications that tell the original encode date, and copyrights, which absolutely can not be modified (sorry about your luck TA noobs), and one of those programs is called "MediaInfo". This is what is used a a "proof" in the scene to show when a "rip off' has occurred, and proof to us with knowledge in p2p when some no name new group decides to release something that seems an awful lot like a previous release. This is sad that this occurs, but it's even more embarrassing to the group who claim's the release is their own when in fact it is not. If you would like this application, visit MediaInfo, which is a very handy tool, and seems some people (TA) should try to use it before releasing.

Another method of mislabeling is this, those whom retag another releaser's work. While in p2p it's recognized and well known it's okay to put your "uploaded by:" information in the description, it's considered highly disrespectful to tag a release with your own name. For example, "Example.Movie.2009.DvdRip.Xvid-RealGroup {weretaggeditgroup}", doing something such as this is improper. It takes away the fans of a release group, and makes it harder for them to find their favorite groups on search indexes, and also, confuses the new crowd as to whom is actually responsible for the release. In the description, however, it's perfectly acceptable, because as I previously stated, this doesn't affect the search indexes and when a user downloads a .torrent file for example, it doesn't change the original title of the .torrent or release.

The scene however, despises p2p, because they release for the "thrill and competition" of the release, and do not want their releases or releasers being in the public spotlight. That is how they're remained unaffected through the many different forms of peer to peer over the years, and this is how they continue to operate securely. They say they despise open torrent sites, for this reason, their releases are meant to remain underground, but those of us from public or private torrent sites, feel that "sharing is caring" and we are all about the total promotion of free and open file sharing. So you can take sides, or suggest as I do, that both the scene and p2p need eachother, and without one another, they couldn't exist, as many of the scene's sources, come through contacts they get by seeing their group on a public site, ironically.

Overall here today, I hope I helped to explain to many of you the difference between the two, "the scene" and "p2p", and also showed you comparisons. I hope to further in the future, follow articles based upon "the scene" and "p2p" groups, with even more detail. Remember people, that regardless of where it comes from, they deserve our appreciation and respect, for their hard work, effort, dedication, quality, speed, and the risks they take, to keep file sharing alive. Overall that's the big factors behind it

3.5.10

High Definition x264 Standards

High Definition x264 Standards
 Revision 3.1 :: 2008-12-20
 [ Intro ]
 For the past two and a bit months most groups have adapted to the new 3.0 rules which made the x264 scene more
 uniform. It is however time for a small addtion to the rules. With 3.1 compressed rars are no longer allowed as
 compressing h264 does not reduce the size much, it just makes extracting slower. We have also decided to
 keep all release compliant with Level 4.1 of the ITU-T h264 specification. With all releases L4.1 it should
 be no problem for hardware players to play them. Please refer to the latest ITU-T h264 specification which is
 detailed when it comes to levels, refs etc. instead of using random incorrect internet sources as reason for nuke.
 This rule set will target HDDVD and BluRay sourced 720p and 1080p movie and TV-show rips.

 [ Previous Releases ]
 These rules do not apply to previous releases, and propering for those reasons will not be tolerated.
 [ General ]
 1.1)  Release must be packed in RAR. SFV and NFO must be included.
 1.2)  Rars should be in multiples of 50 MiB, no more than 99 files.
 1.3)  Compressed rars are not allowed.
 1.4)  Release must be muxed into mkv container.
 1.5)  NFO should contain information on Audio and Video Bitrate.
 1.6)  BluRay and HDDVD Sources dupe each other.
 1.7)  Suggested directory format:
         Movie.Name.YEAR.<720p/1080p>.BluRay.x264.-GROUP
         TV.Show.SxxExx.<720p/1080p>.BluRay.x264.-GROUP
 1.8)  No intros, outros, betweenos, or any other form of defacement of the film will be tolerated.
 1.9)  Credits must not be removed but can be encoded at a lower bitrate provided they
       don't contain any scenes (bloopers, story, etc).
 1.10) A sample roughly 60 seconds in length is required.
       1.10.1)  It must be cut from the final release and not encoded separately.
       1.10.2)  It must be put within a directory named "Sample".
 [ Audio ]
 2.1)  Audio must be AC3, DTS or FLAC, preferably from source.
       DTS core must be extracted from a DTS HR/HD MA track.
       AC3 640 kbit, DTS 768 kbit and DTS 1536 kbit must be encoded from a higher bitrate source.
       Encoded DTS track must be decodeable by older hardware decoders.
       FLAC audio must be created from LPCM, DTS HD MA or TRUEHD sources.
 2.2)  Audio bitrate must never be below 640 kbit, unless source only has lower bitrate audio track.
 2.3)  All audio shall be 5.1 with correct channels, except in the case of stereo/mono only.
 2.4)  Release must only contain one audio track muxed into the mkv container, unless original language isn't english.
       2.4.1)  Original language audio track or English dubbed track must be used.
               2.4.1.1)  English dubbed movie without original audio track must be tagged -DUBBED-.
               2.4.1.2)  DUBBED release only allowed if no release with secondary English dubbed audio track exists.
       2.4.2)  If original language is not English:
               2.4.2.1)  English Subtitles must be included.
               2.4.2.2)  English dub is allowed as a secondary audio track.
 [ Video ]
 3.1)  If needed, appropriate de-interlacing and ivtc must be applied.
 3.2)  Must use a minimum encode of 2 passes.
 3.3)  Width of release must be mod 16. Height of release must be mod 8.
 3.4)  Crop the black borders from the source. Crop to the widest frame possible.
       3.4.1) Resizing is not allowed on 1080p encodes. Either crop to closest mod8/mod16 without overcropping, or crop().addborders()
 3.5)  Use the same aspect ratio as the source, not what IMDB or cover says.
 3.6)  Custom Matrices are allowed.
 3.7)  VfW (Video for Windows) is not allowed.
 3.8)  x264 version used must be at least 999 and no more than 50 revisions from newest.
 3.9)  Level 4.1 must be respected.
 3.10) --deblock must be enabled.
       --aq-mode must be enabled.
       --bframes 3 or higher is required.
       --ref 5 or higher is required unless the vertical resolution is greater than 864, then 4 must be used to respect L4.1.
       --me umh or higher is required.
       --subme 7 or higher is required.
       --trellis 1 or higher is required.
 3.11) 720p refers to a MAXIMUM resolution of 1280x720.
       3.11.1) For aspect ratio equal or above 1.78 horizontal resolution must be 1280.
                   e.g. AR of 2.35:1 will be 1280x544.
       3.11.2) For aspect ratio lower than 1.78 vertical resolution must be 720.
                   e.g. AR of 1.33:1 will be 960x720.
 3.12) 1080p refers to a MAXIMUM resolution of 1920x1080.
       3.12.1) For aspect ratio equal or above 1.78 horizontal resolution must be 1920.
                   e.g. AR of 2.35:1 will be 1920x816.
       3.12.2) For aspect ratio lower than 1.78 vertical resolution must be 1080.
                   e.g. AR of 1.33:1 will be 1440x1080.
 3.13) Video bitrate should be as follows:
       3.13.1)  720p - Minimum 4000 kbit, maximum 8000 kbit. Minimum bitrate for animation is 2300 kbit.
       3.13.2) 1080p - Minimum 8000 kbit, maximum 14000 kbit, though not more than source-2000kbit. Minimum bitrate for animation is 5000 kbit.
 [ Subtitles ]
 4.1)  Subtitles must be in a text-based format and muxed into the mkv container.
 4.2)  Subtitles must not be burned into the video stream.
 4.3)  Multi-language subtitles cannot be used as a basis for a dupe.
 4.4)  "Subs" directories are forbidden.
 [ Total Size ]
 5.1)  Final mkv file size in MiB (1048576 bytes) must be:
           Multiples of 2240
           DVD5/x (1493, 1120, etc.)
           8140, 2713
           In addition, 3360 and 4070 are allowed for 1080p tv.
 5.2)  A max undersize of 40 MiB can be tolerated.
 5.3)  Propering a release that could have been a larger size is not allowed, unless below minimum bitrate.

 [ Suggested encode settings ]
 6.1)  First pass:
       x264.exe --pass 1 --level 4.1 --stats .stats --bitrate 4000 --threads auto --bframes 3 --me dia --ref 1 --subme 1 --no-dct-decimate --partitions none --progress --no-psnr --no-ssim --output NUL movie.avs
 6.2)  Second pass:
       x264.exe --pass 2 --level 4.1 --stats .stats --bitrate 4000 --threads auto --bframes 3 --b-pyramid --weightb --me umh --ref 5 --mixed-refs --subme 7 --trellis 1 --analyse all --8x8dct --no-fast-pskip --progress --no-psnr --no-ssim --output movie.mkv movie.avs
 [ Signed By (in alphabetic order) ]
 1920, BestHD, CiNEFiLE, CLASSiC, CULTHD, CYBERMEN, DEFiNiTE, HALCYON, HANGOVER, HDEX, HDMI,

 hV, iKA, Japhson, ORPHEUS, REAVERS, SECTOR7, SEPTiC, SiNNERS, SUNSPOT, TiMELORDS, VOA
 [ These rules apply from 2009-01-01 00:00:00 GMT (1230768000 unixtime) ]

 [ Change Log ]

 + = added
 - = removed
 * = changed
 3.1:

 +   1.3: Compressed rars are not allowed.
 +   3.9: Level 4.1 must be respected.
 *  3.10: --ref must now respect L4.1, not just allow it.

2.5.10

The 2010 XXX Imagesets Scene Rules

This summary is not available. Please click here to view the post.

1.5.10

The 2010 0day Scene Rules

This is intended as an addendum to the existing 0day rules. All the old rules
are still valid, unless they have been altered or updated by this addendum.

The 0day scene has gone through major changes in this decade. As technologies
have changed, so have we, but our adaptations have left many grey areas in the
current rules. The last rules update was years ago when programs were much
smaller and transfer speeds much lower. The existing 0day rules did not address
problems of software encountered today, simply because at that date it did not
exist. These changes have led to a series of loopholes which groups have been
taking advantage of. The new rules we constructed aim to close these loopholes,
as well as increase the general quality level of releases in the scene.

This document covers a new ruleset for 0day.  These rules and guidelines are
intended for release-groups in the first place, and sites secondary. We hope
that in time many sites will take over the majority of these rules. The
following groups have signed and committed to following these rules:

      ACME AiR AGAiN ALiAS ARN BACKLASH BEAN BLiZZARD BRD CORE CRD
        CROSSFiRE DIGERATI DVT EMBRACE FALLEN FAS iNViSiBLE LND
           MESMERiZE NGEN NULL ORiON OUTLAWS RiTUEL ROGUE rG
                RAiN SHOCK SSG TBE TE UNLEASHED VACE ZWT

This particular 2010.1 revision was created to address a number of unclear bits
in the original release. Although we do appreciate constructive criticism, we
would like to point out that these rules were not created by an individual, and
as such they are not trivial to construct. With this new revision we hope to
clarify the rules to match our intentions when we released them. If you did not
get the rules you want, please remember that this was a combined effort from a
large number of groups, where the opinion of the collective supersedes that of
any single group.

These rules will go into effect starting January 31st, 2010.

When a rule is described as *should*, we interpret this as follows: you are
expected to follow the rule, if you do not, groups are free to proper your
release. If it is not propered however, you will not get nuked.

When a rule is described as *must*, there is no compromise, you either follow
the rule or you get nuked.

1) Release Name
~~~~~~~~~~~~~~~

[.].v[.][.][.]
[.][.]-

1.1) Developer.Name is only mandatory if the application name is not unique
enough for duping. This means that you must include the developer in the case
where duping for your application name will also return results that do not
match the application you are releasing. Groups should use some common sense to
keep the directory name reasonable length.

1.2) The program name must be the "official" name of the application. Do not
omit dashes, think of your dupe results. This is the name in the about box or
splashscreen of the application, or if this is not available, the name listed
on the website. Releases that are named incorrectly require a DIRFIX or they
will be nuked. A DIRFIX release is a directory with inside a zip that includes
both nfo file and file_id.diz.

1.3) The Language tag must be used only on NON english releases. Multilingual
and bilingual are optional, every language included must be listed in the nfo
when these tags are used.

1.4) Currently valid OS tags are:
        - Win98, WinME, WinNT, Win2k, WinXP, Win2k3, Vista, Win2k8, Win7
          (can have an optional tag for more specific edition)
        - [Distribution.]Linux
        - MacOSX
        - [Free|Net|Open]BSD
        - [Open]Solaris
        - AIX
        - HPUX
        - Open.Enterprise.Server (NetWare)

1.5) It is recommended to omit the Operating.System tag when it is WinAll (= NT5
based windows and optionally earlier, always with latest official service pack).
Using a UnixAll (= all of the operating systems above, excluding Windows, Linux
or MacOSX) or a WinAll tag means your app *must* run on *all* of the operating
systems that fall under it.

1.6) It is recommended to omit the CPU tag when it is x86; it must be x64 for
x86_64/EM64T, but not IA64!
Currently valid CPU tags are:
        - x86, x64, IA64, PPC, SPARC, SPARC64, RISC, Alpha

1.7) Release.Type can be omitted for Cracked/Regged, it is strongly recommended
for keygen releases. Possible tags are:
        - Keygen.Only
        - Keymaker.Only
        - Keyfilemaker.Only
        - Keygen.and.Patch.Only
        - Keymaker.and.Patch.Only
        - Keyfilemaker.and.Patch.Only
        - Incl.Keygen
        - Incl.Keymaker
        - Incl.Keyfilemaker
        - Incl.Keygen.and.Patch
        - Incl.Keymaker.and.Patch
        - Incl.Keyfilemaker.and.Patch
        - Cracked
        - Regged

1.8) Additional.Tags like READ.NFO, DIRFIX, NFOFIX.. must go as follows:
  - Program.Name.v1.2.Regged.READ.NFO-GROUP
  - Program.Name.v1.2.Regged.DIRFIX-GROUP

1.9) You can use underscores or dots as separator in the releasename, but do not
mix them if there is no reason for it (e.g. a program name contains underscores
and your separator is a dot is a valid reason to mix)

The lists in this section may not be complete, but they try to be. You are
expected to follow them whenever possible. Straying from them does however not
necessarily mean the release is a nuke. It is impossible to predict what tags
may be required for future releases.

2) Packaging:
~~~~~~~~~~~~~

2.1) Filenames must be named up to a maximum of 8.3 characters (filename +
extension).

2.2) Acceptable compression format at this time is any compression method that
supports multiple volumes and long file names, followed by the traditional
PKZIPing. Compressions other than RAR must include an extract utility or be a
self-extracting archive.

2.3) The traditional packaging methods (zip/diz) shall be maintained, with a
diz file being present in each zip. The diz file must contain as a bare minimum
the number of the current disk and the maximum number of disks.

Minimal file_id.diz must include:
 [xx/??]
Where ?? is the total nr of disks in the release. The total number of lines of
your diz must not exceed 30, each line being no more than 45 characters long.

An nfo must be included in at least the first disk of the release. There is
no limitation to its length, its width is determined at 80 characters max.

2.4) On a side note: using ridiculous compressions that will save 10 disks but
takes 10 hours to unpack are not an acceptable solution. We leave it up to
nukers to decide where the line is between reasonable and unreasonable.

3) Release Size:
~~~~~~~~~~~~~~~~

3.1) Allowed split volume sizes are:
        - 1,444,000 bytes
        - 2,888,000 bytes
        - 5,000,000 bytes
        - 10,000,000 bytes
        - 50,000,000 bytes

In the following paragraphs, utils make up for the majority of the releases in
the 0day scene, namely all applications, shareware games, etc. When we talk of
games, we mean the game-rip scene that releases ripped versions of store-bought
games.

3.2) The utils disk limit is as of now 70 x 5,000,000 bytes or 35 x 10,000,000
bytes. This equates to a total of 350,000,000 bytes of compressed data. Volumes
of 1,444,000 and 2,888,000 bytes are allowed, as long as the release does not
exceed 99 disks. Oversize releases are allowed when no valid ISO release exists
and the group (or an iso group they work with) is not in possession of the iso
to release. In other words, there is NO size limit for 0day apps, except when a
valid (not nuked) iso exists!

3.3) The games disk limit is as of now 80 x 5,000,000 bytes or 40 x 10,000,000
bytes (or comparable for 1,444,000 and 2,888,000 bytes). This equates to a
total of 400,000,000 bytes of compressed data. Volumes of 1,444,000 and
2,888,000 bytes are allowed, as long as the release does not exceed 99 disks.

Any release must have less than 100 volumes. In case 10,000,000 bytes do not
suffice, you are allowed to use volumes of larger size; up to 50,000,000 bytes.

3.4) A size proper is valid when a group manages to reduce the size of the
original release by at least 30% without sacrificing essential content:

 - Documentation, help files, and other non functional items can be ripped from
   a release to decrease size. No functional parts of an application may be
   ripped.
 - C++ redistributables, .NET framework, and other common operating system
   components should be ripped. The nfo should note what has been ripped and
   optionally include an url where it can be downloaded.
 - A documentation addon is only allowed if the documentation cannot be
   downloaded freely and publicly (without registration) from the developer's
   website.

4) Specific Release Type:
~~~~~~~~~~~~~~~~~~~~~~~~~

4.1) All of these releases must provide functionality identical to that of a
fully licensed copy.

- 4.2) Cracked: The program file has been altered to register the program. Any
  nags/trial limitations must be removed. Any remnants of "Trial" in the app
  need to be removed. Any "phone-home" checks must be disabled, or as bare
  minimum, instructions must be provided how they can be disabled.

- 4.3) Regged: Any way to make an application "registered" without requiring
  modification of any of the applications executables/libraries. Must include
  a text file with the required information, serials must not be put in the
  release nfo. Please name this file carefully, as to deter possible
  webspiders looking for serial information.

- 4.4) Keygen: A small standalone program which generates valid serials/keys
  which are based on user input or hardware id. A Keyfilemaker is a keygen that
  generates a file which serves to activate an application or game.

  4.4.1) Keygens can be written in any language but they *should* be native
  executables for the OS the application is meant for: Linux keygens for Linux
  applications, Mac keygens for Mac applications, etc. This means that if you do
  not follow this suggestion, you could get propered. However, you won't be
  nuked if there is no native keygen available.

  4.4.2) A keygen that generates a system-dependant serial must explicitly warn
  the user of this fact, either in the nfo or at runtime.

  4.4.3) Windows keygens in java are allowed if the program is coded in java
  or uses java. Same with any other interpreter language. If a library is
  included with the latest windows install, as is the case for VB6/.NET/VBScript
  currently, then keygens written in these languages are allowed without
  question. The motivation here is that a scene release must run on a clean
  OS install, introducing no additional dependencies other than those imposed
  by the application being released.

  4.4.4) A console-based application that usually runs on headless systems
  (servers, etc) requires a console-based keygen.

  4.4.5) Generic Keygens (All.Products) are allowed and dupe full releases for
  as long as the generic keygen continues to work for *every* application it was
  intended for. Once any application changes its registration scheme, it is
  allowed to update the generic keygen. Proof is not required, but always
  welcome.

  4.4.6) Keygen.Only releases are releases that only contain the actual keygen,
  no installation files. They are an addition to previously Cracked/Regged
  releases.

  4.4.7) A Keygen.and.Patch release combines a keygen with a crack to enable
  full functionality. You are still allowed to release a keygen.only for these
  releases.

- 4.5) Retail: A store-bought supply is included in this release. You are
  allowed to release a retail after a previous release if there is an added
  benefit to using the retail version. In this case you are required to add a
  READ.NFO tag to your dirname and list the benefits when compared to the
  previous release.

- 4.6) PROPER/WORKING: a proper of a previous scene-release that was not fully
  working must always include adequate proof and information for nukers to
  test and confirm the validity of the proper. This means including screenshots,
  pieces of code, or clear steps to reproduce the problems that occur with
  the release you are propering.

- 4.7) READ.NFO: If you label a release READ.NFO, please have a clearly stated
  section in your nfo on what the READ.NFO is all about, dont make people guess.
  If you want people to read it for a certain reason, make sure they can.

5) Operating Systems:
~~~~~~~~~~~~~~~~~~~~~

5.1) If a developer has not mentioned default or minimum requirements for
operating system, the default is Windows XP, which is also a minimum. This means
your release *must* work on every operating system the application was designed
for, with the following exception:

 - If a program supports Windows Operating Systems before WinXP, then your
   crack *should* work on them aswell.

Optional: combine multiple operating system versions for the same CPU in 1
release if it remains within size limits, for example:
- FreeBSD5,6,7 x86 can be in a single release tagged FreeBSD
If the installers are freely downloadable (available without registration) and
the same keygen/crack works for every version, consider only including the
latest version of the OS.

Please keep in mind that the contents of .tar.gz, .rpm, .deb and any other
packaging system are generally identical. Please make a note in your nfo in
case of exceptions.

6) Minor Updates:
~~~~~~~~~~~~~~~~~

6.1) MU stands for Minor Update. This term denotes an update of a previously
released application within a certain time-period, the MU-period. Major updates
are allowed regardless of the last time a previous version was released. In
this case, the nfo must include some motivation for considering this a major
update (security- and stability-critical hotfixes for instance). Typical major
updates are defined as a version-change for the most significant number in the
version, for instance v9.1 being updated to v10.0. Exceptions are possible,
but must be noted in the nfo.

MU-period of 1 month, disregarding the number of days in a month. Examples:

- a release on 2010-01-01 will be out of mu on 2010-02-01
- a release on 2010-01-15 will be out of mu on 2010-02-15
- a release on 2010-01-29 will be out of mu on 2010-02-28
- a release on 2010-01-31 will be out of mu on 2010-02-28
- a release on 2010-02-28 will be out of mu on 2010-03-28
- a release on 2010-03-31 will be out of mu on 2010-04-30

This ensures no more than a single release of the same application per month.
We use the CET/CEST timezones, as we always have.

The minor update period is counted from the last valid release which contained
the software itself. In other words, keymaker.only releases are not considered.
A valid release is defined as a release that was not nuked. When multiple
editions of the same application exist and are valid (for instance, they
provide different functionality) they can be considered as different
applications with separate MU-periods.

This MU-rule will go into effect on 31st January. This means any application
released after this date will require the above described MU-period to pass
before a new release is valid. Applications released before this date are
not considered.

7) General Rules:
~~~~~~~~~~~~~~~~~

7.1) If the age of the last modified file of an installed program is older than
one (1) year it is not allowed to pre it without a READ.NFO or INTERNAL tag.

7.2) A group must release the newest version of the software available, with the
following exception: you can release an older version of an application, but
*only* if it is newer than any existing release of the same app, and you have a
valid reason for not releasing the latest version (for instance, it is very hard
to get the supply, or the application takes months to crack).

There is a grace-period of 3 days: if a new version came out in the last 3
days before your release, you will not get nuked if you release the older one.

7.3) Releases must provide the same functionality as a retail copy of the
application (where possible and reasonable). Examples:
 - A virus scanner must be able to update its definitions at the time of
   release, and must do so without any restriction on the number of concurrent
   licensed users. (i.e. a single-user regged license is inadequate as it will
   soon be blacklisted)
 - A flexlm application must include every retail license-feature applicable
   to your release (any feature that is actually checked out in the best
   edition)
 - A keygen must provide either all, or the best license (watermarked keys
   are still allowed)

7.4) Your nfo should provide a minimum of useful information. Suggestions
include:
 - (complete) application name
 - (complete) version, including if it is a beta version
 - the release date
 - type of crack included
 - short description of the application/game
 - description on how to use the crack (important!)
 - operating systems this release will work on
 - pre-requisites for the application/game
 - url to the application's website

7.5) If you do not want your work to be used by other groups (be it documents,
cracking methods, tools, or similar), then make sure you don't give it out to
anyone you can't trust. It is deemed public property as soon as it is publicly
available, and you lose any exclusive rights to it.

7.6) Stealing cracks/keygens from P2P, WEB, or other scene groups is clearly
not allowed!

7.7) Security should be everyone's primary concern. Including nicknames or
identities of people that have not given explicit permission in your nfo's is
absolutely not allowed, and may result in severe repercussions.

A big thanks to everyone involved in creating this document!

30.4.10

THE 2010 BDR Releasing Standarts

THE 2010 BDR RELEASING STANDARDS
 
- GENERAL

        G1)  Release size must be between 23365 MB and 23866 MB unless source is BD25.
        G2)  Group watermarks within the Bluray are strictly forbidden.
        G3)  Releases must be made region free.
        G4)  Any new unmentioned copy protection that comes out must be stripped.
        G5)  If for any reason any standards cannot be met it a brief explantion
             must be written in the nfo.


        - PACKAGiNG

        P1)  Sample, nfo and sfv are required for each release.
        P2)  NFO must contain at least: 
              - IMDB link
              - Bluray Region
              - Audio streams
              - Subtitle streams
              - Video status: encoded or untouched
              - In case of encoding: average bitrate
              - HD audio status: transcoded or untouched
              - Menu: stripped or maintained
        P3)  Rar's must be split into 250 MB archives.
        P4)  Recovery record of 1% must be used.
        P5)  Passwords or encryption is not tolerated.
        P6)  Compression is not allowed.


        - TAGGiNG

        T1)  Acceptable characters are as follows:
                 ABCDEFGHIJKLMNOPQRSTUVWXYZ
                 abcdefghijklmnopqrstuvwxyz
                 0123456789 . -
        T2)  Suggestion for tagging:
              - Movie.Name.YEAR...BDR-GROUP
              - TV.Show.SxxDxx...BDR-GROUP
              - Music.YEAR...MBDR-GROUP
        T3)  The first release of a movie, if it has the original audio, English subs and menu,
             must be tagged Movie.Name.YEAR.BDR-GROUP. Next releases must contain a
             language tag (MULTiSUBS/MULTi/NL/NORDiC/iTALiAN/etc) or region tag (R1/R2/R3).
        T4)  All releases are to include production year, except for TV series.
        T5)  Sub directories are to be labeled as DiSC1, DiSC2, etc.
             EXTRA and CD1, CD2 dirs are not allowed.
        T6)  Additional explanation of some tags:
             MULTi:     In case of a minimum of 2 audio languages.
             MULTiSUBS: In case of a minimum of 6 subtitle languages.
 
- ViDEO

        V1)  An x264 build within 50 builds of latest must be used for encoding.
        V2)  One-click apps that re-encode BD50->BD25 rips are strictly forbidden.
        V3)  All movies must be at their original framerate.
        V4)  Must use 2 passes.
        V5)  Minimum average bitrate are determined by the runtime:
             19000kbps for < 100 minutes
             18000kbps for 100-120 minutes
             17000kbps for > 120 minutes
             If minimum average bitrate cannot be achieved, a valid explanation
             is required in the NFO. Animation movies may have a lower minimum
             bitrate, -4000kbps for the corresponding runtime class.
        V6)  Some Bluray movies also contain 720p or 480p, next to the default 1080p.
             These lower resolutions are an added value but are not needed.
             If the movie needs to be re-encoded, these need to be stripped.
        V7)  Must use 4 reference frames (--ref 4).
        V8)  Must insert access unit delimiters (--aud).
        V9)  Must use square pixels (--sar 1:1).
        V10) Must use at least subpixel refinement level 7 (--subme 7).
        V11) Must be compliant to level 4.1 high profile (--level 4.1).
        V12) Bitrate peak limit must not exceed 40 mbps (--vbv-bufsize 30000 --vbv-maxrate 40000).
        V13) Must use bframes level 3 (--bframes 3).
        V14) Trellis rd quantization must be level 1 (--trellis 1).
        V15) Must check all partition search types (--analyse x).
        V16) Must use at least level uhm for the motion estimation method (--me uhm/esa/tesa).
        V17) CABAC must be used.
        V18) Must use b-pyramid level strict for restrictions imposed by the
             Blu-Ray standard (--b-pyramid strict)
        V19) Suggested encode settings:
             First pass:
             x264.exe --pass 1 --level 4.1 --stats .stats --bitrate %bitrate --no-mbtree --keyint 24 --min-keyint 2 --threads auto --bframes 3 --me dia --ref 1 --subme 3 --direct auto --sar 1:1 --b-pyramid strict --partitions none --no-dct-decimate --output NUL BDR.avs

             Second pass:
             x264.exe --pass 2 --level 4.1 --stats .stats --bitrate %bitrate --no-mbtree --keyint 24 --min-keyint 2 --threads auto --bframes 3 --me umh --ref 4 --subme 7 --direct auto --sar 1:1 --b-pyramid strict --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 38000 --weightb --mixed-refs --mvrange 511 --aud --trellis 1 --analyse all --output BDR.mkv BDR.avs



       - AUDiO
  
        A1)  Dolby Digital 5.1 and DTS, and their equivalent HD audio stream
             are considered the standard audio formats.  
        A2)  Blurays that only contain DD2.0 or PCM audio are allowed and
             must be noted in the NFO.
        A3)  Superior audio tracks need to be kept, according to the following
             ladder (from best to worst quality):

             DTS-HD MA 7.1 / True-HD 7.1 > LPCM 7.1 > DTS-HD MA 5.1 / True-HD 5.1
             > LCPM 5.1 > DTS 1536 > DTS 768 > AC3 640 > AC3 448 > LPCM 2.0 > AC3 2.0

             If video needs to be encoded , choose the next highest in rank.
             Although both DTS-HD MA and True-HD vs. LPCM are lossless audio
             formats, due to the high bandwidth and space requirements of LPCM,
             most studios downconvert 24/48 master audio to lower 16/48 fidelity.
             Rather, others chose to losslessly pack or these audio masters
             with DTS-HD MA or Dolby TrueHD. Once unzipped, the stream is equal 
             to the original 24/48 master audio.
        A4)  Though, you'll sometimes find it necessary to strip HD audio to
             make the Bluray fit on BD-R, as HD-audio is much larger. In this
             case, you can extract the core of the True-HD and DTS-HD audio
             (eac3to -core), and use this for audio.
        A5)  Downsampling of the audio bitrate is not allowed
        A6)  For non-English movies, the movie's original language audio
             stream must be kept unless it is not contained in the retail.
             In this case you can use other language track but release must be
             tagged DUBBED. In the circumstances that a reissue/new edition
             Bluray contains an original language audio stream, a re-release
             of the movie is valid.
        A7)  For all English movies, the English audio stream must be kept.
        A8)  The inclusion of other audio streams will be based upon the
             ripper's discretion, whether they are foreign or commentary.


        - MENU
             
        M1)  Menus must be included. In cases when it is not possible to
             maintain the menu, a valid reason must be explained in the nfo.
             In cases where the retail does not contain a menu, it must
             be mentioned in the NFO.
        M2)  The English menu must always be kept. Foreign menus may be
             stripped, if this is required to make the release fit on BD-R.
             If there is no English menu, but a foreign one, at least one of
             those must be kept.
        M3)  If all else is stripped and you want to avoid reencoding the
             main movie, or you can't get the minimum bitrate, then the menu
             may be re-encoded at a minimum average bitrate of 10000 kbit/s. 
 

        - OTHER CONTENT

        E1)  All subtitles must be kept. An exception on this rule is
             that director's comment subtitles may be stripped when the
             director's comment audio track has been stripped.
        E2)  Extras are an added value but are not needed. Extras are 
             allowed to be re-encoded at ripper's discretion. Extras
             may also be encoded in 720p resolution. Extras may be
             de-interlaced at ripper's discretion.
        E3)  Extras may be encoded at a lower bitrate. Mimimum bitrate for
             1080/720i/p resolution extras is 3000 kbps, and for 480i/p resolution
             extras the minimum bitrate is 1500 kbps.
        E4)  When an extra is stripped, it must be replaced by a dummy file
             so that the Bluray-player won't crash.
        E5)  Warnings and intros must be blanked, or even better, skipped.
        E6)  PS3_UPDATES may be stripped only in the case that the minimum
             bitrate can't be achieved or when it is the last move you can
             make to prevent encoding. Side note: PS3 updates are always
             available for manual download on PSN or Internet.


        - SAMPLE

        S1)  A sample of 1 minute, to a maximum size of 250 MB, cut from the 
             release is required in a 'Sample' directory. A .m2ts file must
             be cut and used as sample. You cannot rename a rar and use it as
             the sample.  
- PROPERS
                       
        R1)  Propers may only be released if previous release had technical 
             flaws such as bad quality, undersized, errors, etc.  
        R2)  Propers based on previous releases having stripped the menu
             are allowed.
        R3)  It is not allowed to release a proper with HD audio, when a
             previous release has transcoded the HD audio to non-HD audio.
        R4)  Just because a previous release was not COMPLETE, it does not
             provide a legitimate reason to dupe.
        R5)  Propers based on previous releases having improper dir names
             will not be tolerated.
        R6)  PPF patches or xDelta patches must be used for fixing
             releases with simple problems. REPACKS/PROPERS must be
             avoided if a PPF patch or xDelta patch is possible.
        R7)  In case the original releasegroup doesn't release a fix
             within 48 hours, another releasegroup is allowed to proper
             it.
        R7)  Blurays with different audio or subtitle streams do not
             dupe eachother.


        - NOTES & SUGGESTiONS

        N1)  Limitations
             The authoring possibilities for bluray aren't that advanced yet
             to make some rules explicitly mandatory at this stage. Knowledge
             and software are developing rapidly though and we are confident
             this will improve soon. The rules in question are related to
             editing the menu's, editing & disabling menu buttons and the
             complete removal of intro movies. Although we can't make these rules
             mandatory at this stage, we strongly encourage the usage of them. 

        N2)  Applicability
             These rules apply from 2010-05-01 00:00:00 GMT (1272672000 unixtime).
             Released pre'd before this time are not allowed to be nuked based
             on these rules.

        N3)  Nuking
             Nukes can be based on the code assigned to each rule.