Content:Files: Difference between revisions

Jump to navigation Jump to search
Line 36: Line 36:
In general, AniDB applies a "last modified" doctrine when it comes to assigning groups; this is done via the "no lookthrough" rule. When assigning groups, assign the file to the last group that modified it; we do not trace it backwards to the "original" group.<br>
In general, AniDB applies a "last modified" doctrine when it comes to assigning groups; this is done via the "no lookthrough" rule. When assigning groups, assign the file to the last group that modified it; we do not trace it backwards to the "original" group.<br>
<u>Example:</u>
<u>Example:</u>
<pre style="white-space: pre-wrap;">* [AonE] issues a release in 1080p h.264 hi10p.  [Deadfish] then takes [AonE]'s release, and reencodes it from h.264 hi10p to 720p h.264 8-bit. [Deadfish] is the group that last modified, so the file is assigned to [Deadfish]. We do not "lookthrough" and assign the file to the original [AonE].</pre>
<pre style="white-space: pre-wrap;">* [AonE] issues a release in 1080p h.264 hi10p.  [Deadfish] then takes [AonE]'s release, and reencodes it from 1080p h.264 hi10p to 720p h.264 8-bit. [Deadfish] is the group that last modified, so the file is assigned to [Deadfish]. We do not "lookthrough" and assign the file to the original [AonE].</pre>


When determining whether a given file is a remux or not, it is not always clear, especially if the groups are obscure, the groups release anonymously, and/or the files in question are very old.  Here are some common pitfalls/misconceptions:
When determining whether a given file is a remux or not, it is not always clear, especially if the groups are obscure, the groups release anonymously, and/or the files in question are very old.  Here are some common pitfalls/misconceptions:
staff
1,112

edits

Navigation menu

MediaWiki spam blocked by CleanTalk.
MediaWiki spam blocked by CleanTalk.