Which links, where? If you mean on either http://xiph.org/flac/ or the no longer updated http://flac.sourceforge.net/, probably the developers simply have not yet compiled official binaries. Perhaps some reader here has done this for his/her personal usage and platform and might be willing to share the results.

As per the penultimate item on the bulleted list of changes, the sources are now maintained using git at Xiph, not SourceForge. The relevant link: https://git.xiph.org/?p=flac.git;a=tree Download all files at once by clicking on the link entitled “snapshot”.

Finally, moving to Validated News! Congratulations to everyone who helped to bring FLAC back from its cryosleep.

Yeah, this is more of a developers release. There are no big changes, (edit: besides the UTF-8 support in Windows of course, thank Case for that) it's been made easier to compile libFLAC. There's no real need to upgrade for end users, except if you want to encode RF64, W64 or 7- or 8-channel files. (edit: or if you want to encode files with non-latin characters in the filenames) There's a checked and tested Windows binary shipped with the new FLAC frontend however, if you're curious. On other platforms you'll have to compile it yourself for now I guess.

Further to my earlier comments about the availability of compiled binaries and packages of the source, see the posts starting here in the thread about prereleases of 1.3.0:http://hydrogenaudio.org/forums/?showtopic...125#entry835436Replies directed specifically at previous posts within that thread should probably go there. However, if they have significant relevance to the final version as a whole, posting them here might be more prudent.

Other posts about the final release of 1.3.0 should be kept in this thread, in the hope that discussions about it can be easily located by readers, rather than being fragmented across various locations.

How is the official 1.2.1b build compiled? Is it possible to have a 1.3.0 built the same way of the official one? I just want to make sure it will work with everything.

Old official FLAC was compiled with Visual Studio 6.0. It made small binaries as it could dynamically link against msvcrt.dll that came with Windows since Windows 2000. I don't think anyone has the compiler in use anymore.

Yes, not sure why it was left out of the changelog. Another problem size was 4 GB. Both issues are solved and I have tested over 20 GB FLAC files succesfully. Such large FLAC actually revealed bugs in foobar2000 that are fixed in latest versions.

Good point about the fixes for large input files and the curious fact of these being omitted from the changelog. I have added those and some other things to the list of changes in the OP, alongside a couple of new links that are useful to have in the same place for quick access.

Yes, not sure why it was left out of the changelog. Another problem size was 4 GB. Both issues are solved and I have tested over 20 GB FLAC files succesfully. Such large FLAC actually revealed bugs in foobar2000 that are fixed in latest versions.

I tested these compiles on my Intel Core2. A CD image (44.1/16/stereo, 53min 50sec) was encoded with -8 setting.

Encoding time (smaller is better):

CODE

Case 76.2 sktf 77.0 sjohn33 32bit 79.6 slamedude SSE 32bit 79.5 s

john33 64bit 77.6 slamedude SSE 64bit 76.6 s

Case: flac built by Case using MSVC 2012 (see post #12 in this thread)john33: flac built by john33 using ICC 12.1 (see post #20 in this thread)ktf: flac built by ktf using MinGW (see post #134)lamedude: flac built by lamedude using MSVC 2012 (see post #132)

I can confirm that the 64-bit encoder is slower than the 32-bit version. Running Win 8 Pro, i5 2500k, using foobar2000 1.2.6 as a front-end, 32-bit averages around 245x real-time, while 64-bit is around 222x.