[Mai-Otome] SS v2
Moderator: AniDB
-
- Posts: 27
- Joined: Tue Feb 22, 2005 10:13 pm
- Location: Orlando, Florida (US)
- Contact:
[Mai-Otome] SS v2
Recently, DerIdiot denied a CREQ from me, but I don't see why he denied it.
This is the CREQ link:
http://anidb.info/perl-bin/animedb.pl?s ... .id=238857
In it, I'm requesting to change the file's version from v2 to v1, since this file is not a v2, it's actually a HQ version of file 188732.
And here's the proof of what I just stated, from the URL http://static-subs.com:
"Mai Otome 05 - Released
Mai Otome 05 [LQ] & [HQ] are now available for download."
So...can anyone tell me (even you, Baka-sama), why this CREQ was denied?
Thanks in advance,
-Karasuhebi
This is the CREQ link:
http://anidb.info/perl-bin/animedb.pl?s ... .id=238857
In it, I'm requesting to change the file's version from v2 to v1, since this file is not a v2, it's actually a HQ version of file 188732.
And here's the proof of what I just stated, from the URL http://static-subs.com:
"Mai Otome 05 - Released
Mai Otome 05 [LQ] & [HQ] are now available for download."
So...can anyone tell me (even you, Baka-sama), why this CREQ was denied?
Thanks in advance,
-Karasuhebi
-
- Posts: 158
- Joined: Sun Jan 09, 2005 10:54 am
- Location: Germany
-
- Posts: 27
- Joined: Tue Feb 22, 2005 10:13 pm
- Location: Orlando, Florida (US)
- Contact:
Okay everyone, thanks for the help. ^_^
That's kinda weird that a HQ version is referred to a v2, and then a REAL v2 (which was the case with ep 2v2, HQ version) would be listed as a v3. I think you should just leave both versions (LQ and HQ) as v1s so that way if the group releases a v2, it won't have to be listed as a v3.
Example:
http://anidb.info/perl-bin/animedb.pl?s ... #eid_42091
-Karasuhebi
That's kinda weird that a HQ version is referred to a v2, and then a REAL v2 (which was the case with ep 2v2, HQ version) would be listed as a v3. I think you should just leave both versions (LQ and HQ) as v1s so that way if the group releases a v2, it won't have to be listed as a v3.
Example:
http://anidb.info/perl-bin/animedb.pl?s ... #eid_42091
-Karasuhebi
-
- Posts: 27
- Joined: Tue Feb 22, 2005 10:13 pm
- Location: Orlando, Florida (US)
- Contact:
K-F is now doing a similar thing releasing an .avi and .mp4 at the same time.
Personally I think the versions should be incremented for each release that comes at a different time where one file is meant to replace the other. If there are multiple releases that come out at essentially the same time (the SS LQ & HQ, DB Releases for different Languages, K-F releases in different codecs) these should be the same version level. If a group comes out with a TV Cap and then later releases a DVD-Rip, then the DVD-Rip should be labeled v2 regardless how the file was marked.
I know that it is annoying to find two files from the same group that are both marked as v1, but in the cases above, you can tell from the list the differences between the two files (although the .avi vs.s .mp4 is difficult, you have to look at the extension on the ed2k link). But since they were released at the same time as releases with different options for users rather than one being a replacement of the other they both should be v1.
Now, there are cases in the DB where there are two v1s and there is no obvious reason for it. One I came across recently is: http://anidb.info/perl-bin/animedb.pl?s ... 85#eid_985 Look at the two fivestar releases, why are their two with different sizes and video codecs??? There is obviously something wrong here, so if there are multiple v1's they need to be clearly marked as to why they are there.
Now, you won't be able to keep up with all of the idiotic things that various groups do to mark their releases (this is one of the advantages of using AniDB is a consistent interface...), but using some guidelines at least AniDB should be able to handle things in a consistent manner where someone can figure out what happened.
I remember one DB file that was released. Then they put out a patch, the result of that patch was put in as v2. Then DB released a v2 of the file, which was [properly] marked as v3 in AniDB. Although what DB called a v2 is listed as v3 in the database, someone can tell that there really were 3 releases by the group (despite what they say).
So to summarize:
1) Multiple v1's should be allowed if the group releases multiple types of the files (different qualities, languages or encodings) at essentially the same time. The v1's should have file comments that clearly state what the difference is. [The wiki page on file comments may need to be revised to support this.]
2) Subsequent releases of the file by a group should be marked with a version number, regardless of how the group marks the releases. File comments should be added if the group's version number disagrees with AniDB. For instance, if a group releases a TV capture it should be v1, if they later release a DVD rip it should be v2. Then if the group releases a DVD rip v2, that should be put in AniDB as v3 with file comments for the v2 and v3 to explain the difference.
If you try to follow what the groups do exactly it will just add confusion, things should be handled in a consistent manner, and I believe this handles the situations.
Personally I think the versions should be incremented for each release that comes at a different time where one file is meant to replace the other. If there are multiple releases that come out at essentially the same time (the SS LQ & HQ, DB Releases for different Languages, K-F releases in different codecs) these should be the same version level. If a group comes out with a TV Cap and then later releases a DVD-Rip, then the DVD-Rip should be labeled v2 regardless how the file was marked.
I know that it is annoying to find two files from the same group that are both marked as v1, but in the cases above, you can tell from the list the differences between the two files (although the .avi vs.s .mp4 is difficult, you have to look at the extension on the ed2k link). But since they were released at the same time as releases with different options for users rather than one being a replacement of the other they both should be v1.
Now, there are cases in the DB where there are two v1s and there is no obvious reason for it. One I came across recently is: http://anidb.info/perl-bin/animedb.pl?s ... 85#eid_985 Look at the two fivestar releases, why are their two with different sizes and video codecs??? There is obviously something wrong here, so if there are multiple v1's they need to be clearly marked as to why they are there.
Now, you won't be able to keep up with all of the idiotic things that various groups do to mark their releases (this is one of the advantages of using AniDB is a consistent interface...), but using some guidelines at least AniDB should be able to handle things in a consistent manner where someone can figure out what happened.
I remember one DB file that was released. Then they put out a patch, the result of that patch was put in as v2. Then DB released a v2 of the file, which was [properly] marked as v3 in AniDB. Although what DB called a v2 is listed as v3 in the database, someone can tell that there really were 3 releases by the group (despite what they say).
So to summarize:
1) Multiple v1's should be allowed if the group releases multiple types of the files (different qualities, languages or encodings) at essentially the same time. The v1's should have file comments that clearly state what the difference is. [The wiki page on file comments may need to be revised to support this.]
2) Subsequent releases of the file by a group should be marked with a version number, regardless of how the group marks the releases. File comments should be added if the group's version number disagrees with AniDB. For instance, if a group releases a TV capture it should be v1, if they later release a DVD rip it should be v2. Then if the group releases a DVD rip v2, that should be put in AniDB as v3 with file comments for the v2 and v3 to explain the difference.
If you try to follow what the groups do exactly it will just add confusion, things should be handled in a consistent manner, and I believe this handles the situations.
-
- Posts: 27
- Joined: Tue Feb 22, 2005 10:13 pm
- Location: Orlando, Florida (US)
- Contact:
So..what's the final decision on this? I see someone moved this to the archive of CREQs and we still don't have a final decision or a reply from DerIdiot. Also, he denied another one of my CREQs for the HQ version of Mai-Otome, this time for episode 6. Here's the link, for whoever wants to see it:
http://anidb.info/perl-bin/animedb.pl?s ... .id=240511
Baka-sama, please post a comment about this. We wanna know what AniDB is gonna do about this.
-Karasuhebi
http://anidb.info/perl-bin/animedb.pl?s ... .id=240511
Baka-sama, please post a comment about this. We wanna know what AniDB is gonna do about this.
-Karasuhebi
thats differentegg wrote:K-F is now doing a similar thing releasing an .avi and .mp4 at the same time.
different codec, different container.
ss just adds 400kbit/s and calls it hq. as if that would make any difference.
the source is the same, the codec is the same. only thing that changes is 400kbit/s
for me i considered that a different version. my fellow mods disagreed so i reverted back to all being v1.
as for the stupid redundant comments. come on people use your fuckin brain. "hq version", "lq version" thats utter nonsense. why do you think we got a quality rating. oh there is no difference in quality you say? well then no need to label them different either. let ss be tards and play their multitag game, but that doesn't mean we have to do so either.
let me get this straight. "xvid/h264 version" gets only added as it's NOT possible to see a difference between the versions without opening the filedetails. while a "hq/lq" version SHOULD be possible to see based on the quality rating, but as ss just releases 2 times the same file and there is lil to no difference.... well thats not our problem blame them. as it's same codec + same surce the difference between the versions is easy enough to tell by size as 400kbit/s more blows up the size.
also see: http://www.anidb.net/wiki/index.php?tit ... lecomments
anyway this case is closed. there won't be anymore discussion about this as i'm fed up with it. make a creq and face instant deny without any explanation!Do NOT...
add redundant info like "HQ version/LQ version" use the freakin quality rating!