608 lines
58 KiB
HTML
608 lines
58 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<title>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>
|