┌──────────────────────────────────────────────────────────────────────────────┐
│ THE.2020.WEB.AND.WEBRIP.SD.HD.X264.UHD.X265.RULESET.v2.0-WDX │
│ │
│ High Definition x264/H264 and Ultra High Definition x265/H265 WEB and WEBRip │
│ Standards │
│ Version 2.0 - 2020-05-13 │
├──────────────────────────────────────────────────────────────────────────────┤
│ │
│ [ Intro ] │
│ The landscape of the WEB scene has changed in the last four years. │
│ Subsequently, the ability to defeat DRM has become ubiquitous. │
│ What were once rules written around the assumption that capturing and │
│ transcoding would be more commonplace than lossless downloading have │
│ naturally become increasingly out of date. │
│ │
│ HDTV is still slowly, but surely, being replaced by WEB. Not just in │
│ quality, but with more and more providers transitioning to streaming at │
│ airtime, and some even putting entire seasons up days/weeks before airtime. │
│ │
│ Transcoding only for crop has become a burden, and only serves to damage the │
│ section. │
│ Internals have been abused with rampant technical flaws, lesser quality and │
│ identical files. │
│ While UHD and HDR streams were but an afterthought four years ago, they have │
│ now become a daily occurrence with groups left unsure of how to release │
│ them. │
│ │
│ Worst of all, with an almost endless array of web sources available │
│ simultaneously, groups continuously pick the first to appear, which, more │
│ often than not, is the worst possible quality. │
│ │
│ This update will address all these issues and more, by taking one large leap │
│ forward and no steps back. │
│ │
│ Compliance with this document is optional as of its pre date, and mandatory │
│ as of 2020-05-20 00:00:00 UTC (1589932800 Unix time). │
│ │
├──────────────────────────────────────────────────────────────────────────────┤
│ │
│ [ Recommended ] │
│ It is recommended to view the unformatted version of this ruleset bundled │
│ within this release. │
│ │
├──────────────────────────────────────────────────────────────────────────────┤
│ │
│ [ Ruleset Structure ] │
│ Rules listed under untouched or transcoded labelled sections only apply to │
│ releases of that type and supersede any similar rule mentioned elsewhere. │
│ e.g. Rule 8.1 defines SD as resolutions with a maximum horizontal display of │
│ 720 pixels, unless the release is considered untouched, in which case rule │
│ 1.6 applies. │
│ │
│ 1) [ Untouched: WEB.H264 / WEB.H265 ] │
│ 1.1) Untouched releases must be considered as anything that has been │
│ losslessly downloaded by official (offered) or unofficial │
│ (backdoor) methods. │
│ 1.1.1) Untouched video streams must be in the H.264/MPEG-4 AVC or │
│ H.265/HEVC codec. See exception in 1.5.1. │
│ 1.2) Source video and audio streams must be left as obtained from the │
│ source. │
│ 1.3) Untouched video streams with, and without, x264/x265 headers must │
│ be tagged as WEB.H264 and WEB.H265 respectively. │
│ 1.3.1) HEVC/H265 may only be used when the source does not offer a │
│ H264 stream in situations it is used any untouched sections │
│ referring to H264/x264 must be considered as H265/x265. │
│ 1.4) Transcoding untouched files must only occur if files do not meet │
│ the standards and specifications listed in this section, and must │
│ only be a last resort. │
│ 1.4.1) Any transcoding of untouched files must follow the │
│ transcoding standards - see sections marked as 'Transcoded'. │
│ 1.4.2) Transcoding must be done from files of the highest resolution │
│ and bitrate offered. │
│ 1.4.2.1) 720p/1080p and 1080p/2160p streams are considered of │
│ equal value, unless DRM protection levels of │
│ 1080p/2160p are laxed to 720p levels. │
│ e.g. 2160p is protected at the same laxed level as │
│ 720p. │
│ e.g. 1080p is protected at the same laxed level │
│ as 720p. │
│ 1.4.3) Transcoding may occur when correcting a technical flaw. │
│ e.g. Decimating a source with duplicates every 5th frame. │
│ 1.4.4) In situations where a target resolution is not offered by any │
│ lossless source, or the resolution offered by any source does │
│ not meet the minimum resolution requirements, transcoding │
│ from the highest resolution and bitrate offered is allowed. │
│ However, if at least one source can provide the correct │
│ resolution, transcoding is not allowed. │
│ e.g. If 1080p and 720p can be retrieved from multiple │
│ sources, but SD cannot be retrieved from any source, │
│ transcoding the 1080p to SD is allowed. │
│ 1.4.5) If the untouched file does not contain any technical flaws │
│ and meets the minimum standards required, transcoding to │
│ create any WEBRip is not allowed. │
│ e.g. 1080p.WEB.H264 -> 720p.WEBRip.x264. │
│ 1.4.5.1) When transcoding video for a valid reason, audio must │
│ not be transcoded unless necessary and be included as │
│ is and vice versa. │
│ e.g. Video contains dupes and must be decimated, │
│ audio is fine. Video must be re-encoded but the │
│ audio must be included as is. │
│ 1.4.5.1.1) Except for SD audio which must either be an │
│ untouched track respecting rule 2.2 or a │
│ transcoded track from the highest quality audio │
│ track respecting rule 5.6.2. │
│ 1.5) Untouched video streams which do not use an AVC or HEVC codec must │
│ be transcoded and follow the transcoding standards, see section 3. │
│ 1.5.1) Except in very rare cases VP9/AV1 may be used, only when the │
│ source does not offer a H264/H265 stream. │
│ 1.5.1.1) Any untouched sections referring to H264/x264 must be │
│ considered as VP9 or AV1. │
│ 1.5.1.2) Transcoding from either of these codecs, except when │
│ correcting technical flaws, is not allowed. │
│ 1.6) Standard definition (SD) refers to a resolution with a horizontal │
│ minimum of 720 pixels, or a resolution which does not exceed the │
│ specifications of 720p, see rule 8.2. │
│ 1.6.1) If all sources provide standard definition resolutions which │
│ fall below the above minimum, transcoding from the highest │
│ available resolution is allowed, see rule 1.4.4. │
│ 1.6.2) Except in situations where only one source has the file on │
│ offer at a specific resolution. If the resolution of the file │
│ falls below the above minimum, the file may still be │
│ released. However, the NFO must state why the resolution does │
│ not meet the minimum. │
│ 1.7) In rare cases, a resolution exceeding the specifications outlined │
│ in rules 1.6, 8.2, 8.3 and 8.4 is allowed when the only available │
│ stream offered for the target resolution exceeds limitations due to │
│ a reasonable circumstance. │
│ e.g. Streaming provider offers 720p only at 1392x660 due │
│ maintaining AR while offering a cropped stream. │
│ 1.7.1) The NFO must state why the resolution exceeds the maximum. │
│ 1.8) Must use the highest available bitrate offered by the source for │
│ that resolution. │
│ e.g. Releasing a 720p at 4,000 Kbps bitrate, when a 720p at │
│ 8,000 Kbps bitrate is offered is not allowed. │
│ 1.9) Retaining black borders (i.e. needs cropping) is not a technical │
│ flaw. Transcoding only to perform cropping is not allowed. │
│ 1.9.1) Container level cropping is not allowed. │
│ 1.9.2) When transcoding to fix another valid technical flaw (e.g. │
│ decimating duplicates), cropping must be applied if │
│ necessary. │
│ 1.10) VFR (Variable Frame Rate) methods are allowed only if present in │
│ the original source. │
│ 1.10.1) If CFR (Constant Frame Rate) can be used when remuxing and │
│ does not result in playback issue, CFR must be used. │
│ 1.10.1.1) FPS values stored in the video bitstream must be │
│ corrected when remuxing. MKVToolnix with '--fix- │
│ bitstream-timing-information' enabled is the │
│ recommended method. │
│ 1.11) Trimming unrelated footage (see rule 7.7) must be done losslessly │
│ via keyframe intervals (GOP). MKVToolnix is the recommended tool. │
│ 1.11.1) If unrelated footage cannot be removed via this method, │
│ transcoding a maximum of one GOP per cut point is allowed │
│ and the release must still be tagged WEB. VideoRedo is the │
│ recommended tool. │
│ 1.12) Incorrect pixel aspect ratio (PAR), or a non-square sample aspect │
│ ratio (SAR), must be fixed using the correct display aspect ratio │
│ (DAR) set at a container level (--aspect-ratio). MKVToolnix is the │
│ recommended tool. │
│ e.g. A video stream with a non-square SAR must specify the │
│ correct DAR when muxing. │
│ 1.13) Releases with a non-square SAR are not considered technically │
│ flawed. │
│ 1.13.1) However, a source which provides files with a square SAR │
│ will trump an equivalent file with a non-square SAR. It is │
│ recommended to use a source which provides files with a │
│ square SAR. │
│ 1.13.2) In situations where a source initially provides a non-square │
│ SAR file and later updates with a square SAR file, the │
│ initial release with a non-square SAR is considered of lower │
│ quality and a technical flaw. │
│ e.g. Release A: 960x720, SAR: 4:3, DAR: 16:9. │
│ Release B: 1280x720, SAR: 1:1, DAR: 16:9. │
│ Both releases are considered as 720p. │
│ If Release A is first: Release A remains unnuked and is │
│ a valid release until Release B is released. Release B │
│ then propers Release A. │
│ If Release B is first: Release A dupes Release B. │
│ │
│ 2) [ Untouched: Audio ] │
│ 2.1) Must use the original audio track offered by the source. │
│ 2.2) Standard definition releases must only contain an audio track with │
│ a maximum of 2.0 channels. │
│ 2.2.1) Except where the only available audio track on offer contains │
│ more than 2.0 channels. The NFO must mention why an audio │
│ track with more than 2.0 channels was used. │
│ 2.2.2) In situations where a source provides two audio tracks, a 2.0 │
│ and 5.1 track, the 2.0 audio track must be used. │
│ 2.2.3) If a source provides identical channel audio tracks using two │
│ different codecs, it is at the discretion of the group which │
│ track is used. It is recommended to use the smaller file. │
│ e.g. A source offers AC3 2.0 and AAC 2.0, the group may │
│ choose to remux the AC3 or AAC. │
│ 2.3) High Definition releases must use the highest available audio │
│ format and quality offered by the source. │
│ 2.3.1) Highest quality must determined by all characteristics of an │
│ audio track in this order: positional metadata (e.g. Atmos), │
│ channel count, codec and bitrate. │
│ e.g. 576 Kbps, 5.1 E-AC3 w/ Atmos > 640 Kbps, 5.1 AC3 > │
│ 2.0 E-AC3. │
│ e.g. 385 Kbps, 5.1 AC3 > 128 Kbps, 5.1 E-AC3 │
│ e.g. 445 Kbps 5.1 AAC > 384 Kbps, 5.1 E-AC3 │
│ 2.3.2) In situations where a lesser audio format is offered for │
│ larger resolutions in comparison to lower resolutions, groups │
│ must use the highest available audio format from all │
│ resolutions. │
│ e.g. A source provides an AC3 5.1 track for SD │
│ resolutions, but an AAC 2.0 track for 720p/1080p. The AC3 │
│ 5.1 track must be used for 720p/1080p resolutions. │
│ 2.3.3) If using the highest available audio format results in a │
│ technical flaw (e.g. sync issues or glitches), minor │
│ adjustments to the audio track may be applied. If groups are │
│ unable to correct any flaws, the original audio track must be │
│ used. │
│ │
│ 3) [ Transcoded: WEBRip.x264 / WEBRip.x265 ] │
│ 3.1) Transcoded releases should be considered as anything that has been │
│ captured or encoded by a group to a lesser format or quality │
│ (lossy). │
│ 3.2) Transcoded releases must be tagged as WEBRip.x264/x265. │
│ 3.3) Streams must be captured at the highest available resolution and │
│ bitrate offered. │
│ e.g. Source offers 2160p, 1080p and 720p streams. Using │
│ anything but the 2160p stream is not allowed. │
│ 3.3.1) Streams must not have any degradation in quality throughout │
│ the capture, and releases with drops to a lower resolution or │
│ bitrate is considered a technical flaw. │
│ 3.3.2) Audio must be captured in the highest format offered by the │
│ source stream, not what the capturing device is capable of. │
│ This includes channel count and bitrate offered. │
│ e.g. If a Netflix show lists a 5.1 track, the resultant │
│ capture and release should also contain a 5.1 audio │
│ track. │
│ 3.4) Captures should be done at the native broadcast framerate of the │
│ source. │
│ 3.4.1) Captures from devices which are unable to output a native │
│ format must be restored to the original framerate. │
│ 3.4.2) If captures cannot be completely restored to their native │
│ framerate, it is considered a technical flaw. │
│ e.g. A single dupe frame every 1000 or blended/ghost │
│ frames due to mangling from the streaming device. │
│ 3.5) Captures should be done at the native colour space of the source │
│ (e.g. YUV or RGB), and manual corrections should be made to achieve │
│ an output near-identical to the source. │
│ 3.6) Capture software and hardware which introduces video cropping │
│ greater than 2 pixels on any side is not allowed, and is considered │
│ a technical flaw. │
│ 3.7) Final resolution must maintain the same aspect ratio as the source │
│ after cropping and kept at mod 2. │
│ 3.7.1) Sources must have all black borders cropped to the widest │
│ frame. │
│ 3.7.2) The same aspect ratio as calculated from the source must be │
│ used, see rule 8.12. │
│ 3.8) If the video is being transcoded from an untouched source (rule │
│ 1.4.4 and 1.4.5), the NFO must state the reason for transcoding. │
│ 3.8.1) If a technical flaw is present that is being rectified by │
│ transcoding (rule 1.4.3), the flaw must also be included with │
│ the reason for transcoding. │
│ e.g. A file from 2 lossless providers both have the same │
│ interlacing flaw. │
│ The flaw: Interlaced video. │
│ The reason: No other WEB.H264 provider has a correctly │
│ deinterlaced file. │
│ │
│ 4) [ Transcoded: Video Codec ] │
│ 4.1) Video must be: │
│ 4.1.1) H.265/MPEG-H HEVC encoded with x265 10-bit for SD/720p/1080p │
│ HDR and 2160p SDR/HDR content. │
│ 4.1.2) H.264/MPEG-4 AVC encoded with x264 8-bit for SD, 720p and │
│ 1080p SDR content. │
│ 4.1.3) Custom builds of x264/x265 are allowed and must be based off │
│ the current x264/x265 codebase. e.g. tMod, kMod. │
│ 4.2) x264/x265 headers must remain intact and must not be modified or │
│ removed. │
│ 4.3) x264/x265 must be kept up to date, with a maximum allowance, or │
│ grace period, of 60 days before groups are required to update to │
│ the latest revision. │
│ 4.3.1) The official x264 git repository is the only reference for │
│ determining the current revision: │
│ https://code.videolan.org/videolan/x264/tree/stable │
│ 4.3.2) The official x265 git repository is the only reference for │
│ determining the current revision: │
│ https://bitbucket.org/multicoreware/x265/wiki/Home │
│ 4.3.2.1) Until such a time as MulticoreWare implement official │
│ revisional building, 3rd party builds (e.g. self- │
│ compiles, http://msystem.waw.pl/x265 or │
│ https://builds.x265.eu) can be used and must be kept up │
│ to date respecting 4.3. │
│ 4.3.3) The 60 day grace period must only be applied at pre time, not │
│ the tagged encoded date. │
│ 4.3.4) The grace period is only applicable to the revision preceding │
│ the latest update and does not reset active grace periods of │
│ preceding revisions. │
│ e.g. 2016-01-01: Revision A is used. │
│ 2016-01-02: Revision B is committed, 60-day grace period │
│ begins for revision A. │
│ 2016-01-05: Revision C is committed, 60-day grace period │
│ begins for revision B. │
│ 2016-03-02: Revision A is no longer allowed, Revision B │
│ or C may be used. │
│ 2016-03-05: Revision B is no longer allowed, Revision C │
│ must be used. │
│ 4.4) Segmented encoding is not allowed. │
│ 4.5) Constant Rate Factor (--crf) must be used. │
│ 4.5.1) Decimal values may be used. │
│ 4.5.2) Starting with an initial value of 16 or 14 (for especially │
│ compressible sources) for 2160p, 17 for 720p/1080p and 19 for │
│ SD is recommended. │
│ 4.6) While the encoded video stream bitrate exceeds x percent (where x │
│ is defined below) of the y (where y is defined below) resolution │
│ source video stream bitrate, the CRF value must be incremented by 1 │
│ or 0.1, until it does not. │
│ 4.6.1) 2160p │
│ 4.6.1.1) 20% for SD. │
│ 4.6.1.2) 40% for 720p. │
│ 4.6.1.3) 60% for 1080p. │
│ 4.6.1.4) 98% for 2160p. │
│ 4.6.2) 1080p │
│ 4.6.2.1) 40% for SD. │
│ 4.6.2.2) 70% for 720p. │
│ 4.6.2.3) 98% for 1080p. │
│ 4.6.3) 720p │
│ 4.6.3.1) 60% for SD. │
│ 4.6.3.2) 98% for 720p. │
│ 4.6.4) SD │
│ 4.6.4.1) 98% for SD. │
│ 4.6.5) When the source codec is HEVC is being transcoded to AVC, 40% │
│ of the source bitrate must be added to the video stream │
│ bitrate, to account for HEVC's 40-50% improvement over AVC. │
│ e.g. Transcoding 2160p SDR with a bitrate of 15,000 Kbps │
│ to WEBRiP.1080p SDR - in this case, 40% of 15,000 Kbps is │
│ 6,000. The bitrate used for calculations is now 21,000 │
│ Kbps. │
│ 4.7) Use of 2-pass is accepted for all resolutions. However, this method │
│ should be used only in extreme cases and not as a primary │
│ replacement for CRF methods. e.g. If the source contains an │
│ excessive amount of grain or black and white scenes. │
│ 4.7.1) The NFO must provide sufficient detailed evidence of 2-pass │
│ producing a visual improvement, bitrate or file size │
│ advantage over CRF in regards to the source used. │
│ e.g. Source has heavy grain throughout, which required │
│ the use of 2-pass to remain transparent at a reasonable │
│ bitrate. Included in the proof directory is test encodes │
│ of some troublesome areas at CRF and 2-pass showing a │
│ substantial improvement in quality at a more reasonable │
│ bitrate. CRF needs 6.5GB to stay transparent 2-pass only │
│ needed 4GB is detailed evidence. │
│ e.g. The source was grainy so 2-pass was used is NOT │
│ detailed evidence. │
│ 4.7.2) Exceeding CRF 24 on any resolution is a good indication to │
│ consider the use of 2-pass. │
│ 4.7.3) 2-pass encodes must follow the percentage values in 4.6, it │
│ is recommended to target the maximum value allotted and work │
│ down. │
│ 4.8) Exceeding the percentage values in 4.6 is allowed, but very │
│ detailed justification must be included in the NFO. │
│ e.g. 720p encoded at CRF 13 resulting in an encode 80% of the │
│ source, this value was picked as the sourced content had a lot │
│ of strobing effects (e.g. 1m10s-15m30s) and confetti scenes │
│ (e.g. 20m55s-50m60s) which compressed poorly and required a │
│ higher bitrate to maintain transparency. Proof directory │
│ contains samples of these troublesome scenes at 30% and 50% │
│ showing a substantial picture improvement. │
│ 4.9) Using unreasonably high CRF values or low target bitrates with │
│ 2-pass for the source content is considered a technical flaw. │
│ e.g. Producing a 1080p encode at 40% of the source bitrate, │
│ offering no justification in the NFO and having poor │
│ transparency to the source IS a technical flaw. │
│ e.g. Producing a 1080p encode at 20% of the source bitrate │
│ (This may occur on animation content to avoid a bloated │
│ encode), offering justification in the NFO and having good │
│ transparency to the source is NOT a technical flaw. │
│ 4.10) Encoded video bitrate must not exceed the source video bitrate. │
│ 4.10.1) Video bitrate refers only to the bitrate for the video │
│ stream, and not the overall muxed bitrate of all streams │
│ within the container or the bitrate of a captured file. │
│ 4.10.1.1) Original video stream bitrate can be determined by │
│ observing network traffic during playback, or │
│ examining manifests/metadata of the encrypted video │
│ when capturing. │
│ 4.10.2) The following algorithm can also be used to estimate a CRF │
│ value if the value originally used results in a bitrate │
│ which exceeds the source's. │
│ ValidCRF = [-6 * (DestinationBitrate - ExcessiveBitrate) / │
│ ExcessiveBitrate] + CRFUsed │
│ e.g. Source bitrate: 4,500Kbps │
│ Target bitrate: ~3,400Kbps │
│ Encoded bitrate @ CRF17: 5,900Kbps │
│ ValidCRF = (-6 * (3400 - 5900) / 5900) + 17 │
│ 4.11) Settings cannot go below what is specified for preset (--preset) │
│ 'slower' for x264 or 'slow' for x265 by the revision used. │
│ 4.12) Level (x264: --level, x265: --level-idc) must be: │
│ 4.12.1) '3.1' for SD │
│ 4.12.2) '4.1' for 720p │
│ 4.12.3) '4.1' for 1080p, '4.2' for 1080p above 30fps │
│ 4.12.4) '5.1' for 2160p, '5.2' for 2160p above 30fps. │
│ 4.13) Custom matrices are not allowed. │
│ 4.14) Zones (--zones) may be used, but should be used sparingly with a │
│ high degree of caution, the NFO must provide sufficient detailed │
│ evidence for each zone used. │
│ e.g. Used a zone at CRF 13 between frames 1634-5343 due to │
│ confetti spam and heavy motion resulting in very poor │
│ compressibility. Proof directory contains two samples of this │
│ scene with and without the use of the zone showing a drastic │
│ improvement in quality while still keeping a reasonable file │
│ size. │
│ 4.15) GPU offloading or any other forms of acceleration (e.g. --opencl, │
│ nvenc) is not allowed. │
│ 4.16) Optional tuning (--tune) parameters allowed are: 'film', 'grain', │
│ or 'animation'. │
│ 4.17) Optional settings recommended for tuning per source, see │
│ forum.doom9.org for further information: │
│ 4.17.1) For complex video, --preset veryslow is encouraged. │
│ 4.17.2) --aq-mode 3 --aq-strength x.x │
│ 0.5-0.7 for grainy films. │
│ 0.6-0.9 for digital films. │
│ 0.9-1.1 for animation. │
│ 4.17.3) --psy-rd x.x:0.0 │
│ 0.8-1.2 for films. │
│ 0.5-0.8 for animation. │
│ 4.17.4) --deblock x:x │
│ -3:-3 for films. │
│ 1:1 for animation. │
│ 4.18) Sample Aspect Ratio (--sar) must be '1:1' (square). │
│ 4.19) Disabling deblocking (--no-deblock) is not allowed. │
│ 4.20) Frame rate must be passed to x264/x265 such that the keyframe │
│ interval (--keyint) and minimum GOP length (--min-keyint) can be │
│ correctly set by the encoder. Changing these values is not │
│ allowed. │
│ 4.21) Color space must be 4:2:0. │
│ 4.22) Color matrix (--colormatrix) may be optionally set to 'bt709' for │
│ HD SDR content, but is not required. │
│ 4.22.1) However color matrix must be set for all all SD SDR │
│ resolutions. │
│ 4.22.1.1) 'bt709' must be used for encodes from high definition │
│ sources. │
│ 4.22.1.2) Source specification must be used for standard │
│ definition sources. │
│ 4.22.1.3) 'undef' must be used if not specified by the source │
│ for standard definition sources. │
│ 4.23) x265 specifics: │
│ 4.23.1) Range (--range), color primaries (--colorprim), transfer │
│ (--transfer), color matrix (--colormatrix) and chroma sample │
│ location (--chromaloc) must be set to the same value as the │
│ source, or omitted if the source value is undefined. │
│ 4.23.2) Ultra-HD Bluray support (--uhd-bd) is not allowed. │
│ 4.23.3) High tier (--high-tier), repeat headers (--repeat-headers), │
│ access unit delimiter (--aud) and HRD signalling (--hrd) │
│ must be enabled. │
│ 4.23.4) HDR releases must be encoded with: │
│ 4.23.4.1) HDR10 signalling (--hdr10) and HDR10 optimization │
│ (--hdr10-opt) enabled. │
│ 4.23.4.2) Master Display (--master-display) and Max CL (--max- │
│ cll) set to the same value as the source, or omitted │
│ if the source value is undefined. │
│ 4.23.4.2.1) Master Display and Max CL values must be taken │
│ from the whole concatenated source, not a │
│ partial source. e.g. the first m2ts file. │
│ 4.24) Any form of tone-mapping (e.g. HDR to SDR, DV to SDR, HDR10Plus to │
│ SDR) is not allowed. │
│ 4.25) Suggested command line: │
│ 4.25.1) x264 --preset slower --level ## --crf ## │
│ 4.25.1.1) Optional tweaks: --no-mbtree --no-fast-pskip --no-dct- │
│ decimate │
│ 4.25.2) x265 --high-tier --repeat-headers --aud --hrd --preset slow │
│ --level-idc ## --crf ## --range ## --colorprim ## --transfer │
│ ## --colormatrix ## --chromaloc ## │
│ 4.25.2.1) If HDR append: --hdr10 --hdr10-opt --master-display ## │
│ --max-cll ## │
│ 4.25.2.2) Optional tweaks: --no-cutree --no-open-gop --no-sao │
│ --pmode --aq-mode 4 │
│ │
│ 5) [ Transcoded: Audio ] │
│ 5.1) Segmented encoding is not allowed. │
│ 5.2) Audio must not be resampled and must be kept in the original format │
│ of the source. │
│ e.g. 48 kHz for 48 kHz sources, 24 bit for 24 bit sources. │
│ 5.2.1) Except when resampling due to codec limitations. │
│ e.g. Source is TrueHD 192 KHz being transcoded to AC3 for │
│ a 720p release, AC3 is limited to 48 KHz. Resampling is │
│ accepted. │
│ 5.3) Audio must not have gain levels (normalization) adjusted and must │
│ be kept at the same levels as the source. │
│ 5.4) Audio must not have channels altered or removed and must be kept at │
│ the same channel count and layout as the source. │
│ e.g. dual mono stays dual mono, mono stays mono, stereo stays │
│ stereo, 5.1 stays 5.1 │
│ 5.5) Lossy tracks include, but are not limited to: DTS-HD HR, E-AC3, │
│ DTS-ES, DTS, AC3, AAC, MP2. │
│ 5.6) Audio tracks must be: │
│ 5.6.1) For 720p and above: │
│ 5.6.1.1) Audio tracks already in a lossy format must not be │
│ transcoded, but kept in the original format. │
│ 5.6.1.2) In cases when no lossy format is available or │
│ transcoding audio to correct technical flaws in the │
│ audio track, AC3 or E-AC3 must be used. │
│ 5.6.1.3) AC3 or E-AC3 bitrate must target 640 Kbps without │
│ upscaling bitrate. Only the following methods are │
│ allowed (in order of preference): │
│ 5.6.1.3.1) Dolby Media Encoder │
│ 5.6.1.3.2) eac3to: -640 │
│ 5.6.1.3.3) FFmpeg: -b:a 640k │
│ 5.6.1.4) When transcoding, positional audio metadata (e.g. │
│ DTS:X, TrueHD Atmos) and channels above 5.1 (e.g. 7.1) │
│ can be retained at the discretion of the group. │
│ 5.6.2) VBR AAC LC (Low Complexity) for SD and commentary audio. │
│ 5.6.2.1) Apple/QAAC, FDK-AAC or Nero must be used. │
│ 5.6.2.2) Audio with more than two channels must be down-mixed to │
│ stereo. Only the following methods are allowed (in │
│ order of preference): │
│ 5.6.2.2.1) eac3to: -downStereo │
│ 5.6.2.2.2) FFMpeg: -ac 2 │
│ 5.6.2.3) Quality based VBR encoding must be used; targeted or │
│ constrained VBR must not be used. Only the following │
│ methods are allowed (in order of preference): │
│ 5.6.2.3.1) QAAC: --tvbr 82 --quality 2 │
│ 5.6.2.3.2) FDK-AAC: --bitrate-mode 4 --profile 2 │
│ 5.6.2.3.3) Nero: -q 0.4 │
│ 5.6.3) FLAC must be used for lossless mono and lossless stereo │
│ tracks, as well as multi-channel LPCM tracks. For all HD │
│ resolutions from a retail source. │
│ 5.6.3.1) The best compression (level 8, --compression-level-8) │
│ must be used. │
│ 5.6.3.2) Replay-gain values (--replay-gain) must not be applied. │
│ │
│ 6) [ Transcoded: Filters ] │
│ 6.1) Inverse telecine (IVTC), de-interlacing, or decimation must be │
│ applied as required. │
│ 6.2) Only the following smart deinterlacers can be used: QTGMC (with │
│ preset slow or better) or Nnedi3. │
│ 6.3) Only the following accurate field matching filters may be used: │
│ TIVTC or Decomb. │
│ 6.4) Only the following sharp resizers can be used: Spline36Resize, │
│ Spline64Resize or BlackmanResize. │
│ 6.5) Only frame accurate input source plugins can be used such as: │
│ DGIndex, DGDecNV or LSMASHSource. Use of frame inaccurate input │
│ source filters (e.g. DirectShowSource) is not allowed. │
│ 6.6) Use of destructive and effects filters including, but not limited │
│ to: RemoveGrain, GrainFactory3, MedianBlur, FineSharp are not │
│ allowed. │
│ 6.7) Optional recommended filtering methods: │
│ 6.7.1) Sources that require crop, and are not mod2 on opposing │
│ sides, can be avoided by moving the video by one pixel. │
│ e.g. 139 pixels can be cropped from the top and bottom of │
│ a source. │
│ source = LSMASHVideoSource("source.mkv") │
│ Overlay(source, source, 0, -1) │
│ Crop(0, 138, 0, -140) │
│ 6.7.2) Use of SelectRangeEvery() as a quick method to test whether a │
│ higher or lower CRF value should be used. │
│ e.g. SelectRangeEvery(3000, 150). │
│ 6.7.3) Selective debanding with f3kdb on scenes that require it is │
│ recommended, high attention to detail and caution must be │
│ observed. │
│ │
│ 7) [ Common: Video ] │
│ 7.1) Multiple video tracks are not allowed. │
│ 7.2) HDR, DV and HDR10Plus must only be released at the highest │
│ resolution offered by the source, except in cases when 8.6.3 │
│ applies. │
│ e.g. Source offers 2160p, 1080p and 720p HDR streams HDR may │
│ only be released at 2160p, not 1080p or 720p. │
│ 7.3) Must be free from technical flaws. │
│ 7.3.1) Technical flaws include, but are not limited to: sync issues, │
│ interlacing, lack of IVTC, bad aspect ratio, invalid │
│ resolution, unrelated footage, warnings, glitches not present │
│ on source, under-crop, over-crop and DRM. │
│ 7.4) Dupes based on source are not allowed, use INTERNAL. │
│ 7.5) Single features must not be split across multiple files. │
│ 7.5.1) Sources with opening and closing credits spanning across │
│ multiple files must be released as a single release. │
│ e.g. File 1: Opening credits │
│ File 2: Feature │
│ File 3: Closing credits │
│ Release: A single file with opening credits, feature and │
│ closing credits. Muxed together or encoded as a single │
│ file. │
│ 7.5.2) Sources with multiple episodes, parts etc., that are in a │
│ single video file, must be split into individual releases if │
│ there is a clear delineation between them, such as credits. │
│ e.g. Source contains 10 episodes in a single stream with │
│ all episodes strung together with credits between every │
│ episode, each episode must be released separately. │
│ 7.6) Non-feature footage including, but not limited to: credits, │
│ previously on, intertitles must not be removed or encoded │
│ separately. │
│ 7.6.1) In situations of a progressive feature containing interlaced │
│ non-feature footage, the interlaced footage may be left │
│ interlaced, or only that footage must be deinterlaced. │
│ e.g. Only the credits are interlaced, you may leave them │
│ interlaced or only apply a deinterlacer to the credits, │
│ not the entire video. │
│ 7.7) Unrelated footage must be removed. │
│ 7.7.1) Unrelated footage includes, but is not limited to: │
│ commercials, content warnings, studio worksheets, test │
│ screens, piracy warnings. │
│ 7.8) English-spoken features must not contain foreign overlays for │
│ relevant on-screen information. │
│ 7.8.1) Relevant on-screen information includes, but is not limited │
│ to: location titles, hardcoded subtitles, introduction text, │
│ or any other information essential to the plot of the │
│ feature. │
│ 7.8.2) Non-relevant on-screen information includes: opening credits, │
│ movie title, closing credits. │
│ 7.8.3) For sources where relevant on-screen information is included │
│ in the form of English subtitles instead of overlays, these │
│ subtitles must be included as a forced track (see 11.2). If │
│ the source does not include them in English, it is not │
│ allowed to omit them and release the feature without them, as │
│ it is still considered relevant information. │
│ 7.9) Using multiple web based video sources of the same feature is │
│ allowed and must not be encoded separately. Each source and what │
│ content came from which must be noted in the NFO. │
│ e.g. Feature from a German streaming service with credits from │
│ an American streaming service to avoid German translated │
│ credits, as the German streaming service had better quality for │
│ the feature. │
│ │
│ 8) [ Common: Resolution / Aspect Ratio ] │
│ 8.1) Standard definition (SD) refers to a maximum horizontal display │
│ resolution of 720 pixels. │
│ 8.2) 720p refers to a maximum display resolution of 1280x720. │
│ 8.2.1) For aspect ratios greater than or equal to 1.78:1, horizontal │
│ pixel width must be 1280 pixels. │
│ e.g. Source aspect ratio of 2.40:1 will resize to │
│ 1280x534. │
│ 8.2.2) For aspect ratios less than or equal to 1.78:1, vertical │
│ pixel height must be 720 pixels. │
│ e.g. Source aspect ratio of 1.33:1 will resize to │
│ 960x720. │
│ 8.3) 1080p refers to a maximum display resolution of 1920x1080. │
│ 8.4) 2160p refers to a maximum display resolution of 3840x2160. │
│ 8.5) Resolution must be mod2. │
│ 8.6) Upscaling is not allowed. │
│ 8.6.1) 1080p from a 1080p source and 2160p from a 2160p source │
│ encodes must only be cropped, no resizing is allowed. │
│ 8.6.2) In situations where cropping is needed vertically and/or │
│ horizontally, resolutions are allowed to be under the max │
│ height or width. │
│ e.g. 1080p at 1916x1072 is acceptable. │
│ 8.6.3) In situations where the source video stream does not meet the │
│ minimum requirements for 720p/1080p/2160p, the video must be │
│ resized down to SD/720p/1080p and a source sample must be │
│ included. │
│ 8.7) Dupes based on resolution are not allowed, use INTERNAL. │
│ 8.7.1) Releases with an AR difference of at least 5% to the previous │
│ release are not considered a dupe. These releases must be │
│ tagged as WS, FS or OM (open matte), not PROPER, and the │
│ original release must not be nuked. Original aspect ratio │
│ (OAR) releases are always allowed. │
│ 8.7.1.1) AR difference example: │
│ Old release resolution (after crop) is 1920x1040 │
│ New release resolution (after crop) is 1440x1080 │
│ OldReleaseAR = 1920 / 1040 = 1.846 │
│ NewReleaseAR = 1440 / 1080 = 1.333 │
│ (OldReleaseAR - NewReleaseAR) / [(OldReleaseAR + │
│ NewReleaseAR) / 2] = AR difference │
│ |AR difference * 100| = AR difference (%) │
│ (1.846 - 1.333) / [(1.846 + 1.333) / 2] = 0.322 │
│ |0.322 * 100| = 32.2% │
│ 32.2% is greater than the 5% minimum, therefore the new │
│ release is not considered a dupe. │
│ 8.8) Black borders, and anything that is not part of the feature, must │
│ be cropped. │
│ 8.8.1) Black borders include, but are not limited to: black or │
│ colored borders, duplicate lines, dirty lines or pixels. │
│ 8.8.2) Retention or removal of faded edges is left to the discretion │
│ of the group. Inclusion of faded edges is not considered a │
│ technical flaw. │
│ 8.8.2.1) Faded edges refers to a line of pixels which are of │
│ similar appearance to pixels parallel to the video │
│ frame. │
│ 8.8.2.2) Releases which include faded edges must consider faded │
│ edges as a valid part of the video frame and do not │
│ count as black borders. │
│ e.g. A release cannot be propered if 1 pixel of │
│ faded edges and 1 pixel of black exists. │
│ 8.8.3) In the case of varying aspect ratios throughout the feature, │
│ video must be cropped to the widest frame. │
│ 8.8.3.1) Studio logos and credits must be disregarded when │
│ determining the widest frame. │
│ 8.8.4) Situations where video cropping of the same content varies │
│ between sources are not considered a technical flaw, and may │
│ not be propered. │
│ 8.9) Video can be over or under-cropped by a maximum of 1 pixel per │
│ side. Over or under-cropping by more than 1 pixel per side is │
│ considered a technical flaw. │
│ 8.9.1) Under-crop refers to portions of the video frame which is not │
│ part of the feature. │
│ 8.10) Resolution must be within 0.2% of the original aspect ratio. │
│ 8.10.1) The original aspect ratio must only be calculated from the │
│ source after cropping. │
│ 8.10.2) In situations where the source aspect ratio is incorrect as │
│ a result of bad mastering, a source sample and comparison │
│ screenshot of the final aspect ratio must be included. │
│ 8.11) Sample aspect ratio (SAR): │
│ SAR = (PixelHeight / PixelWidth) / (DARHeight / DARWidth) │
│ 8.12) Display aspect ratio (DAR): │
│ DAR = (PixelWidth * DARWidth) / (PixelHeight * DARHeight) │
│ 8.13) Display resolution: │
│ DisplayWidth = PixelWidth * (SARWidth / SARHeight) │
│ 8.14) Aspect ratio (AR) error: │
│ Original AR = (SourceWidth - [CropLeft + CropRight]) / │
│ (SourceHeight - [CropTop + CropBottom]) │
│ Release AR = EncodeWidth / EncodedHeight │
│ AR Error % = [(Original AR - Release AR) / Original AR] * 100 │
│ 8.15) Target resolution when resizing to maintain mod2 and reduce AR │
│ error: │
│ TargetHeight = TargetWidth / [(SourceWidth - [CropLeft + │
│ CropRight]) / (SourceHeight - [CropTop + CropBottom])] │
│ The correct mod2 value can also be calculated from the ceiling of │
│ TargetHeight if the value is odd, and the floor of TargetHeight if │
│ the value is even. │
│ 8.15.1) Alternatively, the following can be used to confirm the │
│ correct resolution is used from the above method by │
│ calculating the upper and lower integer limit of │
│ TargetHeight: │
│ HeightA = floor(TargetHeight + (TargetHeight mod2)) │
│ HeightB = floor(TargetHeight - (TargetHeight mod2)) │
│ The TargetHeight value (HeightA or HeightB) which results in │
│ an aspect ratio error which tends to zero must be used. │
│ e.g. TargetWidth: 1280. │
│ SourceWidth: 1920, SourceHeight: 1080. │
│ CropLeft + CropRight = 0, CropTop + CropBottom = 4. │
│ TargetHeight = 1280 / ((1920 - 0) / (1080 - 4)) or │
│ 717.33. │
│ HeightA = floor(717.33 + (717.33 mod2)) or 718. │
│ HeightB = floor(717.33 - (717.33 mod2)) or 716. │
│ TargetWidth x HeightA = 1280x718 with -0.09% AR error. │
│ TargetWidth x HeightB = 1280x716 with 0.19% AR error. │
│ -0.09% tends closer to zero than 0.19% does (0.09 < │
│ 0.19), therefore, HeightA must be used. │
│ │
│ 9) [ Common: Framerate ] │
│ 9.1) Constant frame rate (CFR) must be used. │
│ 9.1.1) Variable frame rate (VFR) methods are not allowed. │
│ 9.2) Dupes based on frame rate are not allowed, use INTERNAL. │
│ 9.3) Features which contain a constant dupe sequence must be decimated. │
│ e.g. A silent movie at 1080p24 with a dupe sequence of 1-in-6 │
│ must be decimated to 20 fps. │
│ 9.4) For sources which contain footage at varying frames per second │
│ throughout (hybrid sources), applying an inverse telecine is left │
│ to the discretion of the group. The NFO must list a reason as per │
│ the final decision chosen. │
│ 9.4.1) It is assumed that the majority of the feature contains │
│ enough unique frames to not require an inverse telecine │
│ filter. If it can be proven an inverse telecine or decimating │
│ filter does not result in any loss of unique frames, this is │
│ considered a technical flaw. │
│ e.g. The feature is filmed at 29.970 fps, but contains │
│ some footage filmed at 23.976 fps. Choosing to encode the │
│ entire release at 29.970 is valid. │
│ 9.5) Native and converted frame rates refer to the standard in which the │
│ feature was produced. │
│ 9.5.1) NTSC produced content is native to NTSC. │
│ 9.5.2) PAL produced content is native to PAL. │
│ 9.5.3) NTSC produced content that is mastered in PAL is considered │
│ as converted video. │
│ 9.5.4) PAL produced content that is mastered in NTSC is considered │
│ as converted video. │
│ 9.6) Sources which contain converted video must be restored to the │
│ original frame rate. │
│ 9.6.1) Converted video includes, but is not limited to: ghosted, │
│ blended, or duplicate frames. │
│ 9.6.2) Converted video does not include NTSC to PAL or PAL to NTSC │
│ sources which are sped up or slowed down. │
│ 9.6.2.1) NTSC slow down or PAL speed up must be corrected by │
│ muxing video to the correct fps and slowing down or │
│ speeding up audio. eac3to is the recommended tool. │
│ e.g. Source is PAL sped up, therefore it must be │
│ slowed down back to NTSC. │
│ Video: Mux with --default-duration 24000/1001p - to │
│ force NTSC fps │
│ Audio: eac3to input.ac3 output.ac3 -slowdown │
│ -keepDialnorm - to slow audio down to NTSC │
│ 9.6.2.2) Relevant rules from section 5 must be respected when │
│ transcoding audio. │
│ 9.6.2.3) WEB releases must still be tagged as such, when only │
│ correcting slow down or speed up. │
│ 9.6.2.4) 24 fps must be considered a valid frame rate and not │
│ corrected, if it is only sped up or slowed down with no │
│ other issues. │
│ 9.6.3) If the restoration process is successful in restoring the │
│ footage to the native format without significant issues or │
│ artifacts, the CONVERT tag must not be used. │
│ 9.6.4) In situations where the footage cannot be restored to the │
│ native format or results in significant issues or artifacts, │
│ the CONVERT tag must be used. │
│ 9.7) True 50 / 59.940 fps video must be released at 50 / 59.940 fps. │
│ True 25 / 29.970 fps video released at 50 / 59.940 fps is not │
│ allowed and considered a technical flaw. │
│ 9.7.1) In cases of varying framerates of 25 / 29.970 fps and true 50 │
│ / 59.940 fps, the framerate of the main feature must be used. │
│ e.g. studio for talk shows, game coverage for sports. │
│ 9.7.2) In rare situations, 25 / 50 fps sources must be restored to │
│ 23.976 or 29.97 fps. │
│ 9.7.3) In rare situations, 29.97 / 59.940 fps sources must be │
│ restored to 25 fps. │
│ │
│ 10) [ Common: Audio ] │
│ 10.1) Sync must not drift during the entire release. │
│ 10.2) Glitching or unrelated audio that occurs in any audio channel │
│ present (e.g. L, R, C) is considered a technical flaw. │
│ 10.2.1) Glitching is defined as, but not limited to: an audible │
│ glitch, missing audio, pops or clicks as a result of │
│ encoding, unintended gaps within playback, missing dialogue, │
│ muted or muffled audio. │
│ 10.3) An English spoken release must only contain a single English │
│ dialogue track. │
│ 10.3.1) Except in situations of a remastered/restored source, │
│ whereby both original and remastered/restored audio track │
│ may be muxed in. It is at the discretion of the group which │
│ track is chosen as the primary dialogue track. │
│ 10.4) A non-English spoken release may contain a secondary dialogue │
│ track. │
│ 10.4.1) The original audio track must be used and forced English │
│ subtitles must be present, see 11.2. │
│ 10.4.2) Secondary dubbed tracks must only be different dialects or │
│ varieties of the original language or an English dub. │
│ e.g. Original Spanish with secondary Latin Spanish. │
│ e.g. Original French with secondary English dub. │
│ 10.4.3) In rare cases, a third dubbed track may be included for │
│ another dialect or variety of the original language, │
│ accompanied with an English dubbed track. │
│ e.g. Chinese original language, English dubbed track and │
│ a Cantonese dubbed track. │
│ 10.5) Non-English spoken releases which use only a dubbed track must be │
│ tagged as DUBBED. │
│ 10.6) Commentary audio may be included. │
│ 10.7) Audio tracks must only be included once at the highest level of │
│ quality allowed for that resolution. e.g. Including an English │
│ dialogue track at lossless DTS-HD and lossy AC3 is not allowed. │
│ 10.7.1) This does not apply to embedded cores in lossless tracks, │
│ which are broken out by muxers as additional tracks. │
│ 10.8) Including additional special audio tracks (e.g. isolated scores, │
│ original mixes, different narrators) is allowed. │
│ 10.9) Supplementary audio tracks must have the title field set to a │
│ descriptive name. e.g. original, remastered, commentary with │
│ director. │
│ 10.10) The correct ISO 639 language code supported by MKVToolnix must be │
│ set for all audio tracks. │
│ 10.10.1) In situations where the language is not supported by │
│ MKVToolnix, 'und' must be used. │
│ 10.11) Dupes based on multiple audio tracks, audio format, different │
│ narrators or remastered audio are not allowed, use INTERNAL. │
│ 10.12) Retail audio may be used in place of audio tracks extracted from │
│ the source. Each source and what content came from which must be │
│ noted in the NFO. │
│ e.g. Video from Netflix, dubbed track from DVD. │
│ 10.12.1) Lossless tracks include, but are not limited to: DTS:X, │
│ TrueHD Atmos, DTS-HD MA and TrueHD. │
│ 10.12.2) Use of the highest quality retail lossless track in the │
│ order of preference specified in 10.12.1 is accepted for │
│ resolutions above 720p. │
│ 10.12.3) 720p must respect 5.6.1 by first attempting to extract an │
│ AC3 or E-AC3 core at or above 640 Kbps or transcoding from │
│ the best lossless/lossy retail track. │
│ 10.12.4) SD and commentary audio must respect 5.6.2, by transcoding │
│ from the best lossless/lossy retail track. │
│ │
│ 11) [ Common: Subtitles ] │
│ 11.1) All subtitles present on the source must be converted to SubRip │
│ format and included in the release. │
│ 11.1.1) It is at the discretion of the group to include forced │
│ subtitles for dubbed audio tracks not included in the │
│ release. │
│ 11.1.2) Except in cases when 11.2.2 applies for non-forced tracks, │
│ PGS or ASS format must be used instead. │
│ 11.1.3) Except when capturing non-forced subtitles are optional, but │
│ it is strongly recommend to find a way to extract them from │
│ the source. │
│ 11.2) Features with foreign dialogue or overlays must include a separate │
│ SubRip subtitle (.srt) track for forced English subtitles set as │
│ forced and default. │
│ 11.2.1) Except in situations where the source video stream contains │
│ hardcoded subtitles for non-English dialogue and overlays. │
│ 11.2.2) Except for features with excessive positional subtitles │
│ (e.g. Anime) which cannot be presented well in SubRip │
│ format. PGS or ASS subtitles must be used instead and set as │
│ forced and default. │
│ 11.3) Forced SubRip subtitles must be free of technical flaws. │
│ Including, but not limited to: sync issues, spelling, incorrect │
│ OCR. │
│ 11.3.1) SubRip subtitles must be carefully OCR'd. │
│ 11.3.2) Minor errors in grammar or punctuation which do not change │
│ the meaning of the sentence are tolerated. However, it is │
│ recommended all errors be corrected. │
│ 11.4) Subtitles from an officially licenced (e.g. HBO TV, Starz TV) HDTV │
│ source or retail discs of the same feature are allowed. │
│ 11.4.1) Subtitles included from another source must be noted in the │
│ NFO. The source and which subtitle tracks used must be │
│ mentioned. │
│ 11.4.2) Fan-made or custom subtitles are not allowed. │
│ 11.4.2.1) This does not included stripped SDH subtitles, which │
│ may be optionally made by groups from a valid SDH │
│ subtitle. │
│ 11.5) Hardcoded subtitles which are only present in the source video │
│ stream are allowed, with the exception of non-English hardcoded │
│ subtitles in English features. │
│ 11.5.1) When hardcoded subtitles extend over the entire feature, it │
│ must be tagged as SUBBED. │
│ e.g. English hardcoded subtitles throughout entire │
│ feature = Tag SUBBED │
│ e.g. English hardcoded subtitles for foreign │
│ dialogue only = Do not tag SUBBED │
│ 11.5.2) Subtitles which are only present within the letterboxed │
│ matte (i.e. the black borders) of a video frame must be │
│ cropped and OCR'd to SubRip format. │
│ 11.5.3) In situations where subtitles overlay active video and │
│ letterbox matte, cropping must be to the widest frame where │
│ the subtitles are present and applied equally to the │
│ relevant sides of the video frame. │
│ 11.5.4) 11.5.2 and 11.5.3 do not apply to WEB releases. │
│ 11.6) Subtitles, unless otherwise stated, are not subject to propers or │
│ nukes for any technical flaws that may be present in the track. │
│ 11.7) Dupes based on subtitles are not allowed, use INTERNAL. │
│ │
│ 12) [ Common: Subtitle Format ] │
│ 12.1) Allowed formats are PGS (.sup), SubStation Alpha (.ass) and SubRip │
│ (.srt). │
│ 12.1.1) Compression must only be used when muxing PGS subtitles, │
│ zlib is the only allowed compression algorithm. │
│ 12.1.2) PGS subtitles must not be resized and must be muxed as is. │
│ 12.1.3) UTF-8 encoding must be used for SubStation Alpha and SubRip │
│ subtitle tracks. │
│ 12.1.4) When converting to SubStation Alpha format, subtitles must │
│ be cleanly converted without any unnecessary modifications │
│ to display format. e.g. position, font, color. Subtitle Edit │
│ is the recommended tool. │
│ 12.1.5) Closed captions (e.g. CEA-708) embedded in video bitstreams │
│ must be left as is and not stripped. │
│ 12.1.5.1) Retaining closed captions when transcoding is optional │
│ but strongly recommend. │
│ 12.1.5.2) Extracting closed captions to create SubRip or when │
│ appropriate SubStation Alpha formatted subtitles is │
│ optional but strongly recommend. │
│ 12.2) Subtitles must: │
│ 12.2.1) Have the correct ISO 639 language code supported by │
│ MKVToolNix set │
│ 12.2.1.1) In situations where the language is not supported by │
│ MKVToolNix, 'und' must be used. │
│ 12.2.2) Not be set as default or forced, unless otherwise stated in │
│ section 11. │
│ 12.2.3) Have the correct sync offset set during muxing. │
│ 12.2.4) Be converted correctly without creating new flaws. Groups │
│ are not responsible for any flaws already present in non- │
│ forced subtitle tracks. │
│ e.g. Subtitle is out of sync on the source in a non- │
│ forced track, when converted it is still out of sync. │
│ This is not a technical flaw. │
│ e.g. Subtitle is in sync on the source and converted │
│ to SubRip format incorrectly by the group resulting │
│ in sync issues. This is a technical flaw. │
│ 12.3) It is strongly recommended to have descriptive names set on the │
│ title field. │
│ e.g. Director's Commentary, English (Forced), English (SDH). │
│ 12.4) Burning-in subtitles to the video stream is not allowed. │
│ 12.5) External subtitles located in 'Subs' directories are not allowed. │
│ │
│ 13) [ Common: Container ] │
│ 13.1) Container must be Matroska (.mkv). MKVToolnix is the recommended │
│ muxer. │
│ 13.1.1) Custom muxing tools are allowed. However, the output must │
│ adhere to the Matroska specifications and must retain │
│ identical compatibility with demuxers as files created with │
│ MKVToolnix. │
│ 13.2) Support for file streaming and playback from RAR is mandatory. │
│ 13.3) Matroska header compression must not be enabled. │
│ 13.4) Chapters are allowed and strongly recommended. │
│ 13.4.1) Chapter names are optional, but any chapter names including │
│ those auto-generated by muxers must be in English. │
│ 13.5) Watermarks, intros, outros or any other forms of defacement in any │
│ track (e.g. video, audio, subtitles, chapters) are not allowed. │
│ │
│ 14) [ Common: Packaging ] │
│ 14.1) Releases must be packed with RAR files and broken into a maximum │
│ of 101 volumes. │
│ 14.1.1) The old style extension-based naming scheme must be used. │
│ i.e. .rar to .r99. │
│ 14.1.2) The extension of the first volume in the archive set must be │
│ .rar. │
│ 14.2) RAR5/RARv5.0 is not allowed. RAR3/v2.0 or RAR4/v2.9 must be used. │
│ 14.2.1) Custom RAR tools can be used. Files produced from custom │
│ tools must adhere to the RAR3/v2.0 or RAR4/v2.9 archive │
│ specification and retain identical compatibility with │
│ extractors and demuxers as file created with WinRAR/rar. │
│ 14.3) The following archive sizes are allowed: │
│ 14.3.1) 15,000,000 bytes or 20,000,000 bytes for SD. Multiples of │
│ these values are not allowed. │
│ 14.3.2) Positive integer multiples of 50,000,000 bytes for all │
│ resolutions. │
│ e.g. (50 * 10^6) * n bytes, where n > 0. │
│ (50 * 10^6) * 4 bytes, 100,000,000 bytes, 400,000,000 │
│ bytes. │
│ 14.3.3) Releases must have a minimum of 10 volumes before the next │
│ multiple of 50,000,000 bytes is used. │
│ e.g. 10 volumes at 50,000,000 bytes can be repackaged to │
│ 5 volumes at 100,000,000 bytes. │
│ 5 volumes at 100,000,000 bytes cannot be repacked to 4 │
│ volumes at 150,000,000 bytes. │
│ 14.4) A single SFV must be present for the primary archives and contain │
│ the entire archive set. │
│ 14.5) NFO, RAR, SFV, Proof, Sample files must have unique, lower-case │
│ filenames with the group tag. │
│ 14.5.1) Group tags must be unique to each group, and may be an │
│ abbreviated variation of the group name. │
│ 14.6) Preing a release with missing RAR(s) or SFV on all sites is │
│ considered a technical flaw. │
│ 14.7) Corrupt RAR(s) (errors upon extraction) is considered a technical │
│ flaw. │
│ 14.8) RAR compression and recovery records are not allowed. │
│ 14.9) Encryption or password protection is not allowed. │
│ 14.10) RAR archive set must only contain a single mkv file, any other │
│ files (e.g. multiple mkv files, txt files) are not allowed. │
│ 14.10.1) Except for extras releases, multiple mkv files are allowed │
│ and filenames must be unique and descriptive. │
│ e.g. │
│ The.Big.Bang.Theory.S01.EXTRAS.1080p.WEB.H264-GROUP │
│ contains: │
│ - Interview.with.the.Cast.mkv │
│ - S01E01.Bloopers.mkv │
│ 14.10.1.1) All extras of the resolution tagged must be included. │
│ 14.10.1.2) External extras located in 'Extras' directories are │
│ not allowed. │
│ │
│ 15) [ Common: Proof ] │
│ 15.1) Proof must be provided for every release that contains retail │
│ elements. e.g. subtitles and audio. │
│ 15.1.1) A photograph of reasonable high quality of the printed side │
│ of the physical disc with the group name clearly visible │
│ must be used. │
│ 15.1.2) Photographs must be at least 640x480px in resolution. Disc │
│ details must be clear and legible. │
│ 15.1.3) Small identifiable or sensitive information may be redacted. │
│ 15.1.4) Photographs must be of the actual disc used for the final │
│ encode. │
│ 15.1.5) Cover scans or m2ts samples may be included, but do not │
│ count as the required proof. │
│ 15.2) Proof must be placed in a separate directory named 'Proof'. │
│ 15.2.1) Proof must be in JPEG or PNG format and must not be │
│ archived. │
│ 15.3) When video, audio or subtitles are taken from multiple retail │
│ sources, proof must be provided for all sources used. │
│ e.g. Video from Source A and audio from Source B are used. │
│ Proof of Source A and B is required. │
│ 15.4) All EXIF data (especially any personally identifiable such as │
│ geolocation) must be stripped. │
│ 15.4.1) Drawing attention (e.g. nuking, propering, mentioning in │
│ nfo) to proof which has not stripped EXIF data is strictly │
│ not allowed. │
│ 15.5) A release which fails to pre with the required proof is considered │
│ technically flawed and can be propered. │
│ 15.5.1) Proof fixes must be pred within 24 hours of the original │
│ pre. │
│ 15.5.2) Fixes provided after a proper has been released, or after 24 │
│ hours has elapsed from the original pre will not be │
│ accepted. │
│ │
│ 16) [ Common: Samples / Source Samples ] │
│ 16.1) Releases must include a 50-70 second sample for each release, │
│ samples must: │
│ 16.1.1) Be placed in a separate directory named 'Sample'. │
│ 16.1.2) Be cut from the final video, not encoded separately and not │
│ be archived. │
│ 16.1.3) Not contain opening (e.g. studio titles) or closing (e.g. │
│ credits) footage when possible. e.g. cut samples from at │
│ least 2m in or the middle to avoid this. │
│ 16.2) Source samples are required for any release where the validity of │
│ the source may be brought into question. │
│ 16.2.1) Included source samples must have a unique filename and be │
│ placed within the 'Proof' directory. │
│ 16.2.2) If there is a question as to the validity of a source, │
│ encoding methods, or filters used; the release may be nuked │
│ within 24 hours of pre requesting a source sample and must │
│ include the initial suspicion or reason. │
│ e.g. │
│ source.sample.requested_suspicion.of.invalid.decimation. │
│ 16.2.3) Requests may mention a specific timecode to verify the │
│ sample provided is the same source used for the encode in │
│ question. │
│ e.g. include.ghosting.at.2m22s. │
│ 16.2.4) The group has 48 hours from the first nuke to pre a source │
│ sample that is at least 30 seconds and no more than minutes │
│ in length. If no specific timestamp is requested, source │
│ samples must be of the main feature and not the starting or │
│ ending credits. │
│ 16.2.5) Source samples must be packed as per section 14 and use the │
│ SOURCE.SAMPLE tag. │
│ 16.2.6) Failing to provide source proof, or providing insufficient │
│ proof to disprove any claims, the original release must │
│ remain nuked and can be considered technically flawed. │
│ │
│ 17) [ Common: NFO ] │
│ 17.1) A single NFO file must be present, and must contain the following │
│ information: │
│ 17.1.1) Transcoded content: Source video stream bitrate. │
│ 17.1.1.1) Must be retrieved using an accurate method, such as: │
│ MediaInfo (using --parsespeed=1), ffprobe, etc. │
│ 17.2) The following information is optional, but recommended: │
│ 17.2.1) Release name and group. │
│ 17.2.2) Release date. │
│ 17.2.3) Runtime. │
│ 17.2.4) Resolution and aspect ratio. │
│ 17.2.5) Frame rate. │
│ 17.2.6) Audio format. │
│ 17.2.7) File size. │
│ 17.2.8) Archive information. │
│ 17.2.9) List of included subtitles. │
│ 17.2.10) CRF value. │
│ │
│ 18) [ Common: Tagging ] │
│ 18.1) The following source tags are allowed: │
│ WEB, WEBRIP │
│ 18.2) Only the following additional tags are allowed: │
│ ALTERNATIVE.CUT, BW, CHRONO, COLORIZED, CONVERT, DC, DIRFIX, │
│ DUBBED, DV, EXTENDED, EXTRAS, FS, HDR, HDR10Plus, HR, INTERNAL, │
│ LINE, NFOFIX, OAR, OM, PROOFFIX, PROPER, PURE, RATED, READNFO, │
│ REAL, REMASTERED, REPACK, RERIP, RESTORED, SAMPLEFIX, │
│ SOURCE.SAMPLE, SUBBED, THEATRICAL, UNCENSORED, UNCUT, UNRATED, WS │
│ 18.2.1) <VERSION / CUT TITLE> may be used when a tag from 18.2 does │
│ not fit. │
│ e.g. Deadpool 2: The Super Duper Cut may be tagged as │
│ Deadpool.2.2018.The.Super.Duper.Cut │
│ 18.2.2) Proof must be provided for all remastered/restored releases │
│ to prove it is in fact a remaster/restore. Acceptable proof │
│ is: │
│ 18.2.2.1) At least 3 screenshots comparing the new and old │
│ sources or encodes, depicting a stark difference │
│ included in the 'Proof' directory. │
│ 18.2.2.2) Link in the NFO to a comparison website (e.g. caps-a- │
│ holic.com) which has already performed comparisons. │
│ 18.2.2.3) Subsequent releases from the same remastered/restored │
│ source may refer back to the first release in the NFO │
│ in lieu of including proof again. │
│ e.g. 1080p released first with proof, 720p can │
│ refer back to the proof in the 1080p. │
│ 18.2.3) HR may only be used when 21.5.3 applies. │
│ 18.3) Variations of any additional tag are not allowed. │
│ e.g. READ.NFO or RNFO is not allowed, READNFO must be used. │
│ 18.4) READNFO should be used sparingly. Discretion is recommended. │
│ 18.4.1) The READNFO tag must not be used with PROPER, REPACK, or │
│ RERIP. │
│ 18.5) Tags must be grouped together, period-delimited, and follow the │
│ mandatory directory format, see rule 19.4. │
│ e.g. EXTENDED.RERIP, REMASTERED.REPACK. │
│ 18.6) Tags must only be used once, but the order is left to the │
│ discretion of the group. │
│ 18.6.1) Except in situations where the REAL tag is required to be │
│ stacked to differentiate between multiple invalid releases. │
│ e.g. A REAL.REAL.PROPER is required for a REAL.PROPER │
│ and PROPER. │
│ 18.7) All HDR content must be tagged as such. │
│ │
│ 19) [ Common: Directory Nomenclature ] │
│ 19.1) Acceptable characters allowed for directories are: │
│ ABCDEFGHIJKLMNOPQRSTUVWXYZ │
│ abcdefghijklmnopqrstuvwxyz │
│ 0123456789._- │
│ 19.2) Single punctuation must be used. Consecutive punctuation is not │
│ allowed. │
│ e.g. Show----Name.S01E01, Show.Name....S01E01 │
│ 19.3) Typos or spelling mistakes in the directory are not allowed. │
│ 19.4) Releases must match the following directory format: │
│ 19.4.1) │
│ Feature.Title.<YEAR>.<TAGS>.[LANGUAGE].<RESOLUTION>.<FORMAT> │
│ -GROUP │
│ 19.4.2) Weekly.TV.Show.[COUNTRY_CODE].[YEAR].SXXEXX[Episode.Part].[E │
│ pisode.Title].<TAGS>.[LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
│ 19.4.3) Weekly.TV.Show.Special.SXXE00.Special.Title.<TAGS>.[LANGUAGE │
│ ].<RESOLUTION>.<FORMAT>-GROUP │
│ 19.4.4) Multiple.Episode.TV.Show.SXXEXX-EXX[Episode.Part].[Episode.T │
│ itle].<TAGS>.[LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
│ 19.4.5) Cross.Over.TV.Show.One.SXXEXX[Episode.Part].[Episode.Title]_ │
│ Show.Two.SXXEXX[Episode.Part].[Episode.Title].<TAGS>.[LANGUA │
│ GE].<RESOLUTION>.<FORMAT>-GROUP │
│ 19.4.6) Miniseries.Show.PartX.[Episode.Title].<TAGS>.[LANGUAGE].<RES │
│ OLUTION>.<FORMAT>-GROUP │
│ 19.5) Named directory arguments formatted inside <> must be included. │
│ Optional arguments formatted inside [] can be used in some cases. │
│ 19.5.1) Mini-series parts must be at least 1 integer wide, and │
│ values used may extend past 9. │
│ e.g. Miniseries.Part.1, Miniseries.Part.10. │
│ 19.5.2) Episode and seasonal numbering must be at least 2 integers │
│ wide, and values used may extend past 99. │
│ e.g. S01E99, S01E100, S101E01. │
│ 19.5.3) Episode part refers to episodes, usually cartoons or │
│ animation, which split episodes into stories by different │
│ directors. Episode parts must be alphanumeric (A-Z, a-z, │
│ 0-9). │
│ e.g. The first episode from Season 2 of SpongeBob │
│ SquarePants is split into S02E01A/B, see: │
│ https://goo.gl/CVGXKu │
│ 19.5.4) Season must be omitted if a series is not a mini-series and │
│ does not have seasons. │
│ e.g. One Piece must be tagged as One.Piece.E01. │
│ 19.5.5) Episode title is optional. │
│ 19.5.6) Tags refers to all permitted tags only, see section 18. │
│ 19.5.7) Non-English releases must include the language tag. English │
│ releases must not include the language tag. │
│ 19.5.7.1) Language tags must be the full name of the language. │
│ Abbreviations or language codes are not allowed. │
│ e.g. FRENCH, RUSSIAN, GERMAN. │
│ 19.5.8) Format refers to whether the release is transcoded │
│ (WEBRip.x264/x265) or untouched (WEB.H264/WEB.H265). │
│ 19.6) Do not indicate the ripping, or encoding methods that were used. │
│ Use the NFO for any technical details. │
│ 19.7) Non-series releases (e.g. movies, documentaries) must include the │
│ production year. │
│ 19.8) Different shows with the same title produced in different │
│ countries must have the ISO 3166-1 alpha 2 country code in the │
│ show name. │
│ 19.8.1) Except for UK shows, which must use UK, not GB. │
│ 19.8.2) This rule does not apply to an original show, only shows │
│ that succeed the original. │
│ e.g. The.Office.S01E01 and The.Office.US.S01E01. │
│ 19.9) Different shows with the same title produced in the same country │
│ which begin in different years must have the year of the first │
│ season in the directory. │
│ 19.9.1) The year is not required for the show broadcasted first. │
│ e.g. Second.Chance.S01E01 and Second.Chance.2016.S01E01. │
│ 19.10) Different shows with the same titles produced in the same country │
│ which begin in different years must have the ISO-3166-1 alpha 2 │
│ country code followed by the year of the first season in the │
│ directory. │
│ 19.10.1) See rules 19.8 and 19.9 for country code and year │
│ explanations. │
│ e.g. Wanted.S01E01 (2005), Wanted.AU.S01E01 (2013), │
│ Wanted.AU.2016.S01E01 (2016). │
│ 19.11) Show names which are hyphenated or include punctuation must │
│ follow the format shown in the title sequence or credits of the │
│ first episode, limited to the list of acceptable characters. │
│ 19.11.1) If no title card exists, see rule 19.13.1. │
│ 19.11.2) Additional titles and names given to an individual season │
│ must not be used. │
│ e.g. Archer.Vice.S05, Strike.Back.Legacy.S05. │
│ 19.11.3) Acronyms which show the ellipsis of letters with non- │
│ standard characters must be replaced with a period. │
│ e.g. M*A*S*H must be M.A.S.H. │
│ e.g. George Carlin... It's Bad for Ya! must be │
│ George.Carlin.Its.Bad.For.Ya. │
│ 19.12) Directory nomenclature and numbering must remain consistent │
│ across the lifetime of an individual show or event. │
│ 19.12.1) Shows which contain acronyms or secondary titles must │
│ follow the format used by the first release. │
│ e.g. Law.and.Order.SVU.S01E01 is the standard format │
│ that must be used for all following episodes, │
│ Law.and.Order.Special.Victims.Unit.S01E02 is not │
│ allowed. │
│ Shadowhunters.The.Mortal.Instruments.S01E01 is the │
│ standard format, Shadowhunters.S01E02 is not allowed. │
│ 19.12.2) Shows which air with extended content under modified names │
│ must use the primary show name and numbering with the │
│ EXTENDED tag. │
│ e.g. QI.S06E01 and QI.XL.S01E01, must be tagged as │
│ QI.S06E01 and QI.S06E01.EXTENDED respectively. │
│ Room.101.S01E01 and Room.101.Extra.Storage.S01E01, must │
│ be tagged as Room.101.S01E01 and │
│ Room.101.S01E01.EXTENDED respectively. │
│ 19.12.3) Groups cannot change the directory format of a show after a │
│ second release or episode with the same format exists. │
│ e.g. 2016-01-01: Law.and.Order.SVU.S01E01 sets the │
│ format. │
│ 2016-01-08: Law.and.Order.SVU.S01E02 continues the │
│ format. │
│ 2016-01-09: │
│ Law.and.Order.Special.Victims.Unit.S01E01.DIRFIX is not │
│ valid as the second episode already exists and │
│ continues with the previously defined format. │
│ 19.12.4) Except in situations where the show has an official change │
│ in its name, whereby all official references by the │
│ broadcaster or studio are of the new name. This change must │
│ be mentioned in the first NFO with the new name with │
│ relevant references. │
│ e.g. Gold.Rush.Alaska.S01E01 changed to │
│ Gold.Rush.S02E01. │
│ 19.12.5) Official name changes for a show does not include the │
│ renaming of individual seasons. Seasonal name changes must │
│ be ignored. │
│ e.g. Power.Rangers.S01 and Power.Rangers.S07 must be │
│ used. Power.Rangers.Lost.Galaxy.S07 must not be used. │
│ Strike.Back.S03, Strike.Back.S05 must be used. │
│ Strike.Back.Vengeance.S03, Strike.Back.Legacy.S05 must │
│ not be used. │
│ 19.12.6) Any deviations or changes require sufficient evidence │
│ listed in the NFO as to the reason for change. │
│ 19.13) User-contributed services such as TVMaze or TheTVDB must not be │
│ used as a reference when naming and numbering episodes. It may be │
│ used as a general guide; however, official guides must be used. │
│ 19.13.1) The following order must be used as the primary source for │
│ naming and numbering. │
│ 19.13.1.1) Official website of the show. │
│ 19.13.1.2) Order and format listed by the original broadcaster. │
│ 19.13.1.3) Network guide. │
│ 19.13.2) In situations where official sources have inconsistent │
│ listings, or offer none at all, previously established │
│ numbering must be used. │
│ e.g. MythBusters, National Geographic Special Episodes. │
│ │
│ 20) [ Common: Fixes ] │
│ 20.1) The following fixes are allowed: │
│ DIRFIX, NFOFIX, PROOFFIX, SAMPLEFIX. │
│ 20.2) Any other form of fix is not allowed. │
│ e.g. RARFIX, SFVFIX, SUBFIX │
│ 20.3) All fixes require an NFO and must state which release is being │
│ fixed. │
│ 20.4) A proper may not be released for a flaw which can be fixed with │
│ the above methods, with the exception of prooffixes, see 15.5.1. │
│ 20.5) If multiple releases from a single season require a DIRFIX, a │
│ single DIRFIX per season is allowed and recommended. │
│ e.g. Show.Name.S01.1080p.DIRFIX.WEB.H264-GROUP. │
│ 20.5.1) If a single DIRFIX is used, all relevant releases and │
│ corresponding fixes must be listed in the NFO. │
│ e.g. The NFO should contain the following: │
│ This is the correct order in which to watch the show; │
│ Some.Show.S01E02.720p.WEB.H264-GROUP is actually E01 │
│ Some.Show.S01E01.720p.WEB.H264-GROUP is actually E02 │
│ Some.Show.S01E03.720p.WEB.H264-GROUP │
│ Some.Show.S01E05.720p.WEB.H264-GROUP is actually E04 │
│ Some.Show.S01E04.720p.WEB.H264-GROUP is actually E05 │
│ Some.Show.S01E06.720p.WEB.H264-GROUP │
│ │
│ 21) [ Common: Dupes ] │
│ 21.1) Same second releases, with a maximum acceptable variance of two │
│ seconds (+/- 2 seconds) between timestamps reported by a majority │
│ of pre bots, are not considered dupes and should not be nuked. │
│ 21.1.1) Timestamps must be considered as whole integers and round │
│ half towards zero. │
│ 21.1.2) The earliest timestamp must be used when considering dupes. │
│ e.g. Release A: 1451572201.427158 -> 1451572201 │
│ Release B: 1451572203.626645 -> 1451572203 │
│ Release C: 1451572204.137665 -> 1451572204 │
│ Release B does not dupe Release A: 1451572203 - │
│ 1451572201 = 2, i.e. maximum variance allowed. │
│ Release C dupes Releases A and B: 1451572204 - │
│ 1451572201 = 3, i.e. 3 > 2. │
│ 21.1.3) In situations where a release is found to contain a │
│ technical flaw, same second dupes which do not exhibit any │
│ technical flaws must be considered the final release. Groups │
│ may release a DIRFIX to PROPER for their original release, │
│ but it is not required. │
│ e.g. Release A and Release B are released at the same │
│ time. Release A is nuked as containing glitches, Release │
│ B then becomes the de facto release and a DIRFIX to │
│ PROPER may be released. │
│ 21.2) WEBRip.x264/x265 dupes WEB.H264/H265. │
│ 21.3) WEB.H264/H265 does not dupe WEBRip.x264/x265. │
│ 21.4) WEB.H264/H265 and WEBRip.x264/x265 does not dupe │
│ DSR/PDTV/HR.PDTV/AHDTV/HDTV. │
│ 21.5) WEB.H264/H265 and WEBRip.x264/x265 dupes an equivalent Retail │
│ release. │
│ 21.5.1) Except in situations where the aspect ratio of the release │
│ exceeds that of its respective retail release. │
│ e.g. A 2.39:1 release will not dupe a 1.78:1 retail │
│ release, provided there is clearly more visible on- │
│ screen footage. Proof demonstrating this difference is │
│ recommended, but not mandatory. │
│ 21.5.2) Except in situations where the release is a different │
│ version (e.g. ALTERNATIVE.CUT, COLORIZED) of its respective │
│ retail release, and is not censored after uncensored. │
│ e.g. An UNCENSORED.720p.WEB.H264 release does not dupe a │
│ censored 720p.BluRay.x264. │
│ 21.5.3) Except in situations where SD WEB has a width between, and │
│ including, 960 and 1024. In that case it may be released │
│ after SD retail, and only if no HD retail release exists. │
│ The release must be tagged as HR (High resolution). │
│ 21.6) Native video streams do not dupe converted video streams. │
│ 21.7) Converted video streams dupe native video streams. │
│ 21.8) Releases with muxed-in subtitles do not dupe releases with │
│ hardcoded subtitles. │
│ 21.9) Releases with hardcoded subtitles (i.e. SUBBED) dupe releases with │
│ muxed in subtitles. │
│ 21.10) HDR after SDR or vice versa does not dupe. │
│ 21.11) Non-foreign tagged English release does not dupe a foreign tagged │
│ release. │
│ │
│ 22) [ Common: Propers / Rerips / Repacks ] │
│ 22.1) Detailed reasons must be included in the NFO for all repacks, │
│ rerips, and propers. │
│ 22.1.1) Proper reasons must be clearly stated in the NFO, including │
│ timestamps and specifics in regards to the flaw when │
│ appropriate. │
│ 22.1.2) If a release is not globally nuked, a sample demonstrating │
│ the flaws in the original release is required and must be │
│ placed within the 'Proof' directory. │
│ 22.2) Propers are only permitted in the case of a technical flaw in the │
│ original release. │
│ 22.2.1) Except in cases of video and/or audio based qualitative │
│ propers, which are only allowed within 15 minutes of the │
│ original release's pre time. │
│ 22.2.1.1) All qualitative propers must follow 23.1.1, 23.1.1.1 │
│ and 23.1.3 to prove superior quality of video and/or │
│ audio. │
│ 22.2.1.2) Mixing sources on qualitative based propers is not │
│ allowed, use INTERNAL. │
│ e.g. Video from Netflix, audio from retail. Video │
│ from Amazon, audio from Netflix. │
│ 22.2.1.3) 23.2, 23.2.1 and 23.2.2 must be respected │
│ (supplementing internal(led)/internalling with │
│ proper(ed)/propering) on all qualitative propers. │
│ 22.2.2) Transcoded releases cannot proper any untouched files. │
│ e.g. WEBRip.x264 cannot proper WEB.H264. │
│ 22.2.2.1) Unless it is a transcode of a lossless stream │
│ correcting the technical flaw, see rule 1.4. │
│ 22.2.2.2) Unless it can be proven that all untouched sources are │
│ flawed which cannot be repaired by transcoding, but a │
│ WEBRip does not exhibit the same technical flaw(s). │
│ e.g. iTunes, Amazon, and Netflix only offer the │
│ content. Amazon and iTunes sourced files cannot be │
│ repaired by transcoding, however a Netflix WEBRip │
│ is fine. │
│ 22.2.3) Untouched files can proper transcoded releases for any valid │
│ technical flaw. │
│ 22.3) Audio or visual glitches can be propered with a release which does │
│ not exhibit the same flaw. │
│ 22.3.1) In situations where mastering issues results in visual or │
│ audio glitches, a release must not be nuked until a valid │
│ proper, repack, or rerip using a glitch-free source or │
│ master is released. │
│ 22.4) Highest quality video and audio, and all subtitles present counts │
│ at time of pre. Propering with higher quality video, audio, or │
│ subtitles that may appear later on the source is not allowed, use │
│ INTERNAL. │
│ e.g. Movie is posted to Netflix with 24 subtitles and 448 │
│ E-AC3 audio, released as is. Two hours later, five additional │
│ subtitle tracks are added, and audio is upgraded to 640Kbps │
│ E-AC3 audio and propered. That proper is invalid. │
│ 22.4.1) This does not apply when certain regions may have degraded │
│ video or audio quality, but another region on the source │
│ does not. │
│ e.g. Netflix has limited bitrates to 10Mbps in South │
│ America due to bandwidth limitations, but Europe has the │
│ expected 25Mbps streams. Using the 10Mbps stream from │
│ South America is a technical flaw. │
│ 22.4.2) Propers based on one region having more subtitles than │
│ another is not allowed, use INTERNAL. │
│ e.g. Netflix in Japan has four more subtitle tracks at │
│ time of pre than Europe, group releases from Europe │
│ missing the extra 4 subtitles - propering from Japan is │
│ not allowed, use INTERNAL. │
│ 22.5) RERIP must be used for ripping or encoding issues. │
│ 22.6) REPACK must be used for packing or muxing issues. │
│ │
│ 23) [ Common: Internals ] │
│ 23.1) Internals are only allowed when they provide superior quality to │
│ the last internal/non-internal WEB/WEBRip or non-internal retail │
│ release, when internaling over: │
│ e.g. Feature is released as WEB, then released again as │
│ INTERNAL with superior quality. To release another INTERNAL it │
│ must be superior to the last INTERNAL not the first release. │
│ e.g. Feature is released as WEB, then retail and then │
│ again as INTERNAL retail. To release INTERNAL it must be │
│ superior to the non-internal retail, not the internal │
│ retail or the first release (WEB). │
│ 23.1.1) Video quality, a minimum of four B to B frame comparisons │
│ (INTERNAL vs last release) in PNG format spread throughout │
│ the feature, showing a stark improvement in video quality, │
│ must be included in the 'Proof' directory. │
│ 23.1.1.1) Comparison frame numbers must be included in the NFO │
│ file or embedded in comparisons. FFInfo is the │
│ recommend method. │
│ 23.1.2) Number of subtitle or audio tracks, the release must have │
│ all the tracks the previous release had plus new additional │
│ tracks. │
│ 23.1.2.1) Inclusion or lacking of closed captions subtitles │
│ defined by rule 12.1.5 or stripped SDH subtitles │
│ defined by rule 11.4.2.1, must not be taken into │
│ consideration. │
│ e.g. Only improvement is inclusion of closed │
│ captions - internal is invalid. │
│ 23.1.3) Audio quality must be better quality as defined by rule │
│ 2.3.1. │
│ 23.2) Any aspects (i.e. video, subtitles, audio) not being internalled │
│ over better quality, must be of equal quality to the previous │
│ release. As per 23.1.2.1 closed captions and stripped SDH │
│ subtitles must not be taken into consideration. │
│ e.g. Internalling over video quality, but not providing audio │
│ of equal or better quality or lacking subtitles the previous │
│ release had, is not allowed. │
│ e.g. Internalling over audio quality, but not providing │
│ video of equal or better quality or lacking subtitles the │
│ previous release had, is not allowed. │
│ e.g. Internalling over video quality, having better │
│ audio, more/equal subtitles and lacking closed │
│ captions the original release had is allowed. │
│ 23.2.1) All improvements must be detailed within the NFO. │
│ 23.2.2) Proof of superior quality for a certain source need only be │
│ provided for the first release of a season. All other │
│ releases must refer back to the first release in the NFO. │
│ 23.3) Internals with equal files/quality are allowed after one year of │
│ release and should be used sparingly only when a release has gone │
│ missing from archives. The release that went missing must be │
│ mentioned in the NFO. │
│ 23.4) Internals are required to follow all rules. │
│ 23.5) Using DIRFIX.INTERNAL to avoid a nuke is not allowed, and must be │
│ nuked fix.for.nuke. │
│ │
│ 24) [ Common: Ruleset Specifics ] │
│ 24.1) This ruleset is to be considered the ONLY official ruleset for WEB │
│ and WEBRip releases. It supersedes all previous revisions, │
│ rulesets and precedents. │
│ 24.1.1) Releasing under former rulesets or codecs is not allowed, │
│ and must be nuked defunct.ruleset or defunct.codec. │
│ 24.1.2) The naming standards listed in this document must only take │
│ effect once a current running season has ended. Any existing │
│ naming schemes must be used in the event of missing │
│ episode(s) from older seasons being filled. │
│ 24.1.3) This ruleset is not retroactive, and only applies to │
│ releases released under it. │
│ 24.2) The following definition of keywords throughout this ruleset are │
│ as follows: │
│ 24.2.1) Must: the rule is explicit in the definition and is │
│ compulsory. │
│ 24.2.2) Should: implies the rule is a suggestion, and is non- │
│ compulsory. │
│ 24.2.3) Can or may: implies the rule is optional, and is non- │
│ compulsory. │
│ 24.2.4) e.g: refers to common examples, elements listed should not │
│ be considered as all possibilities. │
│ 24.2.5) i.e: refers to the only examples, elements listed will be │
│ considered as all valid possibilities. │
│ │
│ 25) [ Common: Notes ] │
│ 25.1) The inclusion of 2-pass in this ruleset should not be misconstrued │
│ as preferring it for every release, CRF must always be considered │
│ the primary method. Instead, it is encouraged for groups to use │
│ 2-pass methods for rare cases when files provided are of extremely │
│ high quality. │
│ 25.1.1) Video which contains an excessive amount of noise may often │
│ result in an unnecessary large bitrate. In such situations, │
│ encoding to a smaller bitrate using 2-pass can result in a │
│ file size improvement with negligible loss in video quality. │
│ 25.2) Dolby Vision (DV) and HDR10+ (HDR10Plus) are considered out of │
│ scope, due to lack of support and no standard workflow for │
│ producing them, and must only be released as INTERNAL. │
│ 25.2.1) DV encodes must have DV Profile (--dolby-vision-profile) and │
│ RPU metadata (--dolby-vision-rpu) set to the same values as │
│ the source. │
│ 25.2.1.1) Including the DV enhancement layer on a HDR or │
│ HDR10Plus encode is another option. │
│ 25.2.1.2) Until such a time as Matroska gains support for Dolby │
│ Vision, MP4 may be used and dlb_mp4base or MP4Box are │
│ the only allowed muxers. It is fully at the group's │
│ discretion to work around any pitfalls of the MP4 │
│ container (e.g. limited audio codec and subtitles │
│ support). Groups are exempt from any rules with │
│ regards to these pitfalls. │
│ 25.2.2) HDR10Plus releases, in addition to HDR specifics (see │
│ 4.23.4), must have SEI tone mapping metadata (--dhdr10-info) │
│ set to the same values as the source. Tone mapping metadata │
│ optimisation (--dhdr10-opt) must be enabled. │
│ 25.2.3) Any metadata must be extracted from the whole concatenated │
│ source, not a partial source. e.g. the first m2ts file. │
│ 25.2.4) Until such a time as mapping metadata to cropped encodes is │
│ possible, DV and HDR10Plus are exempt from cropping rules │
│ and must be left uncropped. │
│ 25.2.5) The rules below will apply in a hypothetical future when all │
│ pitfalls and issues mentioned above are resolved, support │
│ has become widespread, does not result in any playback │
│ issues and at least three months have elapsed from support │
│ being added. │
│ 25.2.5.1) If the source contains a DV enhancement layer, it must │
│ be muxed in with the correct DV Profile set for the │
│ source during muxing. │
│ 25.2.5.2) If the source contains HDR10Plus SEI metadata, 25.2.2 │
│ is mandatory. │
│ 25.2.5.3) 25.2.3 must be respected. │
│ 25.2.5.4) The HDR10Plus tag must not be used. │
│ 25.2.5.5) DV single layer encodes (see 25.2.1) or untouched are │
│ only allowed when the source is single layer DV (i.e. │
│ No HDR, only DV). The DV tag must only be used in the │
│ case of single layer DV. │
│ 25.2.5.6) Dolby Vision (DV) and HDR10+ (HDR10Plus) no longer │
│ need be released only as INTERNAL. │
│ 25.3) YouTube may only be used as a source if geographical restrictions │
│ apply to legitimate content uploaded by the rights holder or on a │
│ verified channel. │
│ 25.4) Re-releasing uncropped WEB which has already been released as │
│ uncropped INTERNAL.WEB or cropped WEBRIP is not allowed and must │
│ be considered dupe. │
│ 25.4.1) Any WEB release nuked solely for not being cropped and not │
│ reripped, repacked or propered may be unnuked and now be │
│ considered valid. │
│ 25.5) Re-releasing any INTERNAL WEB/WEBRips that duped │
│ DSR/PDTV/HR.PDTV/AHDTV/HDTV under v1.0 of this ruleset is not │
│ allowed and must be considered dupe. │
│ │
├──────────────────────────────────────────────────────────────────────────────┤
│ │
│ [ Signed (in alphabetical order) - 92 Groups ] │
│ 57CHAN, 707, aAF, ADMiT, ADRENALiNE, AMCON, AMRAP, ANiURL, APRiCiTY, │
│ ASCENDANCE, ASSOCiATE, AVR, BAKFYLLA, BALLIN, BARGE, BATV, BAWSER, BiQ, │
│ BRAINFUEL, BREXiT, CAFFEiNE, CBFM, CookieMonster, CREED, CRiMSON, CROOKS, │
│ DANES, DEADPOOL, DHD, DISKRIMINERING, DKiDS, DKiNO, EDHD, ELIMINERING, EMX, │
│ EXECUTION, EXEKVERING, FaiLED, FAiRCHANCE, FELTET, FFD, FLEKSNES, GIMINI, │
│ GRiP, HANGAR17, HENRETTELSE, HOTLiPS, iNDKAST, iNSPiRiT, iNTENSO, JAWN, JRP, │
│ KOMPOST, KYR, LEiEFiLM, LEViTATE, LiGATE, LSDK, MenInTights, METCON, MoA, │
│ MTB, NCC1701D, NiXON, NORPiLT, NORUSH, OldSeasons, PETRiFiED, PLAYD, │
│ PLUTONiUM, QPEL, REGRET, RiVER, SECRETOS, SERIOUSLY, SHERLOCK, SHiFT, SKGTV, │
│ SKRiTT, SOAPLOVE, STATOiL, TRUMP, TVADDiCT, TViLLAGE, TVSLiCES, TWERK, │
│ UNDERBELLY, VERUM, WALT, WATCHER, WATSON, WEBELL │
│ │
│ [ Refused to Sign ] │
│ This refused to sign list consists of 31 groups, many of them sub-groups. │
│ │
│ ACES, BAMBOOZLE, BiSH, BRASS, CONVOY, CROSSFIT, CUTEYS, DARKFLiX, │
│ DECAPiTATiON, DEFY, ELiMiNATE, FLX, HANDBOLL, HILLARY, I_KnoW, KiNDERGARTEN, │
│ KLINGON, LiNKLE, MEMENTO, MORSOM, OATH, RADiOACTiVE, ROBOTS, ROWBOATS, │
│ SLAUGHTER, STRiFE, TBS, TURBO, URANiME, W4F, XLF │
│ │
│ These groups felt encouraging the use of high quality sources with │
│ qualitative based propers was "anti-competitive". │
│ They believe it's acceptable to use worse sources to win races instead of │
│ waiting mere seconds and picking the better ones. │
│ │
│ They demanded that they be allowed to release internals that were either │
│ worse quality, technically flawed or same file dupes. │
│ They feel that "because it's always been that way" no change should happen │
│ and are standing in the way of progress. │
│ │
│ They banded together and went against majority voting on changes made to the │
│ rules below: │
│ Rule 22.2.1 (Qualitative based propers allowed within 15 min of pre time) - │
│ 19 for and 7 against. │
│ Rule 23.1 (Internals only for better quality) - 27 for and 2 against. │
│ │
│ Every group present during drafting was given 1 vote and collectively │
│ decided on all changes made. │
│ This egregious and unreasonable behaviour will not be tolerated in a │
│ democratic system. │
│ │
├──────────────────────────────────────────────────────────────────────────────┤
│ │
│ [ Revisions ] │
│ 2016-03-16 - v1.0 - Final commit and public release of ruleset. │
│ 2020-05-13 - v2.0 - Restructuring and hardening of all rules, UHD and HDR │
│ supported properly, qualitative based propers allowed, internals specificity │
│ hardened. │
│ │
└──────────────────────────────────────────────────────────────────────────────┘