Kylemc1413
Operator precedence issue in CRC32 calculation
I was trying to look into why Beatmapper maps fail to load, and since the error mentioned the file's CRC32, I thought I'd start there. I don't think this discovery is the whole issue, but it is something I noticed is wrong in your implementation compared to all the other implementations I could find:
Here, your table lookup value is buffer ^ crc & 0xFF, which, because of operator precedence, does the & first, then the ^. However, if you look at the javascript implementation or wikipedia, they use (buffer ^ crc) & 0xFF. Passing some random numbers through these is showing me different results between the two cases, with Beatmapper, MMA2, and winrar producing the same values, different from what my SongCore logs are showing.
That said, I'm still not sure why these different values only pop up if it's exported from Beatmapper, exporting from MMA2 or manually zipping them causes SongCore to load the song just fine.
And the specific issue is such maps failing to be unzipped when downloaded? Would you be able to test the proposed change and make a PR if it succeeds?
Well, the issue turned out weirder than I thought it would be. Turns out, Beatmapper doesn't compress its files, only zips them. This, for some reason, causes breaking the file into chunks to result in an incorrect crc32. Compressing the files, even just by a few bytes, or calculating the crc32 in a single chunk, causes the files to load as normal.