Same file, different group!!

Forum for discussing AniDB rules & standards. No small talk!

Moderator: AniDB

rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

Right, but often those are generated on the fly. I've seen some of such filenames for fansub releases with incorrect checksums in filename. Somebody just got corrupt file, and automatically added checksum for that corrupt file to its filename.
iWolf from l33t-raws

Post by iWolf from l33t-raws »

#l33t-raws a lot older than I been around it, and I have only been in "charge" for less than a year, but here is my opinion on the matter.

(1) Our files come from WinNY & Share, never denied it... actually I mentione it pretty often in our own board.

(2) The tag ("[l33t-raws]") is more like our stamp of aproval than credit. Some files have the credit for the original capper/encoder on them. Some don't. And if you ask me I'll do the best I can to tell you who the regular capper for a series is... and long as it is a current series I keep a list.

(3) Other groups getting the same file: Cool, I like that they too are checking the file and happen to like the same ones I do. I'm not compiting with anybody, actaully I'm glad there are others doing the same since we don't have the resources to share every series.

Personally I would like it if the people who do quality check files and have similar taste to us would join us... putting our resources together we might be able to do more. :D

(4) What the files should be under in AniDB... what about plain "raws"? just an idea. But do realise saying it comes from a particular group makes them easier to find, or at least find someone who knows the file.

I think that was it...

For anybody who doesn't like us, or the other groups for tagging the files:
http://www.***.org/winny & http://www.***.org/share are the best guides in English for those 2 JP P2P apps.
Guest

Post by Guest »

Ah, the CRC thing... WinNY, Share, and BT all check the file while decoding it... you have to have a corruption problem in the IDE bus to get a corrupt fle out of those 3.

From them, I do the CRC32s manually, which means I can get them wrong. And have.

WinNY uses MD5s, and Share uses SHA1 as the hash algorithms, so you could allways try matching files thru them... or thru the file size. They should both match at the same time, if one does but the otherone doesn't there is a problem.
rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

Yes, you verify file as you complete transfer, but problem is - file could be corrupted before transfer. Say, some japanese released raws on WinMX (it's pretty popular there), lots of peoples downloaded it and someone got a corrupt copy, but didn't noticed it, as WinMX have really weak hashing scheme. Now, that guy renamed files, embedding calculated and wrong checksum into filenames and released them on ed2k for everyone to pick up. After file spreaded really well, some *-raws group pick it up and announce on their site, still with this incorrect checksum, which corrupt file will, of course, match. What do we have now? Such file will be added to DB with crc-ok flag, without any checks to file source! If you think that it is impossible or that big re-releasers are to be trusted - go check Angelic Layer's http://anidb.info/perl-bin/animedb.pl?s ... 79&nonav=1 - well spread and added way before correct file. It was once re-released by ShareReactor. AFAIR, it once had crc-ok in AniDB as well.

So, I still think that "no group" file cannot be checked at all and all of them must have crc-ok removed, since it have no meaning at all - those files just don't have any "official" crcs!
pelican
AniDB Staff
Posts: 234
Joined: Wed Aug 11, 2004 11:19 pm

Post by pelican »

The field may be labelled "file matches official crc", but to an intelligent reader this clearly means that the file is verified, by whatever means, to be the same as the real release. As this is hard to determine for raws, taking the crc from l33t-raws or another secondary raw distributor as official provides a useful indicator, which is all the field can ever be anyway.
rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

By WHAT exactly means? Just like with ShareReactor's example above, those files are actually NOT "verified, by whatever means, to be the same as the real release". Redistibutors do not have access to checksum data of "real" release - it is "no group" after all, so nobody knows where it came from, and, therefore, they can never verify it in any way.
pelican
AniDB Staff
Posts: 234
Joined: Wed Aug 11, 2004 11:19 pm

Post by pelican »

Contrary to your opinion, data does not have to be completely accurate to be useful. I'd much prefer to have 100 no group raws `verified' by irc/bt distributor crcs where 1 one of them might be wrong than have all such raws marked as unknown, giving the user no clue but user count as to which might be correct in cases where there are multiple versions of a raw in the db.
iWolf

Post by iWolf »

While thru that files that have been passed around can contain [usually small bening] corruptions. For my part what I get is straight off of WinNY and Share, which have strong (as in MD5 and SHA1) hashing, and error checks. Both apps will detect a corrupt file and leave it marked as incomplete.

Now, notice I'm using explicitly Japanese P2P network, and our time frames don't allow for files to come from other networks. so this files aren't being passed around, usually they come from the source themselfs, making me the 1st stop, and since WinNY and Share do check the files the files are perfect and uncorrupt when they get to me.

Now there could be human error, and my PC could have some memory error that results ina wrong CRC32. But those are easy to catch, as long as other people check, since they will get a different results...

In any case, even if some percentage of the CRCs are wrong, it is still better than nothing, and they would be correct for the rest of files. Remember corruption, outside the wride level of the network, is accidental not the rule of thumb.
rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

pelican, how knowing that some unknown "no group" "approved" file helps user better than quality, sub language and comment fields that are made exactly for this purpose? Setting additional crc-ok won't automagically make file any better.

Most of those raws in db already good with "1 one of them might be wrong" even without any "verification by irc/bt distributor".

Shall I start my own redist site that will list different CRCs for those file (I'll just flip one bit for every file for fun and no visual damage. I'll even do it in padding area), add new files as crc-ok and then creq crc-status to bad for all other files just because they won't match MY data? "no group" have absolutely NO verifiable source and setting crc-oks based on rumors is, IMHO, unacceptable.

@iWolf, hmm, if you are 1st stop, as you say, then you can easily help DB with this situation. Being 1st stop you know who real releaser/encoder is. Just add him (using his username, for example) as new group with appropriate comments and assign all files he released to him. After that, considering that those P2P networks you use have good corruption control, files can be safely and correctly marked as crc-ok, since they are already automatically verified to match original checksum of releaser specified for that file.
iWolf

Post by iWolf »

rowaasr13 wrote:@iWolf, hmm, if you are 1st stop, as you say, then you can easily help DB with this situation. Being 1st stop you know who real releaser/encoder is. Just add him (using his username, for example) as new group with appropriate comments and assign all files he released to him. After that, considering that those P2P networks you use have good corruption control, files can be safely and correctly marked as crc-ok, since they are already automatically verified to match original checksum of releaser specified for that file.
ON the CRCs: But that gives me more work. Work I don't want. Work that I have no time for. Work that serves me no purpose... and work I'm already doing by putting the CRC in the filename (it would be the same CRC I would put here), all I'm not doing is putting it in AniDB.

The encoder/cappers/rebistributors is a different thing. Specially when I have 6 GSDs to compare. Once it is done the only way for me to know who the original source was is to check the hash in WinNY/Share... anyone can do that, specially someone with the time & a AniDB account, I don't have one.

Hey I'm just a guy who went up the ranks by being helpfull. Other than people to chat I'm getting nothing, I actually have to stop doing other things I enjoyed (I can't use Usenet anymore, nor serve manga in IRC thanks to WinNY being constantly eating my bandwitdh). It isn't like back in the days when I use to help distribute fansubs... then I got subs to go with the videos :lol:

Let me expand on that for a sec, so people can see it from my perspective:

Right now I could get just the series I like, 10-20% of what I'm getting under l33t-raws, and not share them. Would gain lots of free time, lots of space, lots of unused badwidth, the eternal gratitute of my ISP, and the ability to share other things thru other channels making me NOT the person in charge. I would losse a lot people asking me for things, and all the other responabilities of being the "person in charge".

But I don't. Just like a lot of other people, but still the minority of the community, I choose to share... keyword here being "share", I didn't choose to do any moe than that. If you don't like how I do something, that's cool, you are free to do it however you like.

That said, like I mentioned before I would do my best to remember if someone asks me (in person, IRC, our forum) who the original capper of a show is... but taking the time to add it to AniDB is way outside the things I care to do. Anybody is wellcome to take our releases, get the hash, and set up a download rule in WinNY, or a trigger in Share to download via hash. They will see who the encoder (trip) is that way, and can put it here. A lot more accurate than my memory.


I see the links in my post got censored, so replace the **** with u g u u for some nice little howtos/instructions on thos 2 apps


Danm this is a long post -_-
sjabbie
Posts: 346
Joined: Fri Feb 25, 2005 5:57 pm
Location: The Netherlands

Post by sjabbie »

I'm sorry for butting in in the middle of this discussion, but isn't it possible to put the name of the capper/encoder in the filename. Then the person who adds the file to the AniDB can add that person as a group etcetera etcetera. Don't if it's much work ;).
rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

Just put such a file<->releaser list in a text form somewhere on your site then and give a link there - somebody will add it for you. As I've already said, until releaser is added, it is absolutely impossible to know if file was really checked and how.

Sure, some people did read this thread and will trust such files more now, however, with all files being "no group" now, it is impossible to know if your explanation applies to each particular file or not.
iWolf

Post by iWolf »

There you go... not completly accurate (shtuff happens), some shows have more than 1 capper to choose from... GSD I only liste the 2 I use the most... you'll just have to use WinNY and see which one matches. Anything not mark as Share is WinNY.

Notice I'm doing this in good fate, other people consider this sort of thing priviledge info. Meaning anyone can take the list and start to realease the stuff before us (me)... if anyone has that kind of resources, I would ask to join us, its just better for the comunity.

Eureka Seven
エウレカ セブン 第話,92JeyRfcya,0,0,,1
PreCure MH (51?)
ふたりはプリキュア MaxHeart 第話,92JeyRfcya,0,0,,1
Gash Bell (102?)
金色のガッシュベル 第話,U14kVzyY5K,0,0,,1
Mar
MAR メル ヘヴン 第話,ZAJ36yeNBp,0,0,,1
One Piece
ワンピース 第話,IRVI3yqFSv,0,0,,1
ワンピース 第話,3ZiwD6szha,0,0,,1
Agatha Christie (39)
アガサ クリスティ 第話,aaLPbRVQ8B,0,0,,1
Mahoraba (26)
まほらば 第話,92JeyRfcya,0,0,,1
Ueki's Law
うえきの法則 第話,3ZiwD6szha,0,0,,1
うえきの法則 第話,mUgi4tYhZD,0,0,,1
Aquarion
アクエリオン 第話,okidokezwg,0,0,,1
アクエリオン 第話,92JeyRfcya,0,0,,1
Comic Party Revolution (13)
こみっくパーティーRevolution 第話,Ftx35mfjKp,0,0,,1
こみっくパーティーRevolution 第話,3ZiwD6szha,0,0,,1
Elemental Gerad
エレメンタル ジェレイド 第話,okidokezwg,0,0,,1
Bleach (36?)
BLEACH 第話,SvbwiJClDq,0,0,,1
Yakitate Japan (26?)
焼きたて ジャぱん 第話,okidokezwg,0,0,,1
Monster (65?)
MONSTER 第話,92JeyRfcya,0,0,,1
Glass Mask
ガラスの仮面 第話,okidokezwg,0,0,,1
Ichigo 100% (13?)
いちご100% 第話,G1WrcQ3EnH,0,0,,1
いちご100% 第話,ZAJ36yeNBp,0,0,,1
Basilisk
バジリスク 第話,okidokezwg,0,0,,1
Eye-Shield 21
アイシールド21 第話,Ftx35mfjKp,0,0,,1
Naruto (151?)
ナルト 第話,92JeyRfcya,0,0,,1
ナルト 第話,ovBmOjh6P4,0,0,,1
Negima (26?)
魔法先生ネギま 第話,92JeyRfcya,0,0,,1
魔法先生ネギま 第話,okidokezwg,0,0,,1
魔法先生ネギま 第話,SvbwiJClDq,0,0,,1
Gokushou Seitokai
極上生徒会 第話,okidokezwg,0,0,,1
LOVELESS
LOVELESS 第話,okidokezwg,0,0,,1
LOVELESS 第話,3ZiwD6szha,0,0,,1
Futakoi Alt.
フタコイ 第話,okidokezwg,0,0,,1
Taisenki (37?)
陰陽大戦記 第話,ovBmOjh6P4,0,0,,1
陰陽大戦記 第話,okidokezwg,0,0,,1
Beet (37?)
冒険王ビィト 第話,SvbwiJClDq,0,0,,1
冒険王ビィト 第話,ovBmOjh6P4,0,0,,1
Trinity Blood (13?)
トリニティ ブラッド 第話,okidokezwg,0,0,,1
This is my master
これが私の御主人様 第話,ls23DzRYMB,0,0,,1
HachiKuro
ハチクロ 第話,92JeyRfcya,0,0,,1
AMS (24?)
ああっ女神さまっ 第話,92JeyRfcya,0,0,,1
Speed-Grapher
スピードグラファ 第話,Ftx35mfjKp,0,0,,1
Koikoi7
こいこい7 第話,okidokezwg,0,0,,1
Peach Girl (24?)
ピーチガール 第話 Share:ASKARyRfUXZsyZ
Zettai Shounen
絶対少年 第話,okidokezwg,0,0,,1
Kyo Kara Maou 2
今日からマ王 第話,aaLPbRVQ8B,0,0,,1
Fushigi Hoshi (13?)
ふしぎ星の☆ふたご姫 第話,ZAJ36yeNBp,0,0,,1
GSD (50?)
SEED DESTINY 第話,okidokezwg,0,0,,1
SEED DESTINY 第話,SvbwiJClDq,0,0,,1
Tsubasa Chronicles (13?)
ツバサ クロニクル,okidokezwg,0,0,,1
Shinshaku
新釈 眞田十勇士 第話,okidokezwg,0,0,,1
Izumo
IZUMO 第話,okidokezwg,0,0,,1
rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

Ok, I'll do them one by one. Since all l33t-raws files for Eureka 7 are currently marked as "l33t-raws" instead of no group, I think it safe to change them all from l33t-raws to 92JeyRfcya.
rowaasr13
Posts: 415
Joined: Sat Sep 27, 2003 4:57 am

Post by rowaasr13 »

Eureka 7: complete
Pre Cure MH: complete (creqs pending approval)
(for all files that are currently in DB)

It'd be good if users'd add new files with correct releaser in future...
Locked