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