Groupentries:Status

From AniDB
Revision as of 01:25, 23 October 2016 by CDB-Man (talk | contribs) (→‎Common Cases: sub headers)
Jump to navigation Jump to search

The Groupstatus displays information about the current state of a release. Group release comments, such as sources for subtitles and raws, are also stored here.
This information is displayed in the groupinfobox on every anime entry and in the Groups page for every listed group in AniDB.

Note This feature doesn't have to be 100% correct as its data is generated by AniDB automatically for most parts and is very dependent on the users. This means if users didn't add all files a group released it won't show the "true" status.
Please note that the states are not updated in real time. See: Routine maintenance

Animegroup Release Note Comments

Step 1: click on the Animegroup comment edit button to edit the release notes.
Step 2: enter the release notes in the "Note" field. Provide a link to the source of the information in the "Comment for Mod" field.
Note If there are any uncertainties, such as examples not covered below, please consult CDB-Man for clarification.

The Animegroup release note comments are used to provide information on a group's particular release of a given anime. The most common information here would be credit/attribution for original sources, such as if the subtitles are from another group's work, or if a specific group's raws were used.

Note Generally, we don't care to track which encoding staff member in the group did the encode. If the encode was done by a different group though however, that might be something we track.

How to Add Animegroup Release Note Comments

The animegroup release note comments can be edited directly from the anime page.

Step 1: click on the Animegroup comment edit button on the right hand side of the anime page to edit the release notes. (see screenshot 1)
Step 2: enter the release notes in the "Note" field. Provide a link to the source of the information in the "Comment for Mod" field. A valid source could include a link to a fansub blog, a torrent description, etc. Provide an explanation to the mod if the note note is not self explanatory. (see screenshot 2)

Animegroup Release Note Comment Examples

Common Cases

Below is a non-exhaustive list of common release notes, and how they should be formatted.

Case 1
Subs: [UTW]
> The subtitles were taken directly from UTW's release, with little to no modification.
Case 2
Subs: R1
> Subs from the R1 (generally North American English) release were taken, with little to no modification.
> Generally, "R1" should not receive square brackets [], as "R1" is not a group.
Case 3
Raws: [Zero-Raws]
> The raws from [Zero-Raws] were used for the video and audio.
Case 4
Subs: [Hiryuu] and [FFF] (edited), [Hiryuu] (typesetting and karaoke)
The subs are an edit based off of two sources, but typesetting and kfx were borrowed from only one source.
Case 5
Subs: [AnimeMangaTR] (translation of Turkish fansub)
> The Turksish subs from [AnimeMangaTR] were used as the base, from which the English subs were translated.
Case 6
Source: [Coalgirls] (ordered chapters and segment linking removed)
> The group took Coalgirls' segment linked ordered chapter release, and merged all  the files back together.
Case 7
Subs: Crunchyroll (heavily edited, restyled, typesetting)
> Note that "Crunchyroll" is spelled with a lowercase R; "CrunchyRoll" is incorrect.
> Similar to "R1", Crunchyroll isn't a "group" in the classic sense, so no square brackets as well.
Case 8
Subs: R1 (edited, retimed). Raws: [Zero-Raws]
Subs: [UTW] (track 1, edited, retimed), [FroZen] (track 2, restyled, with [UTW] typesetting), [UTW] (track 3, signs). Raws: R2J (video + JP audio), R1 (EN audio)
> Common examples of multiple sources being used, with modifications.
Case 8
Subs: [Doki] (modified; [Doki] itself is modified [SS-Eclipse])
> The group [Tsundere] had used [Soki] subs, which are themselves from [SS-Eclipse].  Currently there is no consensus as to whether the release notes should cite references to the 2nd degree of separation or beyond.  Given the lack of consensus, for now this information should be retained where possible.

Reencodes with Minor/No Modification

The following are common with [Hi10] and [Minitheatre].

Source: [UTW]
> The file is strictly a reencode of the original [UTW] file.
Source: [UTW] (ep 01-06), [FFF] (ep 07-12)
> The file is a reencode of both [UTW] files and [FFF] files.
1) BD Source: [FFF]. www Source: [HorribleSubs]
2) Source: [FFF] (BD), [HorribleSubs] (www)
> Currently, both methods 1) and 2) are acceptable.  However, the general consensus is to move towards standard 2), as this is more similar to the other general examples.

The following are common with other encode groups.

Subs: [Senketsu Subs]. Raws: [Zero-Raws] (reencoded).
> If a reencode uses multiple sources, then the note becomes similar to a typical non-reencode release, except with the "(reencoded)" note on the "Raw" credit.
<<Anything Deadfish, where Deadfish has multiple versions of files with multiple sources>>
> ... ask CDB-Man or Devildoll.

Uncommon and Complex Cases

Below are a few examples of more complex notes, where the attribution can get complex. Please note that when the citations become this complex, there are no strict standards. However, the general formatting of the simpler notes should be followed to the extent possible. The objective is always to maintain readability; if the data is complex enough such that a reasonable departure from the general formatting will result in increased readability, then that can be considered. As mentioned above, in cases of uncertainty, please consult CDB-Man for clarification.

Subs: [Commie] (HDTV), [Coalgirls] (2012 BD release), [deanzel] (2015 BD release)
> [Hi10] had used different sources for each release batch.
Subs: Dialogue by [Node] (R1, arcs 1-3, restyled, modified) and [Coalgirls] (R1, arcs 4-5, modified, and PVs); typesetting by [Coalgirls] (based on [Commie])
> [Coalgirls] only has 1 subtitle track, but it is heavily modified with multiple attributions.
Subs: [Steins;Sub] & [BSEnc] (track 1, signs + karaoke, heavily edited), [BSEnc] (track 2, modified [Commie], edited), [Forge] (track 3, modified [Steins;Sub] + [BSEnc] karaoke + [WhyNot] Ep S1, heavily edited), R1 (track 4). Raws: [Mysilu]  (1080p video + JP audio), [Philosophy-Raws] (1080p EN audio), [BESnc] (720p video + JP audio), [Forge] (720p EN audio)
> ... a very big mess.

Possible States

(assuming all files released by the group got added to AniDB)

  • complete
The group released for every episode for a specific anime in AniDB at least 1 file.
  • finished
The group released at least a file for the last episode of an anime.
  • ongoing
The group hasn't finished/completed this series yet. The release is still ongoing.
  • stalled
The group hasn't released a file for this series for at least 2 months.
  • specials only
The group released only special Episodes, but none of the regular episodes.
  • dropped
The group has officially abandoned this project or the group does not exist any more.
THIS IS THE ONLY STATE SET MANUALLY BY MODS.
  • N/A / unknown
The state of this release is currently unknown. This should generally be changed automatically to one of the other states within 24h.
Note Ongoing, stalled, finished, specials only and complete are automatically generated states! They're usually not set manually by a mod.
Note For movies where there are releases recorded as multi-part episode entries (such as Princess Mononoke or Hanamonogatari), state "complete" will be indicated as long as a group has released at least 1 file, regardless of if that file is a "part x" file or the "complete" file. This is NOT a bug, and this will not be changed.

How it works

ongoing to stalled

AniDB only check for the highest added file for an episode by a group to set states. A timestamp gets set for this episode and if a higher episode doesn't get released in a defined timeframe it gets set stalled. Adding lower episodes won't change the timestamp.

ongoing/stalled to finished/completed

A release will get considered complete/finished by AniDB if at least a file for the last ep gets added. AniDB compares the highest file with the total ep count set for the anime. If those match it's finished. If a group even released a file for every episode of this anime it's complete

dropped/stalled to ongoing

This is identical to ongoing/stalled to finished/completed. Once an episode with a higher number than the one with the timestamp gets added it gets updated to another state.

ongoing/stalled to dropped

This process is manual! Set accordingly on the anime or groupages