Other news: The FLAC git has seen some changes on 2GB file limits on Windows. I didn't full understand the mailing list conversation, but apparently the limit was raised to 4GB and this can't be fixed until 1.3.1.

The fix has no such limits. Only API wasn't allowed to be changed, but that affects nothing but FLAC__metadata_simple_iterator_get_block_offset function. That means this function won't work if there's more than 2 GB worth of metadata. I have tested the modified code with 20 GB FLAC files without trouble.

Edit: I added experimental Unicode support to flac.exe last night. If anyone wants to experiment you can download this.

Thanks for testing. I had missed a couple of functions that took filenames. Appropriate fixes have been made and my own quick testing found no more problems.I updated the archive with latest changes and added metaflac in too. It contains the same unicode and wildcard treatment.

15 percent increase in decoding speed? It is hardly much compared to how CPU power has evolved over the years, but still cool in the 'just because one can' department. (After all, this is the yardstick I have been evaluating other codecs against; can it touch FLAC on both speed and compression simultaneously?)

Static building never worked for me, but if you build shared, the flac utility will be static anyway (you'll have to run the script src/flac/flac and use src/flac/.libs/lt-flac after that), which does work here.

This release was mainly meant to fix built issues, so building should actually be easier.

These are with the UTF-8 runtime patches you made? There are still problems with them (it actually got worse). I tested them on Windows XP SP3 and Windows 7 SP1, and I got this when used on three files, one with Cyrillic, one with Arabian and one with Japanese text.

I uploaded a test binary with properly made long filename display fix. In my own testing it performs now correctly, but perhaps ktf could give it a try before I send patches to flac dev list. Download at the usual location.