API tools faq
paste
Advertisement
doc_gonzo

x264 Standards

doc_gonzo
Apr 30th, 2020
503
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 86.93 KB | None | 0 0
raw download clone embed print report
  1. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
  2. ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³
  3. ÃÄÄÄÄÄÄÄÄÄÄ´ Web Definitions for x264 v1.0 a.k.a. wdx264 ÃÄÄÄÄÄÄÄÄÄ´
  4. ÃÄÄÄÄÄÄÄÄÄÄ´ THE.2016.WEB.AND.WEBRIP.SD.HD.X264.RULESET.v1.0-WDX264 ÃÄÄÄÄÄÄÄÄÄ´
  5. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³
  6. ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  7. ³ ³
  8. ³ [ Intro ] ³
  9. ³ In the last 18 months, web based streaming and video on-demand services ³
  10. ³ have increased in popularity. Initially used as a source for missed ³
  11. ³ broadcasts, it has since evolved into an exclusive source for original ³
  12. ³ content. Like most technology, online services are continually evolving ³
  13. ³ the way in which files re provided to end users. As codecs mature, ³
  14. ³ bandwidth increases in speed and decreases in price, equivalent ³
  15. ³ improvements in quality follows at the benefit to the end-users. This ³
  16. ³ increase in quality has the flow-on effect of often being a legitimate ³
  17. ³ logo-free alternative to antiquated MPEG-2 HDTV streams. As companies ³
  18. ³ such as Netflix and Amazon continue to produce popular content at an ³
  19. ³ exponential rate, it became obvious that this new broadcast medium ³
  20. ³ deserved to be recognised with an original ruleset. ³
  21. ³ ³
  22. ³ The purpose of this document is to create a high standard for web-sourced ³
  23. ³ files. It attempts to prevent any improper handling of files, and reduce ³
  24. ³ the potential for adding to the increasing number of ongoing nuke-wars. ³
  25. ³ This ruleset is structured in such a way that everything attempts to be ³
  26. ³ clear and concise, and something everyone must adhere to. ³
  27. ³ ³
  28. ³ Compliance with this document is optional as of its pre date, and ³
  29. ³ mandatory as of 2016-03-21 00:00:00 UTC (1458518400 Unix time). ³
  30. ³ ³
  31. ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  32. ³ ³
  33. ³ 1) [ Untouched: WEB.H264 / WEB.x264 ] ³
  34. ³ 1.1) Untouched releases must be considered as anything that has been ³
  35. ³ losslessly downloaded by official (offered) or unofficial (backdoor) ³
  36. ³ methods. ³
  37. ³ 1.1.1) Untouched video streams must use a commercial (e.g. CoreAVC, ³
  38. ³ MainConcept) or GPL-licensed (e.g. x264, x265) H.264/MPEG-4 AVC ³
  39. ³ or H.265/HEVC codec. ³
  40. ³ 1.2) Source video and audio streams must be left as obtained from the ³
  41. ³ source. Transcoding of audio or video streams is not allowed. ³
  42. ³ 1.3) Untouched video streams without x264 headers must be tagged as ³
  43. ³ WEB.H264. Untouched video streams with x264 headers present in the ³
  44. ³ H264 stream must be tagged as WEB.x264. ³
  45. ³ 1.3.1) In situations where HEVC/H265 is used, any untouched sections ³
  46. ³ referring to H264/x264 must be considered as H265/x265. ³
  47. ³ 1.3.1.1) H265 must be used in place of H264. ³
  48. ³ 1.3.1.2) x265 must be used in place of x264. ³
  49. ³ 1.3.2) Until H265/x265 support is improved in mainstream demuxers, ³
  50. ³ untouched video streams which use H265/x265 do not dupe H264/x264 ³
  51. ³ files, and vice-versa. ³
  52. ³ e.g. WEB.H265 does not dupe WEB.H264 ³
  53. ³ WEB.x264 does not dupe WEB.x265. ³
  54. ³ 1.4) Transcoding untouched files must only occur if files do not meet the ³
  55. ³ standards and specifications listed in this section, and must only ³
  56. ³ be a last resort. ³
  57. ³ 1.4.1) Any transcoding of untouched files must follow the transcoding ³
  58. ³ standards, see section 2. ³
  59. ³ 1.4.2) Transcoding must be done from files of the highest resolution and ³
  60. ³ bitrate offered. ³
  61. ³ 1.4.3) Transcoding may occur when correcting a technical flaw. ³
  62. ³ e.g. Cropping black borders, deinterlacing an interlaced source. ³
  63. ³ 1.4.4) In situations where a target resolution is not offered by any ³
  64. ³ lossless source, or the resolution offered by any source does not ³
  65. ³ meet the minimum resolution requirements, transcoding from the ³
  66. ³ highest resolution and bitrate offered is allowed. However, if at ³
  67. ³ least one source can provide the correct resolution, transcoding ³
  68. ³ is not allowed. ³
  69. ³ e.g. If 1080p and 720p can be retrieved from multiple sources, ³
  70. ³ but SD cannot be retrieved from any source, transcoding the ³
  71. ³ 1080p to SD is allowed. ³
  72. ³ 1.4.5) If the untouched file does not contain any technical flaws and ³
  73. ³ meets the minimum standards required, transcoding to create any ³
  74. ³ WEBRip.x264 is not allowed, use INTERNAL. ³
  75. ³ e.g. 1080p.WEB.H264 -> 720p.WEBRip.x264. ³
  76. ³ 1.5) Untouched video streams which do not use an AVC or HEVC codec must be ³
  77. ³ transcoded and follow the transcoding standards, see section 3. ³
  78. ³ 1.6) Standard definition (SD) refers to a resolution with a horizontal ³
  79. ³ minimum of 720 pixels or a resolution which does not exceed the ³
  80. ³ specifications of 720p, see rule 6.2. ³
  81. ³ 1.6.1) If all sources provide standard definition resolutions which fall ³
  82. ³ below the above minimum, transcoding from the highest available ³
  83. ³ resolution is allowed, see rule 1.4.4. ³
  84. ³ 1.6.2) Except in situations where only one source has the file on offer ³
  85. ³ at a specific resolution. If the resolution of the file falls ³
  86. ³ below the above minimum, the file may still be released, but the ³
  87. ³ NFO must state why the resolution does not meet the minimum. ³
  88. ³ 1.7) DRM and any user identifiable information must be removed. ³
  89. ³ 1.8) Dupes based on source are not allowed, use INTERNAL. ³
  90. ³ 1.9) YouTube may only be used as a source if geographical restrictions ³
  91. ³ apply to legitimate content uploaded by the rights holder or on a ³
  92. ³ verified channel. ³
  93. ³ 1.10) Must use the highest available bitrate offered by the source for ³
  94. ³ that resolution. ³
  95. ³ e.g. Releasing a 720p at 4,000 Kbps bitrate, when a 720p at ³
  96. ³ 8,000 Kbps bitrate is offered is not allowed. ³
  97. ³ 1.11) Must be free of technical flaws. Including, but not limited to: DRM, ³
  98. ³ sync issues, interlaced, lack of IVTC, bad AR, missing footage, ³
  99. ³ missing dialogue, unrelated footage or commercials, under or over ³
  100. ³ crop. ³
  101. ³ 1.12) VFR (Variable Frame Rate) methods are allowed only if present in the ³
  102. ³ original source. ³
  103. ³ 1.12.1) If CFR (Constant Frame Rate) can be used when remuxing and does ³
  104. ³ not result in playback issue, CFR must be used. ³
  105. ³ 1.13) Trimming unrelated footage (section 8) is allowed and must be done ³
  106. ³ losslessly via keyframe intervals (GOP). MKVToolnix is the ³
  107. ³ recommended tool. ³
  108. ³ 1.13.1) If unrelated footage cannot be removed via this method, the file ³
  109. ³ must be transcoded and follow the transcoding standards, see ³
  110. ³ section 3. ³
  111. ³ 1.14) Incorrect pixel aspect ratio (PAR) or a non-square sample aspect ³
  112. ³ ratio (SAR) must be fixed using the correct display aspect ratio ³
  113. ³ (DAR) set at a container level (--aspect-ratio). MKVToolnix is the ³
  114. ³ recommended tool. ³
  115. ³ e.g. A video stream with a non-square SAR must specify the correct ³
  116. ³ DAR when muxing. ³
  117. ³ 1.15) Releases with a non-square SAR are not considered technically ³
  118. ³ flawed. ³
  119. ³ 1.15.1) However, a source which provides files with a square SAR will ³
  120. ³ trump an equivalent file with a non-square SAR. It is recommended ³
  121. ³ to use a source which provides files with a square SAR. ³
  122. ³ 1.15.2) In situations where a source initially provides a non-square SAR ³
  123. ³ file and later updates with a square SAR file, the initial ³
  124. ³ release with a non-square SAR is considered of lower quality ³
  125. ³ and a technical flaw. ³
  126. ³ e.g. Release A: 960x720, SAR: 4:3, DAR: 16:9. ³
  127. ³ Release B: 1280x720, SAR: 1:1, DAR: 16:9. ³
  128. ³ Both releases are considered as 720p. ³
  129. ³ If Release A is first: Release A remains unnuked and is a ³
  130. ³ valid release until Release B is released. Release B then ³
  131. ³ propers Release A. ³
  132. ³ If Release B is first: Release A dupes Release B. ³
  133. ³ ³
  134. ³ 2) [ Untouched: Audio ] ³
  135. ³ 2.1) Must use the original audio track offered by the source. ³
  136. ³ 2.2) Non-destructive audio normalisation tools such as ReplayGain may be ³
  137. ³ used, and must be done to the maximum gain. Audio normalisation on ³
  138. ³ lossy tracks is optional. ³
  139. ³ 2.3) Standard definition releases must only contain an audio track with a ³
  140. ³ maximum of 2.0 channels. ³
  141. ³ 2.3.1) Except where the only available audio track on offer contains more ³
  142. ³ than 2.0 channels. The NFO must mention why an audio track with ³
  143. ³ more than 2.0 channels was used. ³
  144. ³ 2.3.2) In situations where a source provides two audio tracks, a 2.0 and ³
  145. ³ 5.1 track, the 2.0 audio track must be used. ³
  146. ³ 2.3.3) If a source provides identical audio tracks using two different ³
  147. ³ codecs, it is at the discretion of the group which track is used. ³
  148. ³ It is recommended to use the smaller file. ³
  149. ³ e.g. A source offers AC3 2.0 and AAC 2.0, the group may choose to ³
  150. ³ remux the AC3 or AAC. ³
  151. ³ 2.4) High Definition releases must use the highest available audio format ³
  152. ³ and quality offered by the source. ³
  153. ³ 2.4.1) In situations where a lesser audio format is offered for larger ³
  154. ³ resolutions in comparison to lower resolutions, groups must use ³
  155. ³ the highest available audio format from all resolutions. ³
  156. ³ e.g. A source provides an AC3 5.1 track for SD resolutions, but ³
  157. ³ an AAC 2.0 track for 720p/1080p. The AC3 5.1 track must be ³
  158. ³ used for 720p/1080p resolutions. ³
  159. ³ 2.4.2) If using the highest available audio format results in a technical ³
  160. ³ flaw (e.g. sync issues or glitches), minor adjustments to the ³
  161. ³ audio track may be applied. If groups are unable to correct any ³
  162. ³ flaws, the original audio track must be used. ³
  163. ³ ³
  164. ³ 3) [ Transcoded: WEBRip.x264 ] ³
  165. ³ 3.1) Transcoded releases should be considered as anything that has been ³
  166. ³ captured or encoded by a group to a lesser format or quality (lossy). ³
  167. ³ 3.2) Transcoded releases must be tagged as WEBRip.x264. ³
  168. ³ 3.3) Dupes based on source are not allowed, use INTERNAL. ³
  169. ³ 3.4) Must be free of technical flaws. Including, but not limited to: DRM, ³
  170. ³ sync issues, interlaced, lack of IVTC, bad AR, missing footage, ³
  171. ³ missing dialogue, unrelated footage or commercials, under or over ³
  172. ³ crop, dupe or dropped frames. ³
  173. ³ 3.5) Upscaling video streams is not allowed. ³
  174. ³ e.g. 2160p from a 1080p stream is not allowed. ³
  175. ³ 3.6) Streams must be captured at the highest available resolution and ³
  176. ³ bitrate offered. ³
  177. ³ 3.6.1) Streams must not have any degradation in quality throughout the ³
  178. ³ capture, and releases with drops to a lower resolution or bitrate ³
  179. ³ is considered a technical flaw. ³
  180. ³ 3.6.2) 1080p and 2160p streams are considered of equal value when ³
  181. ³ capturing, and encodes (SD/720p/1080p) produced from 1080p or ³
  182. ³ 2160p captures are considered identical. It is encouraged, and ³
  183. ³ recommended, to capture from a 2160p stream where possible and ³
  184. ³ resize so as to produce a higher quality encode. ³
  185. ³ 3.6.3) Audio must be captured in the highest format offered by the source ³
  186. ³ stream, not what the capturing device is capable of. This includes ³
  187. ³ channel count and bitrate offered. ³
  188. ³ e.g. If a Netflix show lists a 5.1 track, the resultant capture ³
  189. ³ and release should also contain a 5.1 audio track. ³
  190. ³ 3.7) Captures should be done at the native broadcast framerate of the ³
  191. ³ source. ³
  192. ³ 3.7.1) Captures from devices which are unable to output a native format ³
  193. ³ must be restored to the original framerate. ³
  194. ³ 3.7.2) If captures cannot be completely restored to their native ³
  195. ³ framerate, such as a single dupe frame every 1000 or blended/ghost ³
  196. ³ frames due to mangling from the streaming device, this is ³
  197. ³ considered a technical flaw. ³
  198. ³ 3.8) Captures should be done at the native colour space of the source ³
  199. ³ (e.g. YUV or RGB), and manual corrections should be made to achieve ³
  200. ³ an output near-identical to the source. ³
  201. ³ 3.9) Capture software and hardware which introduces video cropping greater ³
  202. ³ than 2 pixels on any side is not allowed, and is considered a ³
  203. ³ technical flaw. ³
  204. ³ 3.10) Final resolution must maintain the same aspect ratio as the source ³
  205. ³ after cropping and kept at mod 2. ³
  206. ³ 3.10.1) Sources must have all black borders cropped to the widest frame. ³
  207. ³ 3.10.2) The same aspect ratio, as calculated from the source, must be ³
  208. ³ used, see rule 6.17. ³
  209. ³ 3.11) If the video is being transcoded from an untouched source (rule ³
  210. ³ 1.4.4 and 1.4.5), the NFO must state the reason for transcoding. ³
  211. ³ 3.11.1) If a technical flaw is present that is being rectified by ³
  212. ³ transcoding (rule 1.4.5), the flaw must also be included with the ³
  213. ³ reason for transcoding. ³
  214. ³ e.g. A file from 2 lossless providers both have the same ³
  215. ³ interlacing flaw. ³
  216. ³ The flaw: Interlaced video. ³
  217. ³ The reason: No other WEB.H264 provider has a correctly ³
  218. ³ deinterlaced file. ³
  219. ³ ³
  220. ³ 4) [ Transcoded: Codec ] ³
  221. ³ 4.1) x264 8-bit must be used. ³
  222. ³ 4.1.1) Custom builds of x264 are allowed and must be based off the x264 ³
  223. ³ codebase, e.g. x264-tMod, x264-kMod. ³
  224. ³ 4.1.2) Any experimental or alternate codecs (e.g. x265) are not allowed, ³
  225. ³ use INTERNAL. ³
  226. ³ 4.2) x264 revision must be no more than 50 revisions from the latest at ³
  227. ³ pre time. It is recommended to use the latest revision when encoding. ³
  228. ³ Use the official x264 git repo as the only ³
  229. ³ reference: http://git.videolan.org/?p=x264.git;a=summary ³
  230. ³ 4.3) Segmented encoding is not allowed. ³
  231. ³ 4.4) Justification must be listed in the NFO for use of non-standard CRF ³
  232. ³ values. ³
  233. ³ 4.5) Decimal values may be used for CRF values. ³
  234. ³ 4.6) Constant Rate Factor (--crf) must be used by default. ³
  235. ³ 4.6.1) A CRF value of 19 must be used for all SD resolutions. ³
  236. ³ 4.6.1.1) If the resultant video bitrate exceeds 2,000 Kbps, the CRF ³
  237. ³ value must be incremented by 1. ³
  238. ³ 4.6.1.2) If the resultant video bitrate exceeds 1,500 Kbps, the CRF ³
  239. ³ value may be optionally incremented by up to 1.0, e.g. 19.2, ³
  240. ³ 19.6. ³
  241. ³ 4.6.2) A CRF value of 18 must be used for all 720p resolutions. ³
  242. ³ 4.6.2.1) If the resultant video bitrate exceeds 9,000 Kbps, the CRF ³
  243. ³ value must be incremented by 1. ³
  244. ³ 4.6.2.2) If the resultant video bitrate exceeds 8,000 Kbps, the CRF ³
  245. ³ value may be optionally incremented by up to 1.0, e.g. 18.2, ³
  246. ³ 18.6. ³
  247. ³ 4.6.3) A CRF value of 17 must be used for all 1080p resolutions. ³
  248. ³ 4.6.3.1) If the resultant video bitrate exceeds 15,000 Kbps, the CRF ³
  249. ³ value must be incremented by 1. ³
  250. ³ 4.6.3.2) If the resultant video bitrate exceeds 14,000 Kbps, the CRF ³
  251. ³ value may be optionally incremented by up to 1.0, e.g. 17.2, ³
  252. ³ 17.6. ³
  253. ³ 4.6.4) A CRF value of 17 must be used for all 2160p resolutions. ³
  254. ³ 4.7) Use of 2-pass is accepted for all resolutions of 720p and above, ³
  255. ³ however this method should be used only in extreme cases and not as ³
  256. ³ a primary replacement for CRF methods. e.g. If the source contains an ³
  257. ³ excessive amount of grain or black and white scenes. ³
  258. ³ 4.7.1) 2-pass should be a last resort when encoding. Instead, groups are ³
  259. ³ encouraged and recommended to use CRF as the default encoding ³
  260. ³ method. ³
  261. ³ 4.7.2) The NFO must provide sufficient evidence of 2-pass producing a ³
  262. ³ visual improvement, bitrate, or file size advantage over CRF in ³
  263. ³ regards to the source used. ³
  264. ³ 4.7.3) There is no maximum or minimum file size when using 2-pass methods ³
  265. ³ as target bitrates should take precedent over target file sizes. ³
  266. ³ Multiples of 1120MiB (1,174,405,120 bytes) may be used as a ³
  267. ³ general guide for calculating target bitrates. ³
  268. ³ 4.7.4) If groups are unsure of how to calculate an adequate target ³
  269. ³ bitrate applicable for the source, CRF should be used. ³
  270. ³ 4.7.4.1) 720p bitrate must be between 4,000 Kbps and 9,000 Kbps ³
  271. ³ inclusive, and should have a target bitrate of approximately ³
  272. ³ 5,500 Kbps. Minimum bitrate for animation is 2,500 Kbps. ³
  273. ³ 4.7.4.2) 1080p bitrate must be between 9,000 Kbps and 15,000 Kbps ³
  274. ³ inclusive, and should have a target bitrate of approximately ³
  275. ³ 10,500 Kbps. Minimum bitrate for animation is 5,500 Kbps. ³
  276. ³ 4.7.4.3) 2160p bitrate must not exceed 60,000 Kbps. ³
  277. ³ 4.8) Resultant bitrate must not exceed the source bitrate. ³
  278. ³ 4.8.1) When transcoding from an untouched source, it is recommended to ³
  279. ³ use SelectRangeEvery() for a rough estimation on the final CRF ³
  280. ³ value to use. ³
  281. ³ 4.8.2) The following algorithm can also be used to estimate a CRF value ³
  282. ³ if the value originally used results in a bitrate which exceeds ³
  283. ³ the source. ³
  284. ³ ValidCRF = [-6 * (DestinationBitrate - ExcessiveBitrate) / ³
  285. ³ ExcessiveBitrate] + CRFUsed ³
  286. ³ e.g. Source bitrate: 4,500Kbps ³
  287. ³ Target bitrate: ~4,400Kbps ³
  288. ³ Encoded bitrate @ CRF17: 5,900Kbps ³
  289. ³ ValidCRF = (-6 * (4400 - 5900) / 5900) + 17 ³
  290. ³ ValidCRF = 18.52, round up to 19 should result in an average ³
  291. ³ bitrate below the source. ³
  292. ³ 4.9) Settings cannot go below what is specified by --preset slow. ³
  293. ³ e.g. -subme 7 or -me hex is not allowed. ³
  294. ³ 4.10) Deblocking (--deblock) must be used. Values used are left to the ³
  295. ³ discretion of the group. Recommended values: -3:-3 for film, 1:1 ³
  296. ³ for animation. ³
  297. ³ 4.11) Sample Aspect Ratio (--sar) must be square (1:1). ³
  298. ³ 4.12) Keyframe interval (--keyint) must be at least 200, and at most 300. ³
  299. ³ It is recommended to let x264 decide which value to use, but ³
  300. ³ 10*framerate is a good guideline. ³
  301. ³ 4.13) Minimum GOP length (--minkeyint) must be 30 or less. ³
  302. ³ 4.14) Level 3.1 must be used for SD resolutions. ³
  303. ³ 4.15) Level 4.1 must be used for all 720p and 1080p resolutions. ³
  304. ³ 4.16) Level 5.1 must be used for all 2160p resolutions. ³
  305. ³ 4.17) Encoded colourspace (--output-csp) must be 4:2:0. ³
  306. ³ 4.18) Colour matrix (--colormatrix) must be set for all SD resolutions. ³
  307. ³ 4.18.1) 'bt709' must be used for encodes from high definition sources. ³
  308. ³ 4.18.2) Source specification must be used for standard definition ³
  309. ³ sources. ³
  310. ³ 4.18.3) 'undef' must be used if not specified by the source for standard ³
  311. ³ definition sources. ³
  312. ³ 4.19) Colour matrix (--colormatrix) may be optionally set to 'bt709' for ³
  313. ³ all resolutions of 720p and above, but is not required. ³
  314. ³ 4.20) Custom matrices are not allowed. ³
  315. ³ 4.21) Zones (--zones) are not allowed. ³
  316. ³ 4.22) Optional tuning (--tune) parameters allowed are: film, grain, or ³
  317. ³ animation. ³
  318. ³ 4.23) Optional settings recommended for tuning per source, see doom9.org ³
  319. ³ for further information: ³
  320. ³ 4.23.1) For complex video, --preset slower/placebo is encouraged. ³
  321. ³ 4.23.2) --aq-mode 3 --aq-strength x.x ³
  322. ³ e.g. 0.6-0.9 for digital films. ³
  323. ³ 0.5-0.7 for grainy films. ³
  324. ³ 0.9-1.1 for animation. ³
  325. ³ 4.23.3) --psy-rd x.x:0.0 ³
  326. ³ e.g. 0.8-1.2 for films. ³
  327. ³ 0.5-0.8 for animation. ³
  328. ³ 4.23.4) --trellis 2, --no-fast-pskip, --no-mbtree ³
  329. ³ ³
  330. ³ 5) [ Transcoded: Audio ] ³
  331. ³ 5.1) Segmented encoding is not allowed. ³
  332. ³ 5.2) Audio tracks already in a lossy format must not be transcoded, but ³
  333. ³ kept in the original format. ³
  334. ³ 5.3) Stereo must be used for stereo sources, and mono must be used for ³
  335. ³ mono sources. ³
  336. ³ 5.3.1) Any audio track with identical channels is considered a mono ³
  337. ³ source. ³
  338. ³ 5.3.2) Dual mono is not allowed. ³
  339. ³ 5.4) VBR AAC LC (Low Complexity) must be used for SD releases. ³
  340. ³ 5.4.1) Apple/QAAC, FDK-AAC or Nero must be used. ³
  341. ³ 5.4.2) Quality based VBR encoding must be used, targeted or constrained ³
  342. ³ VBR must not be used. Only the following methods are allowed (in ³
  343. ³ order of preference): ³
  344. ³ 5.4.2.1) QAAC: --tvbr 82 --quality 2 ³
  345. ³ 5.4.2.2) FDK-AAC: --bitrate-mode 4 --profile 2 ³
  346. ³ 5.4.2.3) Nero: -q 0.4 ³
  347. ³ 5.4.3) AAC audio must be normalised to the maximum gain. Normalisation ³
  348. ³ must be a complete 2-pass method. No pre-defined values or ³
  349. ³ estimations of maximum gain is allowed. Only the following ³
  350. ³ normalisation methods are allowed (in order of preference): ³
  351. ³ 5.4.3.1) eac3to: -normalize ³
  352. ³ 5.4.3.2) sox: --norm ³
  353. ³ 5.4.3.3) QAAC: --normalize ³
  354. ³ 5.4.4) Any existing normalisation values must be stripped prior to ³
  355. ³ applying normalisation. ³
  356. ³ 5.4.5) FFmpeg, FAAC, and MEncoder are banned. ³
  357. ³ 5.4.6) AC3 is allowed for INTERNAL releases only. ³
  358. ³ 5.4.7) Audio with more than 2 channels must be down-mixed to stereo, ³
  359. ³ with the exception of INTERNAL releases. ³
  360. ³ 5.4.8) Audio must not be resampled. Audio must be kept in the original ³
  361. ³ format as the source. e.g. 48KHz for 48KHz sources. ³
  362. ³ 5.5) AC3, DTS, DTS-ES, E-AC3, MP2, and FLAC are the only allowed formats ³
  363. ³ for resolutions 720p and above. ³
  364. ³ 5.5.1) AC3 bitrate must not be below 640 Kbps, unless the original source ³
  365. ³ audio is already in a low bitrate lossy format. In which case, the ³
  366. ³ original audio must be used and not transcoded. ³
  367. ³ 5.5.2) AC3 640 Kbps, DTS 1536 Kbps, and FLAC must be created from a ³
  368. ³ higher bitrate source. ³
  369. ³ ³
  370. ³ 6) [ Video / Resolution ] ³
  371. ³ 6.1) Standard definition (SD) refers to a maximum horizontal display ³
  372. ³ resolution of 720 pixels. ³
  373. ³ 6.2) 720p refers to a maximum display resolution of 1280x720. ³
  374. ³ 6.3) 1080p refers to a maximum display resolution of 1920x1080. ³
  375. ³ 6.4) 2160p refers to a maximum display resolution of 3840x2160. ³
  376. ³ 6.5) Upscaling is not allowed. ³
  377. ³ 6.6) Resolution must be mod 2. ³
  378. ³ 6.7) English spoken titles with foreign overlays (e.g. locations and ³
  379. ³ on-screen text shown in another language) are not allowed, use ³
  380. ³ INTERNAL. ³
  381. ³ 6.8) Non-English spoken titles with hardcoded English subtitles must be ³
  382. ³ tagged as SUBBED. ³
  383. ³ 6.9) Dupes based on resolution are not allowed. ³
  384. ³ 6.9.1) Except in situations of releases with a different aspect ratio. ³
  385. ³ The relevant tag must be used, and the reason mentioned in the ³
  386. ³ NFO, see rule 19.5.3. ³
  387. ³ 6.9.2) Releases which contain an additional 20 pixels or more worth of ³
  388. ³ video on any side are not considered dupes. These releases must be ³
  389. ³ tagged as WS or OM (open matte) and not PROPER, and the original ³
  390. ³ release must not be nuked. ³
  391. ³ 6.10) Retention or removal of faded edges is left to the discretion of the ³
  392. ³ group. Inclusion of faded edges is not a technical flaw, and cannot ³
  393. ³ be propered. ³
  394. ³ 6.10.1) Faded edges refer to a line of pixels which are of similar ³
  395. ³ appearance to pixels' parallel to the video frame. ³
  396. ³ 6.11) Black borders and anything that is not part of the video must be ³
  397. ³ cropped. ³
  398. ³ 6.11.1) Black borders refer to: black or coloured borders, duplicate ³
  399. ³ lines, dirty lines or pixels. ³
  400. ³ 6.12) Video can be over or under cropped by a maximum of 1px per side. ³
  401. ³ Over or under cropping by more than 1px per side is considered a ³
  402. ³ technical flaw. ³
  403. ³ 6.12.1) Under crop refers to portions of the video frame which is not ³
  404. ³ actual picture. Files which contain black borders greater than ³
  405. ³ 1px on any side is considered a technical flaw. ³
  406. ³ 6.12.2) Releases which include faded edges must consider faded edges as ³
  407. ³ a valid part of the video frame and do not count as black ³
  408. ³ borders. ³
  409. ³ e.g. A release cannot be propered if 1px of faded edges and 1px ³
  410. ³ of black exists. ³
  411. ³ 6.12.3) Situations where video cropping of the same content varies ³
  412. ³ between sources are not considered a technical flaw, and may ³
  413. ³ not be propered. ³
  414. ³ 6.13) In the case of varying aspect ratios throughout the video, cropping ³
  415. ³ must be done to the widest video frame. ³
  416. ³ 6.13.1) Studio logos, intertitles, and credits must be disregarded when ³
  417. ³ determining the widest frame. ³
  418. ³ 6.14) Any sort of visual glitch present in the video stream is considered ³
  419. ³ a technical flaw. ³
  420. ³ 6.14.1) Except in situations where glitches are a result of a live-stream ³
  421. ³ or issues with the broadcast or source and are completely ³
  422. ³ unavoidable. It is recommended, but optional, to mention glitches ³
  423. ³ or gaps in playback in the NFO. ³
  424. ³ 6.14.2) Unavoidable glitches as a result of broadcast, live-stream, or ³
  425. ³ mastering issues may be propered with a glitch-free version. ³
  426. ³ 6.14.3) Visual glitches are defined as, but not limited to: ³
  427. ³ visual/compression artifacts, signal/stream issues, missing ³
  428. ³ frames. ³
  429. ³ 6.15) Resized and transcoded video must be within 0.5% of the original ³
  430. ³ aspect ratio. ³
  431. ³ 6.16) Sample aspect ratio (SAR): ³
  432. ³ SAR = (PixelHeight / PixelWidth) / (DARHeight / DARWidth) ³
  433. ³ 6.17) Display aspect ratio (DAR): ³
  434. ³ DAR = (PixelWidth * DARWidth) / (PixelHeight * DARHeight) ³
  435. ³ 6.18) Display resolution: ³
  436. ³ DisplayWidth = PixelWidth * (SARWidth / SARHeight) ³
  437. ³ 6.19) Aspect ratio (AR) error: ³
  438. ³ Original AR = (SourceWidth - [CropLeft + CropRight]) / ³
  439. ³ (SourceHeight - [CropTop + CropBottom]) ³
  440. ³ Release AR = EncodeWidth / EncodedHeight ³
  441. ³ AR Error % = [(Original AR - Release AR) / Original AR] * 100 ³
  442. ³ 6.20) Target resolution when resizing to maintain mod2 and reduce AR ³
  443. ³ error: ³
  444. ³ TargetHeight = TargetWidth / [(SourceWidth - ³
  445. ³ [CropLeft + CropRight]) / (SourceHeight - ³
  446. ³ [CropTop + CropBottom])] ³
  447. ³ The correct mod 2 value can also be calculated from the ceiling of ³
  448. ³ TargetHeight if the value is odd, and the floor of TargetHeight if ³
  449. ³ the value is even. ³
  450. ³ 6.20.1) Alternatively, the following can be used to confirm the correct ³
  451. ³ resolution is used from the above method by calculating the upper ³
  452. ³ and lower integer limit of TargetHeight: ³
  453. ³ HeightA = floor(TargetHeight + [TargetHeight mod 2]) ³
  454. ³ HeightB = floor(TargetHeight - [TargetHeight mod 2]) ³
  455. ³ The TargetHeight value (HeightA or HeightB) which results in an ³
  456. ³ aspect ratio error which tends to zero must be used. ³
  457. ³ e.g. TargetWidth: 1280. ³
  458. ³ SourceWidth: 1920, SourceHeight: 1080. ³
  459. ³ CropLeft + CropRight = 0, CropTop + CropBottom = 4. ³
  460. ³ TargetHeight = 1280 / ((1920 - 0) / (1080 - 4)) or 717.33. ³
  461. ³ HeightA = floor(717.33 + (717.33 mod 2)) or 718. ³
  462. ³ HeightB = floor(717.33 - (717.33 mod 2)) or 716. ³
  463. ³ TargetWidth x HeightA = 1280x718 with -0.09% AR error. ³
  464. ³ TargetWidth x HeightB = 1280x716 with 0.19% AR error. ³
  465. ³ -0.09% tends closer to zero than 0.19% does (0.09 < 0.19), ³
  466. ³ therefore, HeightA must be used. ³
  467. ³ ³
  468. ³ 7) [ Framerate / Filters ] ³
  469. ³ 7.1) IVTC, deinterlacing, or decimation must be applied as required. ³
  470. ³ 7.2) Only smart deinterlacers, such as Yadif, QTGMC, or TFM, must be used. ³
  471. ³ 7.2.1) FieldDeinterlace must not be used for deinterlacing. ³
  472. ³ 7.3) Only accurate field matching filters, such as TIVTC or Decomb, must ³
  473. ³ be used for inverse telecining (IVTC). ³
  474. ³ 7.3.1) Use of MEncoder, MJPEG tools, libav, libavcodec, or FFmpeg as IVTC ³
  475. ³ filters are not allowed. ³
  476. ³ 7.3.2) Deinterlacing filters must not be applied to telecined sources as ³
  477. ³ a method of inverse telecine. Use of an accurate field matching ³
  478. ³ filter must be used on telecined sources to recreate progressive ³
  479. ³ frames and must be decimated to remove any duplicate frames. ³
  480. ³ e.g. Yadif must not be used on a telecined source with a frame ³
  481. ³ sequence of PPIIP, as Yadif will attempt to deinterlace ³
  482. ³ every frame, including the progressive frames. TFM and ³
  483. ³ TDecimate should be used in this situation. ³
  484. ³ 7.4) Only sharp resizers are allowed. Simple resizers such as bicubic, ³
  485. ³ simple, etc, are not allowed. Only the following resizers are allowed ³
  486. ³ (in order of preference): ³
  487. ³ 7.4.1) Spline36Resize/Spline64Resize. ³
  488. ³ 7.4.2) BlackmanResize. ³
  489. ³ 7.4.3) LanczosResize/Lanczos4Resize. ³
  490. ³ 7.5) Sources which contain footage at varying FPS throughout (hybrid ³
  491. ³ sources) and may or may not require IVTC is left to the discretion ³
  492. ³ of the group. The NFO must list a reason as to the final decision. ³
  493. ³ 7.5.1) It is assumed that the majority of a title contains enough unique ³
  494. ³ frames at 30,000/1,001 fps to warrant a higher framerate. If it ³
  495. ³ can be proven IVTC/decimating does not result in any loss of ³
  496. ³ unique frames, this is considered a technical flaw. ³
  497. ³ e.g. The native format of a Netflix title is 30,000/1,001 fps but ³
  498. ³ contains some footage filmed at 24,000/1,001 fps. Choosing ³
  499. ³ to encode the entire release at 30,000/1,001 fps is valid. ³
  500. ³ 7.6) Native and converted framerates refers to the standard in which the ³
  501. ³ video was produced. ³
  502. ³ 7.6.1) NTSC produced video is native to NTSC. ³
  503. ³ 7.6.2) PAL produced video is native to PAL. ³
  504. ³ 7.6.3) NTSC produced video that is broadcast in PAL is considered as ³
  505. ³ converted video. ³
  506. ³ 7.6.4) PAL produced video that is broadcast in NTSC is considered as ³
  507. ³ converted video. ³
  508. ³ 7.7) Converted video that has significant artifacts (e.g. blended frames) ³
  509. ³ and cannot be reversed to the native format must be tagged as ³
  510. ³ CONVERT. ³
  511. ³ 7.7.1) Converted video which does not have any artifacts does not require ³
  512. ³ the CONVERT tag and must not be nuked for the conversion. ³
  513. ³ 7.8) 50 / 60 fps video may be released at 50 / 60 fps or 25 / 30 fps. ³
  514. ³ True 25 / 30 video released at 50 / 60 fps is not allowed and ³
  515. ³ considered a technical flaw. ³
  516. ³ 7.8.1) In rare situations, 25 / 50 fps sources should be restored to ³
  517. ³ 24 or 30 fps. ³
  518. ³ 7.8.2) In rare situations, 30 / 60 fps sources should be restored to ³
  519. ³ 25 fps. ³
  520. ³ ³
  521. ³ 8) [ Audio ] ³
  522. ³ 8.1) Audio must be in the original format provided. Minor adjustments ³
  523. ³ (channel count, adding or removing frames) in order to prevent issues ³
  524. ³ with playback or sync is allowed. ³
  525. ³ 8.1.1) Valid lossy codecs are: AAC, AC3, DTS, DTS-ES, E-AC3, MP2. ³
  526. ³ 8.1.2) For audio originally packaged in a lossless (LPCM) format, audio ³
  527. ³ must be converted to a lossy format without any down-mixing of ³
  528. ³ surround channels. e.g. AC3 640 Kbps, DTS 1536 Kbps, and FLAC. ³
  529. ³ 8.2) Transcoding lossy audio to another lossy format is not allowed. ³
  530. ³ 8.3) Sync must not drift at all during the entire release. ³
  531. ³ 8.4) Glitches that occur in any audio channel present (e.g. L, R, C, SL, ³
  532. ³ SR, etc.) are considered a technical flaw. ³
  533. ³ 8.4.1) Except in situations where glitches are a result of a live-stream ³
  534. ³ or issues with the broadcast or source and are completely ³
  535. ³ unavoidable. It is recommended, but optional, to mention glitches ³
  536. ³ or gaps in playback in the NFO. ³
  537. ³ 8.4.2) Unavoidable glitches as a result of broadcast, live-stream, or ³
  538. ³ mastering issues may be propered with a glitch-free version. ³
  539. ³ 8.4.3) Glitches are defined as, but not limited to: an audible glitch, ³
  540. ³ missing audio, pops or clicks as a result of encoding, gaps within ³
  541. ³ playback, missing dialogue, muted or muffled audio, echoing. ³
  542. ³ 8.5) A release must only contain a single audio track. ³
  543. ³ 8.5.1) Dual-language audio tracks are allowed for non-English material ³
  544. ³ only. ³
  545. ³ 8.6) If the original language of a title is not English: ³
  546. ³ 8.6.1) An English dubbed track is allowed as a secondary audio track. ³
  547. ³ 8.6.2) Releases containing only a dubbed audio track must be tagged as ³
  548. ³ DUBBED. ³
  549. ³ 8.7) Non-English releases without a secondary English audio track must ³
  550. ³ use a language tag indicating the primary spoken language. ³
  551. ³ 8.8) Dupes based on audio format or multiple audio tracks are not allowed, ³
  552. ³ use INTERNAL. ³
  553. ³ 8.9) Retail audio may be used in placed of audio tracks extracted from ³
  554. ³ the source. Proof of the source disc must be provided, see ³
  555. ³ section 13. ³
  556. ³ ³
  557. ³ 9) [ Credits / Previously On / Unrelated Footage ] ³
  558. ³ 9.1) Credits and 'Previously On' footage must be included and is not ³
  559. ³ optional. ³
  560. ³ 9.2) Any unrelated commercials or paid advertisements, regardless of ³
  561. ³ duration (e.g. 1 faded/half opacity frame or 10 seconds) must be ³
  562. ³ completely removed from the release. ³
  563. ³ 9.3) Content rating cards and viewer warnings separate to the show must ³
  564. ³ be completely removed and it is considered a technical flaw if ³
  565. ³ present. ³
  566. ³ 9.3.1) Except in situations where the content warning is integrated into ³
  567. ³ the opening of the show and cannot be removed, e.g. Cops. ³
  568. ³ ³
  569. ³ 10) [ Container ] ³
  570. ³ 10.1) Container must be Matroska (.mkv). MKVToolnix is the recommended ³
  571. ³ muxer. ³
  572. ³ 10.2) Custom muxing tools are allowed. However, the output must adhere to ³
  573. ³ the latest Matroska specification and must retain identical ³
  574. ³ compatibility with demuxers as files created with MKVToolnix. ³
  575. ³ 10.3) Support for file streaming and playback from RAR is mandatory. ³
  576. ³ 10.4) Matroska header compression must not be enabled. ³
  577. ³ 10.5) Header stripping or modification is not allowed. ³
  578. ³ 10.6) Falsifying or modification of encoding parameters and information ³
  579. ³ is not allowed. ³
  580. ³ ³
  581. ³ 11) [ Subtitles ] ³
  582. ³ 11.1) Subtitles for English spoken titles without foreign dialogue are ³
  583. ³ optional, but encouraged. ³
  584. ³ 11.1.1) Optical character recognition (OCR) must not result in spelling ³
  585. ³ errors or mistakes. ³
  586. ³ e.g. Zero ('0') used in place of an upper-case O ('o'). ³
  587. ³ 11.1.2) Minor errors in grammar or punctuation which do not change the ³
  588. ³ meaning of the sentence are allowed, however, it is recommended ³
  589. ³ all errors be corrected. ³
  590. ³ 11.2) English spoken titles with foreign dialogue must include a separate ³
  591. ³ subtitle track for forced subtitles. ³
  592. ³ 11.2.1) Foreign dialogue subtitle tracks must be set as forced and it is ³
  593. ³ considered a technical flaw if not done correctly. ³
  594. ³ 11.2.2) In situations where the source video stream contains hardcoded ³
  595. ³ subtitles for English spoken titles with foreign dialogue, a ³
  596. ³ separate subtitle track for the forced subtitles is not required. ³
  597. ³ 11.3) Non-English spoken titles without hardcoded subtitles must include ³
  598. ³ an English subtitle track set as default. ³
  599. ³ 11.4) Group watermarks in subtitles are not allowed. ³
  600. ³ 11.5) Dupes based on subtitles are not allowed, use INTERNAL. ³
  601. ³ 11.6) Propers based on the inclusion of optional subtitles is not allowed. ³
  602. ³ 11.7) Fan-made or custom subtitles are not allowed. ³
  603. ³ 11.8) Groups must not burn subtitles in to the video stream. ³
  604. ³ 11.9) External subtitles located in 'Subs' directories are not allowed. ³
  605. ³ 11.10) Must be free of any technical flaws. Including, but not limited ³
  606. ³ to: sync issues, incorrect OCR, invalid default or forced muxing ³
  607. ³ flags. ³
  608. ³ 11.11) Subtitles must be extracted from the original source, or obtained ³
  609. ³ from another source which provides the same video. ³
  610. ³ e.g. A source obtained from iTunes does not contain subtitles, but ³
  611. ³ can be extracted from Netflix. These subtitles can be muxed ³
  612. ³ into the final release. ³
  613. ³ 11.12) Retail subtitles may be used in place of subtitles extracted from ³
  614. ³ the source. Proof of the source disc must be provided, see section ³
  615. ³ 13. ³
  616. ³ 11.13) Adjustments and edits may be made to subtitle tracks. ³
  617. ³ 11.13.1) Edits can refer to: adjusting timecodes, fixing grammar, ³
  618. ³ spelling, or punctuation errors, etc. ³
  619. ³ 11.13.2) A summary of the changes must be listed in the NFO. ³
  620. ³ e.g. Shifted all timecodes by 2 seconds to ensure sync is ³
  621. ³ maintained throughout, or spelling errors fixed ³
  622. ³ throughout, etc. ³
  623. ³ 11.14) Subtitles must be muxed into the final MKV in text based ³
  624. ³ format, i.e. SubRip (.srt) or SubSation Alpha (.ssa/.ass). ³
  625. ³ 11.14.1) Retail subtitles must be muxed in text based (.srt/.ssa/.ass) ³
  626. ³ or PGS (.sup) format. PGS is recommended. ³
  627. ³ 11.14.2) All subtitle tracks must have the character set (--sub-charset) ³
  628. ³ set to a Unicode format or UTF-8 when muxing. ³
  629. ³ 11.14.3) Subtitles must not set as default or forced unless otherwise ³
  630. ³ specified. ³
  631. ³ 11.14.4) The correct ISO 639 language code supported by MKVToolnix must ³
  632. ³ be set for all subtitle tracks. ³
  633. ³ 11.14.4.1) In situations where the language is not supported by ³
  634. ³ MKVToolnix, 'und' must be used. ³
  635. ³ e.g. en for English, de for German, etc. ³
  636. ³ 11.14.5) The correct character encoding ³
  637. ³ ³
  638. ³ 12) [ Packaging ] ³
  639. ³ 12.1) Must be packed with RAR files, broken into a maximum of 99 volumes. ³
  640. ³ 12.2) RAR5/RARv5.0 is not allowed. RAR3/v2.0 or RAR4/v2.9 must be used. ³
  641. ³ 12.2.1) Custom RAR tools are permitted. However, files must adhere to ³
  642. ³ the RAR4/RARv2.9 archive specification and must retain identical ³
  643. ³ compatibility with extractors and demuxers as files created with ³
  644. ³ WinRAR/rar. ³
  645. ³ 12.3) Permitted RAR sizes are: ³
  646. ³ 12.3.1) 15,000,000 bytes or 20,000,000 bytes for SD. Multiples of these ³
  647. ³ values are not allowed. ³
  648. ³ 12.3.2) Positive integer multiples of 50,000,000 bytes for all ³
  649. ³ resolutions. ³
  650. ³ e.g. (50 * 10^6) * n bytes, where n > 0. ³
  651. ³ (50 * 10^6) * 4 bytes, 100,000,000 bytes, ³
  652. ³ 400,000,000 bytes, etc. ³
  653. ³ 12.3.3) Releases must have a minimum of 10 volumes before the next ³
  654. ³ multiple of 50,000,000 bytes is used. ³
  655. ³ e.g. 10 volumes at 50,000,000 bytes can be repackaged to 5 ³
  656. ³ volumes at 100,000,000 bytes. ³
  657. ³ 5 volumes at 100,000,000 bytes cannot be repacked to 4 ³
  658. ³ volumes at 150,000,000 bytes. ³
  659. ³ 12.4) Must have SFV and NFO. ³
  660. ³ 12.5) RAR, SFV, and Sample files must have unique, lower-case filenames ³
  661. ³ with the group tag. ³
  662. ³ 12.5.1) Group tags must be unique to each group, and may be an ³
  663. ³ abbreviated variation of the group name. ³
  664. ³ 12.6) Missing RAR(s) or SFV on all sites is considered a technical flaw. ³
  665. ³ 12.7) Corrupt RAR(s) (errors upon extraction) is considered a technical ³
  666. ³ flaw. ³
  667. ³ 12.8) RAR compression and recovery records are not allowed. ³
  668. ³ 12.9) Encryption or password protection is not allowed. ³
  669. ³ ³
  670. ³ 13) [ Proof ] ³
  671. ³ 13.1) Proof picture(s) must have unique filenames and placed in a separate ³
  672. ³ directory named 'Proof'. ³
  673. ³ 13.1.1) Proof file(s) must be included in every release which requires ³
  674. ³ proof. ³
  675. ³ 13.2) Proof must be in JPEG or PNG format. ³
  676. ³ 13.3) Proof is required for iTunes sourced files only. A screenshot of ³
  677. ³ the download in progress must be provided. ³
  678. ³ 13.3.1) A release which fails to pre with the required proof is ³
  679. ³ considered a technical flaw and can be propered. ³
  680. ³ 13.3.2) Proof fixes must be within 24 hours of original pre. Fixes ³
  681. ³ provided after a proper has been released, or after 24 hours has ³
  682. ³ elapsed from the original pre, will not be accepted. ³
  683. ³ 13.3.3) It is also recommended, in an unobstructed way, to include the ³
  684. ³ group name within the screenshot written in Notepad or a similar ³
  685. ³ text editor. ³
  686. ³ 13.4) Releases which include retail-sourced elements (e.g. retail ³
  687. ³ subtitles) must include source proof. ³
  688. ³ 13.4.1) Proof must be photographs of the printed side of all physical ³
  689. ³ discs used with the group tag clearly visible. ³
  690. ³ 13.4.2) The minimum resolution for photographs is 640x480px. Disc details ³
  691. ³ must be clear and legible. ³
  692. ³ 13.5) Small identifiable or sensitive information may be obscured or ³
  693. ³ redacted. ³
  694. ³ 13.6) User identifiable EXIF data must be stripped. It is recommended all ³
  695. ³ EXIF data be stripped. ³
  696. ³ ³
  697. ³ 14) [ Samples ] ³
  698. ³ 14.1) All releases must include a 50-70 second sample for each release. ³
  699. ³ 14.2) Samples must have unique filenames and placed in a separate ³
  700. ³ directory named 'Sample'. ³
  701. ³ 14.3) Samples must be cut from the final video, not encoded separately. ³
  702. ³ ³
  703. ³ 15) [ NFO ] ³
  704. ³ 15.1) NFO must be present in every release. ³
  705. ³ 15.2) It is recommended, but optional, to include the following ³
  706. ³ information in the NFO: ³
  707. ³ 15.2.1) Release name and group. ³
  708. ³ 15.2.2) Title and release date. ³
  709. ³ 15.2.3) CRF value / bitrate used. ³
  710. ³ 15.2.4) Audio format. ³
  711. ³ 15.2.5) Source. ³
  712. ³ 15.2.6) Relevant IMDB/TVDB/Amazon link. ³
  713. ³ 15.2.7) Total video size or RAR count. ³
  714. ³ 15.3) It is optional, but highly recommended, that the source for ³
  715. ³ untouched files be mentioned in the NFO. ³
  716. ³ ³
  717. ³ 16) [ Tagging ] ³
  718. ³ 16.1) Only the following additional tags are allowed: ³
  719. ³ ALTERNATIVE.CUT, CONVERT, COLORIZED, DC, DIRFIX, DOCU, DUBBED, ³
  720. ³ EXTENDED, FESTIVAL, FINAL, INTERNAL, LIMITED, MULTI, NFOFIX, OM, ³
  721. ³ PPV, PROOFFIX, PROPER, REAL, REMASTERED, READNFO, REPACK, RERIP, ³
  722. ³ SAMPLEFIX, SOURCE.SAMPLE, SUBBED, THEATRICAL, UNCENSORED, UNRATED, ³
  723. ³ UNCUT, and WS. ³
  724. ³ 16.2) Variations of any additional tags are not allowed. ³
  725. ³ e.g. READ.NFO or RNFO is not allowed, READNFO must be used. ³
  726. ³ 16.3) READNFO should be used sparingly. Discretion is recommended. ³
  727. ³ 16.3.1) The READNFO tag must not be used with PROPER, REPACK, or RERIP. ³
  728. ³ The NFO is required to contain a reason, therefore the tag is ³
  729. ³ redundant. ³
  730. ³ 16.4) Tags must only be used once, but the order is left to the discretion ³
  731. ³ of the group. ³
  732. ³ 16.4.1) Except in situations where the REAL tag is required to be stacked ³
  733. ³ to differentiate between multiple invalid releases. ³
  734. ³ e.g. A REAL.REAL.PROPER.REPACK is required for a ³
  735. ³ REAL.PROPER.REPACK and PROPER.REPACK. ³
  736. ³ 16.5) Tags must be grouped together, period-delimited, and must follow the ³
  737. ³ mandatory directory format, see rule 17.4. ³
  738. ³ e.g. EXTENDED.LIMITED, REMASTERED.REPACK, REAL.PROPER. ³
  739. ³ ³
  740. ³ 17) [ Directory Nomenclature ] ³
  741. ³ 17.1) Acceptable characters allowed for directories are: ³
  742. ³ ABCDEFGHIJKLMNOPQRSTUVWXYZ ³
  743. ³ abcdefghijklmnopqrstuvwxyz ³
  744. ³ 0123456789.- ³
  745. ³ 17.2) Single punctuation must be used. Consecutive punctuation is not ³
  746. ³ allowed. ³
  747. ³ e.g. Show----Name.S01E01, Show.Name....S01E01, ³
  748. ³ Show.-.Name.--.S01E01, etc. ³
  749. ³ 17.3) Typos or spelling mistakes in the directory are not allowed. ³
  750. ³ 17.4) Releases must follow the matching directory format: ³
  751. ³ 17.4.1) Movie.YEAR.<TAGS>.[LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  752. ³ 17.4.2) Weekly.TV.Show.SXXEXX[Episode.Part].[Episode.Title].<TAGS>. ³
  753. ³ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  754. ³ 17.4.3) Miniseries.Show.Name.Part.XX.[Episode.Title].<TAGS>. ³
  755. ³ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  756. ³ 17.4.4) Daily.TV.Show.YYYY.MM.DD.[Guest.Name].<TAGS>. ³
  757. ³ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  758. ³ 17.4.5) Daily.Sport.League.YYYY.MM.DD.Event.<TAGS>. ³
  759. ³ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  760. ³ 17.4.6) Monthly.Competition.YYYY.MM.Event.<TAGS>. ³
  761. ³ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  762. ³ 17.4.7) Yearly.Competition.YYYY.Event.<TAGS>. ³
  763. ³ [LANGUAGE].<RESOLUTION>.<FORMAT>-GROUP ³
  764. ³ 17.5) Named directory arguments formatted inside <> must be included. ³
  765. ³ Optional arguments formatted inside [] may be used in some cases. ³
  766. ³ 17.5.1) Episode part refers to episodes, usually cartoons or animation, ³
  767. ³ which split episodes into stories by different directors. ³
  768. ³ Episodes parts must be alphanumeric (a-z, A-Z, 0-9). ³
  769. ³ e.g. The first episode from Season 2 of SpongeBob SquarePants ³
  770. ³ is split into S02E01A/B, etc. https://goo.gl/CVGXKu ³
  771. ³ 17.5.2) Episode title and guest names are optional. ³
  772. ³ 17.5.3) Guest name(s) used must be in the order in which they appear on ³
  773. ³ the show to avoid any confusion. ³
  774. ³ 17.5.4) Tags refers to all permitted tags only, see section 16. ³
  775. ³ 17.5.5) Non-English releases must include the language tag and must be ³
  776. ³ used to denote the language of the audio track. English releases ³
  777. ³ must not include the language tag. ³
  778. ³ 17.5.5.1) Language tags must be the full name of the language. ³
  779. ³ Abbreviations or language codes are not allowed. ³
  780. ³ e.g. FRENCH, RUSSIAN, GERMAN. ³
  781. ³ 17.5.6) Resolution identifiers are only applicable for releases 720p and ³
  782. ³ above, and must precede the format of the release, see section 6 ³
  783. ³ for resolution specifications. ³
  784. ³ e.g. 720p.WEB.H264, 2160p.WEBRip.x264. ³
  785. ³ 17.5.7) Format refers to whether the release is transcoded (WEBRip.x264) ³
  786. ³ or untouched (WEB.H264/WEB.x264). ³
  787. ³ 17.6) Do not indicate source, ripping, or encoding methods that were used. ³
  788. ³ Use the NFO for any technical details. ³
  789. ³ 17.7) All movie releases must include the production year. ³
  790. ³ 17.8) Movie distribution tags (FESTIVAL, LIMITED) must be used with ³
  791. ³ discretion. Use boxofficemojo.com or IMDB screen details as ³
  792. ³ references. ³
  793. ³ 17.9) Different shows with the same title and format produced in different ³
  794. ³ countries must have the ISO 3166-1 alpha 2 country code in the ³
  795. ³ show name. ³
  796. ³ 17.9.1) Except for UK shows, which should use UK, not GB. ³
  797. ³ 17.9.2) This rule does not apply to an original show, only shows that ³
  798. ³ precede the original with the same premise or format. ³
  799. ³ e.g. The.Office.S01E01 and The.Office.US.S01E01. ³
  800. ³ 17.10) Different shows with the same title produced in the same country ³
  801. ³ which begin in different years must have the year of the first ³
  802. ³ season in the directory. ³
  803. ³ 17.10.1) The year is not required for the show broadcasted first. ³
  804. ³ e.g. Second.Chance.S01E01 and Second.Chance.2016.S01E01. ³
  805. ³ 17.11) Different shows with the same titles produced in the same country ³
  806. ³ which begin in different years must have the ISO-3166-1 alpha 2 ³
  807. ³ country code followed by the year of the first season in the ³
  808. ³ directory. ³
  809. ³ 17.11.1) See rules 17.12 and 17.13 for country code and year ³
  810. ³ explanations. ³
  811. ³ e.g. Wanted.S01E01 (2005), Wanted.AU.S01E01 (2013), ³
  812. ³ Wanted.AU.2016.S01E01 (2016). ³
  813. ³ 17.12) Show names which are hyphenated or include punctuation must follow ³
  814. ³ the format shown in the title sequence or credits of the first ³
  815. ³ episode congruent to the list of acceptable characters. ³
  816. ³ 17.12.1) If no title card exists, the format listed on the official ³
  817. ³ website for the show must be used, followed by what is listed ³
  818. ³ by the streaming service. ³
  819. ³ 17.12.2) Additional titles and names given to an individual season must ³
  820. ³ not be used. ³
  821. ³ e.g. Archer.Vice.S05, Strike.Back.Legacy.S05. ³
  822. ³ 17.13) Directory nomenclature and numbering must remain consistent ³
  823. ³ across the lifetime of an individual show or event. ³
  824. ³ 17.13.1) Shows which contain acronyms or secondary titles must follow the ³
  825. ³ format used by the first release. ³
  826. ³ e.g. Law.and.Order.SVU.S01E01 is the standard format that must ³
  827. ³ be used for all following episodes, ³
  828. ³ Law.and.Order.Special.Victims.Unit.S01E02 is not allowed. ³
  829. ³ Shadowhunters.The.Mortal.Instruments.S01E01 is the ³
  830. ³ standard format, Shadowhunters.S01E02 is not allowed. ³
  831. ³ 17.13.2) Groups cannot change the directory format of a show after a ³
  832. ³ second release or episode with the same format exists. ³
  833. ³ e.g. 2016-01-01: Law.and.Order.SVU.S01E01 sets the format. ³
  834. ³ 2016-01-08: Law.and.Order.SVU.S01E02 continues the format. ³
  835. ³ 2016-01-09: Law.and.Order.Special.Victims.Unit.S01E01. ³
  836. ³ DIRFIX is not valid as the second episode already exists ³
  837. ³ and continues with the previously defined format. ³
  838. ³ 17.13.3) Except in situations where the show has an official change in ³
  839. ³ its name, whereby all official references by the broadcaster or ³
  840. ³ studio is of the new name. This change must be mentioned in the ³
  841. ³ first NFO with the new name with relevant references. ³
  842. ³ e.g. Gold.Rush.Alaska.S01E01 changed to Gold.Rush.S02E01. ³
  843. ³ 17.13.4) Official name changes for a show does not include the renaming ³
  844. ³ of individual seasons. Seasonal name changes must be ignored. ³
  845. ³ e.g. Power.Rangers.S01 and Power.Ranges.S07 must be used. ³
  846. ³ Power.Rangers.Lost.Galaxy.S07 must not be used. ³
  847. ³ Strike.Back.S03, Strike.Back.S05 must be used. ³
  848. ³ Strike.Back.Vengeance.S03, Strike.Back.Legacy.S05 must ³
  849. ³ not be used. ³
  850. ³ 17.13.5) Any deviations or changes require sufficient evidence listed in ³
  851. ³ the NFO as to the reason for change. ³
  852. ³ 17.14) For shows which begin on network television and continue ³
  853. ³ exclusively on a web-based service, the title or numbering of the ³
  854. ³ show shall not change. ³
  855. ³ 17.14.1) Except in situations where the show is not a direct continuation ³
  856. ³ of the previous seasons. ³
  857. ³ 17.14.2) If the show continues without any changes, the title of the show ³
  858. ³ shall not change, but will follow the season and episode ³
  859. ³ numbering as listed on the web-based service which purchased ³
  860. ³ the show. ³
  861. ³ 17.15) User contributed services such as TVRage, TVMaze, or TheTVDB must ³
  862. ³ not be used as a reference when naming and numbering episodes. It ³
  863. ³ may be used as a general guide; however, official guides must be ³
  864. ³ used. ³
  865. ³ 17.15.1) The following order must be used as the primary source for ³
  866. ³ naming and numbering. ³
  867. ³ 17.15.1.1) Official website of the show. ³
  868. ³ 17.15.1.2) Order and format listed by the streaming service. ³
  869. ³ 17.15.1.3) Network guide. ³
  870. ³ ³
  871. ³ 18) [ Fixes ] ³
  872. ³ 18.1) Only the following fixes are allowed: ³
  873. ³ DIRFIX, NFOFIX, PROOFFIX, and SAMPLEFIX. ³
  874. ³ 18.2) Any other form of fix is not allowed. ³
  875. ³ e.g. RARFIX, SFVFIX, SUBFIX, etc. ³
  876. ³ 18.3) All fixes require an NFO and must state which release is being ³
  877. ³ fixed. ³
  878. ³ 18.4) A proper may not be released for an error that can be fixed with ³
  879. ³ the above methods, with the exception of proof fixes, see rule ³
  880. ³ 13.3.2. ³
  881. ³ 18.5) If multiple releases from a single season require a DIRFIX, a single ³
  882. ³ DIRFIX per season is allowed and is recommended. ³
  883. ³ e.g. Show.Name.S01.DIRFIX.WEBRip.x264-GROUP. ³
  884. ³ 18.5.1) If a single DIRFIX is used, all relevant releases and ³
  885. ³ corresponding fixes must be listed in the NFO. ³
  886. ³ ³
  887. ³ 19) [ Dupes ] ³
  888. ³ 19.1) Same second releases, with a maximum acceptable variance of two ³
  889. ³ seconds (+/- 2 seconds) between timestamps reported by a majority ³
  890. ³ of pre bots, are not considered dupes and should not be nuked. ³
  891. ³ 19.1.1) Timestamps must be considered as whole integers and round half ³
  892. ³ towards zero. ³
  893. ³ 19.1.2) The earliest timestamp must be used when considering dupes. ³
  894. ³ e.g. Release A: 1451572201.427158 -> 1451572201 ³
  895. ³ Release B: 1451572203.626645 -> 1451572203 ³
  896. ³ Release C: 1451572204.137665 -> 1451572204 ³
  897. ³ Release B does not dupe Release A: 1451572203 - 1451572201 ³
  898. ³ = 2, i.e. maximum variance allowed. ³
  899. ³ Release C dupes Releases A and B: 1451572204 - 1451572201 ³
  900. ³ = 3, i.e. 3 > 2. ³
  901. ³ 19.1.3) In situations where a release is found to contain a technical ³
  902. ³ flaw, same second dupes which do not exhibit any technical flaws ³
  903. ³ must be considered the final release. Groups may release a DIRFIX ³
  904. ³ to PROPER for their original release, but it is not required. ³
  905. ³ e.g. Release A and Release B are released at the same time. ³
  906. ³ Release A is nuked as containing glitches, Release B then ³
  907. ³ becomes the de facto release and a DIRFIX to PROPER may be ³
  908. ³ released. ³
  909. ³ 19.2) WEBRip.x264 dupes WEB.H264/x264. ³
  910. ³ 19.3) WEB.H264/x264 does not dupe WEBRip.x264. ³
  911. ³ 19.4) WEB.H264/x264 and WEBRip.x264 does not dupe DSR/PDTV. ³
  912. ³ 19.5) WEB.H264/x264 and WEBRip.x264 dupes an equivalent AHDTV/HDTV/Retail ³
  913. ³ release. ³
  914. ³ 19.5.1) SD WEB.H264/x264 and WEBRip.x264 dupes an SD AHDTV/HDTV/Retail ³
  915. ³ release. ³
  916. ³ 19.5.2) 720p, 1080p, 2160p WEB.H264/WEB.x264 and WEBRip.x264 dupes a ³
  917. ³ respective AHDTV/HDTV/Retail release. ³
  918. ³ e.g. 720p.WEB.H264 dupes 720p.HDTV.x264, 1080p.WEBRip.x264 ³
  919. ³ dupes 1080p.AHDTV.x264. ³
  920. ³ 1080p.WEB.H264 does not dupe 720p.BluRay.x264 if ³
  921. ³ 1080p.BluRay.x264 does not exist. ³
  922. ³ 19.5.3) Except in situations where the aspect ratio of a ³
  923. ³ WEB.H264/x264 and WEBRip.x264 release exceeds that of its ³
  924. ³ respective AHDTV/HDTV/Retail release. ³
  925. ³ e.g. A 2.39:1 release will not dupe a 1.78:1 retail provided ³
  926. ³ there is clearly more footage visible on-screen. Proof ³
  927. ³ demonstrating this difference is recommended, but not ³
  928. ³ mandatory. ³
  929. ³ 19.5.4) Except in situations where a WEB.H264/x264 or WEBRip.x264 release ³
  930. ³ is an uncensored or extended edit of its respective ³
  931. ³ AHDTV/HDTV/Retail release. ³
  932. ³ e.g. An uncensored WEB.H264 release does not dupe HDTV.x264, ³
  933. ³ EXTENDED.WEBRip.x264 does not dupe BluRay.x264. ³
  934. ³ 19.6) Releases with hardcoded subtitles (i.e. SUBBED) dupes releases with ³
  935. ³ muxed-in subtitles. ³
  936. ³ 19.7) Releases with muxed-in subtitles do not dupe releases with hardcoded ³
  937. ³ subtitles. ³
  938. ³ 19.8) Native video streams do not dupe converted video streams. ³
  939. ³ 19.9) Converted video streams dupe native video streams. ³
  940. ³ ³
  941. ³ 20) [ Propers / Rerips / Repacks ] ³
  942. ³ 20.1) Detailed reasons must be included in the NFO for all repacks, ³
  943. ³ rerips, and propers. ³
  944. ³ 20.1.1) Proper reasons must be clearly stated in the NFO, including ³
  945. ³ timestamps and specifics in regards to the flaw when appropriate. ³
  946. ³ A sample demonstrating the flaw in the original release is ³
  947. ³ encouraged, but not mandatory. ³
  948. ³ 20.2) Propers are only permitted in the case of a technical flaw in the ³
  949. ³ original release. ³
  950. ³ 20.3) If fixing a technical flaw requires transcoding of the file, it must ³
  951. ³ follow the transcoding rules and tagged as WEBRip.x264. ³
  952. ³ 20.4) Transcoded releases cannot proper any untouched files. ³
  953. ³ e.g. WEBRip.x264 cannot proper WEB.H264. ³
  954. ³ 20.4.1) Unless it is a transcode of a lossless stream correcting the ³
  955. ³ technical flaw, see rule 1.4. ³
  956. ³ 20.4.2) Unless it can be proven that all untouched sources are flawed ³
  957. ³ which cannot be repaired by transcoding, but a WEBRip does not ³
  958. ³ exhibit the same technical flaw(s). ³
  959. ³ e.g. iTunes, Amazon, and Netflix only offer the content. Amazon ³
  960. ³ and iTunes sourced files cannot be repaired by transcoding, ³
  961. ³ however a Netflix WEBRip is fine. ³
  962. ³ 20.5) Untouched files can proper transcoded releases for any valid ³
  963. ³ technical flaw. ³
  964. ³ 20.6) Audio or visual glitches can be propered with a release which does ³
  965. ³ not exhibit the same flaw. ³
  966. ³ 20.6.1) In situations where mastering issues results in visual or audio ³
  967. ³ glitches, a release must not be nuked until a valid proper, ³
  968. ³ repack, or rerip using a glitch-free source or master is ³
  969. ³ released. ³
  970. ³ 20.7) RERIP must be used for ripping or encoding issues. ³
  971. ³ 20.8) REPACK must be used for packing or muxing issues. ³
  972. ³ 20.9) Propers are only valid for releases with timestamps after the ³
  973. ³ official start date of this ruleset. ³
  974. ³ 20.9.1) Groups cannot proper existing releases using rules created as a ³
  975. ³ result of this ruleset. ³
  976. ³ e.g. If the resolution is not mod 2 or x264 revision used is ³
  977. ³ older than 50 revisions at the time of pre, the release ³
  978. ³ cannot be nuked. ³
  979. ³ 20.9.2) With exceptions of a release containing technical flaws which ³
  980. ³ would apply to any ruleset regardless of section. e.g. bad IVTC, ³
  981. ³ sync issues, bad or invalid cropping, etc. ³
  982. ³ ³
  983. ³ 21) [ Internals ] ³
  984. ³ 21.1) Internals are allowed to be released for any reason, including, but ³
  985. ³ not limited to: releases containing technical flaws, use of ³
  986. ³ alternate codecs, containers, or settings for experimental purposes. ³
  987. ³ 21.2) Any severe technical flaws must be mentioned in the NFO. ³
  988. ³ 21.3) Internal releases may only be nuked for technical flaws that are not ³
  989. ³ mentioned in the NFO. ³
  990. ³ 21.3.1) In situations where technical flaws are not mentioned in the NFO, ³
  991. ³ groups may provide an NFOFIX to avoid or reverse a nuke. ³
  992. ³ 21.4) Using DIRFIX.INTERNAL to avoid a nuke is not allowed, and must be ³
  993. ³ nuked fix.for.nuke. ³
  994. ³ ³
  995. ³ 22) [ Ruleset Specifics ] ³
  996. ³ 22.1) This ruleset is to be considered the ONLY official ruleset in ³
  997. ³ regards to WEB and WEBRip releases. It supersedes all previous ³
  998. ³ rules and precedents derived from existing TV and Retail rules in ³
  999. ³ regards to WEB sources. ³
  1000. ³ 22.2) Rules listed under untouched or transcoded labelled sections only ³
  1001. ³ apply to releases of that type and supersede any similar rule ³
  1002. ³ mentioned elsewhere. ³
  1003. ³ e.g. Rule 6.1 defines SD as resolutions with a maximum horizontal ³
  1004. ³ display of 720 pixels, unless the release is considered ³
  1005. ³ untouched, in which case rule 1.6 applies. ³
  1006. ³ 22.3) If there is a question as to the validity of a source used, the ³
  1007. ³ release may be nuked within 24 hours of pre requesting a source ³
  1008. ³ sample and must include the initial suspicion or reason. ³
  1009. ³ e.g. source.sample.requested_suspicion.of.invalid.decimation. ³
  1010. ³ 22.3.1) The group has 24 hours from the first nuke to pre a source ³
  1011. ³ sample that is at least 10 seconds in length. ³
  1012. ³ 22.3.2) Source samples must be packed with RAR files, and use the ³
  1013. ³ SOURCE.SAMPLE tag. ³
  1014. ³ 22.3.3) Providing insufficient proof to disprove any claims, or a ³
  1015. ³ failure to provide any source proof, and the release must remain ³
  1016. ³ nuked and can be propered. ³
  1017. ³ 22.4) The following definition of keywords throughout this ruleset are as ³
  1018. ³ follows: ³
  1019. ³ 22.4.1) Must: the rule is explicit in the definition and is compulsory. ³
  1020. ³ 22.4.2) Should: implies the rule is a suggestion, and is non-compulsory. ³
  1021. ³ 22.4.3) Can or may: implies the rule is optional, and is non-compulsory. ³
  1022. ³ ³
  1023. ³ 23) [ Notes ] ³
  1024. ³ 23.1) Proof is only enforced for iTunes as all other sources require ³
  1025. ³ various unofficial (backdoor) methods of downloading. Creating a ³
  1026. ³ fake GUI showing an active download is not difficult, which could ³
  1027. ³ result in proof being fabricated. As such, it is pointless to ³
  1028. ³ require proof for anything but iTunes, where streams can only be ³
  1029. ³ downloaded by a single method. ³
  1030. ³ 23.1.1) This includes web stores or shops which provide video files via a ³
  1031. ³ regular HTTP download. Policing or moderating these methods would ³
  1032. ³ be implausible for a single ruleset. Providing screenshots of a ³
  1033. ³ download in progress from a website does not prove the file was ³
  1034. ³ obtained from an official source. ³
  1035. ³ 23.2) The burden of proving P2P source material is on the propering group ³
  1036. ³ or nuker. ³
  1037. ³ 23.3) The inclusion of 2-pass in this ruleset should not be misconstrued ³
  1038. ³ as preferring it for every release, CRF must always be considered ³
  1039. ³ the primary method. Instead, it is encouraged for groups to use ³
  1040. ³ 2-pass methods for rare cases when files provided are of extreme ³
  1041. ³ high quality. ³
  1042. ³ 23.3.1) Video which contains an excessive amount of noise may often ³
  1043. ³ result in an unnecessary large bitrate. In such situations, ³
  1044. ³ using a smaller bitrate using 2-pass can result in a file size ³
  1045. ³ improvement with negligible loss in video quality. ³
  1046. ³ ³
  1047. ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  1048. ³ ³
  1049. ³ [ Signed ] ³
  1050. ³ ³
  1051. ³ 2HD AEROHOLiCS ALTEREGO AZR AMB3R ANiHLS ANiURL BARGE BATV BiQ C4TV ³
  1052. ³ CHAMPiONS DEADPOOL DEFEATER DEFLATE DRAWER FADE FaiLED FiHTV FQM ³
  1053. ³ GORE HatchetGear iBlade KOENiG KYR Ltu NTROPiC QCF REGRET RiVER RPTV ³
  1054. ³ SH0W SiGeRiS SKGTV spamTV TASTETV TiMELiNE WaLMaRT W4F WNN ZOMBiE ³
  1055. ³ ³
  1056. ³ [ Refused to sign ] ³
  1057. ³ ³
  1058. ³ CBFM ³
  1059. ³ ³
  1060. ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  1061. ³ ³
  1062. ³ [ Revisions ] ³
  1063. ³ 2016-03-16 - ecb63c67 - Final commit and public release of ruleset. ³
  1064. ³ ³
  1065. ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!