staff
1,124
edits
Content:Files: Difference between revisions
Jump to navigation
Jump to search
→Assigning files to a group when files may have been modified: 9-bit
m (→Assigning files to a group when files may have been modified: capitalization) |
|||
| 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 | <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> | ||
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: | ||