Thought i would start a new thread for the FLAC-git releases.
https://github.com/xiph/flac/commits/master
FLAC git-90d7fdb3 20221012
Built on October 13, 2022, GCC 12.2.0
(Code Base : 1.4.1)
FLAC git-0665053c 20221013
Built on October 15, 2022, GCC 12.2.0
(Code Base : 1.4.1)
https://github.com/xiph/flac/commits/master
FLAC git-92928f28 20221017
Built on October 17, 2022, GCC 12.2.0
(Code Base : 1.4.1)
https://github.com/xiph/flac/commits/master
FLAC git-e7b584ea 20221020
Built on October 20, 2022, GCC 12.2.0
(Code Base : 1.4.1)
https://github.com/xiph/flac/commits/master
FLAC-1.4.1-git-6abf272-20221021
Built on October 21, 2022, GCC 12.2.0
(Code Base : 1.4.1) (-Ofast -m64 -march=haswell)
www.rarewares.org/files/lossless/flac-1.4.1-git-6abf272-20221021.zip (https://www.rarewares.org/files/lossless/flac-1.4.1-git-6abf272-20221021.zip)
john33 you may consider using https when posting links in rarewares.org. Firefox blocks the download and warns about malicious content without s, but suddenly no virus when I manually add s. Not only this file but also the previous ones, and with previous versions of Firefox.
This behaviour does not seem to happen with other websites. I tried Firefox's troubleshooting mode (reverts all custom settings and disables all plugins) the issue persists. Firefox must hate your website, perhaps you can report to Mozilla as well.
Done, thanks. The link was 'as is' created within the forum software, but I'll try to remember to add the 's'. ;)
FLAC-1.4.1-git-6abf272-20221021
Built on October 21, 2022, GCC 12.2.0
(Code Base : 1.4.1) (-Ofast -m64 -march=haswell)
www.rarewares.org/files/lossless/flac-1.4.1-git-6abf272-20221021.zip (https://www.rarewares.org/files/lossless/flac-1.4.1-git-6abf272-20221021.zip)
So far the fastest build for my Ryzen 5 3600x.
@john33 can you build the same git with -march=zen2 ? Just to see if it makes some difference? ;)
FLAC-1.4.1-git-6abf272-20221021
Built on October 21, 2022, GCC 12.2.0
(Code Base : 1.4.1) (-Ofast -m64 -march=znver2)
www.rarewares.org/files/lossless/flac-1.4.1-git-6abf272-20221021-z2.zip (https://www.rarewares.org/files/lossless/flac-1.4.1-git-6abf272-20221021-z2.zip)
FLAC 1.4.2 release compiles are now at Rarewares. Please note that these compiles are aimed at compatibility and not at performance. I'll look at higher performance variants over the next day, or so. :)
FLAC git-3975b3e6 20221104
Built on November 04, 2022, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-29b57b59 20221107
Built on November 07, 2022, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-96b5e6d3 20221109
Built on November 09, 2022, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-9e3d1666 20221113
Built on November 15, 2022, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-7270930 20221117 :)
Built on Nov 17, 2022, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-c42d446 20221128
Built on Nov 28, 2022, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-78445789 20221128
Built on November 28, 2022, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-9b7ca112 20221202
Built on December 04, 2022, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-8d2830b6 20221231
Built on January 02, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-0a52c6fd 20230107
Built on January 07, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-fe0bf230 20230109
Built on January 10, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-fe0bf230 20230109
Built on January 10, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
I've lifted some restrictions on channel mask recently, these changes are in this compile. Channel masks that are non-standard in FLAC should now be accepted properly, without having to resort to --channel-map=none. However, I don't have much files to test, so if anyone with such files could give it a try, that would be much appreciated.
FLAC git-748f3938 20230129
Built on January 29, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-3f1f82c8 20230211
Built on February 11, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
I've lifted some restrictions on channel mask recently, these changes are in this compile. Channel masks that are non-standard in FLAC should now be accepted properly, without having to resort to --channel-map=none. However, I don't have much files to test, so if anyone with such files could give it a try, that would be much appreciated.
Tested 4.1 and FL-FR-FC-BC. Files are accepted and compressed without problems.
FLAC git-3f1f82c8 20230211
Built on February 11, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
Hope it's not faux pas to drop MSVC builds in here, didn't seem worth making my own thread for builds that might be slower or worse since I've no idea what I'm doing anyways.
Same commit as NetRanger's previous post, built with MSVC 2022 and copious "lemme flip some of these optimization switches and see what happens"
x64 - AVX
20230211-git-3f1f82c8-x64-AVX - flac.exe and metaflac.exe only
20230211-git-3f1f82c8-x64-Shared-AVX - what you want if you just want libFLAC.dll for something else (rename it if you need to)
x86/32 - SSE2 - 20230211-git-3f1f82c8-x86-Shared-SSE2 - because I still need a 32-bit libFLAC.dll to let eac3to use...
I forgot CXX and UTILS enabled in CMake when I switched to shared builds, so both also come with FLAC++.dll, flacdiff.exe, and flactimer.exe
FLAC git-771eb050 20230217
Built on February 18, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-771eb050 20230217
Built on February 18, 2023, GCC 12.2.0
This build has much improved foreign metadata handling. When decoding with --keep-foreign-metadata, the right format will be picked automatically instead of default to WAV (which only works for WAV). Also, decoding to AIFF-C sowt and WAVE_FORMAT_EXTENSIBLE is now possible. Finally, a bunch of warnings is added when on restoration of foreign metadata inconsistencies are found, for example when the length of the file has changed.
FLAC git-771eb050 20230217
Built on Feb 17, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
When decoding with --keep-foreign-metadata, the right format will be picked automatically instead of default to WAV
Took some files from the upper section of https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html - the 8, 8C, 16, 16C, 16s (that is sowt), 24, 24C, 32, 32C and ran them through --keep-foreign-metadata-if-present with or without entering a tag field first. Decoded with --keep-foreign-metadata-if-present and let a file deduplicator check that they were bit-exactly the same as the original.
All of them did come out bit-identical. But, if fb2k is likely to only make "pretty standard" tags, it might not have been the hardest of tests.
Edit: tried afterwards an 8-bit sowt file, same (good) result. Why try? Just out of the knowledge that some players have rejected those (after all, who would make a fuss out of endianness on 8-bit? But it is a subformat of AIFC, so it is legit).
Obligatory suggestions coming up - after all, you didn't do all this hard work for users to turn
grateful and stop being pain-in-the-ass about features they don't use themselves eh? ;D
* When re-encoding flac to flac, it is reasonable to let --no-keep-foreign-metadata kill foreign metadata. (Is there any such provision in metaflac?)
Or if one is reluctant to making a change that will actually start killing data when the previous version did not: a --remove-foreign-metadata
* I think a "-k" for --keep-foreign-metadata-if-present should be on the table pretty soon.
* One will always think twice before changing behaviour and thrice before changing
default behaviour, but it isn't unfair to assume that a user that encodes with foreign metadata intends them to be kept? That suggests that decoding by default employs --keep-foreign-metadata-if-present. But, but, but ... you might not want all the WTFs from users who don't understand why their pyr8ed downloads (hm, to be fair it could be purchases too) decode to .aiff.
(Once alternative behaviour deviates enough from 2007-era "-d", one can of course take note that -D is not taken ...)
When decoding with --keep-foreign-metadata, the right format will be picked automatically instead of default to WAV
Took some files from the upper section of https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html - the 8, 8C, 16, 16C, 16s (that is sowt), 24, 24C, 32, 32C and ran them through --keep-foreign-metadata-if-present with or without entering a tag field first. Decoded with --keep-foreign-metadata-if-present and let a file deduplicator check that they were bit-exactly the same as the original.
All of them did come out bit-identical. But, if fb2k is likely to only make "pretty standard" tags, it might not have been the hardest of tests.
Edit: tried afterwards an 8-bit sowt file, same (good) result. Why try? Just out of the knowledge that some players have rejected those (after all, who would make a fuss out of endianness on 8-bit? But it is a subformat of AIFC, so it is legit).
Thanks!
* When re-encoding flac to flac, it is reasonable to let --no-keep-foreign-metadata kill foreign metadata. (Is there any such provision in metaflac?)
I'm not sure that would be very useful. We don't have a --no-transfer-vorbis-comment option either. One can remove the RIFF and AIFF data with
metaflac --remove --block-type=APPLICATION:riff,APPLICATION:aiff.
* One will always think twice before changing behaviour and thrice before changing default behaviour, but it isn't unfair to assume that a user that encodes with foreign metadata intends them to be kept? That suggests that decoding by default employs --keep-foreign-metadata-if-present. But, but, but ... you might not want all the WTFs from users who don't understand why their pyr8ed downloads (hm, to be fair it could be purchases too) decode to .aiff.
(Once alternative behaviour deviates enough from 2007-era "-d", one can of course take note that -D is not taken ...)
I don't think keeping them by default is a good idea. I've seen an AIFF file come out a DAW with an empty AIFF chunk of 15MB for some reason. The user asked why FLAC didn't compress such a block. The answer is because FLAC compresses audio, not metadata.
I don't think keeping them by default is a good idea. I've seen an AIFF file come out a DAW with an empty AIFF chunk of 15MB for some reason. The user asked why FLAC didn't compress such a block. The answer is because FLAC compresses audio, not metadata.
I agree, and that was not my suggestion either.
What I was suggesting - or at least suggesting to
consider - was behaviour upon
decoding. I argue that if there is foreign metadata in the .flac file, it reflects an intention to keep foreign metadata.
And even more so when the default encoding behaviour is to discard them. Then foreign metadata in the .flac must have been due to an
active choice.
(Aside: I have no idea whether any of the wave
file compressors - WavPack, TAK, ALS, (La) and the two animals - do
compress the foreign metadata, foreseeing DAWs misbehaving big this way.)
Thank you for this, the —keep-foreign-metadata command is an important one for me!
FLAC git-0408d251 20230222
Built on February 22, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-9382c537 20230223
Built on Feb 23, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-9382c537 20230223
Built on February 23, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-a336ea52 20230224
https://github.com/xiph/flac/commits/master
flac-1.4.2-4d21da1-20230227
Built on February 28, 2023, Intel compiles. win32-XP is Intel 19.0, others are Intel 19.2.
(Code Base : 1.4.2)
https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-win32-nonXP.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-win32-nonXP.zip)
https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-win32-XP.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-win32-XP.zip)
https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-x64-AVX2.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-x64-AVX2.zip)
The targets are self-explanatory. :)
I've had a report of possible issues with these compiles so please only use them for testing and not for archival. The particular problem was with '-8', but it could affect other settings also.
FLAC git-4d21da11 20230227
Built on February 27, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
I can confirm the problem with the Intel compiles which I will look into. Having just built a GCC version, I can confirm that it works as expected. So, go for NetRanger's build. ;)
I've had a report of possible issues with these compiles so please only use them for testing and not for archival.
This is something true for all these git compiles. I usually don't leave git in a state with known bugs, but a release is usually preceded by a few weeks without adding new features, to find bugs.
Still, I'm always curious about bugs that do not surface on GCC but do on other compilers.
@john33, do you usually run the test suite on builds like these? Can you check whether the test suite fails on these builds?
It turns out that the 'bug' was being caused by using the '/Qipo' Intel Procedural Optimization switch in the compilations.
I have recompiled without this option and the compiles perform as expected. They are on the same links as above.
@ktf, no, I don't normally run the test suite. I have a bunch of files I've used over the years that I test against. I recall having an issue with '/Qipo' on the odd occasion in the past but this is the first time I've encountered it for some years. I'm not sure that it makes a whole bunch of difference in respect of speed, so probably not worth bothering with. Ignoring the XP build, I've tried using the latest Intel oneAPI compiler - based on Clang 16. It works quite well for the 64bit build but will not compile for 32bit. The Intel Classic Compiler - 19.2 - will be removed later this year from the Intel downloads.
It turns out that the 'bug' was being caused by using the '/Qipo' Intel Procedural Optimization switch in the compilations.
Is it a bug in IPO or is it a bug in FLAC being triggered by IPO? Do you have some more details, I'm certainly curious.
It turns out that the 'bug' was being caused by using the '/Qipo' Intel Procedural Optimization switch in the compilations.
Is it a bug in IPO or is it a bug in FLAC being triggered by IPO? Do you have some more details, I'm certainly curious.
I understand your interest, but I suspect the answer is way above my level of understanding!! If anything occurs to me, or comes to light, I'll certainly let you know.
Could you perhaps disclose some more details, if necessary via PM, so I can look into this when I have the time?
Compiler bugs are pretty rare, and I find it especially interesting as you say you've run into this previously.
FLAC git-2b84e859 20230303
Built on March 03, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
flac-git-07471c89-20230306
Built on March 6, 2023, GCC 12.2.0
(Code Base : 1.4.2)
Win32 generic: https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-x86.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-x86.zip) (Not XP friendly)
x64 generic: https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-x64.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-x64.zip)
x64 AVX2 optimised: https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-AVX2.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-AVX2.zip)
Could you perhaps disclose some more details, if necessary via PM, so I can look into this when I have the time?
Compiler bugs are pretty rare, and I find it especially interesting as you say you've run into this previously.
Sorry, I'm not ignoring you!! ;) /Qipo is multifile procedural optimisation which has always been a bit 'flakey'. /Qip is single file procedural optimisation which generally works OK. However, Intel is retiring it's 'Classic' compilers later this year in favour of a 'Clang' base and this only supports /Qipo, and not /Qip. From personal recent testing, the GCC compiles are generally faster than both MSVC and Intel compiles and therefore, where it makes sense, I will probably favour GCC. I will retain the MSVC/Intel compiles where it makes my life easier ( ;) ), and probably for XP friendly compiles using VS2015/Intel 19.0.
However, Intel is retiring it's 'Classic' compilers later this year in favour of a 'Clang' base and this only supports /Qipo, and not /Qip.
Very interesting! Fascinating that very, very large and powerful tech companies all seem to be moving towards Clang/LLVM. ARM, Apple, IBM, Intel, Microsoft, all using LLVM in some form or another in their compilers.
FLAC git-07471c89 20230306
Built on March 06, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
However, Intel is retiring it's 'Classic' compilers later this year in favour of a 'Clang' base and this only supports /Qipo, and not /Qip.
Very interesting! Fascinating that very, very large and powerful tech companies all seem to be moving towards Clang/LLVM. ARM, Apple, IBM, Intel, Microsoft, all using LLVM in some form or another in their compilers.
Equally interesting is that these companies, particularly MS and Intel, used to charge vast amounts for the use of their products even for single usage and now they are free for personal use!!
FLAC git-4d6d8b3 20230308
Built on Mar 08, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC-git-4d6d8b34-20230308
Built on Mar 08, 2023, GCC 12.2
(Code Base : 1.4.2)
x64-AVX2 optimised: https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-AVX2.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-AVX2.zip)
Generic x64: https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-x64.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-x64.zip)
Generic x86(win32-non XP): https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-x86.zip (https://www.rarewares.org/files/lossless/flac-1.4.2-4d6d8b34-20230308-x86.zip)
FLAC git-383512d 20230309
Built on Mar 09, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-9c83e6e4 20230311
Built on March 11, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
Experimenting with some Windows builds (first time). Curious to see how they perform to other's builds.
flac git-9c83e6e4 20230311 - All built with static libs, GCC 12.2 (MinGW w64) on Debian GNU/Linux
flac-avx.zip and
flac-noavx-v1.zip should probably (hopefully) perform on par with similar builds here.
flac-noavx-v2.zip and
flac-noavx-v3.zip perform better than
v1 on Linux, but seem painfully slower in my Windows VM. Curious to see if they perform better on real hardware.
Times on Linux with my Ryzen 5850U. Same options were used for the Windows builds.
flac -f -8p NIN_The_Fragile16.wav
NIN_The_Fragile16.wav: wrote 658391469 bytes, ratio=0.599
With AVX: 0m43.889s
No AVX v1: 1m12.704s
No AVX v2: 1m5.146s
No AVX v3: 0m59.930s
What is the difference between these builds? And what is the reason to leave AVX out of some of these builds?
The only difference is a couple compiler flags. The v1 non-AVX build is just a standard build for CPUs without AVX instructions. v2 and v3 forces the encoder to use multiple threads (via -ftree-parallelize-loops). Despite the extra threads, the benefit is small, and setting too many threads has a negative impact on performance. That option doesn't benefit at all with AVX either. Might be faster for some people without AVX, though it might not be worth the extra CPU power. On Linux, using a few threads seems to have a small benefit, but hurts performance big-time on my VM. Not sure if it's because it's a VM, or something Windows might do differently.
Just experimenting and curious to see if they perform any better for Windows on real hardware. My only Windows machine might be considered an antique by now. In the future I'll probably stick to Linux builds since I don't use Windows much.
I only checked the AVX compile and it is very fast with CD material but also slow on 24bit material as it was configured with disable-asm-optimizations. Is it?
It is. I should have noted that in my post.
For a plain build with asm optimizations, there really is no need to disable AVX, FLAC has CPU feature detection. The only problem is when instructing the compiler to use AVX/AVX2/FMA/BMI/etc. for the whole program.
I didn't disable AVX on the non-AVX builds. I used -march=x86-64-v2. The build with AVX uses x86-64-v3 (very similar to haswell). If I use x86-64-v4, flac exits with illegal instruction since my CPU doesn't have any of the AVX512 instructions.
FLAC git-e683286b 20230318
Built on March 19, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-6633d2f9 20230319
Built on March 20, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-d2060f48 20230420
Built on April 20, 2023, GCC 12.2.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-147cfc8 20230424
Built on Apr 24, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-763e185 20230428
Built on Apr 28, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-1b92b86 20230504
Built on May 04, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC-git-4caaef6b-20230505
Built on May 5, 2023 - GCC 13.1.0 64bit AVX2 optimised.
(Code base-1.4.2) (flac and metaflac)
https://www.rarewares.org/files/lossless/flac-git-4caaef6b-20230505-AVX2.zip (https://www.rarewares.org/files/lossless/flac-git-4caaef6b-20230505-AVX2.zip)
FLAC git-4caaef6b 20230505
Built on May 06, 2023, GCC 13.1.0
FLAC git-22fffdc 20230508
Built on May 08, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-c623f0f 20230509
Built on May 09, 2023, Visual Studio 2022 (v143) 10.0.22000.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-7ed6f4f 20230511
Built on May 11, 2023, Visual Studio 2022 (v143) 17.5.5
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-7761f54 20230520
Built on May 20, 2023, Visual Studio 2022 (v143) 17.6
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-6571cbb 20230523
Built on May 23, 2023, Visual Studio 2022 (v143) 17.6.1
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-0b8a271b 20230524
Built on May 24, 2023, GCC 13.1.0
(Code Base : 1.4.2)
https://github.com/xiph/flac/commits/master
FLAC git-6a9c166 20230601
Built on June 013, 2023, Visual Studio 2022 (v143) 17.6.2
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
I'm planning to release 1.4.3 soon, so if anyone knows of any regressions, please let me know.
I'm planning to release 1.4.3 soon, so if anyone knows of any regressions, please let me know.
That's without the retune?
Yes, I've come to the conclusion the gain isn't worth the hassle.
hey, I used the flac-retune binary you shared here and without a doubt it's the fastest flac encoder I have ever used, by a wide margin
what exactly is so different between, say, the level 8 mode on your binary vs the standard one?
I'm planning to release 1.4.3 soon, so if anyone knows of any regressions, please let me know.
There have been a lot of general speed-ups. Preset 8 from these binaries (the retune ones) (https://hydrogenaud.io/index.php/topic,123889.0.html) is pretty much as fast as flac 1.4.3 preset 7.
Anyway, the problem was, while for my inputs the new preset 8 was much faster and compressed better, there where quite a lot of audio files for which it performed worse. So, the general speed-ups stay, but the potentially better settings (on average, for a balanced pool of music) are left out.
Any reason to keep the 1152? After all, block size did make some speed impact for -0/-1.
FLAC git-7f89a74 20230606
Built on June 06, 2023, Visual Studio 2022 (v143) 17.6.2 10.0.22621.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
Any reason to keep the 1152? After all, block size did make some speed impact for -0/-1.
-r also? At least if 4096-all-the-way is on the table (for the sake of speed), then bump up the -r to keep the partition size close to current partition size?
I don't know if my experience holds up in other scenarios, but from https://hydrogenaud.io/index.php/topic,123889.msg1024954.html#msg1024954 , finer partitioning appeared to be more or less "for free" in that build - that's a surprise. And if it is, then -8r7 makes a slight improvement over -8 = -8r6 on more abrasive material.
I've changed my mind, I think the potential gains are too low (and too dependent on source material) to change behaviour that has been around for quite a while.
@ktf - So u will push the new FLAC release soon then or?
Yes, date is set at 23-06-23, if nothing comes up.
Yes, date is set at 23-06-23, if nothing comes up.
:)
FLAC git-4f9be86 20230615
Built on June 15, 2023, Visual Studio 2022 (v143) 17.6.3 10.0.22621.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
FLAC git-08f8af0 20230618
Built on June 18, 2023, Visual Studio 2022 (v143) 17.6.3 10.0.22621.0
(Code Base : 1.4.2)
+ libFLAC_dynamic.dll
https://github.com/xiph/flac/commits/master
Any reason to keep the 1152? After all, block size did make some speed impact for -0/-1.
-r also? At least if 4096-all-the-way is on the table (for the sake of speed)
I did remember wrong, -b4096 was not at all fast - it was the 3000s that would speed up.
I did the test over again (https://hydrogenaud.io/index.php/topic,123025.msg1029076.html#msg1029076) with Sunday's build in #93. -0b<BBBB> was not equally sensitive to block size this time. The penalty on 1152 and 4096 (and 4608) was still there, but much smaller.
Didn't test directly against official build, as we know build matters - just lazily took
@ktf 's word that there have been speedups ;)
FLAC git-31ccd3df 20230727
Built on July 27, 2023, GCC 13.1.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
FLAC git-31ccd3df 20230727
Built on July 29, 2023, GCC 13.2.0
(Code Base : 1.4.3) - x64 AVX2 optimised.
https://www.rarewares.org/files/lossless/flac-1.4.3-git-31ccd3df-20230727-x64-AVX2.zip (https://www.rarewares.org/files/lossless/flac-1.4.3-git-31ccd3df-20230727-x64-AVX2.zip)
Multithreading enhancement added yesterday to official git.
I attached a 64bit generic clang 17.0.1 version since i tried the newest package of clang. Still GCC versions are faster here.
FLAC git-8cf7e7fb 20230922
Built on September 24, 2023, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
FLAC git-72787c3f 20231124
Built on November 24, 2023, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
FLAC git-7f7da558 20240226
Built on February 27, 2024, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
FLAC git-66152791 20240301
Built on March 01, 2024, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
Just so thrilled to see new builds again 🥲
FLAC git-37ca8113 20240306
Built on March 06, 2024, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
Using this version on a somewhat older windows pc using commandline,
flac -8e --no-padding
WARNING, cannot set number of threads: multithreading was not enabled during compilation of this binary
Current git brakes multithreading here completely also.
Version string : reference libFLAC git-37ca8113 20240306
Compiler is GCC : ......................... yes
GCC version : ............................. 13.2.0
Asm optimizations : ....................... yes
Ogg/FLAC support : ........................ yes
Multithreading : ........................ no
That is strange, I have no such problems. Not on Windows (MinGW64) nor on Linux.
It is the m-ab_s build that compiles without threads. I've tested that, but not an independent build. I'll do that shortly.
This separate build (64 bit, AVX2 optimised) was built with threads enabled:
https://www.rarewares.org/files/lossless/flac-1.4.3-git-37ca8113-20240307.zip (https://www.rarewares.org/files/lossless/flac-1.4.3-git-37ca8113-20240307.zip)
the m-ab_s build
What is that?
the m-ab_s build
What is that?
Media-AutoBuild_Suite - for building audio and video encoders/decoders and, ultimately, ffmpeg and mpv. It uses configure for the flac build.
https://github.com/m-ab-s/media-autobuild_suite
Corrected in todays git.
Corrected in todays git.
Not here.
I just built the current git version. Multi-threading works for me.
Linux x86_64, GCC 12.3.0
flac git-8d4ccdfb 20240308
Not here.
Ops, sorry. No idea what exe files i copied from where for the former test. Recent git indeed still brakes multithreading here.
Version string : reference libFLAC git-8a685ee7 20240307
Multithreading : ........................ no
Maybe this is related: https://github.com/xiph/flac/commit/0c8afdf35aef9004d013c440bc75b8b77f8f4c26
Well, the build I made at "Reply #107" was from the git of March 7 cloned a few minutes before the time of the post, and threading worked at that point. The m-ab_s build doesn't use cmake and I have no idea whether other build systems default to multithreading, I'm guessing not.
I encountered this problem as well. The pthread libraries had recently been updated in MSYS2 so I downgraded to the prior version and configure enabled multithreading as expected. Cmake had no such problem with the latest pthread.
I encountered this problem as well. The pthread libraries had recently been updated in MSYS2 so I downgraded to the prior version and configure enabled multithreading as expected. Cmake had no such problem with the latest pthread.
Ah, OK, I guess that explains it. I make use of the MSYS64 install that m-ab_s uses for general GCC compiles but use the cmake build for FLAC.
There seems to be a problem with the latest winpthread in msys2 indeed. One function used by the autotools pthread macro results in an error, making configure think pthread is not available.
Here is the macro documentation that FLAC uses: https://www.gnu.org/software/autoconf-archive/ax_pthread.html
And here is the error that is in config.log
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccdJznhh.o:conftest.c:(.text+0x8c): undefined reference to `MemoryBarrier'
I'm not sure what to do at this point. Perhaps it is best to leave it for now, as it seems that this is a bug in msys2 that will probably be fixed.
For anyone wanting a quick fix, go to m4/ax_pthread.m4 in the FLAC source directory, and replace lins 331-333
pthread_attr_init(&attr);
pthread_cleanup_push(routine, 0);
pthread_cleanup_pop(0) /* ; */])],
With the following
pthread_attr_init(&attr)/* ; */])],
I encountered this problem as well. The pthread libraries had recently been updated in MSYS2 so I downgraded to the prior version and configure enabled multithreading as expected. Cmake had no such problem with the latest pthread.
Many thanks! I rolled back winpthreads from r652 to r631 and multithreading is back.
FLAC git-d2b24410 20240309
Built on March 09, 2024, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
FLAC git-d2b24410 20240309
Built on March 09, 2024, GCC 13.2.0
(Code Base : 1.4.3)
Seems like Msys2 current winpthreads r655 still has the multithreading bug.
I did a working generic git x64 compile for testing. I never started a win32 enviroment, sorry.
Anyone want to try FLAC for ARM64? (a.k.a. aarch64/ARMv8). Not compatible with Android ARMv8.
FLAC git-49ab34df
GCC 12.3.0
I'm not sure what to do at this point. Perhaps it is best to leave it for now, as it seems that this is a bug in msys2 that will probably be fixed.
The last update of winpthreads to r731 seems to have fixed the issue.
FLAC git-61f8513c 2024-04-30
Static binaries built with GCC 12.3.0
Linux i386, amd64 and aarch64 (Armv8)
FLAC git-61f8513c 2024-04-30
Static binaries built with GCC 12.3.0
Linux i386, amd64 and aarch64 (Armv8)
Uuum, Windows 11 64bit complains that it's unsupported 16 bit application; what's more, all amd64 apps don't have .exe extension. What did you do? :)
FLAC git-61f8513c 2024-04-30
Static binaries built with GCC 12.3.0
Linux i386, amd64 and aarch64 (Armv8)
Uuum, Windows 11 64bit complains that it's unsupported 16 bit application; what's more, all amd64 apps don't have .exe extension. What did you do? :)
These binaries are for Linux. They won't work on Windows.
FLAC git-61f8513c 2024-04-30
Static binaries built with GCC 12.2.0 (MinGW)
Windows 32-bit & 64-bit
These binaries are for Linux. They won't work on Windows.
Of course. You didn't do anything, I didn't read properly LOL
Thanks for Windows binaries.
FLAC git-653b1187 20240501
Built on May 01, 2024, GCC 13.2.0
(Code Base : 1.4.3)
https://github.com/xiph/flac/commits/master
FLAC git-04532802 2024-05-02
Linux static builds [tgz file]
- GCC 12.3.0
- i386, amd64, armv7 & armv8
Windows static builds [zip file]
- GCC 12.2.0 (MinGW)
- 32-bit & 64-bit
FLAC git-1ab3c8e7 2024-05-15
Linux static binaries
- Built with GCC 12.3.0
- i386, amd64, armv7 & armv8
FLAC git-cfe3afca 2024-05-16
Linux static binaries
- Built with GCC 12.3.0
- i386, amd64, armv7 & armv8
FLAC git-cfe3afca 2024-05-16
Windows static binaries
- Built with GCC 12.2.0 (MinGW)
- 32-bit & 64-bit