MSDN documentation:  As I recall the VS2010 installer for docs was strange, and there are steps to get it to install locally.  I gave up on their online help and find Google easier now, since the later versions of MSDN help have become harder to use.   (Note that Google gives better results than Bing or the on-page search box!)

Installing Win32 API documentation is your critical need; it does not need to match some version of Visual Studio.

re trying MinGW: I'm excited about the development of "Clang".  I don't know the status of a complete Win32 development system, but I think it has a component to drop-in the compiler into Visual Studio.  It can be used with the GCC toolchain and libraries.  But, the new C++ Library made for it is also especially interesting.

 When I tested my old samples on my new PC, I found that I had mis-understood algorithm's complexity and I might write wrong information somewhere. I correct my statement and put result for others who think about ECC algorithm.

 When data size is same, Encoding/Decoding time of PAR2 depends on the block size and number of blocks. The complexity is "block size" * "source block count" * "parity (or lost) block count". So, if you set two times larger block size, it requires double more encoding time. If you set half block size, the speed becomes double faster. I mis-understood the calculation cost.

 Now, using many "Cohort" improve speed by the number of cohorts. If there are 100 cohorts, the speed will become 100 times faster. Even though the recovering capability may be less, the calculation speed would be a merit in some cases. So, the "Cohort" idea of JDlugosz is reasonable for PAR2 style algorithm.


 I tested 4 ECC algorithms. James Plank style Reed-Solomon Erasure Codes is the algorithm in PAR2. Because I could not test SSE2 on my old PC, I compiled FWT version on new PC. While I cannot understand the FWT so much, I didn't optimize the code. (It should be double faster with AVX.) FFT and LDPC were compiled on my old PC, and don't use SSE. I didn't test 32-bit RS with FFT, as mine is much slower than the one in RSC32. (the speed of RSC32 would be similar level as 16-bit RS with FFT.)


 I confirmed the speed merit of "Cohort" system for James Plank style Reed-Solomon Erasure Codes. Putting 3000 blocks in each cohort (total 10 cohorts) is 10 times faster than putting 30000 blocks in single cohort. Putting 300 blocks in each cohort (total 100 cohorts) is 100 times faster than putting 30000 blocks in single cohort. On the other hand, the minimun recoverying capability is 10 (or 100) times less.

 But, "Cohort" system doesn't work well for other faster algorithms. Though the speed of FFT or FWT depends on the number of blocks, the difference is small. Using 10 or 100 cohorts will improve speed by only 2 times. The effect of "Cohort" becomes bad trade off, when the algorithm has new technology. Then, Mr. persicum and Michael Niedermayer might state that interleaving (Cohort) was worthless.

 By the way, the speed of LDPC on new PC is unbelievable quick (almost instant). It seems that LDPC's speed depends on memory speed largely. Basically the LDPC algorithm is similar to "Cohort" idea. In the sample implementation, there are 4 nodes per each source block. 24% redundancy for 30000 source blocks gives 7200 parity blocks (Cohorts), and each parity block has 30000 * 4 / 7200 = 17 nodes (Stripes). The recoverying capability of LDPC depends on the Generator Matrix and possible damage model.

 I'm interested in new Reed-Solomon Codes by Sian-Jheng Lin. If the algorithm perfomes real speed as written in his papar, it will become the fastest (long code size) Reed-Solomon Codes on the world. But, I didn't test it yet, as I could not implement, hehe. I should ask him to give me something sample code...

if you mean http://arxiv.org/abs/1503.05761 , its abstract says:


This means that only encodings like 64+32, 64+48, 64+56... available, so the minimum size of ECC file would be 50% of source data that is rather serious limit for general-purpose ECC utility

 Your understanding is good. I did the same question ago, and I got good answer. (16-bit method from Michael Niedermayer, and 32-bit method from persicum.) Just replace the over value with non-used value.

 Finite field based on a prime 4293918721 (= 0xFFF00001) can contain values from 0 to 4293918720. (it's same as reminder from modulo by the prime). So, values from 0xFFF00001 to 0xFFFFFFFF are over the field. The over's range is 1/4096 of total range. Then, there must be non-used range between the other 4095/4096 range, when the number of values is equal or less than 4095. After finding the non-used range, you just move the non-used range to the over range. Addition or XOR is available to move all values to fit the finite field.

 For example, there are 4 values; 0x12300000 (ok), 0x45600000 (ok), 0xFFF00001 (over), and 0xFFFFFFFF (over). After you add 0x00100000 to each values, resulting values become all ok like; 0x12400000, 0x45700000, 0x00000001, and 0x000FFFFF. You can return them by subtract anytime.

 Because of this replacing method, prime based Reed-Solomon Codes gives a little larger recovery data. In above example, it requires one 12-bit value per 4095 32-bit values. In 16-bit Fermat Prime's finite field, it requires one 16-bit value per 65535 16-bit values. Anyway the calculation cost of replace is small, as same as calculating checksum for each block.