staff
1,114
edits
Content:Files: Difference between revisions
Jump to navigation
Jump to search
m
→Private / Personal files: missing word
(→Version: added an importance flag. I would have swapped the paragraphs around, but that wouldn't read naturally, so this is a close substitute without using the actual eyecatch template) |
m (→Private / Personal files: missing word) |
||
| (36 intermediate revisions by 2 users not shown) | |||
| Line 11: | Line 11: | ||
====Type==== | ====Type==== | ||
The type of file. Possible values: ''video file'', ''subtitle file'', ''audio file'', ''other''. | The type of file. Possible values: ''video file'', ''subtitle file'', ''audio file'', ''archive file'', ''linker file'', ''other''. | ||
====Extension==== | ====Extension==== | ||
Short name of the container format, see [[Wikipedia:Filename extension|Wikipedia]]. | Short name of the container format, see [[Wikipedia:Filename extension|Wikipedia]]. All common and many uncommon video, audio, subtitle and archive file formats are supported; contact the staff if you have a file in an unusual file format we don't yet support. | ||
====Size==== | ====Size==== | ||
The actual size of the file in bytes. | The actual size of the file in bytes. | ||
| Line 26: | Line 26: | ||
===Release information=== | ===Release information=== | ||
Information related to the actual ''release'' of the file: ''group'', ''release date'', ''CRC status'' and ''version''. If the origin of a file is unknown, i.e. ''no group'', then | Information related to the actual ''release'' of the file: ''group'', ''release date'', ''CRC status'' and ''version''. If the origin of a file is unknown, i.e. ''no group'', then most of these fields have no meaning and should therefore not be set. Release date can be set for no group files, but only when it can be reliably determined. | ||
====Group==== | ====Group==== | ||
AniDB stores the name and | 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]].}} | ||
=====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> | |||
<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 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: | |||
* 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 Release Notes]]; we do not apply too much weight on this for determining who is the "last modified" group. | |||
=====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 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. | |||
In summary: | |||
* Older fansub = lower bar | |||
* More obscure fansub = lower bar | |||
====Release date==== | ====Release date==== | ||
The date when the group released the file. Usually provided on the group's homepage or on | The date when the group released the file. Usually provided on the group's homepage or on the relevant torrent tracker page. Release dates should be added according to the time of release in the UTC time zone, so sources whose timezone is known are preferred over ones displaying dates in unknown timezones. | ||
====CRC status==== | ====CRC/hash status==== | ||
Indicates whether the file entry in AniDB represents a perfect copy of the original file or not. You may request a change of this status if it hasn't been checked yet. Read more about [[Wikipedia:File verification|file verification]] if you are unfamiliar with this subject. | |||
{{eyecatch|Note|Not all groups provide checksums for their files. This means that this status has no meaning and will have the value "not checked against official CRC/Hash".}} | |||
=====Allowed sources for official hash===== | |||
* Official .sfv (CRC checksum) or .md5 (MD5 checksum) files (good source) | |||
* CRC listing on official page or in the topic of the group's IRC channel (good source) | |||
* CRC tag in the filename: | |||
** If the file is from the fansub group's official torrent or DDL, then the file name is acceptable. (good source) | |||
** CRC tags added afterwards by third parties should not be considered a valid source. | |||
** It should be noted that you should also check the actual calculated CRC of your file and compare it to the CRC in the filename to ensure that you don't yourself have a corrupted file. | |||
=====No-lookthrough rule for CRC/hash verification===== | |||
CRCs and other hashsums are only considered valid for verification if they are calculated '''directly''' from the target file in its entirety. This means that indirect checksums like the following ones are not to be considered: | |||
* Checksums of a ZIP/RAR/etc. archive (or set of archives) containing the file in question, even if the archive only contains one file | |||
* The inherent block-level checksums used by the BitTorrent protocol | |||
====Version==== | ====Version==== | ||
Sometimes the group makes mistakes and wants to correct them by releasing a second (third, fourth...) version, usually called ''v2'' (''v3, v4, ...''). This field is usually based on information in the file name (where no information normally means ''version 1''). | Sometimes the group makes mistakes and wants to correct them by releasing a second (third, fourth...) version, usually called ''v2'' (''v3, v4, ...''). This field is usually based on information in the file name (where no information normally means ''version 1''). | ||
'''IMPORTANT''': Even if a group releases two files of the same episode it does not mean that the first has to be marked ''v1'' and the second ''v2''. There are other reasons to do something like that other than correcting mistakes | '''IMPORTANT''': Even if a group releases two files of the same episode it does not mean that the first has to be marked ''v1'' and the second has to be marked ''v2''. There are other reasons to do something like that other than correcting mistakes, such as: different source (DTV/DVD), different sub languages, dual audio vs single audio releases, high and low quality versions, etc. | ||
'''Discretion should be applied''' when "other reasons" are the cause of multiple releases. For example, if the group's intent is to release as a final product only a dual audio release, but they release a single audio release as a "v0" or "draft" version, then we should consider this single audio "draft" within the version continuity of any subsequent dual audio releases. However, if the group's intent is to release as a final product both a single and dual audio release, do not combine the versioning continuity. | |||
{{eyecatch|Note|We generally do not consider resolution changes and source changes as version bumps. That being said, you are free to add a file comment, indicating a file is marked as v2 and intended to replace a certain file. For example: <pre>Labelled as v2 of https://anidb.net/f2030447</pre>}} | {{eyecatch|Note|We generally do not consider resolution changes and source changes as version bumps. That being said, you are free to add a file comment, indicating a file is marked as v2 and intended to replace a certain file. For example: <pre>Labelled as v2 of https://anidb.net/f2030447</pre>}} | ||
| Line 56: | Line 85: | ||
====Censored==== | ====Censored==== | ||
Only used and available for files with pornographic content. In rare borderline anime entries not classified as 18 Restricted, both uncensored and censored versions may still be available; in this case, include "Censored" or "Uncensored" in the file description field instead. | |||
====Source==== | ====Source==== | ||
The ''original source of the content''. Possible values are; ''unknown, camcorder, TV (ie, analog TV), DTV, HDTV, VHS, VCD, SVCD, LD, DVD, HKDVD, HD-DVD, Blu-ray, www.'' | The '''''original''' source of the content''. Possible values are; ''unknown, camcorder, TV (ie, analog TV), DTV, HDTV, VHS, VCD, SVCD, LD, DVD, HKDVD, HD-DVD, Blu-ray, www.'' | ||
====Quality==== | =====Look-through considerations for Source field===== | ||
When considering source, we look at from which release '''by the original publisher/producer''' this file originated. For example, if a fansub released a file that was a rip from a web streaming website, but the web streaming website itself ripped its video from a BDMV, then the fansub-released file has its source marked as BD; the original publisher/producer source is the BD release, and not an HDTV release (i.e. video capture of a Japanese TV channel), and not a web simulcast (i.e. video rip from a streaming site like Crunchyroll, Funimation, or Daisuki). | |||
====Source field for standalone subtitle files==== | |||
#When standalone subtitle files are released together with video files and the subtitles come from '''the same source as the video''', mark the subtitles as the same source as the video files. | |||
#When standalone subtitle files are released together with video files and the subtitles come from '''a different source than the video''', mark the subtitles as the source where the subtitles came from, and apply look-through rules. | |||
##For example, [Dmon] releases BD source files, and attached to this release are standalone subtitle files ripped from [HorribleSubs] (and possibly edited by the fansub). Since the standalone subtitles are not from the BD, their actual source is documented. Applying the look-through rules; [HorribleSubs] rips from Crunchyroll, so the standalone subtitle files are set as www. | |||
##If the source of the subtitle is an original fan translation, mark the subtitle file source the same source as the original fan translation's release. | |||
#For standalone subtitle files released on their own without video files: | |||
##If the subtitles are 100% fan translations, mark the source as unknown. | |||
##If the subtitles were ripped from a web streaming service such as Crunchyroll, either a direct rip or an indirect rip by extracting from another fansub's release (i.e. taking the subtitle track from [HorribleSubs]' rip of Crunchyroll), mark the source as www. | |||
##If the subtitles were ripped from a home media release (LD, VHS, VCD, DVD, BD, etc), either directly from the home media or indirectly by extracting from another fansub's release (i.e. taking the subtitle track from [Exiled-Destiny]'s rip of a BD), mark the source as the corresponding media type. | |||
====Quality field for standalone subtitle files==== | |||
The quality field is intended to indicate encode quality for video and audio; as such it is much less meaningful for standalone subtitle files. In consideration of this fact, the following general guidelines apply for the quality field as it relates to standalone subtitle files. | |||
<br> | |||
#When standalone subtitle files are released together with video files and the subtitles come from '''the same source as the video''', mark the subtitles at the same quality level as the video files. If there are multiple concurrent video releases (i.e. 720p and 1080p) where each release has a different quality level, but the subtitles are meant to be used for both sets of videos, set the quality level of the subtitles to match the higher quality release's level. | |||
#When standalone subtitle files are released together with video files and the subtitles come from '''a different source than the video''', mark the subtitles at the same quality level as the originating source. | |||
#For standalone subtitle files released on their own without video files: | |||
##If the subtitles are 100% fan translations, mark the quality as unknown. | |||
##If the subtitles were ripped from a web streaming service such as Crunchyroll, either a direct rip or an indirect rip by extracting from another fansub's release (i.e. taking the subtitle track from [HorribleSubs]' rip of Crunchyroll), mark the quality as unknown. | |||
##If the subtitles were ripped from a home media release (LD, VHS, VCD, DVD, BD, etc), either directly from the home media or indirectly by extracting from another fansub's release (i.e. taking the subtitle track from [Exiled-Destiny]'s rip of a BD), mark the quality as unknown. | |||
====Quality for non-subtitle files==== | |||
This is a very arbitrary field. It depends completely on the eye of the beholder. You should not put too much meaning into it, but rather use it as a general pointer of quality. Possible values are; ''eyecancer, very low, low, med, high, very high.'' | This is a very arbitrary field. It depends completely on the eye of the beholder. You should not put too much meaning into it, but rather use it as a general pointer of quality. Possible values are; ''eyecancer, very low, low, med, high, very high.'' | ||
'''Also see:''' ''[[Votes:Animegroups]]''<br> | '''Also see:''' ''[[Votes:Animegroups]]'' | ||
As a '''general''' guideline, refer to the below for a soft-rule convention that is generally followed. The below table can be seen as a "default" or "starting point". If a particular file has sub-par quality, mark down its qualid field relative to the default, as appropriate. Also note, the historical context of the anime should be kept in mind. For example. if an anime is released in the 70s, and the highest quality medium of release is LD, it may be appropriate to use the higher range of tehbump the quality field up a level for the LD release, relative to the defaults below; the goal is to use the qualid field as a differentiator, to identify the LD release as the definitive release relative to other options that may be available (TV, VHS, etc).<br> | <br><br> | ||
'''Note:''' All items highlighted in red below are upscales by definition, as the specifications of the mentioned media do not reach into those resolution ranges. Items in bold signify the more common qualid (if applicable), where more than 1 is specified.<br> | As a '''general''' guideline, refer to the below for a soft-rule convention that is generally followed. The below table can be seen as a "default" or "starting point". If a particular file has sub-par quality, mark down its qualid field relative to the default, as appropriate. Also note, the historical context of the anime should be kept in mind. For example. if an anime is released in the 70s, and the highest quality medium of release is LD, it may be appropriate to use the higher range of tehbump the quality field up a level for the LD release, relative to the defaults below; the goal is to use the qualid field as a differentiator, to identify the LD release as the definitive release relative to other options that may be available (TV, VHS, etc). | ||
<br><br> | |||
'''Note:''' All items highlighted in red below are upscales by definition, as the specifications of the mentioned media do not reach into those resolution ranges. Items in bold signify the more common qualid (if applicable), where more than 1 is specified. | |||
<br><br> | |||
'''Ultimately, use some discretion and common sense.''' | '''Ultimately, use some discretion and common sense.''' | ||
| Line 167: | Line 222: | ||
===Statistics=== | ===Statistics=== | ||
This section provides some basic insight on how many users claim to have had this file and what kind of media they currently have it on. The following statistics are given: | |||
* ''internal'': The number of users who currently have the file on their hard disk. | |||
* ''external'': The number of users who have stored this file on an external storage, such as a NAS or a burned DVD. | |||
* ''deleted'': The number of users who formerly had this file but don't have it anymore. | |||
* ''unknown'': The number of users who haven't specified the location of this file on their mylist. | |||
* ''total'': The total number of users with this file on their mylist. Clicking on this link opens a detailed list of those users. | |||
Do note that not all users share the storage status of their files publicly, or in some cases don't even allow to see you on the user list, and in this case the first four numbers may not sum up to the total number of users. | |||
==Registering new files== | ==Registering new files== | ||
| Line 176: | 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 | 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 184: | 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==== | ||