Content:Files: Difference between revisions

From AniDB
Jump to navigation Jump to search
m (... damn case being important in anchors)
 
(102 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{update}}
{{update}}
__NOTOC__
{{TOCright}}
Files are probably the most important part of AniDB's structure. They are what gets added to users mylists in order to mark episodes watched. Now, there are a few different kinds of files that can be added to the different episodes for anime, but all files have a few fields that apply to them:


<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
AniDB stores information ([[Wikipedia:Metadata|metadata]]) about digital files that at some point in history has been released on the Internet. This information is an integral part of AniDB and for many users the most important reason for using AniDB. Note that AniDB does not, never has and never will, have any copies of these files. Read the [[AniDB:General disclaimer|general disclaimer]] for more information on this.
[[Content:Files#ED2K_Sum|ED2K Sum]] | [[Content:Files#Various_other_hashes|Various other hashes]] | [[Content:Files#CRC_Status|CRC status]] | [[Content:Files#Size|Size]] | [[Content:Files#Type|Type]] | [[Content:Files#Extension|Extension]] | [[Content:Files#Version|Version]] | [[Content:Files#Release_date|Release date]] | [[Content:Files#Released_by|Released by]] | [[Content:Files#Comments|Comments]]
</div>


As a user you do of course not have to use any feature related to files; AniDB offers many features that are completely unrelated to them. There is also the concept of ''generic files'': If you want to add an anime to your MyList, but watched it on TV, have it on DVD or just don't care about registering actual files, see [[Files:Generic files]].


And we also have specific fields that only apply to video files, audio files and subtitle files:
==Metadata==
<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
===Technical information===
[[Content:Files#Video_files|Video files]]: [[Content:Files#Length|Length]] | [[Content:Files#Censored|Censored]] | [[Content:Files#Quality|Quality]] | [[Content:Files#Source|Source]] | [[Content:Files#Resolution|Resolution]] | [[Content:Files#Aspect_Ratio|Aspect Ratio]] | [[Content:Files#Video_Codec|Video Codec]] | [[Content:Files#Video_Bitrate|Video Bitrate]] | [[Content:Files#FPS|FPS]] | [[Content:Files#Video_Flags|Video Flags]]
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]].
</div><p>
<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
[[Content:Files#Audio_files|Audio files]]: [[Content:Files#Track_type|Track type]] | [[Content:Files#Audio_Language|Audio Language]] | [[Content:Files#Audio_Codec|Audio Codec]] | [[Content:Files#Audio_Bitrate|Audio Bitrate]] | [[Content:Files#Channels|Channels]]
</div></p><p>
<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
[[Content:Files#Subtitle_files|Subtitle files]]: [[Content:Files#Subtitle_type|Subtitle type]] | [[Content:Files#Subtitle_Language|Subtitle Language]] | [[Content:Files#Subtitle_Flags|Subtitle Flags]]
</div></p>
'''Note:''' for alot of these fields you can use [[avdump]] to analyze the video file. It can tell you most of the things you need to know.


And the last two sections in this article are about if something is/has gone wrong:
====Type====
<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
The type of file. Possible values: ''video file'', ''subtitle file'', ''audio file'', ''archive file'', ''linker file'', ''other''.
[[Content:Files#Your_version_is_corrupted...|Your version is corrupted...]] | [[Content:Files#Removing_bad_entries|Removing bad entries]]
</div>


===ED2K Sum===
====Extension====
===Ed2k-link===
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.
----
In this field you need to enter either a complete [[ed2k|ed2k-link]], or just an ed2k sum.
{{eyecatch|Note:|This is the only field that is ''required''!'''}}
:So long as you enter a link, not just a hash-sum.<br>If you enter a hash-sum you haveto fill out the size field too.


====Size====
The actual size of the file in bytes.


You can use various tools to get this, the ones we recommend are:
====Check/Hash sums====
:*[[AniDB O'Matic]] (Windows/Linux (through Wine [[AniDB O'Matic#How_to_make_AOM_work_in_Linux|read here]]))
The [[Wikipedia:Hash function|hash sums]] are used for verification and identification purposes and includes ''CRC32, ED2K, MD5, SHA1 and TTH''. Size+ED2K is the unique identifier used in AniDB.
:*[[WebAOM]] (Windows/Linux/OS X/Anything that runs [http://java.sun.com Java])
:*[[Avdump]] (Windows)
::These can also get you the other hash-sums that ought to be filled out.


==Various other hashes==
====Duration====
AniDB stores MD5, SHA1 and CRC32 sums for all the files where this is entered. It is recommended, though not necessary to fill these out. If you use any of the recommended tools to hash your files to get the ed2k-link, they can also give you these hashes as well.
The playback duration in <tt>hours:minutes:seconds</tt>.


==CRC status==
===Release information===
Groups often release files with the checksum of the correct file being published somewhere, for example in the IRC-channel's topic or directly in the filename. Now, only if the CRC you calculated from the file you have matches the CRC of the correct file, set the "CRC status" on AniDB to "crc matches official source".
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.


'''Note:''' If the file is a "''no group''" file, '''do not set crc correct status!''' Most raw files come from [http://en.wikipedia.org/wiki/Share share] or [http://en.wikipedia.org/wiki/Winny winny] hence no official crc is known!
====Group====
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|Not all RAW groups are credited. See [[which RAW groups to credit]].}}


Allowed Source for official CRC
=====Assigning files to a group when files may have been modified=====
* Official sfv (good source)
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>
* CRC listing on official page/IRC topic (good source)
<u>Example:</u>
* CRC tag in filename (not a good source, but works... kinda)
<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>
* [http://www.envirosphere.com/ Envirosphere] & [http://www.baka-updates.com/ Baka-Updates] (3rd hand info, but kinda works.)


==Size==
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:
This field is for how many bites the file is.
* 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.


If you entered an ed2k-link in the ed2k sum field instead of just the hash, you don't need to fill this out.
=====Level of evidence in determining group assignments=====
{{eyecatch|However:|if you did not, you '''haveto''' fill this out.}}
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.


==Type==
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.
Here you choose whether it is a video file, an audio file, a subtitle file or something else.


==Extension==
In summary:
Set which extension the file has. If you supplied an ed2k-link in the ed2k sum field, this is not necessary. The extension will be taken from the ed2k-link.
* Older fansub = lower bar
* More obscure fansub = lower bar


==Version==
====Release date====
Sometimes, the group makes mistakes and wants to correct them by releasing a second (third, fourth...) version, usually called "v2" ("v3", "v4", ...). If there is no such tag in the filename, it's normally "version 1".
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.


'''Note:''' For standardization purpose if the source changes the versions gets set back to v1.
====CRC/hash status====
:''Example: a group releases a file with source dtv. Later they release the same thing again from dvd. Both is to be considered v1!''
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.


==Release date==
{{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".}}
The date the group published the file. Have a look at the group's homepage or other release info pages like [http://www.envirosphere.com/ Envirosphere] or [http://baka-updates.com/ Baka Updates].


==Released by==
=====Allowed sources for official hash=====
Normally, the files are "tagged", meaning that the filename contains a string like "[AonE]" which you can look for in the according shortname dropdown-menu. Please note that not all groups on AniDB are listed under the tag they actually use, as AniDB can only have one distinctive tag for each group. <u>So make sure the group's full name matches as well</u>.<br>
* Official .sfv (CRC checksum) or .md5 (MD5 checksum) files (good source)
However, some people remove the group-tags from filenames. If you have such a file, please check the file, if the group-name is being displayed somewhere in it.
* 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)
*** 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.
** 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.


When you add a new file from a group that already have some files added for this anime, you can save yourself from going through the extra step of searching for the group again and again by using the '''by relation''' list, that contains only groups that already have at least one file added for this anime.<br>
=====No-lookthrough rule for CRC/hash verification=====
Otherwise, you will haveto enter the groupname into the searchfield and click '''Search'''. After doing that, a dropdown menu will appear and list groups whose name match your search.
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


If the group isn't listed, you have to [[Content:Groups|add it first]].
====Version====
''See also: [[Content:File relations]]''


'''Note:''' If a file is a joint release, like a file by e.g. ANBU-AonE, that joint group has its own group entry, so you should not add the file to either ANBU or AonE, but to the group that combines them both.
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'').


'''Note:''' If the file is a RAW, you should check [[which RAW groups to credit]].
'''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.


==Comments==
'''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.
File comments should only be made for important info, and always conforming to the [[Content:Filecomments|standardized forms for file comments]] if applicable. Don't enter what you thought of the release or some such nonsense. Use the [[Votes:Animegroups|anime-group-comments]] for that.


=Video files=
# 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.
This section expands on the special fields for video files that '''should''' be supplied.
# 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.
{{eyecatch|Note:|On '''most''' video files, you will also need to fill in the audio and subtitle information as well!}}
# 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.


<p>
{{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>}}
<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
[[Content:Files#Length|Length]] | [[Content:Files#Censored|Censored]] | [[Content:Files#Quality|Quality]] | [[Content:Files#Source|Source]] | [[Content:Files#Resolution|Resolution]] | [[Content:Files#Aspect_Ratio|Aspect Ratio]] | [[Content:Files#Video_Codec|Video Codec]] | [[Content:Files#Video_Bitrate|Video Bitrate]] | [[Content:Files#FPS|FPS]] | [[Content:Files#Video_Flags|Video Flags]]
</div></p>


==Length==
===Other information===
Enter how many hours, minutes and seconds the file lasts. Just check in your favourite media player. If you have a file that won't display its length correctly, try to use [[avdump]] to determine the length.
Other information that is set manually and in some cases disputable.


==Censored==
====Censored====
This only applies to animes that have both an uncensored and a censored version. If it only has one, leave this setting as the default: Unknown.
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.


==Quality==
====Source====
This is a very arbitrary field. It depends completely on the eye of the beholder. Set this to what you think the file deserves.
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.''


==Source==
=====Look-through considerations for Source field=====
Here you can set the source of the raw (unsubbed) anime. If you don't know the source, leave it as "unknown". If you find a tag like "(S)VHS" or "DVD" in the filename, choose the according option from the dropdown-menu.
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).
Sometimes, it's ok to make an educated guess: For animes that are released fansubbed shortly (within days/weeks) after they aired in Japan, you can safely assume "DTV" (Digital TV) as source. Another case for educated guessing is "HKDVD" (Hongkong-DVD) - the video-quality may be ok for them, but the translation is usually horrible, which is how you can spot them.


==Resolution==
====Source field for standalone subtitle files====
In this field you set which resolution the file has in pixels. Width x Height.
#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.
Or just use [[avdump]].
#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.
==Aspect Ratio==
##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.
Set the playback aspect ratio for the file.
##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.


===Video Codec===
====Quality field for standalone subtitle files====
===Video Bitrate===
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.
===FPS===
<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.
To find out what video codec, bitrate and fps is used for the file, we recommend that you use [[avdump]].
#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.


==Video Flags==
====Quality for non-subtitle files====
*Anamorphic: for an explanation of this, see [[Wikipedia:Anamorphic|here]].
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.''
*Clean video: set this flag if there is nothing hardsubbed in this file. RAWs are always clean.
*VFR: Variable Frame Rate. Use [[avdump]] for this.
*Wrong Aspect Ratio: If the file was encoded with the wrong viewing aspect ratio, check this box. One way to tell whether this is true is if what should be a circle on the screen isn't completely round, but rather elliptic.


=Audio files=
'''Also see:''' ''[[Votes:Animegroups]]''
This also applies to most video files, since they usually have atleast 1 audio track in them.
<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 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>
'''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.'''


<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
{| class="wikitable" border="1"
[[Content:Files#Track_type|Track type]] | [[Content:Files#Audio_Language|Audio Language]] | [[Content:Files#Audio_Codec|Audio Codec]] | [[Content:Files#Audio_Bitrate|Audio Bitrate]] | [[Content:Files#Channels|Channels]]
|-
</div>
!  Source
!  < 480p <br>(or equivalent)
!  480p or equivalents <br>(440x486 (NTSC), <br>520x576 (PAL, SECAM), etc)
!  720p
!  1080p
|-
|  camcorder
|  very low, <br>low
|  low
|  low, <br>'''medium'''
|  '''medium''', <br>high, <br>very high
|-
|  TV (ie, analog TV)
|  very low, <br>'''low'''
|  low, <br>'''medium'''
|  style="background-color: #FFEFEF;"| low, <br>'''medium'''
|  style="background-color: #FFEFEF;"| medium
|-
|  VHS
|  very low, <br>'''low'''
|  low, <br>'''medium'''
|  style="background-color: #FFEFEF;"| low, <br>'''medium'''
|  style="background-color: #FFEFEF;"| medium
|-
|  LD
|  low, <br>'''medium'''
|  medium, <br>'''high'''
|  style="background-color: #FFEFEF;"| high
|  style="background-color: #FFEFEF;"| high
|-
|  VCD
|  low, <br>'''medium'''
|  medium, <br>high
|  style="background-color: #FFEFEF;"| medium, <br>'''high'''
|  style="background-color: #FFEFEF;"| medium, <br>'''high'''
|-
|  SVCD
|  low, <br>'''medium'''
|  medium, <br>high
style="background-color: #FFEFEF;"| medium, <br>'''high'''
|  style="background-color: #FFEFEF;"| medium, <br>'''high'''
|-
|  HKDVD
|  low, <br>'''medium'''
|  medium, <br>high
|  style="background-color: #FFEFEF;"| medium, <br>'''high'''
|  style="background-color: #FFEFEF;"| medium, <br>'''high'''
|-
| DTV
|  low, <br>'''medium'''
|  medium, <br>high
| style="background-color: #FFEFEF;"| medium, <br>high
| style="background-color: #FFEFEF;"| medium, <br>high
|-
|  DVD
| low, <br>'''medium'''
|  medium, <br>'''high''', <br>'''very high'''
| style="background-color: #FFEFEF;"| high, <br>very high
| style="background-color: #FFEFEF;"| high, <br>very high
|-
|  www
|  low, <br>medium
| medium
|  high
|  very high
|-
|  HDTV
|  low, <br>medium
|  medium
|  high
|  very high
|-
|  HD-DVD
|  medium
|  high
|  very high
|  very high
|-
|  Blu-ray
|  medium
|  high
|  very high
|  very high
|-
|  unknown
|  Use discretion
|  Use discretion
|  Use discretion
|  Use discretion
|-
|}


==Track type==
====Description====
This field is for setting whether it is a normal audio track or:
Additional useful information about the file. See [[Content:Filecomments]].
*Commentary
*Fandub
*Alternative Voiceover
*Other, or
*Unknown


==Audio Language==
===Statistics===
Please specify what language is used.
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.


===Audio Codec===
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.
===Audio Bitrate===
===Channels===
----
Set which audio codec, bitrate and how many channels are used. We recommend using [[avdump]] for this.


=Subtitle files=
==Registering new files==
All fansubs have subtitles, only RAWs are without them, so this section should also be filled out for most files.
===What is accepted?===
====Private / Personal files====
The general rule is that [[Animeentries:Fileentries|file entries]] in AniDB are supposed to be useful for a larger group of users. Adding private files is therefore '''not allowed'''.


<div style="border: 1px dotted gray; text-align: center; background-color: #e2e2ff">
'''What is a private / personal file?'''
[[Content:Files#Subtitle_type|Subtitle type]] | [[Content:Files#Subtitle_Language|Subtitle Language]] | [[Content:Files#Subtitle_Flags|Subtitle Flags]]
</div>


==Subtitle type==
A private file is a file that is not released '''publicly on the internet'''.
Here you should specify whether the subs are:
*Hard subs
*Soft subs
*Supplementary soft subs (i.e. sign translation)
*Other, or
*Unknown.


==Subtitle Language==
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.
Select which language is used in the subs from the dropdown list.


==Subtitle Flags==
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:
*Dubsubbed - if the subtitles seem to be an exact match of the english (or other language) audio tracks, and doesn't follow the actual lipmovements very well, it is probably dubsubbed.
* public trackers like Nyaa
*Hearing impaired subs
* private trackers like BakaBT, AnimeBytes
*Image subs (VOBSUB)
* DDL links published on the fansub group's blog
*Styled subs (ASS/SSA)
* XDCC bots on IRC
*Subs for commentary audiostream
*Unstyled subs (SRT)


=Your version is corrupted...=
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.
[[Animeentries:Fileentries|Fileentries]] on AniDB are supposed to be useful for a larger group of users: One of them adds the entry and many others can use it (by adding it to their list).


===Adding wide-spread corrupted files===
Private files and personal files are '''NOT''' to be added to AniDB.
 
====Corruption====
An entry for a corrupted file may still be useful for others as long as it's likely that more people have the exact same corrupted file as you have. (For example if one source sent the corrupted version to many people.)
An entry for a corrupted file may still be useful for others as long as it's likely that more people have the exact same corrupted file as you have. (For example if one source sent the corrupted version to many people.)


If - and only if - this is the case, you can add the file normally to AniDB, marking it as "CRC invalid" and/or "Quality: Corrupted" if there are visible/audible errors in the file.
If - and only if - this is the case, you can add the file normally to AniDB, selecting ''CRC does not match official source'' and/or ''Quality: Corrupted'' if there are visible/audible errors in the file.
 
{{eyecatch|Warning|If the corruption is based on some hard- or software-problem on your side, or if you manually edited the file, you should '''not add''' them to AniDB as they serve no purpose for other users.}}
 
Don't worry - you can still list such files properly in your MyList. For example: You have a corrupted version of group X's release. Navigate to the corresponding episode where the regular, uncorrupted version of group X's release is listed and click on the "add to mylist" icon on the far right. On the next page, you can select the "Type: corrupted version/invalid CRC" so that your MyList entries properly indicate which version you have.
 
If there's no CRC-valid version of group X added for the release you have, consider adding the episodes' [[generic files]] to your list instead.
 
====Remuxed files====
# They have to be ''wide-spread'' (see above); private files are not allowed.
# Do '''not''' mark them with the original group. Use ''no group'' or make your own group, adding the original group's name the subtitles/video are taken from to the file's description.
# Adding such files is generally frown upon unless some value was actually added in the remuxing process.
 
===How to add===
{{eyecatch|Important|Please consult '''[[Tutorial:How_to_Add_Files_for_Dummies!]]''' if this is your first time adding files.}}
 
Since files in AniDB are tied with an actual episode, the place where you add files is at the far right of each episode entry. Click the "add file" icon that looks like this: [[Image:Anidb file add.gif]], and it will take you to a new page where you can fill in the information about the file you want to add. For video files, the most important fields are: '''ED2K-link''', '''CRC'''/'''CRC Status''', '''Release group''' and '''Audio''' and '''Subtitle languages'''.


===Adding "personal" corrupted files===
Alternatively you can use the [[Mass add:Files|mass add file page]] which is linked at the bottom of every anime page (massf).


If your specific (corrupted) version of the file isn't listed on AniDB, for example because of some hard- or software-problem on your side or because you manually edited the files, in most cases you should not add them to AniDB, because they serve no purpose for other users.
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}}


Don't worry - you can still list such files properly in your mylist. For example: You have a corrupted version of group X's release. Navigate to the corresponding episode where the regular, uncorrupted version of group X's release is listed and click on the "add file ()" icon. On the next page, you can select the "Type: corrupted version/invalid crc" so that your mylist-entries properly indicate which version you have.
==Editing file entries==
For editing see [[How to get started with creqing]].


If there's no crc-valid version of group X added for the release you have, consider adding the episodes' [[generic files]] to your list instead.
==Removing file entries==
If you added a bad entry you can also remove it as long as no one else has added it to his/her [[MyList]]. Otherwise, you have to issue a delete request.


=Removing bad entries=
==File relations==
If you added a bad entry yourself you can remove it as long as no one put that file in his/her [[mylist]]. In that case you don't have the neccessary rights to remove it. Please post the entry which should get removed here: [http://www.anidb.net/forum/viewforum.php?f=3 DB Change Requests]
{{main|Content:File relations}}
{{#lsth:Content:File relations|Overview}}


[[Category:Animeentries]][[Category: Guidelines]]
[[Category:Animeentries]]
[[Category:Guidelines]]

Latest revision as of 21:06, 14 May 2023

The information on this page needs to be updated to reflect the current status of AniDB.
Remove this message when done.

AniDB stores information (metadata) about digital files that at some point in history has been released on the Internet. This information is an integral part of AniDB and for many users the most important reason for using AniDB. Note that AniDB does not, never has and never will, have any copies of these files. Read the general disclaimer for more information on this.

As a user you do of course not have to use any feature related to files; AniDB offers many features that are completely unrelated to them. There is also the concept of generic files: If you want to add an anime to your MyList, but watched it on TV, have it on DVD or just don't care about registering actual files, see Files:Generic files.

Metadata

Technical information

Information that is of technical character and in most cases indisputable after verified by Avdump3. For track level information, see Content:Files:Video, Content:Files:Audio and Content:Files:Subtitle.

Type

The type of file. Possible values: video file, subtitle file, audio file, archive file, linker file, other.

Extension

Short name of the container format, see 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

The actual size of the file in bytes.

Check/Hash sums

The hash sums are used for verification and identification purposes and includes CRC32, ED2K, MD5, SHA1 and TTH. Size+ED2K is the unique identifier used in AniDB.

Duration

The playback duration in hours:minutes:seconds.

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 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

AniDB stores the name and group tag of the group/person that produced and released a file. The group tag is typically contained within [ ] square brackets in the filename, for example "[AonE]".

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.
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.
Example:

* [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].

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 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 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

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/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 file verification if you are unfamiliar with this subject.

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)
      • 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:
          • [GuodongSubs][The Beauty Blogger][Sheng Shi Zhuang Niang][EP01][1080P][427.77 MB][1C1E794B].ass (external subtitles) => not compared/not available
          • [GuodongSubs][The Beauty Blogger][Sheng Shi Zhuang Niang][EP01][1080P][427.77 MB][1C1E794B].mkv (main file) => matches official 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

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).

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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 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.
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:
Labelled as v2 of https://anidb.net/f2030447

Other information

Other information that is set manually and in some cases disputable.

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

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.

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

  1. 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.
  2. 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.
    1. 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.
    2. 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.
  3. For standalone subtitle files released on their own without video files:
    1. If the subtitles are 100% fan translations, mark the source as unknown.
    2. 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.
    3. 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.

  1. 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.
  2. 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.
  3. For standalone subtitle files released on their own without video files:
    1. If the subtitles are 100% fan translations, mark the quality as unknown.
    2. 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.
    3. 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.

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 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).

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.

Ultimately, use some discretion and common sense.

Source < 480p
(or equivalent)
480p or equivalents
(440x486 (NTSC),
520x576 (PAL, SECAM), etc)
720p 1080p
camcorder very low,
low
low low,
medium
medium,
high,
very high
TV (ie, analog TV) very low,
low
low,
medium
low,
medium
medium
VHS very low,
low
low,
medium
low,
medium
medium
LD low,
medium
medium,
high
high high
VCD low,
medium
medium,
high
medium,
high
medium,
high
SVCD low,
medium
medium,
high
medium,
high
medium,
high
HKDVD low,
medium
medium,
high
medium,
high
medium,
high
DTV low,
medium
medium,
high
medium,
high
medium,
high
DVD low,
medium
medium,
high,
very high
high,
very high
high,
very high
www low,
medium
medium high very high
HDTV low,
medium
medium high very high
HD-DVD medium high very high very high
Blu-ray medium high very high very high
unknown Use discretion Use discretion Use discretion Use discretion

Description

Additional useful information about the file. See Content:Filecomments.

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

What is accepted?

Private / Personal files

The general rule is that file entries in AniDB are supposed to be useful for a larger group of users. Adding private files is therefore not allowed.

What is a private / personal file?

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 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
  • private trackers like BakaBT, AnimeBytes
  • DDL links published on the fansub group's blog
  • 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

An entry for a corrupted file may still be useful for others as long as it's likely that more people have the exact same corrupted file as you have. (For example if one source sent the corrupted version to many people.)

If - and only if - this is the case, you can add the file normally to AniDB, selecting CRC does not match official source and/or Quality: Corrupted if there are visible/audible errors in the file.

Warning If the corruption is based on some hard- or software-problem on your side, or if you manually edited the file, you should not add them to AniDB as they serve no purpose for other users.

Don't worry - you can still list such files properly in your MyList. For example: You have a corrupted version of group X's release. Navigate to the corresponding episode where the regular, uncorrupted version of group X's release is listed and click on the "add to mylist" icon on the far right. On the next page, you can select the "Type: corrupted version/invalid CRC" so that your MyList entries properly indicate which version you have.

If there's no CRC-valid version of group X added for the release you have, consider adding the episodes' generic files to your list instead.

Remuxed files

  1. They have to be wide-spread (see above); private files are not allowed.
  2. Do not mark them with the original group. Use no group or make your own group, adding the original group's name the subtitles/video are taken from to the file's description.
  3. Adding such files is generally frown upon unless some value was actually added in the remuxing process.

How to add

Important Please consult Tutorial:How_to_Add_Files_for_Dummies! if this is your first time adding files.

Since files in AniDB are tied with an actual episode, the place where you add files is at the far right of each episode entry. Click the "add file" icon that looks like this: , and it will take you to a new page where you can fill in the information about the file you want to add. For video files, the most important fields are: ED2K-link, CRC/CRC Status, Release group and Audio and Subtitle languages.

Alternatively you can use the 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 Avdump3 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).

The description is missing or severely incomplete.
If you can, please help by explaining it.

Editing file entries

For editing see How to get started with creqing.

Removing file entries

If you added a bad entry you can also remove it as long as no one else has added it to his/her MyList. Otherwise, you have to issue a delete request.

File relations

Main article: Content:File relations

File relations, like the name implies, are relations between files on AniDB. There are two types of file relations; File-File and File-Ep. The former tells how two different files relate and the later tells how a file relates to different episodes.