Details for "The.SD.TV.x264.Releasing

Uploaded2016-04-03 16:15:28
Size190.48 kB
Real NFOShow the real NFO
The SD TV x264 Releasing Standards 2016 a.k.a. sdtvx264
[ Intro ]
Since the last revision of this document in 2012, TV-X264-SD has grown
and become a major section that many people contribute to and depend on.
This new revision aims to update the standards from 2012 to standards
suitable for 2016 and the future. Adding clarity and patching loopholes
to once again allow for consistent and quality releases, which was the
aim of this standard back in 2012.
Compliance with this document is optional as of its pre date, and
mandatory as of 2016-04-10 00:00:00 UTC (1460246400 Unix time).
[ Recommended ]
It is recommended to view the unformatted version of this ruleset
bundled within this release.
1) [ HDTV Sources ]
1.1) HDTV is considered as a high definition natively recorded transport
1.2) HDTV sources must not be upscaled, see section 2.
1.3) Providers which downscale 1080i to 720p (e.g. BellTV) are not
2) [ PDTV DSR Sources ]
2.1) PDTV is considered as a 576i/576p natively recorded transport
2.2) DSR is considered as a 480i/480p natively recorded transport
3) [ AHDTV APDTV ADSR Sources ]
3.1) AHDTV, APDTV and ADSR are considered as captured streams from the
analog output (e.g. Component, DVI, HDMI) of a set-top box.
3.2) Captures must be done at the native broadcast format of the source.
3.2.1) Captures from devices which are unable to output a native format
must be restored to the original framerate.
3.2.2) If captures cannot be completely restored to their native
framerate, such as a single dupe frame every 1000 or blended/ghost
frames due to mangling from the set-top box or capture device,
this is considered a technical flaw.
4) [ Codec ]
4.1) Video must be H.264/MPEG-4 AVC encoded with x264 8-bit.
4.1.1) Custom builds of x264 (e.g. x264-tMod, x264-kMod) are allowed and
must be based off the x264 codebase.
4.2) x264 headers must remain intact and must not be modified or removed.
4.3) x264 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
4.3.1) The official x264 git repository is the only reference for
determining the current revision:;asummary
4.3.2) The 60 day grace period must only be applied at pre time, not the
tagged encoded date.
4.3.3) The grace period is only applicable to the revision preceding the
latest update and does not reset active grace periods of preceding
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) Constant Rate Factor (--crf) must be used.
4.4.1) CRF values below 19 and above 24 are never allowed.
4.4.2) Justification must be listed in the NFO for the use of
non-standard CRF values. Groups are not required to follow non-standard CRF values used
by another group. It is suggested that if the average video bitrate exceeds
1500kb/s, a higher CRF value should be chosen, when possible.
4.5) Standard CRF values are as follows:
Compressibility CRF General Examples
High 19-20 Scripted, Talk Shows, Animation, Stand-Up
Medium 21-22 Documentary, Reality, Variety, Poker
Low 23-24 Sports, Awards, Live Events
4.6) Settings cannot go below what is specified by preset (--preset)
e.g. --subme 7 or --me hex are not allowed.
4.7) Level (--level) must be 3.1.
4.8) Colour matrix (--colormatrix) must be set.
4.8.1) bt709 must be used for encodes from HDTV or AHDTV sources.
4.8.2) Source specification must be used for PDTV, APDTV, DSR, ADSR
sources. undef must be used if not specified by the source.
4.9) Colour space (--output-csp) must be i420 (4:2:0).
4.10) Sample aspect ratio (--sar) must be 1:1 (square).
4.11) Deblocking (--deblock) must be used. Values used are left to the
discretion of the group.
4.12) Keyframe interval (--keyint) must be at least 200, and at most 300.
4.12.1) It is recommended to let x264 decide which value to use, but
10*framerate is a good guideline (e.g. Film240, PAL250,
4.12.2) For 50 or 60 FPS content, the maximum keyframe interval must be
at least 200, and at most 600.
4.13) Minimum GOP length (--minkeyint) must be 30 or less.
4.13.1) It is recommended to let x264 decide which value to use, but
1*framerate is a good guideline (e.g. Film24, PAL25, NTSC30).
4.13.2) For 50 or 60 FPS content, values of 60 or less must be used for
the minimum GOP length.
4.14) Custom matrices are not allowed.
4.15) Zones (--zones) are not allowed.
4.16) x264 parameters must not vary within a release.
4.17) Optional tuning (--tune) parameters allowed are: film, grain
or animation.
4.18) Suggested command line:
x264 --crf ## --preset slow --level 3.1 --colormatrix ## --output
out.mkv in.avs
5) [ Video / Resolution ]
5.1) Resolution must be mod 2.
5.2) Upscaling is not allowed.
5.3) Adding borders is not allowed.
5.4) Multiple video tracks are not allowed.
5.5) English spoken titles with foreign overlays, not intended by content
creators (e.g. locations, on-screen text shown in another language)
are not allowed, use INTERNAL.
5.5.1) This does not apply to opening titles or credits, but to relevant
show content only.
5.6) Non-English spoken titles with hardcoded English subtitles must be
tagged as SUBBED.
5.6.1) English spoken titles with hardcoded English subtitles present
for English spoken scenes must be tagged as SUBBED.
5.6.2) English spoken titles with hardcoded Non-English subtitles present
for English spoken scenes are not allowed, use INTERNAL.
5.6.3) Hardcoded subtitles added by content creators are exempt (e.g.
Alien hardsubs, drunk talk hardsubs, hardsubs due to muffled
5.7) Dupes based on resolution are not allowed.
5.7.1) Except in situations of releases with a different aspect ratio.
The relevant tag must be used, and the reason mentioned in the
5.7.2) Releases which contain at least an additional 20 pixels worth of
video on any side are not considered dupes. These releases must
be tagged as WS or OM (open matte) and not proper, and the
original release must not be nuked.
5.8) Black borders and anything (e.g. coloured borders, duplicate lines,
dirty pixels, full-time tickers) that is not part of the video must
be cropped.
5.8.1) Retention or removal of faded edges is left to the discretion of
the group. Inclusion of faded edges is not a technical flaw, and
cannot be propered. Faded edges refer to a line of pixels which are of similar
appearance to pixels parallel to the video frame.
5.8.2) In the case of varying aspect ratios throughout the video,
cropping must be done to the most common frame size (e.g. primary
view of the pitch during sports, studio view during talk shows).
5.8.3) Cropping of letterboxed sources with hardcoded subtitles
positioned within the black borders is left to the discretion of
the group. Video may be left uncropped or cropped evenly both
top and bottom to the widest frame without removing any subtitles. Cropping out hardcoded subtitles entirely is allowed, only
when they are not required, leaving any trace of subtitles or
over-cropping actual picture to remove subtitles is considered
to be a technical flaw.
5.8.4) Video may be over or under cropped by a maximum of 1px per side.
Over or under cropping by more than 1px per side is considered a
technical flaw.
5.9) HDTV and PDTV sources with a greater than 720px width after crop
must be resized to 720px width and a height which maintains a valid
5.10) PDTV sources must be cropped and resized to fit within a maximum
resolution of:
5.10.1) 720x for sources with a width between 720-705px (inclusive)
after crop, only the height may resized to maintain a valid AR.
e.g. 720x576 -- Crop(2,0,-2,-0) -- 716x576 (non-anamorphic)
-- 716x404 (anamorphic)
5.10.2) 704x528 for sources with a width of 704px or less after crop.
e.g. 704x576 -- Crop(0,4,-0,-4) -- 704x568 (non-anamorphic)
-- 704x392 (anamorphic)
544x576 -- Crop(4,0,-4,0) -- 536x576 (non-anamorphic)
-- 702x386 (anamorphic)
5.11) DSR sources must be cropped and resized to fit within a maximum
resolution of:
5.11.1) 720x for sources with a width greater than 720px after crop,
only the height may resized to maintain a valid AR.
e.g. 853x480 -- Crop(0,2,-0,-0) -- 853x478 -- 720x404
5.11.2) 640x for sources with a width between 720-641px (inclusive)
after crop, only the height may resized to maintain a valid AR.
e.g. 720x480 -- Crop(8,2,-16,-0) -- 696x478 (non-anamorphic)
-- 616x478 (anamorphic)
5.11.3) 640x480 for sources with a width of 640x or less after crop.
e.g. 528x480 -- Crop(0,56,-0,-60) -- 528x364 (non-anamorphic)
-- 640x364 (anamorphic)
5.12) Resized video must be within 0.5 of the original aspect ratio.
Original AR (SourceWidth [CropLeft + CropRight]) /
(SourceHeight [CropTop + CropBottom])
Release AR EncodeWidth / EncodedHeight
AR Error [(Original AR Release AR) / Original AR] * 100
Target resolution when resizing to maintain mod2 and reduce AR
TargetHeight TargetWidth / [(SourceWidth
[CropLeft + CropRight]) / (SourceHeight
[CropTop + CropBottom])]
The correct mod 2 value can also be calculated from the ceiling of
TargetHeight if the value is odd, and the floor of TargetHeight if
the value is even.
6) [ Filters ]
6.1) IVTC or deinterlacing must be applied as required.
6.2) Only smart deinterlacers, such as Yadif or QTGMC, must be used.
6.2.1) FieldDeinterlace must not be used for deinterlacing.
6.3) Only accurate field matching filters, such as TIVTC or Decomb, must
be used for inverse telecining (IVTC).
6.3.1) Filters included in MEncoder, MJPEG tools, libav, libavcodec or
FFmpeg must not be used for IVTC.
6.3.2) Deinterlacing filters must not be applied to telecined sources
as a method of inverse telecine.
6.4) Only sharp resizers, such as Spline36Resize, BlackmanResize or
LanczosResize/Lanczos4Resize, must be used.
6.4.1) Simple resizers, such as Bicubic, PointResize or Simple, are not
7) [ Framerate ]
7.1) Constant frame rate (CFR) must be used.
7.1.1) Variable frame rate (VFR) methods are not allowed.
7.2) True 50 / 60 FPS video must be released at 50 / 60 FPS. True 25 /
30 FPS video released at 50 / 60 FPS is not allowed and considered a
technical flaw.
7.2.1) Failure to apply a deinterlacer with bobbing enabled (e.g. QTGMC,
Yadif(mode1)) to double framerate (bob) 25i / 30i video back to
true 50 / 60 FPS, is considered a technical flaw.
7.2.2) In cases of varying framerates of 25 / 30 FPS and true 50 / 60
FPS, the framerate of the main feature must be used (e.g. studio
for talk shows, game coverage for sports).
7.2.3) In rare situations, 25 / 50 FPS sources must be restored to 24 or
30 FPS.
7.2.4) In rare situations, 30 / 60 FPS sources must be restored to 25
7.3) Sources which contain footage at varying FPS throughout (hybrid
sources) and may or may not require IVTC is left to the discretion
of the group. The NFO must list a reason as to the final decision.
7.3.1) It is assumed that the majority of a title contains enough unique
frames at 30,000/1,001 FPS to warrant a higher framerate. If it
can be proven IVTC/decimating does not result in any loss of
unique frames, this is considered a technical flaw.
7.4) Native and converted framerates refers to the standard in which the
video was produced.
7.4.1) NTSC produced video is native to NTSC.
7.4.2) PAL produced video is native to PAL.
7.4.3) NTSC produced video that is broadcast in PAL is considered as
converted video.
7.4.4) PAL produced video that is broadcast in NTSC is considered as
converted video.
7.5) Converted video that has significant abnormalities (e.g. blended
frames, jerky playback due to missing or duplicate frames) due to
the conversion and cannot be reversed to the native format must be
tagged as CONVERT.
7.5.1) Converted video which does not have significant abnormalities do
not require the CONVERT tag and must not be nuked for the
7.6) Dupes based on framerate are not allowed, use INTERNAL.
8) [ Audio ]
8.1) Segmented encoding is not allowed.
8.2) VBR AAC LC (Low Complexity) must be used.
8.2.1) Apple/QAAC, FDK-AAC or Nero must be used. Any other AAC encoders (e.g. FFmpeg, FAAC, MEncoder) are not
8.2.2) Quality based VBR encoding must be used, targeted or constrained
VBR must not be used. Only the following methods are allowed (in
order of preference): QAAC: --tvbr 82 --quality 2 FDK-AAC: --bitrate-mode 4 --profile 2 Nero: -q 0.4
8.2.3) AAC audio must be normalised to the maximum gain. Normalisation
must be a complete 2-pass method. No pre-defined values or
estimations of maximum gain is allowed. Only the following
normalisation methods are allowed (in order of preference): eac3to: normalize sox: --norm QAAC: --normalize
8.2.4) Any existing normalisation values such as dialnorm in AC3 files,
must be stripped prior to applying normalisation.
e.g. Decoding with eac3to: do not enable -keepDialnorm
Decoding with ffmpeg: enable -drc_scale 0
8.2.5) Audio with more than 2 channels must be down-mixed to stereo.
8.2.6) Audio must not be resampled. Audio must be kept in the original
format as the source (e.g. 48KHz for 48KHz sources).
8.2.7) Audio which is already presented as 2 channel VBR AAC LC by the
broadcaster (e.g. Freeview), may be left as obtained from the
source. Audio which is broadcasted as AAC LATM or LOAS must have the
headers converted to AAC ADTS without transcoding.
8.2.8) Suggested command line:
eac3to in.ac3 stdout.wav -downStereo -normalize qaac --tvbr 82
--quality 2 --ignorelength - -o out.aac
8.3) Multiple language audio tracks are allowed.
8.3.1) The default audio track must be the language intended for release
(e.g. An English release containing English, German and Russian
audio tracks, must have the default flag set on the English
8.3.2) The correct ISO 639 language code supported by MKVToolnix must be
set for all secondary audio tracks, default may be left undefined. In situations where the language is not supported by
MKVToolnix, und must be used.
8.4) If the original language of a title is not English:
8.4.1) An English dubbed track is allowed as a secondary audio track.
8.4.2) Releases containing only a dubbed audio track must be tagged as
8.5) Dupes based on multiple audio tracks or audio format are not allowed,
9) [ Glitches / Missing Footage ]
9.1) Where audio or video issues are unavoidable due to a live-broadcast
or mastering issues, a release must not be nuked until a valid
proper, repack or rerip which does not exhibit the same flaw is
9.2) Scrolling or other alert messages added by the broadcasting station
(e.g. Weather or Amber alerts) appearing for a cumulative total of
at least 30 seconds throughout the entire release is considered a
technical flaw.
9.3) Video frame abnormalities (e.g. Abnormal snipes/pop-ups, banner
advertisements that do not fade out entirely) as a result of broken
splicing originating from the broadcasting station is considered a
technical flaw.
9.4) Missing or repeated video footage without any loss of dialogue must
be at least 2 seconds long at any one instance to be considered a
technical flaw.
9.4.1) Except in situations where on-screen text is lost due to missing
footage. Loss of on-screen text is considered a technical flaw.
9.4.2) Except in situations where minor missing or repeated video
footage flaws are present throughout the majority of the release.
Excessive flaws such as these are considered a technical flaw.
e.g. Video frame glitches occurring every 2 minutes throughout
the entire release but only in the amount of 1 second per
instance, is considered excessive and a technical flaw.
Repeated footage occurring every 5 minutes throughout the
entire release but only in the amount of 1.5 seconds per
instance, is considered excessive and a technical flaw.
Video frame glitches of 1 second per instance occurring 6
times throughout the entire release is NOT considered
excessive or a technical flaw.
9.5) Audio which drifts at least 120ms at a single point or a total of
at least 120ms between multiple points throughout the entire release
is considered a technical flaw.
e.g. Sync drifting +120ms after 10 minutes is considered a
technical flaw.
Sync drifting +80ms after 5 minutes, -40ms after 15 minutes,
for a total of 120ms, is considered a technical flaw.
9.6) Glitches that occur in any audio channel present (e.g. L, R, C, SL,
SR) are considered a technical flaw.
9.6.1) Glitches are defined as, but not limited to: missing dialogue,
repeated dialogue, inability to understand dialogue, bad channel
mix, large gaps within playback, persistent clicks/pops/muted/
echoing/muffled audio.
10) [ Editing / Adjustments ]
10.1) Minor adjustments to video or audio tracks (e.g. duplicating or
removing frames, channel count) in order to prevent issues with
playback or sync is allowed.
10.2) Multi-episode releases with no clear delineation between episodes
(e.g. end credits) must not be split.
10.3) Including previously-on footage is optional, but recommended.
10.4) Including upcoming/teaser/scenes from the next episode footage
found at the conclusion of an episode is optional, but recommended.
10.5) Credits must be included if they contain unique show content.
(e.g. bloopers, outtakes, dialogue, unique uninterrupted
soundtrack, in memory of message)
10.5.1) End credits must only be considered optional if they do not
contain unique show content (e.g. regular plain credits with or
without promos), and may be removed at the discretion of the
10.5.2) A simulcast which does not contain unique content in the credits
cannot be propered from a primary broadcaster which contains
unique content, use EXTENDED.
10.5.3) If a different broadcaster or re-broadcast of a show contains
unique content not present in the original broadcast, the first
release cannot not be propered, use EXTENDED. In situations where a unique uninterrupted soundtrack is the
only additional unique content included in the credits, use
of EXTENDED is not allowed, use INTERNAL. It is recommended, but not required, to include unique
content included in the credits that was omitted from the
original broadcast.
10.6) Inclusion of bumper segments, 5-20 second segments containing
coming up/preview/backstage footage (e.g. SNL, Cops) is optional
and at the discretion of the group.
10.6.1) In situations where bumper segments have been omitted in the
first release, a secondary release which includes all bumper
segments is allowed and must be tagged as UNCUT.
10.6.2) In situations where bumpers are included: All bumper segments must be free of any technical flaws. All bumper segments must be included, missing any bumper
segment is considered a technical flaw.
10.6.3) Small segments containing actual show content, not containing
coming up/preview/backstage footage, are not considered as
bumper segments (e.g. Talking Dead, Comic Book Men, Portlandia).
10.7) Any unrelated video (e.g. commercials, rating cards, viewer/content
warnings), regardless of duration (e.g. 1 faded/half opacity frame
or 10 seconds) must be completely removed.
10.7.1) Content warnings can be retained or removed at the discretion of
the group, except when they are intended by content creators
and must be retained (e.g. Tosh 0, Robot Chicken, South Park,
Law and Order SVU). This does not apply to scripted or animation content. Content
warnings not intended by content creators must always be
removed in these cases. Following the opening segment for non-scripted and
non-animation content, all content warnings which precede
each segment must be removed.
10.7.2) Sponsorship advertisements which are integrated into show
content and cannot be removed (e.g. Jimmy Kimmel, Talking Dead,
Deadliest Catch) are exempt.
10.7.3) Show transition cards appearing at the start or end of segments
on some broadcasters (e.g. Seven, Channel 4, ITV1) can be
retained or removed at the discretion of the group.
10.7.4) Opening and closing interleaves (e.g. HBO opening animation,
... presents, this has been a ... production, ... original
series) can be retained or removed at the discretion of the
group, except when they contain show content and must be
10.8) Any unrelated audio (e.g. alerts, commercials), regardless of
duration (e.g. 100ms or 10 seconds) must be completely removed.
10.8.1) Except when a broadcaster (e.g. ABC) splices unrelated audio
into the beginning of a segment, that does not result in sync
11) [ Subtitles ]
11.1) Subtitles for English spoken titles without foreign dialogue are
optional, but encouraged.
11.2) English spoken titles with foreign dialogue must include a separate
subtitle track for forced subtitles.
11.2.1) Foreign dialogue subtitle tracks must be set as forced and it
is considered a technical flaw if not done correctly.
11.2.2) In situations where the source video stream contains hardcoded
subtitles for English spoken titles with foreign dialogue, a
separate subtitle track for the forced subtitles is not
11.2.3) If a broadcaster which is primarily English spoken (e.g. FOX,
BBC) does not contain hardcoded subtitles for scenes with
foreign dialogue in the video stream, then forced subtitles are
not required but recommended.
11.3) Non-English spoken titles without hardcoded subtitles must include
an English subtitle track set as forced before it is considered to
be an English release.
11.4) Subtitles must be extracted from the original source.
11.4.1) Fan-made or custom subtitles are not allowed.
11.5) Adjustments and edits (e.g. adjusting timecodes, fixing grammar,
spelling, punctuation errors) may be made to subtitle tracks.
11.6) Subtitles must be muxed into the final MKV in text based format,
i.e. SubRip (.srt) or SubStation Alpha (.ssa/.ass).
11.6.1) Subtitles must not be set as default or forced unless otherwise
11.6.2) The correct ISO 639 language code supported by MKVToolnix must
be set for all subtitle tracks. In situations where the language is not supported by
MKVToolnix, und must be used.
11.7) External subtitles located in Subs directories are not allowed.
11.8) Dupes based on subtitles are not allowed, use INTERNAL.
12) [ Container ]
12.1) Container must be Matroska (.mkv). MKVToolnix is the recommended
12.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.
12.2) Support for file streaming and playback from RAR is mandatory.
12.3) Matroska header compression must not be enabled.
12.4) Chapters are allowed, and recommended for long events (e.g. long
poker games to mark each round).
12.5) Watermarks, intros, outros or any other forms of defacement in any
track (e.g. video, audio, subtitles, chapters) are not allowed.
13) [ Packaging ]
13.1) Must be packed with RAR files, broken into a maximum of 101
volumes (.rar to .r99)
13.2) RAR5/RARv5.0 is not allowed. RAR3/RARv2.0 or RAR4/v2.9 must be
13.2.1) Custom RAR tools are allowed. However, files must adhere to the
RAR4/RARv2.9 archive specifications and must retain identical
compatibility with extractors and demuxers as files created with
13.3) Permitted RAR sizes are:
13.3.1) 15,000,000 bytes or 20,000,000 bytes. Multiples of these values
are not allowed.
13.3.2) Positive integer multiples of 50,000,000 bytes.
e.g. (50 * 106) * n bytes, where n 0.
(50 * 106) * 4 bytes, 100,000,000 bytes, 400,000,000
bytes, etc.
13.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.
13.4) SFV and NFO must be present.
13.5) RAR, SFV and Sample files must have unique, lower-case filenames
with the group tag.
13.5.1) Group tags must be unique to each group, and may be an
abbreviated variation of the group name.
13.6) Missing RAR(s) or SFV on all sites is considered a technical flaw.
13.7) Corrupt RAR(s) (errors upon extraction) is considered a technical
13.8) RAR compression and recovery records are not allowed.
13.9) Encryption or password protection is not allowed.
13.10) RARs must only contain a single mkv file, any other files (e.g.
multiple mkv files, txt files) are not allowed.
14) [ Samples / Source Samples ]
14.1) Releases must include a single 50-70 second sample.
14.2) Samples must have unique filenames and placed in a separate
directory named Sample
14.3) Samples must be cut from the final video, not encoded separately.
14.4) 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.
14.4.1) The group has 24 hours from the first nuke to pre a source
sample that is at least 10 seconds in length.
14.4.2) Requests may be of a specific timecode to verify the sample
provided is the same source used for the encode in question
14.4.3) Source sample(s) must be packed as per section 13, and use the
14.4.4) Providing insufficient proof to disprove any claims, or a
failure to provide any source proof, and the release must remain
nuked and can be propered.
14.4.5) If there are any questionable issues (e.g. mastering flaws) with
the source, it is recommended to include uniquely named source
sample(s) within the Sample directory.
15) [ Tagging ]
15.1) Only the following additional tags are allowed:
15.1.1) WEST.FEED refers to an alternative version which airs
exclusively on the west coast, such as a live episode of
Undateable which has two separate performances of the same
episode for each coast, east and west. Releases must be tagged as WEST.FEED when they come from an
exclusive west coast airing, even if no east feed has been
released first.
15.2) Variations of any additional tags are not allowed.
e.g. READ.NFO or RNFO is not allowed, READNFO must be used.
15.3) READNFO should be used sparingly. Discretion is recommended.
15.3.1) The READNFO tag must not be used with PROPER, REPACK or RERIP.
The NFO is required to contain a reason, therefore the tag is
15.4) Tags must only be used once, but the order is left to the
discretion of the group.
15.4.1) Except in situations where the REAL tag is required to be
stacked to differentiate between multiple invalid releases.
e.g. A REAL.REAL.PROPER is required for a REAL.PROPER and
15.5) Tags must be grouped together, period-delimited, and must follow the
mandatory directory format, see rule 16.4.
16) [ Directory Naming ]
16.1) Acceptable characters allowed for directories are:
16.2) Single punctuation must be used. Consecutive punctuation is not
e.g. Show----Name.S01E01, Show.Name....S01E01
16.3) Typos or spelling mistakes in the directory are not allowed.
16.4) Releases must follow the matching directory format:
16.4.1) Single.Episode.Special.YYYY.TAGS.[LANGUAGE].FORMAT-GROUP
16.4.2) Weekly.TV.Show.SXXEXX[Episode.Part].[Episode.Title].
16.4.3) Weekly.TV.Show.Special.SXXE00.Special.Title.
16.4.4) Multiple.Episode.TV.Show.SXXEXX-EXX[Episode.Part].
16.4.5) Miniseries.Show.Name.Part.X.[Episode.Title].
16.4.6) Daily.TV.Show.YYYY.MM.DD.[Guest.Name].
16.4.7) Daily.Sport.League.YYYY.MM.DD.Event.
16.4.8) Monthly.Competition.YYYY.MM.Event.
16.4.9) Yearly.Competition.YYYY.Event.
16.4.10) Sports.Match.YYYY[-YY].Round.XX.Event.[Team.vs.Team].
16.4.11) Sport.Tournament.YYYY.Event.[Team/Person.vs.Team/Person].
16.4.12) Country.YYYY.Event.BROADCASTER.FEED.
16.5) Named directory arguments formatted inside must be included.
Optional arguments formatted inside [] may be used in some cases.
16.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, etc.
16.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, etc.
16.5.3) Episode part refers to episodes, usually cartoons or animation,
which split episodes into stories by different directors.
Episodes parts must be alphanumeric (A-Z, a-z, 0-9).
e.g. The first episode from Season 2 of SpongeBob SquarePants
is split into S02E01A/B, etc.
16.5.4) Season must be omitted if a series does not have seasons, and
is not a mini-series.
e.g. One Piece must be tagged as One.Piece.E01
16.5.5) Episode title and guest names are optional.
16.5.6) Guest name(s) used must be in the order in which they appear on
the show to avoid any confusion.
16.5.7) Non-English releases must include the language tag. English
releases must not include the language tag. Language tags must be the full name of the language.
Abbreviations or language codes are not allowed, unless they
are already established and widely adopted (e.g. EE, SI, PL).
16.5.8) Tags refers to all permitted tags only, see section 15.
16.5.9) Format refers to the video source used, i.e. AHDTV, HDTV,
16.6) Do not indicate source, ripping or encoding methods that were used.
Use the NFO for any technical details.
16.7) All single-episode titles, (e.g. documentaries, specials, movies)
must include the production year.
16.8) Inclusion of the channel name is not allowed.
e.g. National.Geographic, HBO.Documentary, History.Channel.
16.9) Different shows with the same title produced in different countries
must have the ISO 3166-1 alpha 2 country code in the show name.
16.9.1) Except for UK shows, which should use UK, not GB.
16.9.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.
16.10) Different shows with the same title produced in the same country
which begin in different years must have the year of the first
season in the directory.
16.10.1) The year is not required for the show broadcasted first.
e.g. Second.Chance.S01E01 and Second.Chance.2016.S01E01.
16.11) Different shows with the same titles produced in the same country
which begin in different years must have the ISO-3166-1 alpha 2
country code followed by the year of the first season in the
16.11.1) See rules 16.9 and 16.10 for country code and year
e.g. Wanted.S01E01 (2005), Wanted.AU.S01E01 (2013),
Wanted.AU.2016.S01E01 (2016).
16.12) 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.
16.12.1) If no title card exists, see rule 16.14.1.
16.12.2) Additional titles and names given to an individual season must
not be used.
e.g. Archer.Vice.S05, Strike.Back.Legacy.S05.
16.12.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.
16.13) Directory nomenclature and numbering must remain consistent
across the lifetime of an individual show or event.
16.13.1) Shows which contain acronyms or secondary titles must follow
the format used by the first release.
e.g. Law.and.Order.SVU.S01E01 is the standard format that must
be used for all following episodes,
Law.and.Order.Special.Victims.Unit.S01E02 is not allowed.
Shadowhunters.The.Mortal.Instruments.S01E01 is the
standard format, Shadowhunters.S01E02 is not allowed.
16.13.2) Shows which air with extended content under modified names
must use the primary show name and numbering with the
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
16.13.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
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.
16.13.4) Except in situations where the show has an official change in
its name, whereby all official references by the broadcaster
or studio is of the new name. This change must be mentioned in
the first NFO with the new name with relevant references.
e.g. Gold.Rush.Alaska.S01E01 changed to Gold.Rush.S02E01.
16.13.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.
16.13.6) Any deviations or changes require sufficient evidence listed in
the NFO as to the reason for change.
16.14) User contributed services such as TVRage, TVMaze or TheTVDB must
not be used as a reference when naming and numbering episodes. It
may be used as a general guide; however, official guides must be
16.14.1) The following order must be used as the primary source for
naming and numbering. Official website of the show. Order and format listed by the original broadcaster. Network guide.
16.14.2) In situations where official sources have inconsistent
listings, or offer none at all, previously established
numbering must be used
e.g. Mythbusters, National Geographics Special Episodes.
17) [ Fixes ]
17.1) The following fixes are allowed: DIRFIX, NFOFIX and SAMPLEFIX. Any
other form of fix is not allowed.
17.2) All fixes require an NFO and must state which release is being
17.3) A proper cannot be released for an error that can be fixed with
the above methods.
17.4) If multiple releases from a single season require a DIRFIX, a
single DIRFIX per season is allowed and is recommended.
17.4.1) If a single DIRFIX is used, all relevant releases and
corresponding fixes must be listed in the NFO.
18) [ Dupes ]
18.1) Same second releases, with a maximum acceptable variance of one
second (+/- 1 second) between timestamps reported by a majority of
pre bots, are not considered dupes and should not be nuked.
18.1.1) Timestamps must be considered as whole integers and round half
towards zero.
18.1.2) The earliest timestamp must be used when considering dupes.
e.g. Release A: 1451572201.427158 - 1451572201
Release B: 1451572202.626645 - 1451572202
Release C: 1451572203.137665 - 1451572203
Release B does not dupe Release A: 1451572202 1451572201
1, i.e. maximum variance allowed.
Release C dupes Releases A and B: 1451572203 1451572201
2, i.e. 2 1.
18.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
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.
18.2) AHDTV dupes HDTV.
18.3) HDTV does not dupe AHDTV.
18.4) PDTV and APDTV dupes HDTV and AHDTV.
18.5) PDTV does not dupe APDTV.
18.6) DSR and ADSR dupes HDTV, AHDTV, PDTV and APDTV.
18.7) DSR does not dupe ADSR.
18.8) AHDTV, HDTV, PDTV, APDTV, DSR and ADSR dupes an equivalent Retail
18.8.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.
18.8.2) Except in situations where the release is a different version
retail release, and is not censored after uncensored.
e.g. An UNCENSORED.HDTV.x264 release does not dupe a censored
18.9) Releases with hardcoded subtitles (i.e. SUBBED) dupe releases with
muxed-in subtitles.
18.10) Releases with muxed-in subtitles do not dupe releases with
hardcoded subtitles.
18.11) Native video streams do not dupe converted video streams.
18.12) Converted video streams dupe native video streams.
18.13) Different versions of releases (i.e ALTERNATIVE.CUT, COLORIZED,
WEST.FEED, WS) do not dupe their counterparts or vice versa,
except for censored after uncensored and FS after WS.
18.14) Programs which have identical footage but have different narrators
in the same language (e.g. British narrator for BBC and American
narrator for Discovery) dupe each other, use INTERNAL.
18.15) Different broadcasters which offer alternate commentary and
coverage in the same language (e.g. CTV for Canada, NBC for
America, BBC for England) for special worldwide events (e.g. The
Olympics), do not dupe each other.
19) [ Propers / Rerips / Repacks ]
19.1) Detailed reasons must be included in the NFO for all repacks,
rerips and propers.
19.1.1) Proper reasons must be clearly stated in the NFO, including
timestamps and specifics in regards to the flaw when
appropriate. A sample demonstrating the flaw in the original
release is encouraged, but not mandatory.
19.2) Propers are only permitted in the case of a technical flaw in the
original release.
19.2.1) Flaws present in optional content cannot be propered, use
INTERNAL. In situations where bumper segments have been included, see
rule 10.6.2.
19.2.2) Time compressed sources (e.g. ABC, Freeform, NBC) that contain
blended and missing frames cannot be propered for bad IVTC,
which is the result of the time compression.
19.2.3) Releases which exhibit minor IVTC flaws as a result of source
compression, video glitches, logos, ratings bugs, snipes or
banner advertisements, are not considered technically flawed and
cannot be propered. Except in situations where the same flaws result in excessive
frame abnormalities or issues throughout the majority of the
19.3) Qualitative propers are not allowed, use INTERNAL.
19.3.1) Sources with different crops cannot be propered from a different
source which contains more valid pixels than the original
20) [ Interna
Download nfoThe.SD.TV.x264.Releasing.Standards.2016-SDTVx264.nfo
Download NoticeThe.SD.TV.x264.Releasing.Standards.2016-SDTVx264.rar

Comments for "The.SD.TV.x264.Releasing.Standards.2016-..."

No comments yet.

You must login to post a comment!