Content:Files: Difference between revisions

 
(19 intermediate revisions by 2 users not shown)
Line 8: Line 8:
==Metadata==
==Metadata==
===Technical information===
===Technical information===
Information that is of technical character and in most cases indisputable after verified by [[Avdump2]]. For track level information, see [[Content:Files:Video]], [[Content:Files:Audio]] and  [[Content:Files:Subtitle]].
Information that is of technical character and in most cases indisputable after verified by {{Avdump-current-version}}. For track level information, see [[Content:Files:Video]], [[Content:Files:Audio]] and  [[Content:Files:Subtitle]].


====Type====
====Type====
Line 43: Line 43:


=====Level of evidence in determining group assignments=====
=====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 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.
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 64: Line 64:
* CRC tag in the filename:
* 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)
** If the file is from the fansub group's official torrent or DDL, then the file name is acceptable. (good source)
*** This excludes external subtitle/audio files that contain the ''main'' file's CRC '''only''', those should be added as 'CRC/Hash status' ''not compared/not available'', unless there is another official source with the external file's CRC/Hash
**** '''Example:'''
***** <code>[GuodongSubs][The Beauty Blogger][Sheng Shi Zhuang Niang][EP01][1080P][427.77 MB][1C1E794B].ass</code> (external subtitles) => not compared/not available
***** <code>[GuodongSubs][The Beauty Blogger][Sheng Shi Zhuang Niang][EP01][1080P][427.77 MB][1C1E794B].mkv</code> (main file) => matches official source
** CRC tags added afterwards by third parties should not be considered a valid 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.
** 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.
Line 73: Line 77:


====Version====
====Version====
''See also: [[Content:File relations]]''
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 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.
'''IMPORTANT''': Even if a group releases two files of the same episode, it does not automatically mean that the first has to be marked ''v1'' and the second has to be marked ''v2''. There are reasons other than error correction to release multiple files for a given episode, 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 a reason other than error correction is the cause of multiple releases. Please consult a moderator for any exceptions or uncertainties.


'''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.
# Example, [Ohys-Raws] released three 720p HDTV rips for an entire 12 episode series: set 1 of rips using the TBS HDTV source, set 2 using the Tokyo MX source, and set 3 using the AT-X source, for a total of 12 × 3 = 36 HDTV 720p files released. All 3 source-based releases are v1 files, they are not v2 and v3 files of each other. Add file notes to distinguish the raw source.
# Example: [HorribleSubs] releases CrunchyRoll rips with 12 files in 480p www and 12 files in 720p www for a series total of 24 files, 2 www per episode. These 480p www and 720p www releases are v1 files, they are not v2 files of each other.
# 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.
# Example: in highly exceptional cases, releases that would normally not be considered part of the same continuity may be labelled v2. For example, in this case [https://anidb.net/c15725208 here], the two 540p files for episodes 2 & 4 released by the group were meant to fix an audio problem with the corresponding 480p files, it is '''coincidental''' that the new audio came from a source that had a different resolution of 540p. In this case we considered the 540p files v2 of the 480 files. This case is an exception among exceptions, and must be considered by a moderator on a case-by-case basis.


{{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 different resolution releases 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>}}


===Other information===
===Other information===
Line 118: Line 129:
'''Also see:''' ''[[Votes:Animegroups]]''
'''Also see:''' ''[[Votes:Animegroups]]''
<br><br>
<br><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).
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 format of release is LD, it may be appropriate to use the higher range of the quality field, and bump up a level for the LD release, relative to the defaults below (i.e. bump from the default medium up to high instead); 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><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.
'''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.
Line 238: Line 249:
'''What is a private / personal file?'''
'''What is a private / personal file?'''


A private or personal file is a file that you create for yourself.  It is a file that is not released ''publicly on the internet''. For example, if you reencode a file for your own use, or you remux a bunch of files together to create a new file, these are private files as they are only available for your personal consumption.
A private file is a file that is not released '''publicly on the internet'''.
 
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 likely should not be added to AniDB.  "Published on the internet" includes, but is not limited towards:
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, AnimeBytes
* DDL links published on the fansub group's blog
* DDL links published on the fansub group's blog
* XDCC bots on IRC
* XDCC bots on IRC


Personal files are '''NOT''' to be added to AniDB.
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====
Line 271: Line 286:
Alternatively you can use the [[Mass add:Files|mass add file page]] which is linked at the bottom of every anime page (massf).
Alternatively you can use the [[Mass add:Files|mass add file page]] which is linked at the bottom of every anime page (massf).


Furthermore, it's strongly suggested (we basically demand it) to use [[Avdump2]] to parse the file before or after adding it to AniDB to get accurate metadata and to mark the file as verified (which causes some data of the file to stay locked and non-creq'able).
Furthermore, it's strongly suggested (we basically demand it) to use {{Avdump-current-version}} to parse the file before or after adding it to AniDB to get accurate metadata and to mark the file as verified (which causes some data of the file to stay locked and non-creq'able).
{{missing}}
{{missing}}


Line 281: Line 296:


==File relations==
==File relations==
See [[Content:File relations]].
{{main|Content:File relations}}
{{#lsth:Content:File relations|Overview}}


[[Category:Animeentries]]
[[Category:Animeentries]]
[[Category:Guidelines]]
[[Category:Guidelines]]
staff
1,114

edits

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