Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC v1.5.0 (Release) (Read 4977 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC v1.5.0 (Release)

FLAC v1.5.0 (Release)

The attached compiles are using the CPU optimization x86-64-v3 similar to haswell including AVX2 and x86-64-v4 for the AVX-512 version.
Inside builds are done with GCC 14.2.0
In addition there are "disable-asm-optimizations" versions with faster 16bit performance but slower 24bit performance for the use in CD format apps like CUETools or EAC.
Since 7-Zip is so effective i also added an AVX2 version with a single different compiler setting, falign-functions=16. It showed advantages for older intel CPUs at least.
At this point i want also send out thanks to @ktf for his hard work and @Porcus for the intense testing he has done of the different flac versions over time.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.5.0 (Release)

Reply #1 –
well, my I7 3rd gen is now officially obsolete to me :(

Re: FLAC v1.5.0 (Release)

Reply #4 –
It seems like you only took flac.exe and not libFLAC.dll from the archive. I think it'll work fine if you copy both to the same place.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.5.0 (Release)

Reply #5 –
Quote from: ktf on
It seems like you only took flac.exe and not libFLAC.dll from the archive. I think it'll work fine if you copy both to the same place.
You're right! I was testing with only exe, It seems that is not compatible with old dlls anymore.
Whatever, FLAC 1.5 is working here now.

Thank you kft!

Re: FLAC v1.5.0 (Release)

Reply #6 –
FLAC v1.5.0 (Release)
Built on February 11, 2025, GCC 14.2.0

32/64-bit Win builds

Re: FLAC v1.5.0 (Release)

Reply #7 –
FLAC 1.5.0

Linux static binaries
- Built with GCC 14.2.0 / glibc 2.29
- amd64 & i386

Re: FLAC v1.5.0 (Release)

Reply #8 –
From the perspective of a regular long-time Flac user, I would also like to thank KTF/contributors for the continuous development of this format. Of course there is a quantum of work behind it, but it's amazing how far the performance has come even without the use of specific instructions!
Traditionally, thanks to Wombat, NetRanger and others for specific compilations. I understand that the GCC preference has its reasons which have been explained here and there... I would still ask Wombat for the AVX2 version and NetRanger for the "standard" version, compiled using the current version of Clang. The reason is that the difference in performance of the versions provided in this thread (Wombat-s AVX2 and NetRangers "Standard" version) is negligible on my below-average configuration (mobile i5/KB-R, file 24/96, 24/44.1, 1:30h, for v. 1.5.0 multithreading via -j <thread count> enabled) and I would like to confront these results with the versions created with Clang. In the case of version 1.4.3, Clang compilations continuously gave me better results on the order of couple of percent compared to GCC. All of the above refers of course to the "release" versions of 1.5.0/1.4.3.

Re: FLAC v1.5.0 (Release)

Reply #10 –
flac-1.5.0, x64, AVX2, clang 19.1.7. There are not much additional flags for clang to set but fast-math.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.5.0 (Release)

Reply #11 –
FLAC 1.4.3 and 1.5.0 shows an error at decode:
Spoiler (click to show/hide)

Original Metadata:
Spoiler (click to show/hide)

Sample file:
Spoiler (click to show/hide)

What could be the problem?



Re: FLAC v1.5.0 (Release)

Reply #12 –
Your FLAC file contains both ID3v2 and ID3v1 tags. ID3v2 is somewhat tolerated but not recommended, ID3v1 has never been legally allowed but now the decoder is more picky and doesn't allow it. You should remove all ID3 tags from FLACs.

Re: FLAC v1.5.0 (Release)

Reply #15 –
Quote from: Case on
but now the decoder is more picky and doesn't allow it
Actually, this error is because the decoder got *less* picky. In the past, the decoder would stop after reaching the number of samples in the streaminfo metadata, therefore effectively skipping the ID3v1. However, this resulted in a number of problems. Now the decoder keeps decoding, which makes it able to read files with a wrong samplecount, thereby stumbling on the ID3v1.

The easiest way to check whether ID3v1 is the problem, is by running flac 1.5.0 in test mode. Then it will give a more explicit warning.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.5.0 (Release)

Reply #16 –
Easy for one who won't have to do the job, to propose changes - but given how often this has been asked in the age of 1.4.x, maybe it would save time to update the error message with something more informative.
Especially in those cases where the STREAMINFO length has been reached AND then immediately after, there is "TAG" or "ID3" (or "APETAGEX" or "LYRICSBEGIN"?).

(BTW, the format spec is also opaque on whether "irrelevant data at the end" is really forbidden, so maybe it should only be a warning?)
 

Re: FLAC v1.5.0 (Release)

Reply #17 –
Quote from: ktf on
Quote from: Case on
but now the decoder is more picky and doesn't allow it
Actually, this error is because the decoder got *less* picky. In the past, the decoder would stop after reaching the number of samples in the streaminfo metadata, therefore effectively skipping the ID3v1. However, this resulted in a number of problems. Now the decoder keeps decoding, which makes it able to read files with a wrong samplecount, thereby stumbling on the ID3v1.
A file with wrong number of samples stored sounds corrupted. I can't say I have seen anyone suffer from such problem even with corrupted FLAC files, but I suppose it's a good idea to allow decoding past such corruption. Since that is the case the new behavior sounds like a bug - since the decoder knows that the indicated length has been decoded perfectly and the new data isn't FLAC, why error out and treat it like it is bad FLAC bitstream?