xREL.v3

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
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.