1089 lines
100 KiB
HTML
1089 lines
100 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<title>wdx264v1.0-ecb63c67.nfo</title>
|
|
<style type="text/css">
|
|
@font-face {
|
|
font-family: nfo;
|
|
font-style: normal;
|
|
font-weight: normal;
|
|
src: url(nfo.eot);
|
|
}
|
|
.nfo {
|
|
padding: 12px;
|
|
font-family: nfo, courier new;
|
|
font-size: 11px;
|
|
line-height: 1em;
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<pre class="nfo">┌─────────────────────────────────────────────────────────────────────────────┐
|
|
│ ┌────────────────────────────────────────────────────────┐ │
|
|
├──────────┤ Web Definitions for x264 v1.0 a.k.a. wdx264 ├─────────┤
|
|
├──────────┤ THE.2016.WEB.AND.WEBRIP.SD.HD.X264.RULESET.v1.0-WDX264 ├─────────┤
|
|
│ └────────────────────────────────────────────────────────┘ │
|
|
├─────────────────────────────────────────────────────────────────────────────┤
|
|
│ │
|
|
│ [ Intro ] │
|
|
│ In the last 18 months, web based streaming and video on-demand services │
|
|
│ have increased in popularity. Initially used as a source for missed │
|
|
│ broadcasts, it has since evolved into an exclusive source for original │
|
|
│ content. Like most technology, online services are continually evolving │
|
|
│ the way in which files re provided to end users. As codecs mature, │
|
|
│ bandwidth increases in speed and decreases in price, equivalent │
|
|
│ improvements in quality follows at the benefit to the end-users. This │
|
|
│ increase in quality has the flow-on effect of often being a legitimate │
|
|
│ logo-free alternative to antiquated MPEG-2 HDTV streams. As companies │
|
|
│ such as Netflix and Amazon continue to produce popular content at an │
|
|
│ exponential rate, it became obvious that this new broadcast medium │
|
|
│ deserved to be recognised with an original ruleset. │
|
|
│ │
|
|
│ The purpose of this document is to create a high standard for web-sourced │
|
|
│ files. It attempts to prevent any improper handling of files, and reduce │
|
|
│ the potential for adding to the increasing number of ongoing nuke-wars. │
|
|
│ This ruleset is structured in such a way that everything attempts to be │
|
|
│ clear and concise, and something everyone must adhere to. │
|
|
│ │
|
|
│ Compliance with this document is optional as of its pre date, and │
|
|
│ mandatory as of 2016-03-21 00:00:00 UTC (1458518400 Unix time). │
|
|
│ │
|
|
├─────────────────────────────────────────────────────────────────────────────┤
|
|
│ │
|
|
│ 1) [ Untouched: WEB.H264 / WEB.x264 ] │
|
|
│ 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 use a commercial (e.g. CoreAVC, │
|
|
│ MainConcept) or GPL-licensed (e.g. x264, x265) H.264/MPEG-4 AVC │
|
|
│ or H.265/HEVC codec. │
|
|
│ 1.2) Source video and audio streams must be left as obtained from the │
|
|
│ source. Transcoding of audio or video streams is not allowed. │
|
|
│ 1.3) Untouched video streams without x264 headers must be tagged as │
|
|
│ WEB.H264. Untouched video streams with x264 headers present in the │
|
|
│ H264 stream must be tagged as WEB.x264. │
|
|
│ 1.3.1) In situations where HEVC/H265 is used, any untouched sections │
|
|
│ referring to H264/x264 must be considered as H265/x265. │
|
|
│ 1.3.1.1) H265 must be used in place of H264. │
|
|
│ 1.3.1.2) x265 must be used in place of x264. │
|
|
│ 1.3.2) Until H265/x265 support is improved in mainstream demuxers, │
|
|
│ untouched video streams which use H265/x265 do not dupe H264/x264 │
|
|
│ files, and vice-versa. │
|
|
│ e.g. WEB.H265 does not dupe WEB.H264 │
|
|
│ WEB.x264 does not dupe WEB.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 section 2. │
|
|
│ 1.4.2) Transcoding must be done from files of the highest resolution and │
|
|
│ bitrate offered. │
|
|
│ 1.4.3) Transcoding may occur when correcting a technical flaw. │
|
|
│ e.g. Cropping black borders, deinterlacing an interlaced source. │
|
|
│ 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.x264 is not allowed, use INTERNAL. │
|
|
│ e.g. 1080p.WEB.H264 -> 720p.WEBRip.x264. │
|
|
│ 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.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 6.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, but the │
|
|
│ NFO must state why the resolution does not meet the minimum. │
|
|
│ 1.7) DRM and any user identifiable information must be removed. │
|
|
│ 1.8) Dupes based on source are not allowed, use INTERNAL. │
|
|
│ 1.9) 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. │
|
|
│ 1.10) 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.11) Must be free of technical flaws. Including, but not limited to: DRM, │
|
|
│ sync issues, interlaced, lack of IVTC, bad AR, missing footage, │
|
|
│ missing dialogue, unrelated footage or commercials, under or over │
|
|
│ crop. │
|
|
│ 1.12) VFR (Variable Frame Rate) methods are allowed only if present in the │
|
|
│ original source. │
|
|
│ 1.12.1) If CFR (Constant Frame Rate) can be used when remuxing and does │
|
|
│ not result in playback issue, CFR must be used. │
|
|
│ 1.13) Trimming unrelated footage (section 8) is allowed and must be done │
|
|
│ losslessly via keyframe intervals (GOP). MKVToolnix is the │
|
|
│ recommended tool. │
|
|
│ 1.13.1) If unrelated footage cannot be removed via this method, the file │
|
|
│ must be transcoded and follow the transcoding standards, see │
|
|
│ section 3. │
|
|
│ 1.14) 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.15) Releases with a non-square SAR are not considered technically │
|
|
│ flawed. │
|
|
│ 1.15.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.15.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) Non-destructive audio normalisation tools such as ReplayGain may be │
|
|
│ used, and must be done to the maximum gain. Audio normalisation on │
|
|
│ lossy tracks is optional. │
|
|
│ 2.3) Standard definition releases must only contain an audio track with a │
|
|
│ maximum of 2.0 channels. │
|
|
│ 2.3.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.3.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.3.3) If a source provides identical 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.4) High Definition releases must use the highest available audio format │
|
|
│ and quality offered by the source. │
|
|
│ 2.4.1) 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.4.2) 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 ] │
|
|
│ 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. │
|
|
│ 3.3) Dupes based on source are not allowed, use INTERNAL. │
|
|
│ 3.4) Must be free of technical flaws. Including, but not limited to: DRM, │
|
|
│ sync issues, interlaced, lack of IVTC, bad AR, missing footage, │
|
|
│ missing dialogue, unrelated footage or commercials, under or over │
|
|
│ crop, dupe or dropped frames. │
|
|
│ 3.5) Upscaling video streams is not allowed. │
|
|
│ e.g. 2160p from a 1080p stream is not allowed. │
|
|
│ 3.6) Streams must be captured at the highest available resolution and │
|
|
│ bitrate offered. │
|
|
│ 3.6.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.6.2) 1080p and 2160p streams are considered of equal value when │
|
|
│ capturing, and encodes (SD/720p/1080p) produced from 1080p or │
|
|
│ 2160p captures are considered identical. It is encouraged, and │
|
|
│ recommended, to capture from a 2160p stream where possible and │
|
|
│ resize so as to produce a higher quality encode. │
|
|
│ 3.6.3) 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.7) Captures should be done at the native broadcast framerate of the │
|
|
│ source. │
|
|
│ 3.7.1) Captures from devices which are unable to output a native format │
|
|
│ must be restored to the original framerate. │
|
|
│ 3.7.2) If captures cannot be completely restored to their native │
|
|
│ framerate, such as a single dupe frame every 1000 or blended/ghost │
|
|
│ frames due to mangling from the streaming device, this is │
|
|
│ considered a technical flaw. │
|
|
│ 3.8) 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.9) 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.10) Final resolution must maintain the same aspect ratio as the source │
|
|
│ after cropping and kept at mod 2. │
|
|
│ 3.10.1) Sources must have all black borders cropped to the widest frame. │
|
|
│ 3.10.2) The same aspect ratio, as calculated from the source, must be │
|
|
│ used, see rule 6.17. │
|
|
│ 3.11) 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.11.1) If a technical flaw is present that is being rectified by │
|
|
│ transcoding (rule 1.4.5), 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: Codec ] │
|
|
│ 4.1) x264 8-bit must be used. │
|
|
│ 4.1.1) Custom builds of x264 are allowed and must be based off the x264 │
|
|
│ codebase, e.g. x264-tMod, x264-kMod. │
|
|
│ 4.1.2) Any experimental or alternate codecs (e.g. x265) are not allowed, │
|
|
│ use INTERNAL. │
|
|
│ 4.2) x264 revision must be no more than 50 revisions from the latest at │
|
|
│ pre time. It is recommended to use the latest revision when encoding. │
|
|
│ Use the official x264 git repo as the only │
|
|
│ reference: http://git.videolan.org/?p=x264.git;a=summary │
|
|
│ 4.3) Segmented encoding is not allowed. │
|
|
│ 4.4) Justification must be listed in the NFO for use of non-standard CRF │
|
|
│ values. │
|
|
│ 4.5) Decimal values may be used for CRF values. │
|
|
│ 4.6) Constant Rate Factor (--crf) must be used by default. │
|
|
│ 4.6.1) A CRF value of 19 must be used for all SD resolutions. │
|
|
│ 4.6.1.1) If the resultant video bitrate exceeds 2,000 Kbps, the CRF │
|
|
│ value must be incremented by 1. │
|
|
│ 4.6.1.2) If the resultant video bitrate exceeds 1,500 Kbps, the CRF │
|
|
│ value may be optionally incremented by up to 1.0, e.g. 19.2, │
|
|
│ 19.6. │
|
|
│ 4.6.2) A CRF value of 18 must be used for all 720p resolutions. │
|
|
│ 4.6.2.1) If the resultant video bitrate exceeds 9,000 Kbps, the CRF │
|
|
│ value must be incremented by 1. │
|
|
│ 4.6.2.2) If the resultant video bitrate exceeds 8,000 Kbps, the CRF │
|
|
│ value may be optionally incremented by up to 1.0, e.g. 18.2, │
|
|
│ 18.6. │
|
|
│ 4.6.3) A CRF value of 17 must be used for all 1080p resolutions. │
|
|
│ 4.6.3.1) If the resultant video bitrate exceeds 15,000 Kbps, the CRF │
|
|
│ value must be incremented by 1. │
|
|
│ 4.6.3.2) If the resultant video bitrate exceeds 14,000 Kbps, the CRF │
|
|
│ value may be optionally incremented by up to 1.0, e.g. 17.2, │
|
|
│ 17.6. │
|
|
│ 4.6.4) A CRF value of 17 must be used for all 2160p resolutions. │
|
|
│ 4.7) Use of 2-pass is accepted for all resolutions of 720p and above, │
|
|
│ 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) 2-pass should be a last resort when encoding. Instead, groups are │
|
|
│ encouraged and recommended to use CRF as the default encoding │
|
|
│ method. │
|
|
│ 4.7.2) The NFO must provide sufficient evidence of 2-pass producing a │
|
|
│ visual improvement, bitrate, or file size advantage over CRF in │
|
|
│ regards to the source used. │
|
|
│ 4.7.3) There is no maximum or minimum file size when using 2-pass methods │
|
|
│ as target bitrates should take precedent over target file sizes. │
|
|
│ Multiples of 1120MiB (1,174,405,120 bytes) may be used as a │
|
|
│ general guide for calculating target bitrates. │
|
|
│ 4.7.4) If groups are unsure of how to calculate an adequate target │
|
|
│ bitrate applicable for the source, CRF should be used. │
|
|
│ 4.7.4.1) 720p bitrate must be between 4,000 Kbps and 9,000 Kbps │
|
|
│ inclusive, and should have a target bitrate of approximately │
|
|
│ 5,500 Kbps. Minimum bitrate for animation is 2,500 Kbps. │
|
|
│ 4.7.4.2) 1080p bitrate must be between 9,000 Kbps and 15,000 Kbps │
|
|
│ inclusive, and should have a target bitrate of approximately │
|
|
│ 10,500 Kbps. Minimum bitrate for animation is 5,500 Kbps. │
|
|
│ 4.7.4.3) 2160p bitrate must not exceed 60,000 Kbps. │
|
|
│ 4.8) Resultant bitrate must not exceed the source bitrate. │
|
|
│ 4.8.1) When transcoding from an untouched source, it is recommended to │
|
|
│ use SelectRangeEvery() for a rough estimation on the final CRF │
|
|
│ value to use. │
|
|
│ 4.8.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. │
|
|
│ ValidCRF = [-6 * (DestinationBitrate - ExcessiveBitrate) / │
|
|
│ ExcessiveBitrate] + CRFUsed │
|
|
│ e.g. Source bitrate: 4,500Kbps │
|
|
│ Target bitrate: ~4,400Kbps │
|
|
│ Encoded bitrate @ CRF17: 5,900Kbps │
|
|
│ ValidCRF = (-6 * (4400 - 5900) / 5900) + 17 │
|
|
│ ValidCRF = 18.52, round up to 19 should result in an average │
|
|
│ bitrate below the source. │
|
|
│ 4.9) Settings cannot go below what is specified by --preset slow. │
|
|
│ e.g. -subme 7 or -me hex is not allowed. │
|
|
│ 4.10) Deblocking (--deblock) must be used. Values used are left to the │
|
|
│ discretion of the group. Recommended values: -3:-3 for film, 1:1 │
|
|
│ for animation. │
|
|
│ 4.11) Sample Aspect Ratio (--sar) must be square (1:1). │
|
|
│ 4.12) Keyframe interval (--keyint) must be at least 200, and at most 300. │
|
|
│ It is recommended to let x264 decide which value to use, but │
|
|
│ 10*framerate is a good guideline. │
|
|
│ 4.13) Minimum GOP length (--minkeyint) must be 30 or less. │
|
|
│ 4.14) Level 3.1 must be used for SD resolutions. │
|
|
│ 4.15) Level 4.1 must be used for all 720p and 1080p resolutions. │
|
|
│ 4.16) Level 5.1 must be used for all 2160p resolutions. │
|
|
│ 4.17) Encoded colourspace (--output-csp) must be 4:2:0. │
|
|
│ 4.18) Colour matrix (--colormatrix) must be set for all SD resolutions. │
|
|
│ 4.18.1) 'bt709' must be used for encodes from high definition sources. │
|
|
│ 4.18.2) Source specification must be used for standard definition │
|
|
│ sources. │
|
|
│ 4.18.3) 'undef' must be used if not specified by the source for standard │
|
|
│ definition sources. │
|
|
│ 4.19) Colour matrix (--colormatrix) may be optionally set to 'bt709' for │
|
|
│ all resolutions of 720p and above, but is not required. │
|
|
│ 4.20) Custom matrices are not allowed. │
|
|
│ 4.21) Zones (--zones) are not allowed. │
|
|
│ 4.22) Optional tuning (--tune) parameters allowed are: film, grain, or │
|
|
│ animation. │
|
|
│ 4.23) Optional settings recommended for tuning per source, see doom9.org │
|
|
│ for further information: │
|
|
│ 4.23.1) For complex video, --preset slower/placebo is encouraged. │
|
|
│ 4.23.2) --aq-mode 3 --aq-strength x.x │
|
|
│ e.g. 0.6-0.9 for digital films. │
|
|
│ 0.5-0.7 for grainy films. │
|
|
│ 0.9-1.1 for animation. │
|
|
│ 4.23.3) --psy-rd x.x:0.0 │
|
|
│ e.g. 0.8-1.2 for films. │
|
|
│ 0.5-0.8 for animation. │
|
|
│ 4.23.4) --trellis 2, --no-fast-pskip, --no-mbtree │
|
|
│ │
|
|
│ 5) [ Transcoded: Audio ] │
|
|
│ 5.1) Segmented encoding is not allowed. │
|
|
│ 5.2) Audio tracks already in a lossy format must not be transcoded, but │
|
|
│ kept in the original format. │
|
|
│ 5.3) Stereo must be used for stereo sources, and mono must be used for │
|
|
│ mono sources. │
|
|
│ 5.3.1) Any audio track with identical channels is considered a mono │
|
|
│ source. │
|
|
│ 5.3.2) Dual mono is not allowed. │
|
|
│ 5.4) VBR AAC LC (Low Complexity) must be used for SD releases. │
|
|
│ 5.4.1) Apple/QAAC, FDK-AAC or Nero must be used. │
|
|
│ 5.4.2) 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.4.2.1) QAAC: --tvbr 82 --quality 2 │
|
|
│ 5.4.2.2) FDK-AAC: --bitrate-mode 4 --profile 2 │
|
|
│ 5.4.2.3) Nero: -q 0.4 │
|
|
│ 5.4.3) AAC audio must be normalised to the maximum gain. Normalisation │
|
|
│ must be a complete 2-pass method. No pre-defined values or │
|
|
│ estimations of maximum gain is allowed. Only the following │
|
|
│ normalisation methods are allowed (in order of preference): │
|
|
│ 5.4.3.1) eac3to: -normalize │
|
|
│ 5.4.3.2) sox: --norm │
|
|
│ 5.4.3.3) QAAC: --normalize │
|
|
│ 5.4.4) Any existing normalisation values must be stripped prior to │
|
|
│ applying normalisation. │
|
|
│ 5.4.5) FFmpeg, FAAC, and MEncoder are banned. │
|
|
│ 5.4.6) AC3 is allowed for INTERNAL releases only. │
|
|
│ 5.4.7) Audio with more than 2 channels must be down-mixed to stereo, │
|
|
│ with the exception of INTERNAL releases. │
|
|
│ 5.4.8) Audio must not be resampled. Audio must be kept in the original │
|
|
│ format as the source. e.g. 48KHz for 48KHz sources. │
|
|
│ 5.5) AC3, DTS, DTS-ES, E-AC3, MP2, and FLAC are the only allowed formats │
|
|
│ for resolutions 720p and above. │
|
|
│ 5.5.1) AC3 bitrate must not be below 640 Kbps, unless the original source │
|
|
│ audio is already in a low bitrate lossy format. In which case, the │
|
|
│ original audio must be used and not transcoded. │
|
|
│ 5.5.2) AC3 640 Kbps, DTS 1536 Kbps, and FLAC must be created from a │
|
|
│ higher bitrate source. │
|
|
│ │
|
|
│ 6) [ Video / Resolution ] │
|
|
│ 6.1) Standard definition (SD) refers to a maximum horizontal display │
|
|
│ resolution of 720 pixels. │
|
|
│ 6.2) 720p refers to a maximum display resolution of 1280x720. │
|
|
│ 6.3) 1080p refers to a maximum display resolution of 1920x1080. │
|
|
│ 6.4) 2160p refers to a maximum display resolution of 3840x2160. │
|
|
│ 6.5) Upscaling is not allowed. │
|
|
│ 6.6) Resolution must be mod 2. │
|
|
│ 6.7) English spoken titles with foreign overlays (e.g. locations and │
|
|
│ on-screen text shown in another language) are not allowed, use │
|
|
│ INTERNAL. │
|
|
│ 6.8) Non-English spoken titles with hardcoded English subtitles must be │
|
|
│ tagged as SUBBED. │
|
|
│ 6.9) Dupes based on resolution are not allowed. │
|
|
│ 6.9.1) Except in situations of releases with a different aspect ratio. │
|
|
│ The relevant tag must be used, and the reason mentioned in the │
|
|
│ NFO, see rule 19.5.3. │
|
|
│ 6.9.2) Releases which contain an additional 20 pixels or more worth of │
|
|
│ video on any side are not considered dupes. These releases must be │
|
|
│ tagged as WS or OM (open matte) and not PROPER, and the original │
|
|
│ release must not be nuked. │
|
|
│ 6.10) Retention or removal of faded edges is left to the discretion of the │
|
|
│ group. Inclusion of faded edges is not a technical flaw, and cannot │
|
|
│ be propered. │
|
|
│ 6.10.1) Faded edges refer to a line of pixels which are of similar │
|
|
│ appearance to pixels' parallel to the video frame. │
|
|
│ 6.11) Black borders and anything that is not part of the video must be │
|
|
│ cropped. │
|
|
│ 6.11.1) Black borders refer to: black or coloured borders, duplicate │
|
|
│ lines, dirty lines or pixels. │
|
|
│ 6.12) Video can be over or under cropped by a maximum of 1px per side. │
|
|
│ Over or under cropping by more than 1px per side is considered a │
|
|
│ technical flaw. │
|
|
│ 6.12.1) Under crop refers to portions of the video frame which is not │
|
|
│ actual picture. Files which contain black borders greater than │
|
|
│ 1px on any side is considered a technical flaw. │
|
|
│ 6.12.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 1px of faded edges and 1px │
|
|
│ of black exists. │
|
|
│ 6.12.3) Situations where video cropping of the same content varies │
|
|
│ between sources are not considered a technical flaw, and may │
|
|
│ not be propered. │
|
|
│ 6.13) In the case of varying aspect ratios throughout the video, cropping │
|
|
│ must be done to the widest video frame. │
|
|
│ 6.13.1) Studio logos, intertitles, and credits must be disregarded when │
|
|
│ determining the widest frame. │
|
|
│ 6.14) Any sort of visual glitch present in the video stream is considered │
|
|
│ a technical flaw. │
|
|
│ 6.14.1) Except in situations where glitches are a result of a live-stream │
|
|
│ or issues with the broadcast or source and are completely │
|
|
│ unavoidable. It is recommended, but optional, to mention glitches │
|
|
│ or gaps in playback in the NFO. │
|
|
│ 6.14.2) Unavoidable glitches as a result of broadcast, live-stream, or │
|
|
│ mastering issues may be propered with a glitch-free version. │
|
|
│ 6.14.3) Visual glitches are defined as, but not limited to: │
|
|
│ visual/compression artifacts, signal/stream issues, missing │
|
|
│ frames. │
|
|
│ 6.15) Resized and transcoded video must be within 0.5% of the original │
|
|
│ aspect ratio. │
|
|
│ 6.16) Sample aspect ratio (SAR): │
|
|
│ SAR = (PixelHeight / PixelWidth) / (DARHeight / DARWidth) │
|
|
│ 6.17) Display aspect ratio (DAR): │
|
|
│ DAR = (PixelWidth * DARWidth) / (PixelHeight * DARHeight) │
|
|
│ 6.18) Display resolution: │
|
|
│ DisplayWidth = PixelWidth * (SARWidth / SARHeight) │
|
|
│ 6.19) 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 │
|
|
│ 6.20) Target resolution when resizing to maintain mod2 and reduce AR │
|
|
│ error: │
|
|
│ TargetHeight = TargetWidth / [(SourceWidth - │
|
|
│ [CropLeft + CropRight]) / (SourceHeight - │
|
|
│ [CropTop + CropBottom])] │
|
|
│ The correct mod 2 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. │
|
|
│ 6.20.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 mod 2]) │
|
|
│ HeightB = floor(TargetHeight - [TargetHeight mod 2]) │
|
|
│ 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 mod 2)) or 718. │
|
|
│ HeightB = floor(717.33 - (717.33 mod 2)) 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. │
|
|
│ │
|
|
│ 7) [ Framerate / Filters ] │
|
|
│ 7.1) IVTC, deinterlacing, or decimation must be applied as required. │
|
|
│ 7.2) Only smart deinterlacers, such as Yadif, QTGMC, or TFM, must be used. │
|
|
│ 7.2.1) FieldDeinterlace must not be used for deinterlacing. │
|
|
│ 7.3) Only accurate field matching filters, such as TIVTC or Decomb, must │
|
|
│ be used for inverse telecining (IVTC). │
|
|
│ 7.3.1) Use of MEncoder, MJPEG tools, libav, libavcodec, or FFmpeg as IVTC │
|
|
│ filters are not allowed. │
|
|
│ 7.3.2) Deinterlacing filters must not be applied to telecined sources as │
|
|
│ a method of inverse telecine. Use of an accurate field matching │
|
|
│ filter must be used on telecined sources to recreate progressive │
|
|
│ frames and must be decimated to remove any duplicate frames. │
|
|
│ e.g. Yadif must not be used on a telecined source with a frame │
|
|
│ sequence of PPIIP, as Yadif will attempt to deinterlace │
|
|
│ every frame, including the progressive frames. TFM and │
|
|
│ TDecimate should be used in this situation. │
|
|
│ 7.4) Only sharp resizers are allowed. Simple resizers such as bicubic, │
|
|
│ simple, etc, are not allowed. Only the following resizers are allowed │
|
|
│ (in order of preference): │
|
|
│ 7.4.1) Spline36Resize/Spline64Resize. │
|
|
│ 7.4.2) BlackmanResize. │
|
|
│ 7.4.3) LanczosResize/Lanczos4Resize. │
|
|
│ 7.5) Sources which contain footage at varying FPS throughout (hybrid │
|
|
│ sources) and may or may not require IVTC is left to the discretion │
|
|
│ of the group. The NFO must list a reason as to the final decision. │
|
|
│ 7.5.1) It is assumed that the majority of a title contains enough unique │
|
|
│ frames at 30,000/1,001 fps to warrant a higher framerate. If it │
|
|
│ can be proven IVTC/decimating does not result in any loss of │
|
|
│ unique frames, this is considered a technical flaw. │
|
|
│ e.g. The native format of a Netflix title is 30,000/1,001 fps but │
|
|
│ contains some footage filmed at 24,000/1,001 fps. Choosing │
|
|
│ to encode the entire release at 30,000/1,001 fps is valid. │
|
|
│ 7.6) Native and converted framerates refers to the standard in which the │
|
|
│ video was produced. │
|
|
│ 7.6.1) NTSC produced video is native to NTSC. │
|
|
│ 7.6.2) PAL produced video is native to PAL. │
|
|
│ 7.6.3) NTSC produced video that is broadcast in PAL is considered as │
|
|
│ converted video. │
|
|
│ 7.6.4) PAL produced video that is broadcast in NTSC is considered as │
|
|
│ converted video. │
|
|
│ 7.7) Converted video that has significant artifacts (e.g. blended frames) │
|
|
│ and cannot be reversed to the native format must be tagged as │
|
|
│ CONVERT. │
|
|
│ 7.7.1) Converted video which does not have any artifacts does not require │
|
|
│ the CONVERT tag and must not be nuked for the conversion. │
|
|
│ 7.8) 50 / 60 fps video may be released at 50 / 60 fps or 25 / 30 fps. │
|
|
│ True 25 / 30 video released at 50 / 60 fps is not allowed and │
|
|
│ considered a technical flaw. │
|
|
│ 7.8.1) In rare situations, 25 / 50 fps sources should be restored to │
|
|
│ 24 or 30 fps. │
|
|
│ 7.8.2) In rare situations, 30 / 60 fps sources should be restored to │
|
|
│ 25 fps. │
|
|
│ │
|
|
│ 8) [ Audio ] │
|
|
│ 8.1) Audio must be in the original format provided. Minor adjustments │
|
|
│ (channel count, adding or removing frames) in order to prevent issues │
|
|
│ with playback or sync is allowed. │
|
|
│ 8.1.1) Valid lossy codecs are: AAC, AC3, DTS, DTS-ES, E-AC3, MP2. │
|
|
│ 8.1.2) For audio originally packaged in a lossless (LPCM) format, audio │
|
|
│ must be converted to a lossy format without any down-mixing of │
|
|
│ surround channels. e.g. AC3 640 Kbps, DTS 1536 Kbps, and FLAC. │
|
|
│ 8.2) Transcoding lossy audio to another lossy format is not allowed. │
|
|
│ 8.3) Sync must not drift at all during the entire release. │
|
|
│ 8.4) Glitches that occur in any audio channel present (e.g. L, R, C, SL, │
|
|
│ SR, etc.) are considered a technical flaw. │
|
|
│ 8.4.1) Except in situations where glitches are a result of a live-stream │
|
|
│ or issues with the broadcast or source and are completely │
|
|
│ unavoidable. It is recommended, but optional, to mention glitches │
|
|
│ or gaps in playback in the NFO. │
|
|
│ 8.4.2) Unavoidable glitches as a result of broadcast, live-stream, or │
|
|
│ mastering issues may be propered with a glitch-free version. │
|
|
│ 8.4.3) Glitches are defined as, but not limited to: an audible glitch, │
|
|
│ missing audio, pops or clicks as a result of encoding, gaps within │
|
|
│ playback, missing dialogue, muted or muffled audio, echoing. │
|
|
│ 8.5) A release must only contain a single audio track. │
|
|
│ 8.5.1) Dual-language audio tracks are allowed for non-English material │
|
|
│ only. │
|
|
│ 8.6) If the original language of a title is not English: │
|
|
│ 8.6.1) An English dubbed track is allowed as a secondary audio track. │
|
|
│ 8.6.2) Releases containing only a dubbed audio track must be tagged as │
|
|
│ DUBBED. │
|
|
│ 8.7) Non-English releases without a secondary English audio track must │
|
|
│ use a language tag indicating the primary spoken language. │
|
|
│ 8.8) Dupes based on audio format or multiple audio tracks are not allowed, │
|
|
│ use INTERNAL. │
|
|
│ 8.9) Retail audio may be used in placed of audio tracks extracted from │
|
|
│ the source. Proof of the source disc must be provided, see │
|
|
│ section 13. │
|
|
│ │
|
|
│ 9) [ Credits / Previously On / Unrelated Footage ] │
|
|
│ 9.1) Credits and 'Previously On' footage must be included and is not │
|
|
│ optional. │
|
|
│ 9.2) Any unrelated commercials or paid advertisements, regardless of │
|
|
│ duration (e.g. 1 faded/half opacity frame or 10 seconds) must be │
|
|
│ completely removed from the release. │
|
|
│ 9.3) Content rating cards and viewer warnings separate to the show must │
|
|
│ be completely removed and it is considered a technical flaw if │
|
|
│ present. │
|
|
│ 9.3.1) Except in situations where the content warning is integrated into │
|
|
│ the opening of the show and cannot be removed, e.g. Cops. │
|
|
│ │
|
|
│ 10) [ Container ] │
|
|
│ 10.1) Container must be Matroska (.mkv). MKVToolnix is the recommended │
|
|
│ muxer. │
|
|
│ 10.2) Custom muxing tools are allowed. However, the output must adhere to │
|
|
│ the latest Matroska specification and must retain identical │
|
|
│ compatibility with demuxers as files created with MKVToolnix. │
|
|
│ 10.3) Support for file streaming and playback from RAR is mandatory. │
|
|
│ 10.4) Matroska header compression must not be enabled. │
|
|
│ 10.5) Header stripping or modification is not allowed. │
|
|
│ 10.6) Falsifying or modification of encoding parameters and information │
|
|
│ is not allowed. │
|
|
│ │
|
|
│ 11) [ Subtitles ] │
|
|
│ 11.1) Subtitles for English spoken titles without foreign dialogue are │
|
|
│ optional, but encouraged. │
|
|
│ 11.1.1) Optical character recognition (OCR) must not result in spelling │
|
|
│ errors or mistakes. │
|
|
│ e.g. Zero ('0') used in place of an upper-case O ('o'). │
|
|
│ 11.1.2) Minor errors in grammar or punctuation which do not change the │
|
|
│ meaning of the sentence are allowed, however, it is recommended │
|
|
│ all errors be corrected. │
|
|
│ 11.2) English spoken titles with foreign dialogue must include a separate │
|
|
│ subtitle track for forced subtitles. │
|
|
│ 11.2.1) Foreign dialogue subtitle tracks must be set as forced and it is │
|
|
│ considered a technical flaw if not done correctly. │
|
|
│ 11.2.2) In situations where the source video stream contains hardcoded │
|
|
│ subtitles for English spoken titles with foreign dialogue, a │
|
|
│ separate subtitle track for the forced subtitles is not required. │
|
|
│ 11.3) Non-English spoken titles without hardcoded subtitles must include │
|
|
│ an English subtitle track set as default. │
|
|
│ 11.4) Group watermarks in subtitles are not allowed. │
|
|
│ 11.5) Dupes based on subtitles are not allowed, use INTERNAL. │
|
|
│ 11.6) Propers based on the inclusion of optional subtitles is not allowed. │
|
|
│ 11.7) Fan-made or custom subtitles are not allowed. │
|
|
│ 11.8) Groups must not burn subtitles in to the video stream. │
|
|
│ 11.9) External subtitles located in 'Subs' directories are not allowed. │
|
|
│ 11.10) Must be free of any technical flaws. Including, but not limited │
|
|
│ to: sync issues, incorrect OCR, invalid default or forced muxing │
|
|
│ flags. │
|
|
│ 11.11) Subtitles must be extracted from the original source, or obtained │
|
|
│ from another source which provides the same video. │
|
|
│ e.g. A source obtained from iTunes does not contain subtitles, but │
|
|
│ can be extracted from Netflix. These subtitles can be muxed │
|
|
│ into the final release. │
|
|
│ 11.12) Retail subtitles may be used in place of subtitles extracted from │
|
|
│ the source. Proof of the source disc must be provided, see section │
|
|
│ 13. │
|
|
│ 11.13) Adjustments and edits may be made to subtitle tracks. │
|
|
│ 11.13.1) Edits can refer to: adjusting timecodes, fixing grammar, │
|
|
│ spelling, or punctuation errors, etc. │
|
|
│ 11.13.2) A summary of the changes must be listed in the NFO. │
|
|
│ e.g. Shifted all timecodes by 2 seconds to ensure sync is │
|
|
│ maintained throughout, or spelling errors fixed │
|
|
│ throughout, etc. │
|
|
│ 11.14) Subtitles must be muxed into the final MKV in text based │
|
|
│ format, i.e. SubRip (.srt) or SubSation Alpha (.ssa/.ass). │
|
|
│ 11.14.1) Retail subtitles must be muxed in text based (.srt/.ssa/.ass) │
|
|
│ or PGS (.sup) format. PGS is recommended. │
|
|
│ 11.14.2) All subtitle tracks must have the character set (--sub-charset) │
|
|
│ set to a Unicode format or UTF-8 when muxing. │
|
|
│ 11.14.3) Subtitles must not set as default or forced unless otherwise │
|
|
│ specified. │
|
|
│ 11.14.4) The correct ISO 639 language code supported by MKVToolnix must │
|
|
│ be set for all subtitle tracks. │
|
|
│ 11.14.4.1) In situations where the language is not supported by │
|
|
│ MKVToolnix, 'und' must be used. │
|
|
│ e.g. en for English, de for German, etc. │
|
|
│ 11.14.5) The correct character encoding │
|
|
│ │
|
|
│ 12) [ Packaging ] │
|
|
│ 12.1) Must be packed with RAR files, broken into a maximum of 99 volumes. │
|
|
│ 12.2) RAR5/RARv5.0 is not allowed. RAR3/v2.0 or RAR4/v2.9 must be used. │
|
|
│ 12.2.1) Custom RAR tools are permitted. However, files must adhere to │
|
|
│ the RAR4/RARv2.9 archive specification and must retain identical │
|
|
│ compatibility with extractors and demuxers as files created with │
|
|
│ WinRAR/rar. │
|
|
│ 12.3) Permitted RAR sizes are: │
|
|
│ 12.3.1) 15,000,000 bytes or 20,000,000 bytes for SD. Multiples of these │
|
|
│ values are not allowed. │
|
|
│ 12.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, etc. │
|
|
│ 12.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. │
|
|
│ 12.4) Must have SFV and NFO. │
|
|
│ 12.5) RAR, SFV, and Sample files must have unique, lower-case filenames │
|
|
│ with the group tag. │
|
|
│ 12.5.1) Group tags must be unique to each group, and may be an │
|
|
│ abbreviated variation of the group name. │
|
|
│ 12.6) Missing RAR(s) or SFV on all sites is considered a technical flaw. │
|
|
│ 12.7) Corrupt RAR(s) (errors upon extraction) is considered a technical │
|
|
│ flaw. │
|
|
│ 12.8) RAR compression and recovery records are not allowed. │
|
|
│ 12.9) Encryption or password protection is not allowed. │
|
|
│ │
|
|
│ 13) [ Proof ] │
|
|
│ 13.1) Proof picture(s) must have unique filenames and placed in a separate │
|
|
│ directory named 'Proof'. │
|
|
│ 13.1.1) Proof file(s) must be included in every release which requires │
|
|
│ proof. │
|
|
│ 13.2) Proof must be in JPEG or PNG format. │
|
|
│ 13.3) Proof is required for iTunes sourced files only. A screenshot of │
|
|
│ the download in progress must be provided. │
|
|
│ 13.3.1) A release which fails to pre with the required proof is │
|
|
│ considered a technical flaw and can be propered. │
|
|
│ 13.3.2) Proof fixes must be within 24 hours of original pre. Fixes │
|
|
│ provided after a proper has been released, or after 24 hours has │
|
|
│ elapsed from the original pre, will not be accepted. │
|
|
│ 13.3.3) It is also recommended, in an unobstructed way, to include the │
|
|
│ group name within the screenshot written in Notepad or a similar │
|
|
│ text editor. │
|
|
│ 13.4) Releases which include retail-sourced elements (e.g. retail │
|
|
│ subtitles) must include source proof. │
|
|
│ 13.4.1) Proof must be photographs of the printed side of all physical │
|
|
│ discs used with the group tag clearly visible. │
|
|
│ 13.4.2) The minimum resolution for photographs is 640x480px. Disc details │
|
|
│ must be clear and legible. │
|
|
│ 13.5) Small identifiable or sensitive information may be obscured or │
|
|
│ redacted. │
|
|
│ 13.6) User identifiable EXIF data must be stripped. It is recommended all │
|
|
│ EXIF data be stripped. │
|
|
│ │
|
|
│ 14) [ Samples ] │
|
|
│ 14.1) All releases must include a 50-70 second sample for each release. │
|
|
│ 14.2) Samples must have unique filenames and placed in a separate │
|
|
│ directory named 'Sample'. │
|
|
│ 14.3) Samples must be cut from the final video, not encoded separately. │
|
|
│ │
|
|
│ 15) [ NFO ] │
|
|
│ 15.1) NFO must be present in every release. │
|
|
│ 15.2) It is recommended, but optional, to include the following │
|
|
│ information in the NFO: │
|
|
│ 15.2.1) Release name and group. │
|
|
│ 15.2.2) Title and release date. │
|
|
│ 15.2.3) CRF value / bitrate used. │
|
|
│ 15.2.4) Audio format. │
|
|
│ 15.2.5) Source. │
|
|
│ 15.2.6) Relevant IMDB/TVDB/Amazon link. │
|
|
│ 15.2.7) Total video size or RAR count. │
|
|
│ 15.3) It is optional, but highly recommended, that the source for │
|
|
│ untouched files be mentioned in the NFO. │
|
|
│ │
|
|
│ 16) [ Tagging ] │
|
|
│ 16.1) Only the following additional tags are allowed: │
|
|
│ ALTERNATIVE.CUT, CONVERT, COLORIZED, DC, DIRFIX, DOCU, DUBBED, │
|
|
│ EXTENDED, FESTIVAL, FINAL, INTERNAL, LIMITED, MULTI, NFOFIX, OM, │
|
|
│ PPV, PROOFFIX, PROPER, REAL, REMASTERED, READNFO, REPACK, RERIP, │
|
|
│ SAMPLEFIX, SOURCE.SAMPLE, SUBBED, THEATRICAL, UNCENSORED, UNRATED, │
|
|
│ UNCUT, and WS. │
|
|
│ 16.2) Variations of any additional tags are not allowed. │
|
|
│ e.g. READ.NFO or RNFO is not allowed, READNFO must be used. │
|
|
│ 16.3) READNFO should be used sparingly. Discretion is recommended. │
|
|
│ 16.3.1) The READNFO tag must not be used with PROPER, REPACK, or RERIP. │
|
|
│ The NFO is required to contain a reason, therefore the tag is │
|
|
│ redundant. │
|
|
│ 16.4) Tags must only be used once, but the order is left to the discretion │
|
|
│ of the group. │
|
|
│ 16.4.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.REPACK is required for a │
|
|
│ REAL.PROPER.REPACK and PROPER.REPACK. │
|
|
│ 16.5) Tags must be grouped together, period-delimited, and must follow the │
|
|
│ mandatory directory format, see rule 17.4. │
|
|
│ e.g. EXTENDED.LIMITED, REMASTERED.REPACK, REAL.PROPER. │
|
|
│ │
|
|
│ 17) [ Directory Nomenclature ] │
|
|
│ 17.1) Acceptable characters allowed for directories are: │
|
|
│ ABCDEFGHIJKLMNOPQRSTUVWXYZ │
|
|
│ abcdefghijklmnopqrstuvwxyz │
|
|
│ 0123456789.- │
|
|
│ 17.2) Single punctuation must be used. Consecutive punctuation is not │
|
|
│ allowed. │
|
|
│ e.g. Show----Name.S01E01, Show.Name....S01E01, │
|
|
│ Show.-.Name.--.S01E01, etc. │
|
|
│ 17.3) Typos or spelling mistakes in the directory are not allowed. │
|
|
│ 17.4) Releases must follow the matching directory format: │
|
|
│ 17.4.1) Movie.YEAR.<TAGS>.[LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.4.2) Weekly.TV.Show.SXXEXX[Episode.Part].[Episode.Title].<TAGS>. │
|
|
│ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.4.3) Miniseries.Show.Name.Part.XX.[Episode.Title].<TAGS>. │
|
|
│ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.4.4) Daily.TV.Show.YYYY.MM.DD.[Guest.Name].<TAGS>. │
|
|
│ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.4.5) Daily.Sport.League.YYYY.MM.DD.Event.<TAGS>. │
|
|
│ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.4.6) Monthly.Competition.YYYY.MM.Event.<TAGS>. │
|
|
│ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.4.7) Yearly.Competition.YYYY.Event.<TAGS>. │
|
|
│ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP │
|
|
│ 17.5) Named directory arguments formatted inside <> must be included. │
|
|
│ Optional arguments formatted inside [] may be used in some cases. │
|
|
│ 17.5.1) Episode part refers to episodes, usually cartoons or animation, │
|
|
│ which split episodes into stories by different directors. │
|
|
│ Episodes 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, etc. https://goo.gl/CVGXKu │
|
|
│ 17.5.2) Episode title and guest names are optional. │
|
|
│ 17.5.3) Guest name(s) used must be in the order in which they appear on │
|
|
│ the show to avoid any confusion. │
|
|
│ 17.5.4) Tags refers to all permitted tags only, see section 16. │
|
|
│ 17.5.5) Non-English releases must include the language tag and must be │
|
|
│ used to denote the language of the audio track. English releases │
|
|
│ must not include the language tag. │
|
|
│ 17.5.5.1) Language tags must be the full name of the language. │
|
|
│ Abbreviations or language codes are not allowed. │
|
|
│ e.g. FRENCH, RUSSIAN, GERMAN. │
|
|
│ 17.5.6) Resolution identifiers are only applicable for releases 720p and │
|
|
│ above, and must precede the format of the release, see section 6 │
|
|
│ for resolution specifications. │
|
|
│ e.g. 720p.WEB.H264, 2160p.WEBRip.x264. │
|
|
│ 17.5.7) Format refers to whether the release is transcoded (WEBRip.x264) │
|
|
│ or untouched (WEB.H264/WEB.x264). │
|
|
│ 17.6) Do not indicate source, ripping, or encoding methods that were used. │
|
|
│ Use the NFO for any technical details. │
|
|
│ 17.7) All movie releases must include the production year. │
|
|
│ 17.8) Movie distribution tags (FESTIVAL, LIMITED) must be used with │
|
|
│ discretion. Use boxofficemojo.com or IMDB screen details as │
|
|
│ references. │
|
|
│ 17.9) Different shows with the same title and format produced in different │
|
|
│ countries must have the ISO 3166-1 alpha 2 country code in the │
|
|
│ show name. │
|
|
│ 17.9.1) Except for UK shows, which should use UK, not GB. │
|
|
│ 17.9.2) This rule does not apply to an original show, only shows that │
|
|
│ precede the original with the same premise or format. │
|
|
│ e.g. The.Office.S01E01 and The.Office.US.S01E01. │
|
|
│ 17.10) 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. │
|
|
│ 17.10.1) The year is not required for the show broadcasted first. │
|
|
│ e.g. Second.Chance.S01E01 and Second.Chance.2016.S01E01. │
|
|
│ 17.11) 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. │
|
|
│ 17.11.1) See rules 17.12 and 17.13 for country code and year │
|
|
│ explanations. │
|
|
│ e.g. Wanted.S01E01 (2005), Wanted.AU.S01E01 (2013), │
|
|
│ Wanted.AU.2016.S01E01 (2016). │
|
|
│ 17.12) Show names which are hyphenated or include punctuation must follow │
|
|
│ the format shown in the title sequence or credits of the first │
|
|
│ episode congruent to the list of acceptable characters. │
|
|
│ 17.12.1) If no title card exists, the format listed on the official │
|
|
│ website for the show must be used, followed by what is listed │
|
|
│ by the streaming service. │
|
|
│ 17.12.2) Additional titles and names given to an individual season must │
|
|
│ not be used. │
|
|
│ e.g. Archer.Vice.S05, Strike.Back.Legacy.S05. │
|
|
│ 17.13) Directory nomenclature and numbering must remain consistent │
|
|
│ across the lifetime of an individual show or event. │
|
|
│ 17.13.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. │
|
|
│ 17.13.2) 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. │
|
|
│ 17.13.3) Except in situations where the show has an official change in │
|
|
│ its name, whereby all official references by the broadcaster or │
|
|
│ studio is 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. │
|
|
│ 17.13.4) 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.Ranges.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. │
|
|
│ 17.13.5) Any deviations or changes require sufficient evidence listed in │
|
|
│ the NFO as to the reason for change. │
|
|
│ 17.14) For shows which begin on network television and continue │
|
|
│ exclusively on a web-based service, the title or numbering of the │
|
|
│ show shall not change. │
|
|
│ 17.14.1) Except in situations where the show is not a direct continuation │
|
|
│ of the previous seasons. │
|
|
│ 17.14.2) If the show continues without any changes, the title of the show │
|
|
│ shall not change, but will follow the season and episode │
|
|
│ numbering as listed on the web-based service which purchased │
|
|
│ the show. │
|
|
│ 17.15) User contributed services such as TVRage, 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. │
|
|
│ 17.15.1) The following order must be used as the primary source for │
|
|
│ naming and numbering. │
|
|
│ 17.15.1.1) Official website of the show. │
|
|
│ 17.15.1.2) Order and format listed by the streaming service. │
|
|
│ 17.15.1.3) Network guide. │
|
|
│ │
|
|
│ 18) [ Fixes ] │
|
|
│ 18.1) Only the following fixes are allowed: │
|
|
│ DIRFIX, NFOFIX, PROOFFIX, and SAMPLEFIX. │
|
|
│ 18.2) Any other form of fix is not allowed. │
|
|
│ e.g. RARFIX, SFVFIX, SUBFIX, etc. │
|
|
│ 18.3) All fixes require an NFO and must state which release is being │
|
|
│ fixed. │
|
|
│ 18.4) A proper may not be released for an error that can be fixed with │
|
|
│ the above methods, with the exception of proof fixes, see rule │
|
|
│ 13.3.2. │
|
|
│ 18.5) If multiple releases from a single season require a DIRFIX, a single │
|
|
│ DIRFIX per season is allowed and is recommended. │
|
|
│ e.g. Show.Name.S01.DIRFIX.WEBRip.x264-GROUP. │
|
|
│ 18.5.1) If a single DIRFIX is used, all relevant releases and │
|
|
│ corresponding fixes must be listed in the NFO. │
|
|
│ │
|
|
│ 19) [ Dupes ] │
|
|
│ 19.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. │
|
|
│ 19.1.1) Timestamps must be considered as whole integers and round half │
|
|
│ towards zero. │
|
|
│ 19.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. │
|
|
│ 19.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. │
|
|
│ 19.2) WEBRip.x264 dupes WEB.H264/x264. │
|
|
│ 19.3) WEB.H264/x264 does not dupe WEBRip.x264. │
|
|
│ 19.4) WEB.H264/x264 and WEBRip.x264 does not dupe DSR/PDTV. │
|
|
│ 19.5) WEB.H264/x264 and WEBRip.x264 dupes an equivalent AHDTV/HDTV/Retail │
|
|
│ release. │
|
|
│ 19.5.1) SD WEB.H264/x264 and WEBRip.x264 dupes an SD AHDTV/HDTV/Retail │
|
|
│ release. │
|
|
│ 19.5.2) 720p, 1080p, 2160p WEB.H264/WEB.x264 and WEBRip.x264 dupes a │
|
|
│ respective AHDTV/HDTV/Retail release. │
|
|
│ e.g. 720p.WEB.H264 dupes 720p.HDTV.x264, 1080p.WEBRip.x264 │
|
|
│ dupes 1080p.AHDTV.x264. │
|
|
│ 1080p.WEB.H264 does not dupe 720p.BluRay.x264 if │
|
|
│ 1080p.BluRay.x264 does not exist. │
|
|
│ 19.5.3) Except in situations where the aspect ratio of a │
|
|
│ WEB.H264/x264 and WEBRip.x264 release exceeds that of its │
|
|
│ respective AHDTV/HDTV/Retail release. │
|
|
│ e.g. A 2.39:1 release will not dupe a 1.78:1 retail provided │
|
|
│ there is clearly more footage visible on-screen. Proof │
|
|
│ demonstrating this difference is recommended, but not │
|
|
│ mandatory. │
|
|
│ 19.5.4) Except in situations where a WEB.H264/x264 or WEBRip.x264 release │
|
|
│ is an uncensored or extended edit of its respective │
|
|
│ AHDTV/HDTV/Retail release. │
|
|
│ e.g. An uncensored WEB.H264 release does not dupe HDTV.x264, │
|
|
│ EXTENDED.WEBRip.x264 does not dupe BluRay.x264. │
|
|
│ 19.6) Releases with hardcoded subtitles (i.e. SUBBED) dupes releases with │
|
|
│ muxed-in subtitles. │
|
|
│ 19.7) Releases with muxed-in subtitles do not dupe releases with hardcoded │
|
|
│ subtitles. │
|
|
│ 19.8) Native video streams do not dupe converted video streams. │
|
|
│ 19.9) Converted video streams dupe native video streams. │
|
|
│ │
|
|
│ 20) [ Propers / Rerips / Repacks ] │
|
|
│ 20.1) Detailed reasons must be included in the NFO for all repacks, │
|
|
│ rerips, and propers. │
|
|
│ 20.1.1) Proper reasons must be clearly stated in the NFO, including │
|
|
│ timestamps and specifics in regards to the flaw when appropriate. │
|
|
│ A sample demonstrating the flaw in the original release is │
|
|
│ encouraged, but not mandatory. │
|
|
│ 20.2) Propers are only permitted in the case of a technical flaw in the │
|
|
│ original release. │
|
|
│ 20.3) If fixing a technical flaw requires transcoding of the file, it must │
|
|
│ follow the transcoding rules and tagged as WEBRip.x264. │
|
|
│ 20.4) Transcoded releases cannot proper any untouched files. │
|
|
│ e.g. WEBRip.x264 cannot proper WEB.H264. │
|
|
│ 20.4.1) Unless it is a transcode of a lossless stream correcting the │
|
|
│ technical flaw, see rule 1.4. │
|
|
│ 20.4.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. │
|
|
│ 20.5) Untouched files can proper transcoded releases for any valid │
|
|
│ technical flaw. │
|
|
│ 20.6) Audio or visual glitches can be propered with a release which does │
|
|
│ not exhibit the same flaw. │
|
|
│ 20.6.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. │
|
|
│ 20.7) RERIP must be used for ripping or encoding issues. │
|
|
│ 20.8) REPACK must be used for packing or muxing issues. │
|
|
│ 20.9) Propers are only valid for releases with timestamps after the │
|
|
│ official start date of this ruleset. │
|
|
│ 20.9.1) Groups cannot proper existing releases using rules created as a │
|
|
│ result of this ruleset. │
|
|
│ e.g. If the resolution is not mod 2 or x264 revision used is │
|
|
│ older than 50 revisions at the time of pre, the release │
|
|
│ cannot be nuked. │
|
|
│ 20.9.2) With exceptions of a release containing technical flaws which │
|
|
│ would apply to any ruleset regardless of section. e.g. bad IVTC, │
|
|
│ sync issues, bad or invalid cropping, etc. │
|
|
│ │
|
|
│ 21) [ Internals ] │
|
|
│ 21.1) Internals are allowed to be released for any reason, including, but │
|
|
│ not limited to: releases containing technical flaws, use of │
|
|
│ alternate codecs, containers, or settings for experimental purposes. │
|
|
│ 21.2) Any severe technical flaws must be mentioned in the NFO. │
|
|
│ 21.3) Internal releases may only be nuked for technical flaws that are not │
|
|
│ mentioned in the NFO. │
|
|
│ 21.3.1) In situations where technical flaws are not mentioned in the NFO, │
|
|
│ groups may provide an NFOFIX to avoid or reverse a nuke. │
|
|
│ 21.4) Using DIRFIX.INTERNAL to avoid a nuke is not allowed, and must be │
|
|
│ nuked fix.for.nuke. │
|
|
│ │
|
|
│ 22) [ Ruleset Specifics ] │
|
|
│ 22.1) This ruleset is to be considered the ONLY official ruleset in │
|
|
│ regards to WEB and WEBRip releases. It supersedes all previous │
|
|
│ rules and precedents derived from existing TV and Retail rules in │
|
|
│ regards to WEB sources. │
|
|
│ 22.2) 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 6.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. │
|
|
│ 22.3) If there is a question as to the validity of a source 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. │
|
|
│ 22.3.1) The group has 24 hours from the first nuke to pre a source │
|
|
│ sample that is at least 10 seconds in length. │
|
|
│ 22.3.2) Source samples must be packed with RAR files, and use the │
|
|
│ SOURCE.SAMPLE tag. │
|
|
│ 22.3.3) Providing insufficient proof to disprove any claims, or a │
|
|
│ failure to provide any source proof, and the release must remain │
|
|
│ nuked and can be propered. │
|
|
│ 22.4) The following definition of keywords throughout this ruleset are as │
|
|
│ follows: │
|
|
│ 22.4.1) Must: the rule is explicit in the definition and is compulsory. │
|
|
│ 22.4.2) Should: implies the rule is a suggestion, and is non-compulsory. │
|
|
│ 22.4.3) Can or may: implies the rule is optional, and is non-compulsory. │
|
|
│ │
|
|
│ 23) [ Notes ] │
|
|
│ 23.1) Proof is only enforced for iTunes as all other sources require │
|
|
│ various unofficial (backdoor) methods of downloading. Creating a │
|
|
│ fake GUI showing an active download is not difficult, which could │
|
|
│ result in proof being fabricated. As such, it is pointless to │
|
|
│ require proof for anything but iTunes, where streams can only be │
|
|
│ downloaded by a single method. │
|
|
│ 23.1.1) This includes web stores or shops which provide video files via a │
|
|
│ regular HTTP download. Policing or moderating these methods would │
|
|
│ be implausible for a single ruleset. Providing screenshots of a │
|
|
│ download in progress from a website does not prove the file was │
|
|
│ obtained from an official source. │
|
|
│ 23.2) The burden of proving P2P source material is on the propering group │
|
|
│ or nuker. │
|
|
│ 23.3) 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 extreme │
|
|
│ high quality. │
|
|
│ 23.3.1) Video which contains an excessive amount of noise may often │
|
|
│ result in an unnecessary large bitrate. In such situations, │
|
|
│ using a smaller bitrate using 2-pass can result in a file size │
|
|
│ improvement with negligible loss in video quality. │
|
|
│ │
|
|
├─────────────────────────────────────────────────────────────────────────────┤
|
|
│ │
|
|
│ [ Signed ] │
|
|
│ │
|
|
│ 2HD AEROHOLiCS ALTEREGO AZR AMB3R ANiHLS ANiURL BARGE BATV BiQ C4TV │
|
|
│ CHAMPiONS DEADPOOL DEFEATER DEFLATE DRAWER FADE FaiLED FiHTV FQM │
|
|
│ GORE HatchetGear iBlade KOENiG KYR Ltu NTROPiC QCF REGRET RiVER RPTV │
|
|
│ SH0W SiGeRiS SKGTV spamTV TASTETV TiMELiNE WaLMaRT W4F WNN ZOMBiE │
|
|
│ │
|
|
│ [ Refused to sign ] │
|
|
│ │
|
|
│ CBFM │
|
|
│ │
|
|
├─────────────────────────────────────────────────────────────────────────────┤
|
|
│ │
|
|
│ [ Revisions ] │
|
|
│ 2016-03-16 - ecb63c67 - Final commit and public release of ruleset. │
|
|
│ │
|
|
└─────────────────────────────────────────────────────────────────────────────┘</pre>
|
|
</body>
|
|
</html>
|