staff
1,114
edits
Content:Files: Difference between revisions
Jump to navigation
Jump to search
m
→Private / Personal files: missing word
(→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) |
m (→Private / Personal files: missing word) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 29: | Line 29: | ||
====Group==== | ====Group==== | ||
AniDB stores the name and group tag of the [[Content:Groups|group/person]] that produced and released a file. The | AniDB stores the name and group tag of the [[Content:Groups|group/person]] that produced and released a file. The group tag is typically contained within [ ] square brackets in the filename, for example "[AonE]". | ||
{{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]].}} | ||
| Line 35: | Line 35: | ||
=====Assigning files to a group when files may have been modified===== | =====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> | 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> | |||
<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 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: | ||
* | * A 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. A 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 | * 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 | =====Level of evidence in 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 | 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 80%+ 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. | 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. | ||
| Line 238: | Line 238: | ||
'''What is a private / personal file?''' | '''What is a private / personal file?''' | ||
A private | A private file is a file that is not released '''publicly on the internet'''. | ||
As a general statement, if the files were not published on the internet, they likely should not be added to AniDB. "Published on the internet" includes, but is not limited towards: | The most common example of a private file are personal files you create and/or modify solely for your personal consumption without further public distribution; this includes: personal remuxes and repackaged files, personal re-encodes, personal edits. | ||
As a general statement, if the files were not '''published on the internet''', they are private files and likely should not be added to AniDB. "Published on the internet" includes, but is not limited towards: | |||
* public trackers like Nyaa | * public trackers like Nyaa | ||
* private trackers like BakaBT | * private trackers like BakaBT | ||
| Line 246: | Line 248: | ||
* XDCC bots on IRC | * XDCC bots on IRC | ||
Files that are shared "in a public place", but not broadly available on the internet, do not count as '''published on the internet'''. For example, a hard drive stored "in a public place" such as an internet cafe, with files free to be shared by anyone that visits the cafe, does not count as "published on the internet". While these files may not be personal, they are still not sufficiently public. | |||
Private files and personal files are '''NOT''' to be added to AniDB. | |||
====Corruption==== | ====Corruption==== | ||