Content:Files
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 Avdump2. 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, other.
Extension
Short name of the container format, see Wikipedia. Possible values: .avi, .mpg, .mpeg, .rm, .rmvb, .asf, .wmv, .mov, .ogm, .mp4, .mkv, .rar, .zip, .ace, .srt, .sub, .ssa, .smi, .idx, .ass, .txt, .swf, .flv, .ts, .ogv, .7z, .mp3, .aac, .ac3, .dts, .flac, .mka, .wav.
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 none of these fields have any meaning and should therefore not be set.
Group
AniDB stores the name and short name of the group/person that produced and released a file. The short name is usually found as tags in file names, for example "[AonE]". Please note that not all groups registered in AniDB are listed with the tag they actually use, as AniDB can only have one distinctive tag for each group.
| 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. |
Release date
The date when the group released the file. Usually provided on the group's homepage or on some other release info site like Envirosphere or Baka Updates.
CRC status
Indicates whether the file entry in AniDB represents a perfect copy of the original file or not. You may request a change of the CRC Status if its not checked yet.
See also: Allowed Sources for official CRC
| Note | Not all groups provide CRC checksums for their files. This means that this status has no meaning and will have the value "not checked against official CRC". |
Read more about file verification if you are unfamiliar with this subject.
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).
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.
| 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: Labelled as v2 of https://anidb.net/f2030447 |
Other information
Other information that is set manually and in some cases disputable.
Censored
Mainly used for files with pornographic content.
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
- 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 difference source than the video, mark the subtitles as the source where the subtitles came from, and apply look-through rules.
- For example, group XXX releases BD source files, and attached to this release are standalone subtitle files ripped from HorribleSubs and 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.
- 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 directly from the steaming service or indirectly 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 UTW's rip of a BD), mark the source as the corresponding media type.
Quality 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.
- 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 difference source than the video, mark the subtitles at the same quality level as unknown.
- 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 directly from the steaming service or indirectly 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 UTW'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 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).
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
- The description is missing or severely incomplete.If you can, please help by explaining it.
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 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.
As a general statement, if the files were not publicly on the internet, they should not be added to AniDB. "Published on the internet" includes:
- public trackers like Nyaa
- private trackers like BakaBT
- DDL links published on the fansub group's blog
- XDCC bots on IRC
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
- 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
| 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 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).
- 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.