Crc-32

[Draders]

While were at it lets add drm to our releases so we can choose when and who can view them!

[Cz]

I am not a fansubber, nor do I plan to be in one in the near future, but I agree with some here that CRC-32 is fine for the purposes of fansubbed anime for the following reasons:

1. It is simple to compute
2. It is easily appended to a filename and still not increase filename length by too much
3. Anime files are not that important to require extra verification and error checking

I have no idea about protecting the integrity of the scripts and so on, but if a fansub group wants to go as far as using PGP and so on internally, that's their prerogative. For the average anime viewer, all they need is a simple way to see if their anime files are corrupted or not. Personally I have not found any corrupted anime file with a correct CRC.

I just think that using any more than CRC for error checking anime files is not worth the effort, both on the part of the fansubbers and on the part of anime viewers. If you use longer hashes, appending it to the filename will not be feasible. I certainly would not want my anime files to have excessively long filenames. I would not mind downloading a torrent containing an anime episode together with a separate file containing whatever hash is used, but I would not go that far with files on IRC or some other P2P network UNLESS each episode is distributed as (ZIP/RAR/tar.gz/bzip/7z/etc) archives. I am sure most casual anime watchers do not even care or know about the weird alphanumeric characters at the end of the filenames either.

That's my 2 cents on the subject.

[Kaunteya]

Since version 1.3.b06 of iroffer released on April 3rd 2004 ( and that can be easily verified http://iroffer.org/version_history.html) md5 sum calculation was added to the most common application of DCC file distribution. With simple "/msg botname xdcc info #packnumber" you can verify your md5 sum against the original. Personally, I agree with the statement that low importance of anime encodes does not give much support to use of higher security hash algorhythms. Let's be honest, this is just a copyright-infringing hobby

[Access]

Originally Posted by lwl12

I just think that using any more than CRC for error checking anime files is not worth the effort, both on the part of the fansubbers and on the part of anime viewers. If you use longer hashes, appending it to the filename will not be feasible. I certainly would not want my anime files to have excessively long filenames. I would not mind downloading a torrent containing an anime episode together with a separate file containing whatever hash is used, but I would not go that far with files on IRC or some other P2P network UNLESS each episode is distributed as (ZIP/RAR/tar.gz/bzip/7z/etc) archives. I am sure most casual anime watchers do not even care or know about the weird alphanumeric characters at the end of the filenames either.

Could you at least take care to use a CRC-32 with a different generating polynomial than the one used for TCP/IP? Below...

X32+X26+X23+X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X+1

I believe it is. Running the same polynomial twice on the same datastream, once during TCP/IP transmission, once as a final check, you can be almost certain (mathematically) the second check is useless. If an error slips past the first one, running the same polynomial over the complete datastream will not catch it either (unless there were multiple initial errors that fall between packet boundaries).

At least if you were to use a different generating polynomial for the CRC (there are pleanty of other safe polynomials for 32-bit CRCs) you could provide some value as a real error check.

[el]

Originally Posted by Kaunteya

Since version 1.3.b06 of iroffer released on April 3rd 2004 ( and that can be easily verified http://iroffer.org/version_history.html) md5 sum calculation was added to the most common application of DCC file distribution. With simple "/msg botname xdcc info #packnumber" you can verify your md5 sum against the original. Personally, I agree with the statement that low importance of anime encodes does not give much support to use of higher security hash algorhythms. Let's be honest, this is just a copyright-infringing hobby

That is as long as the bot had the original and complete file in the first place.

[Jekyll]

Originally Posted by Access

Could you at least take care to use a CRC-32 with a different generating polynomial than the one used for TCP/IP? Below...
[...]
At least if you were to use a different generating polynomial for the CRC (there are pleanty of other safe polynomials for 32-bit CRCs) you could provide some value as a real error check.

Did you read this post? TCP does not use CRC. Also, using a different polynomial would generate the need to use a special CRC checking program just for fansubs, not to mention the confusion about which groups use fansub-CRC32 and which use the normal polynomial.

[Access]

Originally Posted by Jekyll

Did you read this post? TCP does not use CRC. Also, using a different polynomial would generate the need to use a special CRC checking program just for fansubs, not to mention the confusion about which groups use fansub-CRC32 and which use the normal polynomial.

That post doesn't match up with the other stuff I've read about TCP/IP. A proper receiver is supposed to check the CRC32 before going on. For TCP communications one failure will cause data to be discareded until a CRC passes, for UDP it takes 2+ failures.

You shouldn't use a 'special' program or polynomial since there are other standard 32-bit polynomials you can use. In fact you should stick with a standard and proven one. The standardized polynomials are ones that have been mathematically proven to be robust. There is a whole science to coming up with 'good' polynomials and it is much too involved to go into here; use whatever standard you like so long as it is not the one posted above. If it's the one I posted above, it's pointless, you might as well not use it all. It's like a car with a 'check engine' warning light that never goes on, even when the engine really has gone bad or really does need checking. What use is a warning light that doesn't work... it only gives a false sense of security and is best left out of the design. Better to have no warning at all than one that never goes off even when something bad happens.

[Jekyll]

Originally Posted by Access

That post doesn't match up with the other stuff I've read about TCP/IP. A proper receiver is supposed to check the CRC32 before going on. For TCP communications one failure will cause data to be discareded until a CRC passes, for UDP it takes 2+ failures.

Take a look at the RFC 793 - Transmission Control Protocol, page 16. It's a 16 bit checksum ("one's complement of the one's complement sum of all 16 bit words in the header and text"). There is no kind of CRC. Also, UDP does not guarantee data integrity at all.

You shouldn't use a 'special' program or polynomial since there are other standard 32-bit polynomials you can use. In fact you should stick with a standard and proven one.

Standards are fine, of course. But how do you tell from a mere [ABCDEF01]ish string what polynomial was used? Do you assume every fansub group would instantly switch over to whatever polynomial is deemed to be ideal? I think this is quite improbable, thus more information would have to be added to the CRC32 in the filename, which would not be a good thing. Also, even with a standard polynomial, you would still have to make sure that your preferred program for CRC32 calculation/checking supports it.

[MrProphet]

Someone thought themselves quite witty and issued this addendum to a fansub of Ayakashi. 8)))

; SlavaSoft Optimizing Checksum Utility - fsum 2.51 <www.slavasoft.com>
;
; Generated on 01/18/06 at 23:16:47 
;
; This .txt is dedicated to http://forums.animesuki.com/showthread.php?t=27749
421cc0f84fd17d923463e37a1b29d342 ?MD2*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
2b6cd61d7c5897576e57332d06e2d4da ?MD4*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
2523cb807ed86320fe99eb6cd7e771e4 *[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
3616fe1241b015b3eb8f35eeb2be74405079c68a ?SHA1*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
b5920c2e6982965da980bebb7c39175c7f3436476714bb6f6d664ba1b701fc26 ?SHA256*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
295d9a54f205100d894203edc3a7f881c0c2fb02651694156279708f992d9de2392c1e23dd013503a550f9837348ccd3 ?SHA384*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
f61e2d30a887e4b601e5ffba9aab1a21ffeb83381d82f86708bad7d23e2e0d18391be4789f31431a6f40a8abd6f23bb6ae467f44990212f9727da96c66935e0e ?SHA512*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
604df10856854aefb0cbb3acfbfef6d6ac900f98 ?RIPEMD160*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
2e177bceb176b5a8e30a23c09550f481d145f3b80d957113 ?TIGER*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
bf5b8444183035e8cf75afcaa2f2227ce5990bcf4cd217e2e040a548b1b5c0ff ?PANAMA*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
56422cd9 ?ADLER32*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
c52a64b9 ?CRC32*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi
6304373187efb0ca800fe69477141a17 ?EDONKEY*[gg]_~ayakashi~_Japanese_Classic_Horror_01_(xvid)_[C52A64B9].avi

[Cz]

Hahaha... that comment in the file and all the hashes for one single file. The question is: did they issue instructions to the users on how to use fsum (assuming the users are even on Windows)?

[el]

Originally Posted by lwl12

Hahaha... that comment in the file and all the hashes for one single file. The question is: did they issue instructions to the users on how to use fsum (assuming the users are even on Windows)?

3 seconds on google it took me to find that programme for the encoder to use, and there is no need to list instructions as they are all on the main web page that the link at the top of the .txt points to.