staff
1,124
edits
(→Group: removing the comment about group tags having to be unique in the DB, since they don't have to be anymore) |
(→Group: adding some language around assigning files to groups, including the "no lookthrough" rule, and the application of a lower bar of evidence for older and more obscure fansubs) |
||
Line 32: | Line 32: | ||
{{eyecatch|Note|If a file is a joint release, like a file by e.g. ANBU-AonE, that joint group has its own group entry. The file should not be registered under either ANBU or AonE, but to the group that combines them both.}} | {{eyecatch|Note|If a file is a joint release, like a file by e.g. ANBU-AonE, that joint group has its own group entry. The file should not be registered under either ANBU or AonE, but to the group that combines them both.}} | ||
{{eyecatch|Note|Not all RAW groups are credited. See [[which RAW groups to credit]].}} | {{eyecatch|Note|Not all RAW groups are credited. See [[which RAW groups to credit]].}} | ||
=====Assigning files to a group when files may have been modified===== | |||
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> | |||
'''--Example:''' | |||
<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 8p. [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: | |||
* The watermark in the video cannot be relied upon when assigning groups; a reencode would keep the watermark of the original group, rather than reflect the reencoding group. The watermark can generally confirm the original source, for the purposes of attribution in the [[Groupentries:Status#Animegroup_Release_Note_Comments|Animegroup release Notes]]; we do not apply too much weight on this for determining who is the "last modified" group. | |||
* The names of tracks in the mkv metadata (e.g. name of the subtitle track) cannot be relied upon when assigning groups; mkvmerge by default keeps the existing track name, so if a remuxing group does not change it, the track name would be a false positive for the original group. The track name can generally ''help'' confirm the original source, for the purposes of attribution in the [[Groupentries:Status#Animegroup_Release_Note_Comments|Animegroup release Notes]]; we do not apply too much weight on this for determining who is the "last modified" group. | |||
=====Level of evidence in determining determining group assignments===== | |||
AniDB generally applies a high bar of evidence when making changes to the database; the evidence needs to show "beyond reasonable doubt", such as an 90%+ probability, that the change is valid -- this is comparable to the level of evidence required to convict a crime in a common law system. | |||
However, AniDB also considers the practicality of finding this level of evidence; we recognize that fansubs are generally not well documented, and that this is especially true as the fansubs in question become more obscure or go further back in time. To remedy this issue, as a general rule, we apply a lower bar of evidence for older fansubs; "the preponderance of the evidence", e.g. "more likely than not" (i.e. 51%+ probability) is sufficient to prove that the change is valid -- this is comparable to the level of evidence required to prove a civil claim in a common law system. | |||
In summary: | |||
* Older fansub = lower bar | |||
* More obscure fansub = lower bar | |||
====Release date==== | ====Release date==== |