lezzo.org/blog/mirror/scenerules.org/t.html?id=2005_XViD-rebuttal.nfo.html
2022-01-24 19:24:31 +00:00

604 lines
60 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>2005_XViD-rebuttal.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">&#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
&#9474; &#9474;
&#9474; An Independent Critic presents &#9474;
&#9474; a Rebuttal of... &#9474;
&#9474; The XviD Releasing Standards 2005 &#9474;
&#9474; &#9474;
&#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496;
&#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
&#9474; Requirements: Notepad with terminal font or any other ascii viewer. &#9474;
&#9500;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9508;
&#9474; &#9492;&#9472;&#9472;&#9472;[ INTRO ]&#9472;&#9472;&#9472;&#9496; &#9474;
&#9474; &#9474;
&#9474; To introduce myself first...I am a member of one of the oldest active XviD &#9474;
&#9474; release groups and one of main writers/contributors to TDX2k2. Neither I, &#9474;
&#9474; nor my group was informed of this new ruleset. That is reflected in the &#9474;
&#9474; fact that we are not a signatory. I find it astounding that the writers of &#9474;
&#9474; this ruleset can give &#34;respect&#34; to the previous TDX teams but at the same &#9474;
&#9474; time self-proclaim themselves to be the new TDX team and write a new ruleset&#9474;
&#9474; without even consulting them. In fact, not even half of the of the (active) &#9474;
&#9474; groups to whom the main TDX2k2 writers belonged have signed off on TXD2k5. &#9474;
&#9474; Several of the oldest XviD groups have not signed TXD2k5, but instead of &#9474;
&#9474; any attempts at compromise, the new ruleset was steamrolled through without &#9474;
&#9474; them or their input. &#9474;
&#9474; &#9474;
&#9474; As a result of these strong-arm tactics, I am now forced to point out each &#9474;
&#9474; any every flaw that the TXD2k5 authors are forcing the XviD scene to &#9474;
&#9474; swallow. The TDX2k5 ruleset was meant to plug the holes in TDX2k2 and some &#9474;
&#9474; had hoped it would usher in a new era in MPEG-4 based encoding. Sadly, this &#9474;
&#9474; abomination does neither. Within the ruleset guideline below, I have &#9474;
&#9474; included my rebuttal comments. While many of my points might seem to be &#9474;
&#9474; bordering on anal, it is my opinion that a ruleset must be precise and &#9474;
&#9474; concise. It should eliminate all ambiguity and close all loopholes. &#9474;
&#9474; As you will see, I find that this new ruleset does neither. The scope of &#9474;
&#9474; the rules is adequate, but it could have gone a lot further in some areas, &#9474;
&#9474; and went too far in others. TDX as a ruleset must curb the release of bad &#9474;
&#9474; rips, while at the same time it cannot impede a ripper&#39;s ability to create &#9474;
&#9474; the highest possible quality rip. I do also acknowledge that some of the &#9474;
&#9474; words and ideas that I contest in my rebuttal were present in TDX2k2. This &#9474;
&#9474; does not excuse TXD2k5 of having the same problem since the TXD2k5 writers &#9474;
&#9474; had the choice to edit or reword anything they felt appropriate. &#9474;
&#9474; &#9474;
&#9474; I know that some people will just dismiss this as me holding a personal &#9474;
&#9474; grudge or think that I&#39;m just out to pick a fight. If you take the time to &#9474;
&#9474; read my rebuttal comments, you should find them to be valid concerns. I &#9474;
&#9474; truly care about the future of the MPEG-4 scene and am deeply troubled when &#9474;
&#9474; I see a document like this being flaunted as a new ruleset. &#9474;
&#9474; &#9474;
&#9474; This document is meant only as a rebuttal of the TXD2k5 document and is not &#9474;
&#9474; intended as a reflection of any of the signee groups. I know that many of &#9474;
&#9474; the groups that signed did so blindly in order to support what appeared to &#9474;
&#9474; be a positive advancement for the XViD Scene. As such, I&#39;m not suprised by &#9474;
&#9474; the number of obvious errors that I was able to locate when picking it &#9474;
&#9474; apart. I don&#39;t believe that having signed TXD2k5 precludes any group from &#9474;
&#9474; lending their voice to anything that might arise from the dialogue that I &#9474;
&#9474; hope to have started. I would encourage all groups who agree with any of my &#9474;
&#9474; points to speak their mind, whether it be with me or the writers of TXD2k5, &#9474;
&#9474; or even in a public forum or their own nfos. I welcome any groups to &#9474;
&#9474; include this nfo or their own rebuttals with their releases. &#9474;
&#9474; &#9474;
&#9474; Thank you for your time. &#9474;
&#9474; &#9474;
&#9474; P.S. I find it strange how TXD2k5&#39;s intro is written in the first person &#9474;
&#9474; singular when it is supposedly an intro from the entire new TDX &#9474;
&#9474; committee... &#9474;
&#9474; &#9474;
&#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496;
&#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
&#9474; &#9492;&#9472;&#9472;&#9472;[ RELEASE RULES ]&#9472;&#9472;&#9472;&#9496; &#9474;
&#9474; &#9474;
&#9474; Movie Length: &#9474;
&#9474; - PAL (25 fps) = MINIMUM runtime is 100 minutes/CD. &#9474;
&#9474; - FILM (23.976 fps) = MINIMUM runtime is 105 minutes/CD. &#9474;
&#9474; - NTSC (29.97 fps) = MINIMUM runtime is 87 minutes/CD. &#9474;
&#9474; - These runtimes are scalable via the following equation: &#9474;
&#9474; N CD time minimum = (N-1) * allowed time where N is number of CDs and &#9474;
&#9474; allowable time applies to fps as outlined above: &#9474;
&#9474; i.e. 3 CD FILM rip minimum = 105 x (3-1) = 210 minutes. &#9474;
&#9474; - MINIMUM time length rule is as implied - that is the MINIMUM time per &#9474;
&#9474; CD -- NOT MAXIMUM!!! (i.e. no such thing as &#34;must be more than 1 CD&#34;) &#9474;
&#9474; - Release runtime must be at least 50 minutes for using the full burnable &#9474;
&#9474; media capacity. In such cases, releases MUST utilize a MINIMUM of &#9474;
&#9474; 680mb of the 700mb standard burnable media (Multi-CD releases MUST &#9474;
&#9474; conform to the 680mb minimum, for each CD used). Any other use of the &#9474;
&#9474; media shall not be over 350mb (Sizes between 350mb to 680mb are not &#9474;
&#9474; allowed). &#9474;
&#9474; - Media usage is at ripper&#39;s discretion, please use it. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - The runtime rule is still a slightly vague and occasionally contested &#9474;
&#9474; issue within TDX. The new wording doesn&#39;t change this at all. The &#9474;
&#9474; correct interpretation of this rule is that it is permitted to use an &#9474;
&#9474; additional CD for every additional x minutes beyond the original x &#9474;
&#9474; minute runtime (x being the runtime based on the framerate). The way it &#9474;
&#9474; is currently worded can still be interpreted such that each CD MUST &#9474;
&#9474; have at least x minutes on it. &#9474;
&#9474; - With the improvements in encoding technology, I don&#39;t understand why &#9474;
&#9474; the new ruleset would be trending towards less compression with the &#9474;
&#9474; modified length rules. &#9474;
&#9474; - The first time I read the new point that was added, I thought that it &#9474;
&#9474; related to shorts but apparently it&#39;s not. The point just seems to &#9474;
&#9474; bumble around. Couldn&#39;t it just have been simply stated that the &#9474;
&#9474; minimum capacity used on a CD is 680MB? The 50 minute rule should have &#9474;
&#9474; just been included in some new rules about the runtime of shorter &#9474;
&#9474; features (which I definitely feel is needed). The new TDX implies that &#9474;
&#9474; everything under 50 minutes can be ripped to 350MB, but doesn&#39;t a 350MB &#9474;
&#9474; rip of a 5 or 10 minute short seem a bit oversized? &#9474;
&#9474; - Why is the capacity of a CD not explicitly defined? Is it 700MB even &#9474;
&#9474; (734,003,200 bytes)? 702MB (which will still fit on a CD)? or something &#9474;
&#9474; else? There have been several releases between 700 and 702MB, is that &#9474;
&#9474; allowed? &#9474;
&#9474; - So what are the rules for non-standard framerate releases? There are &#9474;
&#9474; plenty of silent films that IVTC to 16 to 22fps... &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; AUDIO: &#9474;
&#9474; - MUST be MP3 or Studio AC3 (AC3 transcoding forbidden). &#9474;
&#9474; - MUST be STEREO for STEREO sources, MONO for MONO sources &#9474;
&#9474; (MONO audio as STEREO on source is considered a MONO source). &#9474;
&#9474; - MUST BE VBR! NO CBR MP3! &#9474;
&#9474; - MP3 tracks must have the original frequency as it was on the DVD&#39;s &#9474;
&#9474; audio: i.e. 48khz for 48khz and 44.1khz for 44.1khz. &#9474;
&#9474; - MP3 files must be normalized. &#9474;
&#9474; - ABR is considered a VBR technique. &#9474;
&#9474; - AC3 MUST be used wisely and correctly. Ripper&#39;s discretion on when to &#9474;
&#9474; use it. Using or not using AC3 IS NOT a technical flaw. &#9474;
&#9474; - MONO AC3 is not allowed, in that case must encode to mono MP3. &#9474;
&#9474; - Multi-language audio tracks are FORBIDDEN! (Use INTERNAL!) &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Please define mono. The term was incorrectly used in TDX2k2 and has &#9474;
&#9474; caused all sorts of issues. Technically speaking, any audio track with &#9474;
&#9474; identical channel(s) is mono. Of course, the intention is to forbid the &#9474;
&#9474; use of 2.0 Mono MP3/AC3, but once again, this is left unclear. &#9474;
&#9474; - The term source also needs definition. Is it the source AC3 track on &#9474;
&#9474; the DVD? The original theatrical master? This ruleset still doesn&#39;t &#9474;
&#9474; clear up whether a DVD should be encoded in stereo when the studio &#9474;
&#9474; remasters a mono theatrical track into 2.0 (Stereo) or 5.1 audio. &#9474;
&#9474; - Why MUST MP3 need to be normalized? Wouldn&#39;t minimal processing of a &#9474;
&#9474; track be ideal? The rule also doesn&#39;t state the extent to which the &#9474;
&#9474; audio must be normalized. Without that, the rule means absolutely &#9474;
&#9474; nothing. &#9474;
&#9474; &#9474;
&#9474; VIDEO: &#9474;
&#9474; - Keyframe: &#9474;
&#9474; MUST be &#60;=20 seconds and MUST be inserted according to scene changes &#9474;
&#9474; and framesizes as determined by the codec or encoding application. &#9474;
&#9474; - Group watermarks of any kind on the video will not be tolerated! &#9474;
&#9474; - Intermission messages must be removed from the avi! &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - I know the intermission rule is personal. I still maintain that there &#9474;
&#9474; is often wonderful musical accompaniment during the intermission and &#9474;
&#9474; that would be lost if that rule is kept in effect. Sometimes the &#9474;
&#9474; intermission is used as a directorial tool as well, so removing it &#9474;
&#9474; would alter the flow of the movie. If removing the climax of a movie is &#9474;
&#9474; frowned upon, shouldn&#39;t the same common sense lend itself to any other &#9474;
&#9474; part of a movie? &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Framerate: &#9474;
&#9474; - MUST be as close to original source framerate as possible. &#9474;
&#9474; - In some cases PAL movies should be ivtc&#39;d (i.e. to 24fps). Therefore &#9474;
&#9474; using a PAL source is not an excuse for lack of ivtc. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Once again, the term source needs to be defined. While it seems obvious &#9474;
&#9474; to most what the correct framerate should be, there are some that think &#9474;
&#9474; that the NTSC telecine framerate of 29.97fps is the &#34;source framerate&#34;. &#9474;
&#9474; - Hybrids? What are the guidelines for ripping hybrids? What would &#9474;
&#9474; make a hybrid encode properable? Hasn&#39;t this been a hot enough issue to &#9474;
&#9474; address? &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Codec: &#9474;
&#9474; - MUST BE XviD (all DivX codecs are banned). &#9474;
&#9474; - MUST use 2 pass technique during encoding. &#9474;
&#9474; - NO DUPES BASED ON CODEC TYPE, USE INTERNAL! &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Resolution and Aspect Ratio: &#9474;
&#9474; - Width: 512 - 672 pixels for WS movies (Letterboxed is considered WS). &#9474;
&#9474; 448 - 576 pixels for FS movies (Only 4:3 images). &#9474;
&#9474; - Height and Width: Must be a multiple of 16. &#9474;
&#9474; - Cropping is required to be the MAXIMUM possible (black borders must &#9474;
&#9474; be cropped to their maximum). Over cropped releases are considered &#9474;
&#9474; a technical flaw. Some movies present changing ARs, in that case the &#9474;
&#9474; cropping applies only to the image that presents more pixels (Means &#9474;
&#9474; that part of the movie will have bad cropping). &#9474;
&#9474; - Movie encodes must be within 5% of the original aspect ratio. &#9474;
&#9474; Calculating AR % error: (Release AR - Original AR)/Original AR x 100 &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Due to the popular 1.37:1 AR, the FS rule should probably be extended &#9474;
&#9474; from the 4:3 definition to any AR 1.4/1.5:1 and narrower. It&#39;s obvious &#9474;
&#9474; that 1.37:1 isn&#39;t widescreen. &#9474;
&#9474; - The term &#34;bad cropping&#34; is kind of silly. It&#39;s either overcropped or &#9474;
&#9474; undercropped. Once again, the wording of the 3rd point is imprecise. &#9474;
&#9474; Why not just say what correct cropping is and go from there. The &#9474;
&#9474; &#34;maximum possible&#34; cropping is just to crop the whole frame away. The &#9474;
&#9474; rule regarding a source with varying ARs is appropriate but again badly &#9474;
&#9474; worded. How does cropping apply to anything? Does this sentence make &#9474;
&#9474; sense? &#34;In the case that the movie presents changing ARs, cropping &#9474;
&#9474; applies only to the image that presents more pixels.&#34; Huh?! How about: &#9474;
&#9474; &#34;In the case..., the movie must be cropped such that no frame is &#9474;
&#9474; overcropped&#34;. Simple. &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Subs, Interactive Menus, Trailers: &#9474;
&#9474; - OPTIONAL (ONLY if all other requirements have been met). &#9474;
&#9474; - VOBSUB is the preferred format due to the fact it does not use OCR. &#9474;
&#9474; However, any format that displays with DVobSub is acceptable. &#9474;
&#9474; - Subtitles may be MUXED with video stream, but MAY NOT be BURNED into &#9474;
&#9474; video stream. MUXED subs will proper BURNED subs. &#9474;
&#9474; - Subtitles not muxed into video stream MUST be encapsulated in a .rar &#9474;
&#9474; file with the MOST compression available and shall be contained in &#9474;
&#9474; the directory named &#39;Subs&#39; and will NOT be packaged with main movie &#9474;
&#9474; rars. &#9474;
&#9474; - Burned subtitles shall only be permissible when the source exhibits &#9474;
&#9474; aforementioned subtitles in the picture itself (i.e. Subs in the &#9474;
&#9474; matte portion of the picture MUST be typed in a separate file and the &#9474;
&#9474; frame shall be cropped). If there is a part of the burned subtitles &#9474;
&#9474; on the picture itself, and another part on the matte portion of the &#9474;
&#9474; picture, the frame must be cropped to 2 pixels from the start of the &#9474;
&#9474; subtitles on the matte portion. Upside cropping of the picture has &#9474;
&#9474; nothing to do with the downside, therefore the cropping on the upside &#9474;
&#9474; MUST BE to it&#39;s maximum. &#9474;
&#9474; - English subs on non English movies MUST fit on CD with main movie, &#9474;
&#9474; all other optional subs SHOULD fit on the CD. &#9474;
&#9474; - Foreign movies (Non English Spoken) with no English subs, must have &#9474;
&#9474; the language name taggings (applies to the various non English &#9474;
&#9474; scenes). Movies with English subs present, WILL NOT HAVE any language &#9474;
&#9474; tag on them! &#9474;
&#9474; - Using of hand made subs on non English releases (i.e. fansubs) MUST &#9474;
&#9474; be mentioned in the nfo, and at nuker&#39;s discretion if to nuke the &#9474;
&#9474; release for Bad.Subs, depends on how bad the subtitles are. Please &#9474;
&#9474; use common judgement! Releases that were nuked for bad subtitles, may &#9474;
&#9474; be propered only by subtitles that came from the retail DVD (Ripper&#39;s &#9474;
&#9474; choice if to release the full movie again or just the subtitles). &#9474;
&#9474; - Multi-language subtitles cannot be used as a basis for a dupe. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - I see nothing about Interactive Menus or Trailers, or any other extras &#9474;
&#9474; for that matter. &#9474;
&#9474; - As we appear to be still using the avi container, it is not possible to &#9474;
&#9474; mux subs into the actual container (which is what muxing actually means)&#9474;
&#9474; - I&#39;m not sure about the mandatory use of rar. I know there are certain &#9474;
&#9474; (standalone) players that wouldn&#39;t read through the rar. Not that &#9474;
&#9474; many (if any) current standalones play Vobsubs anyway. &#9474;
&#9474; - I&#39;ve always loved this 1/2 matted burned subs discussion. Doing it the &#9474;
&#9474; way that the ruleset indicates would cause the image to be off-center &#9474;
&#9474; during fullscreen playback. Some people swear that they can&#39;t watch &#9474;
&#9474; anything off-center, personally don&#39;t think it&#39;s the end of the world. &#9474;
&#9474; In any event, a few of us had thought up a great compromise based on &#9474;
&#9474; the macroblock structure of MPEG encoding. It&#39;s too bad we weren&#39;t &#9474;
&#9474; consulted. &#9474;
&#9474; - EngSub Must fit on CD rule: See above rar comment and more above CD &#9474;
&#9474; filesize comment. &#9474;
&#9474; - The next bullet...&#34;will not&#34; or &#34;must/may not&#34;? (And I find the use of &#9474;
&#9474; exclamation marks to be very unprofessional in a ruleset) &#9474;
&#9474; - How many times do I have to say it? How bad do subs have to be to be &#9474;
&#9474; bad.subs? I&#39;m sure there&#39;s no consensus on what &#34;common judgement&#34; is. &#9474;
&#9474; (judgment is misspelled too). This of course is even worse since the &#9474;
&#9474; rules state that if SOMEONE has made the call to nuke it for bad.subs, &#9474;
&#9474; then it can be propered. &#9474;
&#9474; &#9474;
&#9474; Packaging: &#9474;
&#9474; - All releases must be AVI, not BIN/CUE. &#9474;
&#9474; - Must be packed with RAR and broken into 15 or 20 MB volumes. &#9474;
&#9474; Releases that are more then 1 CD must have the RAR files broken into &#9474;
&#9474; 2 or more CD volumes. &#9474;
&#9474; - Compression is not allowed. &#9474;
&#9474; - Recovery and MD5 record are recommended. &#9474;
&#9474; - Must have SFV included for each CD. &#9474;
&#9474; - Must have NFO. &#9474;
&#9474; - NFO SHOULD INCLUDE: &#9474;
&#9474; Group name &#9474;
&#9474; Title &#9474;
&#9474; Actual XviD release date &#9474;
&#9474; DVD release date &#9474;
&#9474; Theatrical release date (US preferably) &#9474;
&#9474; Video size &#9474;
&#9474; Framesize/Aspect Ratio &#9474;
&#9474; Audio bitrate &#9474;
&#9474; Video bitrate &#9474;
&#9474; Movie runtime/Length &#9474;
&#9474; IMDB/Amazon/Any other DVD site info link &#9474;
&#9474; Number of rars per CD (i.e. 50x15MB) &#9474;
&#9474; Ripping method &#9474;
&#9474; DRF average &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Now that we&#39;ve cleared up what it SHOULD include, what MUST it include? &#9474;
&#9474; - DRF. Sigh... (see more about this below) &#9474;
&#9474; - Exactly what ripping method we are talking about? &#9474;
&#9474; - How about...Audio Codec? XviD Build? Packed Bitstream? Max Conseq BFs? &#9474;
&#9474; &#9474;
&#9474; Credits: &#9474;
&#9474; - Movie credits can be encoded separately at a lower bitrate only if the &#9474;
&#9474; time length exceeds the no. of CDs used (i.e. 106 min on 1CD for FILM &#9474;
&#9474; source, or 201 min on 2CDs for PAL source, etc). &#9474;
&#9474; - Any movies with scenes in the credits (i.e. bloopers or continuation &#9474;
&#9474; of story) MAY NOT be downsampled! &#9474;
&#9474; - Cutting Credits is not allowed. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - I don&#39;t see the advantage in restricting when credit downsampling can &#9474;
&#9474; occur. There&#39;s no consistency. They&#39;re either expendable, or they &#9474;
&#9474; aren&#39;t. &#9474;
&#9474; &#9474;
&#9474; Samples: &#9474;
&#9474; - REQUIRED! &#9474;
&#9474; - 1 full minute in length and in a separate folder marked as &#39;Sample&#39;. &#9474;
&#9474; - MUST be taken from the movie - NOT encoded separately. &#9474;
&#9474; - Vob samples are recommended for any rip that is deemed questionable: &#9474;
&#9474; i.e. no ivtc possible on source, ivtc to 24.975fps etc. &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Propers: &#9474;
&#9474; - Propers are ONLY permitted in the case of a technical flaw in the &#9474;
&#9474; original release (i.e. Bad IVTC, Interlacing, bad number of CDs). &#9474;
&#9474; - Releases not nuked on release lists and/or sites MUST include &#9474;
&#9474; original sample of the technical flaw. &#9474;
&#9474; - Qualitative propers are not allowed, nor are propers based on &#9474;
&#9474; decisions made by a ripper (i.e. No. of CDs, AC3 or MP3, etc). &#9474;
&#9474; - Propers based upon the compliance with new instances of TXD2K5 &#9474;
&#9474; guidelines are also forbidden. &#9474;
&#9474; Only propers acceptable when propering old tdx rips are propers based &#9474;
&#9474; on picture damage: Aspect Ratio, IVTC, Over-Cropping. Other propers &#9474;
&#9474; acceptable are propers based on releases that did not follow previous &#9474;
&#9474; tdx guidelines, at the time they were released. &#9474;
&#9474; - Subbed (in original movie language) propers dubbed (in any language). &#9474;
&#9474; - Hardcored Subs may be propered by releases containing Vobsub/Srt. &#9474;
&#9474; &#60;This rule will not apply to movies ripped before TXD2K5> &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - &#34;bad number of CDs&#34;...speaks for itself. &#9474;
&#9474; - Speaking of which...something can be propered for &#34;bad number of CDs&#34; &#9474;
&#9474; but not for &#34;No. of CDs&#34;. &#9474;
&#9474; - Are you expecting new instances of TXD2K5? That whole sentence needs to &#9474;
&#9474; be rethought. &#34;Only propers acceptable&#34; -> &#34;Propers are only acceptable&#34;&#9474;
&#9474; might be slightly better English? Although that whole sentence probably &#9474;
&#9474; needs reworking. The meaning of &#34;old tdx rips&#34; is obvious even if it &#9474;
&#9474; doesn&#39;t seem to make sense. I also believe that the list of flaws was &#9474;
&#9474; previously called technical flaws (a couple points up, why change that?)&#9474;
&#9474; In any event, I&#39;m sure there are plenty of other ways to reword that &#9474;
&#9474; bullet. &#9474;
&#9474; - &#34;Original movie language&#34; -> &#34;Movie&#39;s original/native language&#34;? &#9474;
&#9474; - I know some people are pretty passionate about their subs, but hardcore &#9474;
&#9474; might be going a bit to far (Yes, I know it&#39;s just a typo) &#9474;
&#9474; - Propers imply that there was something wrong with the original release &#9474;
&#9474; and it doesn&#39;t make sense to penalize a group for ripping a hardsubbed &#9474;
&#9474; DVD. &#9474;
&#9474; &#9474;
&#9474; WS vs. FS: &#9474;
&#9474; - FS movies after WS was out, are FORBIDDEN unless proven it contains &#9474;
&#9474; more picture (use of sample or .jpg as proof). &#9474;
&#9474; - WS movies after FS was out, MUST HAVE original sample from the &#9474;
&#9474; previous release, unless proven no WS DVD was out at the time the FS &#9474;
&#9474; was released. A WS not following the above is considered a DUPE! &#9474;
&#9474; - WS or FS name tags on the release name, if the other wasn&#39;t released &#9474;
&#9474; in the past, WILL NOT BE TOLERATED! &#60;use nfo to mention the AR>. &#9474;
&#9474; - WS cannot proper another WS: for example 2.35:1 after 1.85:1 is out. &#9474;
&#9474; Use the tag WS in the dirname instead. However WS after a wider WS &#9474;
&#9474; was released, will be considered a DUPE unless proven it contains &#9474;
&#9474; more picture! Sample rule applies here also. &#9474;
&#9474; - Letterboxed DVDs are not considered FS even if it&#39;s FS on the source! &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - &#34;FS movies after WS was out&#34; is also grammatically incorrect. &#9474;
&#9474; - Why no FS tag when it&#39;s the first one out? I can understand people not &#9474;
&#9474; wanting to read the nfo just to see if the release if FS or WS. &#9474;
&#9474; - Aren&#39;t violations of any rule not to be tolerated? Why makes this one &#9474;
&#9474; so special? &#9474;
&#9474; - Again, define source...In this case, the physical layout of the DVD is &#9474;
&#9474; being considered the source. &#9474;
&#9474; - This whole segment feels that it could be reworked for less redundancy &#9474;
&#9474; and more conciseness. &#9474;
&#9474; &#9474;
&#9474; Special Movie Editions: &#9474;
&#9474; - Allowed: SE, DC, EXTENDED, UNCUT, REMASTERED, UNRATED, THEATRICAL, &#9474;
&#9474; CHRONO. &#9474;
&#9474; - Special Edition releases without any different features in the film &#9474;
&#9474; itself will be considered dupes of previous releases of the same &#9474;
&#9474; movie. &#9474;
&#9474; - Shorter cut version of a movie after a longer version was released is &#9474;
&#9474; allowed (i.e. THEATRICAL), and MUST be mentioned in the dirname. &#9474;
&#9474; - Remastered movies after the original have been released are allowed &#9474;
&#9474; only if the original release was in BLACK AND WHITE and the &#9474;
&#9474; remastered edition is colour. Everything else use INTERNAL! &#9474;
&#9474; (Remastered DVD releases that were nuked in the past and were colour &#9474;
&#9474; after black and white, shall not be unnuked and shall not be duped!) &#9474;
&#9474; - Remastered audio will be considered a dupe if it&#39;s the only reason &#9474;
&#9474; movie was re-released. &#9474;
&#9474; - Extras released in a special movie edition, cannot be used as a basis &#9474;
&#9474; for a dupe, unless released separately &#60;and are not dupes of previous &#9474;
&#9474; releases>. &#9474;
&#9474; - Homemade Rips are not allowed (Use INTERNAL!). For example adding of &#9474;
&#9474; deleted scenes, alternate endings, chrono editions. Only retail DVD &#9474;
&#9474; rips of this versions are allowed. &#9474;
&#9474; - NOTE: PAL - NTSC length difference comes from the no. of frames, not &#9474;
&#9474; extra footage. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - &#34;different features&#34; -> &#34;different footage&#34;? What is a feature in a &#9474;
&#9474; movie and how can it differ? &#9474;
&#9474; - How about Original Black &#38; White after a studio coloured version? &#9474;
&#9474; - Aren&#39;t violations of any rule not to be tolerated? Why makes this one &#9474;
&#9474; so special? &#9474;
&#9474; - Uh, excuse me? PAL &#60;-> NTSC time difference comes from the SAME number &#9474;
&#9474; of frames being played at a different rate. Example: &#9474;
&#9474; NTSC: 86400 frames &#247; 24frames/secs &#247; 60 secs/min = 60 mins &#9474;
&#9474; PAL: 86400 frames &#247; 25frames/secs &#247; 60 secs/min = 57.6 mins &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Directory Naming: &#9474;
&#9474; - All releases are to include production year (applies to the pre scene &#9474;
&#9474; as well). &#9474;
&#9474; - DO NOT indicate Ripping method, DVD/XviD release date, Genre, Audio &#9474;
&#9474; which was used (no AC3) or anything else! (ONLY WITHIN THE NFO) &#9474;
&#9474; - Movie distribution tags i.e. FESTIVAL, STV, LIMITED or TV (TV tag &#9474;
&#9474; is used for TV movies only) are allowed and shall be used wisely and &#9474;
&#9474; correctly. &#9474;
&#9474; - READ.NFO is strictly forbidden. &#9474;
&#9474; - Other permitted tags are: WS/FS &#60;rules above>, PROPER, REPACK, RERIP, &#9474;
&#9474; REAL, RETAIL, EXTENDED, REMASTERED, UNRATED, CHRONO, THEATRICAL, DC, &#9474;
&#9474; SE, UNCUT, INTERNAL, DUBBED, SUBBED. &#9474;
&#9474; - Acceptable characters in naming a directory include (NO spaces or &#9474;
&#9474; double dots - single dots or underscores ONLY): &#9474;
&#9474; &#9474;
&#9474; ABCDEFGHIJKLMNOPQRSTUVWXYZ &#9474;
&#9474; abcdefghijklmnopqrstuvwxyz &#9474;
&#9474; 0123456789 .-_ &#9474;
&#9474; &#9474;
&#9474; - Releases that are more than 1 CD MUST be named CD1, CD2, CD3 and so &#9474;
&#9474; on (&#39;disc1&#39; and others are NOT allowed). &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - I almost missed it, and I know that READ.NFO is often abused, but there &#9474;
&#9474; are legitimate uses for it. Banning it is an overreaction. &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; TV Series Notes: &#9474;
&#9474; - All Episodes &#60;DVD rips> are obligated to follow the above rules. &#9474;
&#9474; - Media usage capacity: &#9474;
&#9474; * 4x 20-23min = 1CD, Releases shall not be over 175mb. &#9474;
&#9474; * 3x 23-35min = 1CD, Releases shall not be over 233mb. &#9474;
&#9474; * 2x 35-50min = 1CD, Releases shall not be over 350mb. &#9474;
&#9474; * Episodes further then 50 minutes, will follow the length rules &#9474;
&#9474; of TXD2K5. &#9474;
&#9474; NOTE: Runtimes not mentioned above should fit on 1 CD i.e. 5x120mb, &#9474;
&#9474; 6x116mb, 7x100mb etc. &#9474;
&#9474; - Sizes mentioned above may be used only when minimum runtime is applied, &#9474;
&#9474; i.e. 23 minutes on 233mb or 35 minutes on 350mb. Media usage is at &#9474;
&#9474; ripper&#39;s discretion (i.e. 25 minutes may also be on 175mb). &#9474;
&#9474; - Recommendation: 26x22min = 1 DVD-R Disc, 13x45min = 1 DVD-R Disc &#9474;
&#9474; i.e. 172mb x 26eps or 344mb x 13eps fits on 1 burnable DVD-R Disc. &#9474;
&#9474; - Exception: 20-23min NTSC episodes (29.97 fps) may use 233mb. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - &#34;Episodes further then&#34; -> &#34;Episodes longer than&#34;? (and no comma) &#9474;
&#9474; - &#34;Sizes mentioned above may be used only when minimum runtime is &#9474;
&#9474; applied&#34;. What does this actually mean? It seems redundant? &#9474;
&#9474; - For consistency, how about 29.97fps 23-35min or 35-50min eps? &#9474;
&#9474; &#9474;
&#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496;
&#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
&#9474; &#9492;&#9472;&#9472;&#9472;[ NOTES TO THE RULES ]&#9472;&#9472;&#9472;&#9496; &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Source related notes: &#9474;
&#9474; - DVD source shall be RETAIL/DVD Screener only. Non DVD sources like &#9474;
&#9474; CAM, TS, TC, VHS, SCREENER, PDVD, LDVD etc, MUST be tagged with source &#9474;
&#9474; in dirname and MUST adhere to ALL TXD2K5 rules! &#9474;
&#9474; - DVD Screeners shall be clearly marked in the directory name and the &#9474;
&#9474; nfo shall contain presence of studio watermarking and counters or &#9474;
&#9474; lack thereof. &#9474;
&#9474; - Use of downsampled DVD-Rs as source is FORBIDDEN! &#60;only untouched> &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Maybe it&#39;s just me, but what is a LDVD? Is is supposed to be Laserdisc? &#9474;
&#9474; &#9474;
&#9474; &#9474;
&#9474; Internals: &#9474;
&#9474; - All INTERNALS must follow TXD2K5 rules, apart from the time length &#9474;
&#9474; rules and multi-language audio tracks rule (and will not be considered &#9474;
&#9474; as dupes). Other codecs and containers are allowed for experimental &#9474;
&#9474; purposes. &#9474;
&#9474; - NOTE: INTERNAL dirfix is not allowed as a basis of avoiding a nuke. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Excuse me? Groups can do whatever they want with internals. Internals &#9474;
&#9474; are not meant to be regulated. Internal dupes? Am I missing something? &#9474;
&#9474; - Many people disagree with dirfixing an internal to avoid a dupe, but &#9474;
&#9474; TDX doesn&#39;t have jurisdiction over internals. Let sites and dupechecks &#9474;
&#9474; decide what they want to do with them. &#9474;
&#9474; &#9474;
&#9474; Ripping related notes: &#9474;
&#9474; - Maximum VIDEO bitrates are covered by length rules. &#9474;
&#9474; - If DRF average would be over 4.0, the resolution should be lowered if &#9474;
&#9474; possible, until the minimal res is reached. See Resolution rules. &#9474;
&#9474; DRF average can be checked with DRF Analyzer &#60;It is recommended to &#9474;
&#9474; check the full avi file and not just the sample>. &#9474;
&#9474; - Quant. Matrix always has to be H.263/MPEG due to lack of hardware &#9474;
&#9474; support for Custom matrixes. &#9474;
&#9474; - Quarterpel/GMC forbidden due to lack of hardware support. &#9474;
&#9474; - Packed Bitstream is not supported on some of the major gen chipsets, &#9474;
&#9474; therefore using it, is not recommended. &#9474;
&#9474; - The use of ITU-R is not recommended since it gives an AR error of &#9474;
&#9474; around 2% from the original DVD&#39;s Aspect Ratio. &#9474;
&#9474; - Multi-language audio tracks are allowed only for INTERNALS. &#9474;
&#9474; Multiple languages should be interleaved into the AVI, with a &#9474;
&#9474; graphedit filter for each appropriate audio stream. &#9474;
&#9474; - NO intros, outros, betweenos, or any other form of defacement of the &#9474;
&#9474; movie will be tolerated. &#9474;
&#9474; &#9474;
&#9474; REBUTTAL: &#9474;
&#9474; - Our friend DRF again. DRF (Detail Removal Factor) is actually a DIVX &#9474;
&#9474; 3.11/SBC ATTRIBUTE. XViD&#39;s equivalent attribute is the Quantizer. &#9474;
&#9474; Obviously I&#39;m quite amused to see DRF mentioned in this new ruleset &#9474;
&#9474; which abolishes SBC. &#9474;
&#9474; - For those that really understand how quantizers work, especially with &#9474;
&#9474; regards to their relationship with the Quantization type, they&#39;d know &#9474;
&#9474; that the raw quant avg doesn&#39;t mean anything without the exact quant &#9474;
&#9474; matrix being used. As such, using the average quant as a statistic to &#9474;
&#9474; to determine the rip quality without considering the exact method of &#9474;
&#9474; quantization would be erroneous. Of course since this ruleset bans all &#9474;
&#9474; Custom Matrices (more on that later), that simplifies things...but MPEG &#9474;
&#9474; and h263 are two completely different animals and look very different &#9474;
&#9474; at comparable quants. As a result, blind avg quant comparison is &#9474;
&#9474; dangerous and not a good benchmark at all. &#9474;
&#9474; - While the argument about compatibility on standalones is a valid one, &#9474;
&#9474; many CQMs do in fact work on standalones and as long as rippers choose &#9474;
&#9474; well, the problems should be minor. On the flipside, the power of the &#9474;
&#9474; wide range of CQMs is unmatched. The choice of matrix gives control of &#9474;
&#9474; how XViD prioritizes the compression of the source material. The &#9474;
&#9474; quality of a high bitrate encode made with h263 or basic MPEG &#9474;
&#9474; quantization pales in comparison to one created with one of several &#9474;
&#9474; high bitrate matrices. &#9474;
&#9474; - The packed bitstream (PB) issue is one that is already solved and thus &#9474;
&#9474; I don&#39;t even know why it has to be brought up again. There are some &#9474;
&#9474; standalones that do not work with 2 consecutive B-Frames with PB and &#9474;
&#9474; there are some (fewer) that don&#39;t work without it. Luckily, a tool was &#9474;
&#9474; developed that allowed for PB to be removed from a video file without &#9474;
&#9474; the need to reencode. Unfortunately it doesn&#39;t work in reverse (It &#9474;
&#9474; can&#39;t add PB to a non PB file). So really, if there were a rule, it &#9474;
&#9474; should be that all B-Frames must be packed, as it would be simple &#9474;
&#9474; enough to remove them if necessary. Alternatively, rips with 2+ &#9474;
&#9474; consecutive B-Frames should be banned entirely. &#9474;
&#9474; - Finally, this whole ITU-R thing...Specifically, the referral is to the &#9474;
&#9474; ITU-R BT.601 Standard for Aspect Ratios. The ITU-R itself is a body &#9474;
&#9474; that establishes standards, so the phrase &#34;the use of ITU-R&#34; doesn&#39;t &#9474;
&#9474; make a whole lot of sense. It still doesn&#39;t make sense if you &#9474;
&#9474; substitute in &#34;ITU-R BT.601 Standard&#34; since you abide or obey standards,&#9474;
&#9474; you don&#39;t &#34;use&#34; them. The ruleset is probably just talking about the &#9474;
&#9474; Gknot checkbox. It is true that the difference between following the &#9474;
&#9474; standard and not doing so is about 2% on the AR. However, the jury is &#9474;
&#9474; still out on which is the correct way to proceed. For now, it really &#9474;
&#9474; seems to come down to the output device being used and what is &#9474;
&#9474; considered to be the &#34;correct&#34; viewing experience. Links below: &#9474;
&#9474; http://www.uwasa.fi/~f76998/video/conversion/ &#9474;
&#9474; http://forum.doom9.org/showthread.php?t=42708 &#9474;
&#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496;
&#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
&#9474; The Tradition Continues: TXD RULES 2K5 (2005-09-25) &#9474;
&#9474; TDX2K2 &#60;2002-07-12) 2K1 (2001-04-22) Original (2000-04-26) &#9474;
&#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496;
&#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
&#9474; &#9492;--------[ GROUPS ]--------&#9496; &#9474;
&#9474; TXD2K5 Rebuttal signed by the following XviD Groups: &#9474;
&#9474; &#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472; &#9474;
&#9474; &#9474;
&#9474; ME &#9474;
&#9474; &#9474;
&#9474; MYSELF &#9474;
&#9474; &#9474;
&#9474; AND I &#9474;
&#9474; &#9474;
&#9492;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9496;
&#9492;----[ Created by Me 2005. Respect goes to all TDX teams 2000-2002 ]----&#9496;
</pre>
</body>
</html>