<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>2010_SDTVX264r.nfo</title>
<style type="text/css">
@font-face {
font-family: nfo;
font-style: normal;
font-weight: normal;
src: url(nfo.eot);
}
.nfo {
padding: 12px;
font-family: nfo, courier new;
font-size: 11px;
line-height: 1em;
}
</style>
</head>
<body>
<pre class="nfo">
██░
███░
███░
███░ ▒░
███░ ███
███░ ▒███░
█▓█ ████
█▓█ ███▓
█▓█ ░█▓█▒
█▓█ ▓█▓█
█▓█ ██▓█
░█▓█ ░█▓█▓
░█▓█ ▒█▓█░
░█▓█ ██▓█
░█▓█ █▓▓▓
███ ▒████
░▒▓▓███████▓▓▓▓█████░
███▓░ ░░░░▒▒▒▒▓▓▓████▓▓▒▒░░
░██▒▒░░▒▒▒▒▒▒░░░░░░░░░░░░▒▓▓▓████████▓░
░▒▓████▓▒ ░░░░░░░░░▒▒▓█████▓░
░▒▓███▓▒░ ░ ░ ░░░░░░▒░░░░░▒▓████▓
░▓███▓▒ ░░▒▓▓▓██████████████████▓▒░░░░▒▒▒▒▒▒▒░░▒▓███▓░
▒███▓░ ░▒▓██████████▓▓▓▓▓▓▓▓██ ░░░▒▒▓█████▓░▒▒▒▒▒░▒░▒▒▒░▒▓██
▒███▒░ ░▒▓████▓▒▒░░ ▒▒▒▒▒▒▒▓▓▓▓▓█ ░ ▒████░░▒░▒▒▒▒▒▒▒▒▒▒ ██
▒█▒░░░ ▒▓████▓▒░ ░░░░▒▒▒██████▓▓▓█░▄▄ ▄▄ ▓██░░▒▓▒▓▓██▓▓▒▒▒░▒▓█░
██░░░░░ ▒████▒░ ░░ ██████░░░▒▒█▓▓█▓▓▓█▓██░ █ ░ █ ██░▒▓▓███▓▓██▓▒▒▒▓▓█▒
██░░░░ ███░ ░░░░░█░ █░░░░░█░░▒█▓▓▓█▓▓▓▓█▓█░ █░ ░ ░█ ██ ▓▓███ ████▒▒▓▓██
██ ░░░ ██░ ░░░░░█░░ █░░░░░█░░▒▓▓▓▓█▓▓▓▓▓██▒░█ ░ █ ██ ▓▓██ █████▒▒▓██
██ ░░░ █▓░░░ ░█░░░ ░█░░░░░█░░▒▓▓▓▓█▓▓▓▓▓▓█▒ █░ ░ ░█ ██░▒▓▓▓▓█████▓░▓▓█░
██ ░░░ █▓░░░ ░█░░░░░░░█░░░░░█░░▓▓▓▓█▓▓▓▓▓██▒ █ ░ ░ █░ █▓░░▒▒▓▓█▓▓▓▓░▒▓█▓
▒█ ░░░ █▓ ░░░█░░░▒▒░░░█░░░░░█░░▓▓▓▓█▓▓▓▓▓██▒ █░ ░█ ░█▓░▒░▒▒▒▒▒▒▒░▒▓██
░█░░░░░ ██░░░█░░▒▒▒▒▒░░█░░░░░█░░▓▓▓▓█▓▓▓▓▓██▒░█ ░ ░ █ ▒█▒░░░░▒▒▒░▒▒▒▒██
█░░░░░ ▓█ ░░▒█▒▒▒▒▒▒░░█░░░░░█░░▒▓▓▓█▓▓▓▓▓██▒ █░ ░ ░█░ ▓█░░▒░░░░░░▒▒░▓█▓
█▓ ░░░ ░█▒░▒▒▒█▒▒▒▒▒░░█░░░░░█░░▒▓▓▓█▓▓▓▓███▒ ▀█░ █▀ ██ ███▓▓▓▓▓▒░▒██
██ ░░░ ██▒▒▒▒▒█▒▒▒▒▒░██████░░░░▓▓▓█▓▓▓▓███▒ ▀█▄█▀ █▓ ███▓▓▓▓█▓░▓█
░█░░░░ ▓█▒▒▒▒█▒▒▒▒▒▒░░░░░░░░░ ▒▓▓█▓██████▒ ▀ ░ █▒▒██▓▓▓▓▓█▒░█▓
█▓ ░░░ █▓▒▒█▒▒▒▒▒▒▒░▒▒▓▓▓▓████████████████████▓▓█▓ ▓█ ███▓▓▓▓██ ██
██ ░░ ██▒█▒▒▓▓████████▓░░██████████████████████████▓░██▓▓▓▓▓█░▒█
█▒ ░░ █████▓▓██████████████████████████████████▓██░▓█▓▓▓▓▓██ ██
██ ░░░ ▒███████████████████████████████████████████ ██▓▓▓▓▓█▒▒█
█▒ ░░░ ▓█████████████████████████████████████████░▓█▓▓▓▓▓▓█ ██
▒█ ░ ████████████████▓▓▓▓▓▓▓▓▓███████████████▓░██▓▓▓▓▓█▒▒█
██ ████▓▓▒▒░░ ░░░░▒▒▒▒░▒███▓█▓██ ██
█▓ ░ ░░░░▒▒▓▓██▒▒█░
█▒ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░██
░█▒ ░▒▓▓▓████████████████████████████████▓▓▓▒▒▒▒██░
██▒▓█████▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓██████████████████████████████▒
▓██▓▓▒▓██████████████▓▓▓▓▓▓▓▓▓▓▒▓▒▒▓▓▓▓▓▓▒░
╔══════════════════════════════════════════════════════════════════════════════╗
║ The SDTV Release Council Presents ║
║ The 2011 x264 SDTV Releasing Standards [TVx264SD11 - DRAFT 1] ║
║ 2011-01-01 00:00:00Z (1293840000) ║
║ ║
║ TVx264SD11 was signed by the following groups: ║
║ ║
║ Repack reason: IKEA products were chosen to avoid the appeal to authority ║
║ fallacy. Hai ZoNeNET! ║
╚══════════════════════════════════════════════════════════════════════════════╝
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» Contents « Line # »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2. What's New in TVx264SD11 . . . . . . . . . . . . . . . . . . . . . . . . 105
3. General Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.1 Previously On & Credits . . . . . . . . . . . . . . . . . . . . . . 187
4. Source Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5. Release Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
6. Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
6.1 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
7. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
8. Video Codec and Container . . . . . . . . . . . . . . . . . . . . . . . 406
9. Subtitles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
10. Packaging and Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 481
11. Propers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
12. Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» List of Tables « Line # »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Sample Reasons when Propering a Nukeable XviD . . . . . . . . . . . . . . 164
2. Source Definitions for SD Releases . . . . . . . . . . . . . . . . . . . 217
3. Valid Release Sizes for SD Releases . . . . . . . . . . . . . . . . . . . 264
4. Common Resolutions for SD Releases . . . . . . . . . . . . . . . . . . . 353
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 1. Preamble »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
The SDTV Release Council was formed in 2010 out of necessity and oppression from
biased nukers and a cartel of TV groups which misrepresented the majority of
groups that desired a ruleset. Unwritten rules yielded obscurity and obscurity
gave them power. The SDTV Release Council intends to regulate and standardise
the SD releases within the TV scene in order to abolish some of the outmoded
quality-inhibiting restrictions based on the preferences and assumptions of
nukers. This official document will cover the rules and guidelines for only SD
resolution content, excluding sports releases.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 2. What's New in TVx264SD11 »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
The most significant changes in this ruleset is the advance in codecs with AVC
replacing XviD and Vorbis replacing MP3. Although AVC and Vorbis do not provide
the same level of compatibility with older standalone players, there have been
large increases in support by most major manufacturers and ultimately we feel it
is better to push forward with better quality than to live in the past.
We chose Ogg Vorbis over MP3 or AAC for several reasons. It tends to sound
better than MP3 at lower bitrates (~ 64kbit/s)[1] because it is designed for the
compression of general purpose audio. Encoding audio at a lower bitrate without
sacrificing quality allows for a higher video bitrate. The format is already
supported on WD TV[2], Popcorn Hour[3], Mvix[4] and "is expected to obtain
widespread adoption with a major backing by many hardware based chip
manufactures [sic] and with the release of Google's new mobile Android platform
and Google TV by the year 2011."[5] Lastly, unlike MP3 and AAC, Vorbis is open
and doesn't have intellectual property restrictions that might hamper its
implementation in hardware players.
[1]: http://preview.tinyurl.com/33wlpz3
[2]: http://preview.tinyurl.com/2wjmc4u
[3]: http://preview.tinyurl.com/22qfm8l
[4]: http://preview.tinyurl.com/3xecxaz
[5]: http://preview.tinyurl.com/2vtz9yf
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 3. General Notes »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. This standard applies to and will be enforced for all English releases.
Groups that release non-English releases may use this ruleset if it is agreed
upon by the groups of their language and if there is not a language-specific
ruleset that explicitly supersedes this ruleset.
2. This is a draft of the ruleset and is open to debate and modification in its
corresponding channel. However, we believe that it is complete enough for
groups to begin using it and for it to be enforced. For those that are (for
whatever reason) unable to join talks, releasing a well-justified rebuttal is
strongly encouraged. Any post-modifications will be only enforced in the next
version of the ruleset.
3. XviD does not dupe x264. x264 dupes XviD. Exceptions:
(a) The x264 release has a better source than the source of the XviD release
(e.g. HDTV.x264 > PDTV.XviD).
(b) The x264 release is a valid proper of a nukeable XviD release
(e.g. PROPER.HDTV.x264 > nuked HDTV.XviD). An x264 proper of an XviD
release is only valid when the XviD release is nukeable for a general
technical flaw that is not particular to the video or audio format. Since
there are no official written rules for TV-XviD, please use discretion
and common-sense when propering. Below is a sample of reasons for
valid and invalid x264 propers of nukeable XviD releases.
┌────────────────────────┬────────────────────┐
│ Valid │ Invalid │
├────────────────────────┼────────────────────┤
│ has.commercial │ gmc.used │
│ no.ivtc │ custom.pixel.shape │
│ out.of.sync.throughout │ bad.audio.bitrate │
│ missing.dialogue │ oversized │
└────────────────────────┴────────────────────┘
Table 1: Sample Reasons when Propering a Nukeable XviD
4. Groups that claim to have an eye for quality should be pushing towards the
format that has improved on encoding efficiency, can produce relatively higher
quality at the same or lower bitrate and is rapidly gaining hardware support.
It is expected that all groups that release SDTV will eventually use x264 so we
may then ban XviD in a future revision.
5. Under exceptional circumstances, the council has the power to override a
global (un)nuke put in place by a nukenet. Such a circumstance would occur for
example if a release is being contested within a nuke war. The release in
question may be brought to the attention of the council who may then decide on
the validity of the release. If the council does decide on the matter, that
decision is final and should be treated as if it were written within the
standard itself. If a council decision is made, the release shall be nuked or
unnuked with "council.decision_reason" as the reason.
6. Episodes that air back-to-back without a natural break such as full credits
or commercials in between must be encoded as a single release. Directory naming
for this will be in the following format:
Series.Title.S##E##-##.EXTRA.TAGS.SOURCE.x264-GRP
»»»»»»»»»»»»»»»»»»»»»»» 3.1 - Previously On and Credits »»»»»»»»»»»»»»»»»»»»»»»»
1. Any previously on footage should be included in the release, but it is not
required. No release may be propered for glitches in or missing portions of
previously on footage.
2. Credits that are overlaid on actual show content are required to be
included.
3. Credits that run cleanly, i.e. with no modifications such as promos for
upcoming shows, are encouraged but not required.
4. Credits run with promos for other shows are not recommended, but may
optionally be included.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 4. Source Notes »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
┌────────┬─────────────────────────────────────────────────────────────────────┐
│ Source │ Definition │
├────────┼─────────────────────────────────────────────────────────────────────┤
│ WebRip │ Web stream that is officially available to a limited region or for │
│ │ a limited time (excluding P2P, etc.). │
│ DSR │ Standard Definition stream that does not meet the PDTV criteria. │
│ PDTV │ Standard Definition stream with a resolution of 704/720 x 480/576 │
│ │ and a video bitrate >= 1.5 mbps if MPEG4 or >= 3 mbps if MPEG2. │
│ WS │ Stream with an aspect ratio > 1.70. │
│ HDTV │ High Definition non-upscaled 720p/1080i/p stream. │
└────────┴─────────────────────────────────────────────────────────────────────┘
Table 2: Source Definitions for SD Releases
1. The source MUST be digital (the raw transport stream) and must not be passed
through analog devices such as capture cards or slingboxes. Examples of digital
sources include USB, Firewire, or Ethernet from a receiver, or using an ATSC,
QAM, or DVB tuner.
2. HDTV > WS.PDTV > PDTV > WS.DSR > DSR > WebRip
3. Releases that are of lower quality than an already available release are
considered dupes (e.g. PDTV dupes WS.PDTV, but HDTV does not).
4. A WebRip may be released only when: (1) the TV rip was not released and (2)
the web stream is only available to a limited region or for a limited time.
5. If a live event (e.g. concert, awards show, etc.) is interrupted, the ripper
must include the approximate total length of the removed interruptions within
the NFO.
6. Releases with a questionable source may be pre-nuked for up to 48 hours after
pre with the reason "source.sample.requested" if there is legitimate reason to
do so (e.g. suspicion of mislabeled source). The release group then has 48 hours
to provide a sample (at least 10 seconds in length) of the source before the
release becomes properable.
7. Releases with non-English audio for the majority of the duration must be
tagged with the language used.
8. Releases can only dupe or proper releases of the same language (e.g. a
SWEDISH release will not dupe an existing English release and cannot proper it).
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 5. Release Sizing »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
┌────────────────────┬────────────┐
│ Runtime │ Size (MiB) │
├────────────────────┼────────────┤
│ 00:12:00--00:19:00 │ 139 │
│ 00:16:00--00:26:00 │ 186 │
│ 00:24:00--00:38:00 │ 279 │
│ 00:33:00--00:51:00 │ 373 │
│ 00:49:00--01:17:00 │ 559 │
│ 01:06:00--01:42:00 │ 746 │
│ 01:39:00--02:34:00 │ 1119 │
│ 02:12:00--03:25:00 │ 1493 │
└────────────────────┴────────────┘
Table 3: Valid Release Sizes for SD Releases
1. Runtimes not listed in the above table must:
* be scaled to meet a bitrate of between 928kbps and 1472kbps
* have a file size equal to a division or multiple of a division of 4479MiB,
e.g. 4479MiB / 3 = 1493MiB * 2 = 2986MiB
2. If the length of the release is nearing the recommended maximum length, the
ripper can opt to use the next recommended size in the interests of quality.
3. CD sizes are long since obsolete and are forbidden.
4. Splitting a release into multiple files is forbidden.
5. A release may be a maximum of 2MiB oversized.
6. A release may be a maximum of 4MiB undersized when the target size is less
than 559MiB, or a maximum of 8MiB when the target size is 559MiB or above.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 6. Video »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. The appropriate deinterlace and IVTC methods must be used when necessary.
2. Duplicate frames must be removed unless required to maintain audio sync.
3. 50/60fps sources must be dropped to 25/30fps.
4. PAL material that has been broadcast in another region may be converted back
to the original frame rate if there is no quality loss suffered as a result
(e.g. a 60fps NTSC source of a video broadcast filmed at 50fps may be converted
back to 25fps with a filter such as rePal).
5. Reconverting the frame rate of an interlaced source to a higher frame rate
(e.g. a PAL 25fps interlaced source to 29.97fps) is not allowed if the source
would have to have a bob deinterlace technique applied to achieve the desired
frame rate.
6. Deinterlacers that produce bad quality results (e.g. FieldDeinterlace,
BlendFields) are banned. Filters such as Yadif or LeakKernelDeint are
recommended.
7. Resizers that produce bad quality results (e.g. PointResize, BicubicResize)
are banned. A sharp resizer must be used (e.g. Lanczos(4)Resize,
Spline(16/36/64)Resize, etc.).
8. Group watermarks are banned, with the exception of blurring potential
security risking watermarks (e.g. VariableBlur[6], MedianBlur[7], etc.).
9. Imperfections lasting the majority of the release may be dealt with by the
group as long as there is minimal impact on viewing quality (e.g. cropping out
a news ticker placed at the bottom of the video frame by the broadcasting
network).
10. Negligible video glitches do not warrant a nuke if they occur between scene
changes or are otherwise known to be the fault of the broadcaster.
11. Network inserted commercials must be removed.
12. The video must not have local overlays (e.g. weather, breaking news,
Amber Alerts, etc.) that exceed five minutes in length, cause a change in video
format (i.e. drop to PDTV on an HDTV release), or cause loss of dialogue or
video. The proper release must be completely free of such overlays to be
considered valid; merely having less spam is not enough.
13. Any other modification of the original content prior to or after encoding is
strictly forbidden (e.g. intros, outros, betweenos).
14. Pixel shape must be square.
[6]: http://preview.tinyurl.com/2c5qhn4
[7]: http://preview.tinyurl.com/26wus6h
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»» 6.1 - Dimensions »»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Width:
* 576--672 pixels for sources with an AR of 1.70-3.00.
* 512--672 pixels for sources with an AR of 1.00-1.69.
2. Common resolutions include:
┌──────┬───────────┐
│ 16:9 │ 624 x 352 │
│ │ 640 x 352 │
├──────┼───────────┤
│ 4:3 │ 512 x 384 │
│ │ 576 x 432 │
└──────┴───────────┘
Table 4: Common Resolutions for SD Releases
3. Upscaling must be kept at a minimum for low resolution sources (typically
480i) and is banned for all higher resolution sources.
4. Black borders must be cropped to their maximum. In the event of changing
aspect ratios, the cropping must be tailored towards the widest frame within
the release.
5. SD sources may be overcropped by a maximum of 2px. HD sources may be
overcropped by a maximum of 4px.
6. The aspect ratio must be within 3% of the source display aspect ratio.
7. Height and width must be MOD16.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 7. Audio »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Must be VBR Ogg Vorbis or the original untranscoded stream.
2. The original stream should only be used at the ripper's discretion and must
provide a valid reason for use within the NFO.
3. Audio sources with more than two channels (e.g. Dolby Digital) must be
downmixed to stereo.
4. Ogg must be encoded VBR with a target of between 64kbps and 128kbps for
multichannel sources and between 48kbps and 96kbps for mono sources. "-b 64" on
encoders such as oggenc2[8] is recommended for most releases.
5. If the source bitrate is lower than 64kbps (multichannel) or 48kbps (mono),
the target bitrate must be the highest possible bitrate and a notice should be
placed in the NFO file.
6. Encoding a multichannel source to mono or a mono source to stereo is
forbidden.
7. Resampling is forbidden.
8. Audio that is more than 100ms out of sync is considered technically flawed.
9. Audio must not have severe drops resulting in the inability to understand
material dialogue.
10. Multiple audio tracks are forbidden.
11. Dupes based on audio format are forbidden.
[8]: http://preview.tinyurl.com/ya9glra
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 8. Video Codec and Container »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Must use x264 (no older than 30 revisions).
2. Must use MKV as the container.
3. Encoding must be 2-pass VBR.
4. Target bitrate must be a minimum of 928kbps. If, for whatever reason, this
cannot be achieved then a reasonable justification must be included in the NFO
and a source sample must be placed in the Sample directory for issues relating
to the source.
5. AVC Profile must be Main Profile (3.0) or higher.
6. Subpixel Refinement must be 6 or 7 (--subme 7; default is 7)
7. Motion estimation method must be hex or higher (--me hex; default is hex).
8. Trellis must be 0 or 1 (--trellis 1; default is 1).
9. Macroblock options must be default or "all" (--partitions all).
10. Reference Frames must be 3 (--ref 3; default is 3).
11. Adaptive Quantization must be used (enabled by default).
12. CABAC encoding must be used (enabled by default).
13. Deblocking must be used (enabled by default).
14. B-frames must be 3 or higher (--bframes 3; default is 3).
15. B-pyramid must be normal (--b-pyramid normal).
16. Adaptive b-frames must be used (enabled by default).
17. Adaptive DCT must not be disabled (enabled by default).
18. Direct MV prediction mode must be set to auto (--direct auto; default is
spatial).
19. Keyframe Interval must be between 200 and 300. The recommended setting is
--keyint 10 * FPS.
20. Min GOP Size must be between 20 and 30. The recommended value is the rounded
output FPS (--min-keyint FPS).
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 9. Subtitles »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Subtitles are optional.
2. VobSub (.sub and .idx) or SubRip (.srt) are the preferred formats.
3. Subtitles must be muxed into the MKV. "Subs" directories are forbidden.
4. Out-of-sync subtitles do not warrant a nuke (e.g. realtime, pre-prepared,
scrolling or otherwise broadcaster-delayed subtitles).
5. Removing official broadcast-sponsor advertisements from subtitles is
optional.
6. Group watermarks in subtitles are strictly forbidden.
7. Hard subtitles will only be allowed when the source exhibits such subtitles
in the picture itself.
8. Release muxed with subs must still adhere to the aforementioned filesizes.
9. Multi-language subtitles cannot be used as a basis for a dupe.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 10. Packaging and Naming »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Releases must be packaged within a RAR archive with M0 (store) compression.
2. RAR archives must be split into 15 or 20 MB parts (where 1 MB is defined as
1,000,000 bytes). 50 MB and 100 MB parts are allowed when packaging files larger
than 1119 MiB. RAR sets may not be larger than 101 RARs when using old-style
volume names.
3. Inclusion of RAR recovery records is recommended.
4. Encryption or password protection is strictly forbidden.
5. An SFV is required for each set of RAR files.
6. All filenames must be unique to avoid dupes.
7. An NFO file is required and should contain the following:
* Release Name
* Group Name
* Release Date
* Video Information (Codec, Bitrate, Resolution, etc.)
* Audio Information (Codec, Bitrate, Channels, etc.)
8. Release directories should generally be named like the following example in
order to maintain consistency within the scene:
* Series.Title.S##E##.EXTRA.TAGS.SOURCE.x264-GRP
* Variety.Show.YYYY.MM.DD.Guest.EXTRA.TAGS.SOURCE.x264-GRP
9. Releases may use the PREAIR tag if they are pred before the air date in the
country of origin, but may not be nuked for missing it. Nukers should use
discretion before nuking a release that appears to have the wrong date as many
taped shows are pred in advance of airing in the country of their origin.
10. Releases must contain a sample between 40--90 seconds long taken directly
from the complete release content. The sample must have a unique filename and
must be placed within the "Sample" directory.
11. Using a renamed RAR as a Sample is forbidden.
12. The following additional tags are considered valid: PROPER, REPACK, RERIP,
REAL, READNFO (with discretion), INTERNAL, UNCUT, SUBBED (i.e. hardsubbed), LD,
PREAIR, DIRFIX, NFOFIX, SAMPLEFIX.
13. Releases with non-English audio must be tagged with the language used
(e.g. SWEDISH, not SVENSKA) and appended with the LD tag if the language is
dubbed (e.g. SWEDISH.LD).
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 11. Propers »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. Propers are permitted in the case of previous technical flaws.
2. Propers must state the proper reason and which release is being propered
within the release NFO.
3. Propers must provide proof of technical flaws within the Sample directory if
the release being propered has not already been nuked.
4. Propers are not allowed after a repack has been released; however, flawed
repacks may be propered.
5. Propers based on audio codec are forbidden.
6. Propers based on video codec are forbidden.
7. Propers based on ripper decisions (e.g removal of pre-/post-show footage,
network-specific footage, etc.) are forbidden. Use internal.
8. Propers based on source parameters (e.g. number of commercials, frame rate,
audio channels or bitrate, etc.) are forbidden.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 12. Internals »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
1. All internals must conform to TVx264SD11 rules, with the exception of minor
known technical issues and non-conforming sizes or audio codecs. Using the
INTERNAL tag to try and protect a severely flawed release from nukes is
forbidden.
2. The following audio codecs may be used for internals: AC3, MP2, Ogg Vorbis,
or MP3. Releases using other codecs are not protected from nukes by the INTERNAL
tag.
3. Using INTERNAL.DIRFIX as a cheap attempt at avoiding a nuke is forbidden. If
the release is technically flawed, it is still deemed nukeable both before and
after an attempted INTERNAL.DIRFIX and the DIRFIX shall be nuked for
fix.for.nuke.
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
» 13. Acknowledgements »
»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
The authors of this ruleset wish to gratefully acknowledge the authors of
TVx2642k8, TVX2K7, TXSRS11 for their dedication and arduous work of which many
of these rules and guidelines were based upon. Special thanks to the reviewers
and the real signers of this ruleset.
╔══════════════════════════════════════════════════════════════════════════════╗
║ The 2011 x264 SDTV Releasing Standards is best viewed with Terminal font. ║
╚══════════════════════════════════════════════════════════════════════════════╝</pre>
</body>
</html>