HydrogenAudio

v1.3.4 released, with Windows binaries even.

• https://github.com/xiph/flac/releases/tag/1.3.4
• https://gitlab.xiph.org/xiph/flac/-/releases#1.3.4
• https://ftp.osuosl.org/pub/xiph/releases/flac/

v1.3.4 released, with Windows binaries even.

It's  a-l-i-v-e!   :-D (https://hydrogenaud.io/index.php?PHPSESSID=6fefc6d6u3i5n63seramhfntf6&topic=122058.msg1007587#msg1007587)

ktf can probably enlighten us on what improvements made it and which ones are still pending.

I've sent in a news item with some details: https://hydrogenaud.io/index.php?topic=122177.0

Moved to validated news.

The official win32 binary reports its version as 1.3.3. Same version is embedded in the encoded files.

Win32 and x64 compiles on Rarewares. They show 1.3.4. :)

The official win32 binary reports its version as 1.3.3. Same version is embedded in the encoded files.

And the copyright year should likely be bumped up to 2022 in both.

The official win32 binary reports its version as 1.3.3. Same version is embedded in the encoded files.

I've notified the person that released those files and checked for myself. It seems the compile really is 1.3.4, but by mistake the commit updating the version number was missing, so all patches are in.

Nice to finally see a new release, although a bit disappointed the compression patch (https://github.com/xiph/flac/pull/245) didn't make it in for this release. Extrapolating the expected time for when we'll see a release with that patch is doing me a stress.

It's  a-l-i-v-e!   :-D (https://hydrogenaud.io/index.php?PHPSESSID=6fefc6d6u3i5n63seramhfntf6&topic=122058.msg1007587#msg1007587)

LOL I forgot about that.

The Windows compiles on github and xiph for 1.3.4 have been updated, 32-bit version now also reports being version 1.3.4.

Windows 10 assholery:

Program 'flac.exe' failed to run: Operation did not complete successfully because the file contains a virus or potentia
lly unwanted softwareAt line:1 char:1

Classifies it as "Win32/Bearfoos.B!ml"

A bugfix release, please disperse.

FLAC v1.3.4 (Release)
Built on February 22, 2022, GCC 11.2.0

https://gitlab.xiph.org/xiph/flac/-/releases#1.3.4

EZ CD Audio Converter updated with FLAC 1.3.4

https://www.poikosoft.com

To bad none of the different compression optimisations went in. I wonder if they only did a release for having it at 02/20/2022 :)

I wonder if they only did a release for having it at 02/20/2022 :)

That was the reason this date was chosen, but the reason for the release is in the first two lines of the changelog:

Fix 12 decoder bugs found by oss-fuzz, including CVE-2020-0499
Fix encoder bug CVE-2021-0561

Windows Binary Speed Differences
As always, depending on the compiler, optimizations used and target CPUs, there will be always some differences in runtime speed. In my case they are rather small, but I decided to share them with the forum.

My CPU is an AMD Ryzen 7 3700X. And I've used Measuere-Command on the windowss PowerShell, and converted a large WAV file (418 MB). Flag used where: --best --exhaustive-model-search --verify --force, to make it as slow as possible. Only 64-bit binaries tested.

NetRanger's compile was the fastest, with an average of 28.3s
xiph's compile 30.0s
Rarewares compile 30.7s

Remember, each system may yield different results.

I,m decode sample 44100 Hz 16bit flac-1.3.2 and flac-1.3.4 = Ok
100% corrected SHA-512 .wav files.

Decode sample 48000 Hz 24bit (Hi-Res) flac-1.3.2 and flac-1.3.4 = Different files.
SHA-512 Not corrected.

Decode flac-1.3.2 and 1.3.4:
(https://i.postimg.cc/QC62p5gt/flac.png)
(https://i.postimg.cc/QC62p5gt/flac.png)

Why such difference in 48000 Hz 24bit ?
I compared Audio MD5 in Foobar2K = no problem, 100% corrected.
Mystic.

Not answering your question on precisely what 1.3.2 and 1.3.4 do different, but:
WAVE is a container format. It contains the audio - that will be the same between those two files - but also non-audio chunks (headers etc) which the FLAC decoder will write anew.
https://xiph.org/flac/faq.html#general__not_wave_compressor
https://xiph.org/flac/faq.html#tools__two_bytes_short


WavPack, Monkey's, TAK and OptimFROG are actually file compressors - by default, they will give you the same .wav file back (as long as it isn't malformed), with metadata and all. FLAC is "only" a lossless audio compressor. It doesn't try to remember where it got the PCM from.

Why such difference in 48000 Hz 24bit ?

Because FLAC 1.3.3 and 1.3.4 decode 24-bit files to a different wave format (the extensible one) whereas 1.3.2 and before decoded to regular wave. See the changelog:

FLAC 1.3.3 (4-Augs-2019)

 [...]
    flac:
        When converting to WAV, use WAVEFORMATEXTENSIBLE when bits per second is not 8 or 16 (erikd).

It's only the header that's different, the PCM data is identical.

Gosh, I didn't realize 1.3.2 is that old.

WAVEFORMATEXTENSIBLE when bits per second is not 8 or 16 (erikd).

"bits per second" - we've all typed that mistake, haven't we?  :-D

Wouldn't it better also output WAVEFORMATEXTENSIBLE whenever channel config isn't standard mono/stereo - no matter what bit depth? (Does it? I don't think so?)

Thanks all for quick response.
And many thanks for new release for Windows.

Genuinely curious, sorry if this is a stupid question…

1.3 came almost 10 years ago, and there was about 6 years between 1.2 and 1.3… now we are at 1.3.4, what kind of feature or change would be considered a major enough revision to make an upcoming version a so-called 1.4? Or even 2.0 if I dare ask?

There are 2 changes to the API that were left out of this release. Merging those would probably be a trigger to name it 1.4.0. I guess there would be a 2.0 on a major format addition.

I'd also say that the IETF specification is an argument for a new first decimal. If anyone goes "well that specification is from date xxxx-xx-xx, what does it apply to?" then releasing it with a 1.4.0 will make for an obvious "ah, anything 1.4 would surely be within".

I guess there would be a 2.0 on a major format addition.

Supporting that. Since FLAC has stuck to 1.x using the first decimal for bigger updates (what do you software folks call it when that is the real "major" version?),  then the mere sight of a "2.0" will induce questions/worries over compatibility. Don't use it if you don't mean it.

Interesting, I do see how that could be a valid concern. A hypothetical “2.0” might indicate something completely new and possibly confuse some. Neat anyway. Looking forward to trying 1.3.4! Will begin to point my programs to the new version.

I just compiled from GitHub.  I get 2 binaries, flac/src/flac/flac that reports at v1.3.4, and flac/src/flac/.lib/flac that still reports as v1.3.3.  I wonder why 2 binaries are made.

I just tested v1.3.4 with some extra cflags on a 622M wave file.  After a few runs, it averages about 5 seconds faster on a 5850U than the precompiled Debian v1.3.3 package.

I just compiled from GitHub.  I get 2 binaries, flac/src/flac/flac that reports at v1.3.4, and flac/src/flac/.lib/flac that still reports as v1.3.3.  I wonder why 2 binaries are made.

I presume you compiled with the defaults (./autogen.sh; ./configure; make) In that case, flac/src/flac/flac is not a binary but a wrapper script and flac/src/flac/.libs/flac is the actual binary.

However, when you run the actual binary in flac/src/flac/.libs/flac it searches for libFLAC in the default place and in your case it finds libFLAC 1.3.3 as bundled with Debian. The wrapper script under flac/src/flac/flac runs the binary flac/src/flac/.libs/flac but pointing it to the libFLAC as compiled under flac/src/libFLAC/.libs/libFLAC.so

Interesting, I do see how that could be a valid concern. A hypothetical “2.0” might indicate something completely new and possibly confuse some. Neat anyway. Looking forward to trying 1.3.4! Will begin to point my programs to the new version.

I think FLAC is using Semantic Versioning: https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

No, it doesn't: https://xiph.org/flac/faq.html#api__release_versioning

Why does your API change for point releases?

The FLAC release numbering scheme of MAJOR.MINOR.MICRO reflects the state of the FLAC format, not the API. This is most intuitive for users, at the expense of flustering developers. The shared library number (derived from the libtool current:revision:age number) is the indicator of binary API compatibility. As of FLAC 1.1.3, the current, revision, and age numbers are also #defined in the library headers to make porting easier; see the porting guide.

Quote from: Replica9000 on 2022-02-24 21:40:15

I just compiled from GitHub.  I get 2 binaries, flac/src/flac/flac that reports at v1.3.4, and flac/src/flac/.lib/flac that still reports as v1.3.3.  I wonder why 2 binaries are made.

I presume you compiled with the defaults (./autogen.sh; ./configure; make) In that case, flac/src/flac/flac is not a binary but a wrapper script and flac/src/flac/.libs/flac is the actual binary.

However, when you run the actual binary in flac/src/flac/.libs/flac it searches for libFLAC in the default place and in your case it finds libFLAC 1.3.3 as bundled with Debian. The wrapper script under flac/src/flac/flac runs the binary flac/src/flac/.libs/flac but pointing it to the libFLAC as compiled under flac/src/libFLAC/.libs/libFLAC.so

You're right.  When I ran flac -v, I thought it version might have been reported from the binary and not the library.
When I ran my test, I remembered to specify the new library path to avoid using the installed Debian version.

LD_LIBRARY_PATH=../flac/src/libFLAC/.libs

Late for the party and congratulations for the release. Some benchmarks on my new but low end i3-12100 on an 1 hour 15 minutes 16/44 wave file. The ones from xiph.org and NetRanger used around 12 seconds with -8. With -8p both of them used around 33 seconds. Both are x64 builds and tested on RAM disk.

Off topic: I am not particularly happy with my new motherboard, so be careful if you want to build a new system.
https://forum.asrock.com/forum_posts.asp?TID=22269&title=usb-compatibility-issue

Got a request from a friend who wanted some CLANG compiled FLAC binaries so............

FLAC v1.3.4 (Release)
Built on February 26, 2022, CLANG 13.0.1

Latest commit included : 2610594d

https://xiph.org/flac/
https://gitlab.xiph.org/xiph/flac/-/releases#1.3.4

Is https://sourceforge.net/projects/flac/files/flac-win/ still supposed to be maintained?

I think it has been abandoned! It probably needs to be taken down.

Great so i literally just ripped a cd today was unaware of this release do i need to re rip now?

Great so i literally just ripped a cd today was unaware of this release do i need to re rip now?

FLAC 1.3.4 has been released. This release has mostly focussed on security related bugs, of which two were labeled with CVEs. Various small fixes were included as well. No changes in compression or speed are expected.

Release on GitHub: https://github.com/xiph/flac/releases/tag/1.3.4
Release on Xiph: https://ftp.osuosl.org/pub/xiph/releases/flac/

Known bugs:
https://hydrogenaud.io/index.php?topic=121349.0

I would assume you are going to get the exact same results if you do.
But you should update your tools going forward.

Great so i literally just ripped a cd today was unaware of this release do i need to re rip now?

No. There are no changes to the format, and haven't been since *looking it up* 2007.
You won't see changes in the compression ratios either.

If you want to have the same flac version in files (e.g. if you select a bunch of them in foobar2000 and don't want the information field to be cluttered with different flac versions before the information on whether there is an mp3 among them), FLAC can re-compress in-place.
(Of course, you do have have a back-up ...)

But unless you are impatient, you might as well wait for flac 1.4.0. ktf has compression improvements ready.

Is 1.4.0 really close to release? Excellent if true. All for even better compression if possible, I already do better than -8 as standard

Oh, that is a speculation. But you aren't getting compression improvements out of upgrading.
And if you want to "upgrade" your FLAC files, you can do so in-place (back up first!) using flac -f <parameters of your choice> flacfile.flac

New compile with the latest Clang 14 compiler

FLAC v1.3.4 (Release)
Built on April 09, 2022, CLANG 14.0.0

Latest commit included : 2610594d

https://xiph.org/flac/
https://gitlab.xiph.org/xiph/flac/-/releases#1.3.4

@NetRanger @john33 Do you usually build git releases from a tarball or a git clone? I've send in this PR specifically for you two, but the question is: would it change anything?

https://github.com/xiph/flac/pull/297

This change makes the vendor string and flac command line version display that it is build from a specific git commit. It works with autotools and CMake, but only when building from a git repository, not from a tarball. Obviously CMake needs some patches to be usable with MSVC, but that'll probably be fixed by the time this is pushed.

Personally, usually from a git clone.

I use media-autobuild_suite for my build needs. MABS mainly use git clone.
Have basically zero knowledge when it come to setting up a build/compile environment. Have tried but........

Just to make this clear to me...... With this PR, when running the command "flac.exe --version" so will it show the version and commit number or? If so, would it also be possible to add so that the compiler is also shown?

Have seen this with other encoders, for example x264.

Just to make this clear to me...... With this PR, when running the command "flac.exe --version" so will it show the version and commit number or?

$ flac --version
flac git-c162eb9e

$ flac
===============================================================================
flac - Command-line FLAC encoder/decoder version git-c162eb9e

vendor string: reference libFLAC git-c162eb9e 20220411

If so, would it also be possible to add so that the compiler is also shown?

That would be possible, but I don't want the output to become too cluttered. For troubleshooting bugs, the git commit is way more important than the compiler used.

As long as version number and commit is there all the time , it's all good to me. ;)

Adding the compiler is just a suggestion. Just thought it would be a good addition.

This is how it looks on x264 :

x264 0.164.3094 bfc87b7
(lsmash 2.16.1)
built on Feb 23 2022, gcc: 11.2.0

flac git-c162eb9e

Can we keep the tag?

flac 1.3.4 git-c162eb9e

Quote from: ktf on 2022-04-11 18:34:50

flac git-c162eb9e

Can we keep the tag?

Code: [Select]

flac 1.3.4 git-c162eb9e

I agree with ya eddie.zato.
That's how it should look. Having just flac and a commit number looks/feel just wrong. The version number is important.

I don't think that would be a good idea. Compiles from git should only be used by those who know what they're doing. People could think they're working with flac 1.3.4, but they're not. They're working with some work-in-progress towards the next release, not 1.3.4.

edit: this is no different than ffmpeg does it. Only version numbers for releases, otherwise hash and build number.

It can be seen this way also...... It's still based on the '1.3.4' (in this case), and have got addition added to it. The GIT in the name should tell a person that it's not the Stable/Release. Sure some might not know what GIT is but there is no fool proof solution out there no matter what you do.

But this is something that can be debated over and over, The easy solution for this is....... since ur the dev, it's up to you.

They're working with some work-in-progress towards the next release, not 1.3.4.

Good point. Can we at least give the date of the git commit? To make it easier to understand that this build is more recent than the other one without looking to git.

flac 20220412 git-2bf5f6ec

Quote from: ktf on 2022-04-12 14:54:41

They're working with some work-in-progress towards the next release, not 1.3.4.

Good point. Can we at least give the date of the git commit? To make it easier to understand that this build is more recent than the other one without looking to git.

Code: [Select]

flac 20220412 git-2bf5f6ec

That can be a middle way to go so this goes forward

Quote

If so, would it also be possible to add so that the compiler is also shown?

That would be possible, but I don't want the output to become too cluttered.

If cluttering the output of --version is a concern, perhaps a new command-line option could be added (--about-build or something similar) which would provide information about the compiler used, and maybe also include the compiler options used for the build.

It is a very niche use case, though.

Quote from: ktf on 2022-04-11 18:34:50

Quote

If so, would it also be possible to add so that the compiler is also shown?

That would be possible, but I don't want the output to become too cluttered.

If cluttering the output of --version is a concern, perhaps a new command-line option could be added (--about-build or something similar) which would provide information about the compiler used, and maybe also include the compiler options used for the build.

It is a very niche use case, though.

That's a very good suggestion.  :)

How about just copying opus-tools' approach? Something like this would include all information necessary without too much clutter.

libFLAC 1.3.4-g179cdce 20220413

@ktf - After a bit of thinking here....... have thought more about what you wrote earlier and what others have added.......

What about this? Think would be a good solution for the '--version' switch

Stable Release
FLAC 1.3.4-2610594d-20220221

GIT Release
FLAC git-7406eab-20220419


Think this is not too much nor too little info given.

Would be clearer for power users but seems rather scary for novice ones.

I've been thinking too, and perhaps releases should simply be more frequent so only 'knowledgeable' users are tempted to use git compiles. The problem here is that there is no good solution that works with tarballs too, so implementing this might give people a false sense of security. It might even make debugging harder because a dev might assume a certain release is an official one because it expects one compiled from git to show a commit hash.

@ktf

Didn't think this would be an easy solution as i wrote earlier, but since many other codecs have had version/git, commit value & date showing for a long time when running --version so don't i think it would make things more 'scary'. But that's just me thinking'

We also the the suggestion that @doccolinni made, add a new command line switch
'--about-build'
That mite be the best 'solution' to be honest if you actually think that if more info would be 'scary' for users when running the --version switch.

Personally so don't i think that not many users bother to run a 'flac.exe --version' to get more info.

More frequent releases in general is good for sure imo, but more info regarding the flac binary in general should be added no matter what.

Personally so don't i think that not many users bother to run a 'flac.exe --version' to get more info.

I guess more users will look at what their players display about the files. "reference libFLAC 1.3.3 20190804" or something else?

Would be clearer for power users but seems rather scary for novice ones.

Would a novice user even know how to run flac.exe from a command prompt in the first place? I would expect novice users to use the fb2k converter or some other frontend that hides such internals.

I've been thinking too, and perhaps releases should simply be more frequent

(https://i.ibb.co/7KV1cQ6/wine-sip.webp)


I also think you're overestimating what a "novice" user could or would do. I know that from a programmer's perspective just fiddling in command line might seem "novice", but it is very much not so.

FLAC v1.3.4-git-1ca7b38 (2002-04-20)
Built on April 20, 2022, GCC 11.2.0

FLAC git-f579b163 20220420
Built on April 21, 2022, GCC 11.2.0

https://github.com/xiph/flac/commit/f579b163fe7ccdb0f713001d4253c5d68a3b8280

We also the the suggestion that @doccolinni made, add a new command line switch
'--about-build'

For the record, I do think this would be useful regardless. It would not be unprecedented - Firefox provides build info on the built-in page about:buildconfig that looks like this:

Spoiler (click to show/hide)
That's a fairly comprehensive information dump, and it's useful for those who need such info.

Beside the aforementioned --about-build, other options for naming this switch might be

• --build-info
• --build-config
• --help-build

I don't yet see the advantage of this. I know ffmpeg has something similar, but only for the configuration of the build (which features were enabled and disabled, what libs were linked against etc.). Furthermore, there is the problem of shared libs. The flac project consists of a few distincts parts: the flac and metaflac command line tools and the libFLAC and libFLAC++ libraries. You can use libFLAC without flac but not the other way around.

It is very well possible to compile the flac command-line utility and link it with a very different version of libFLAC. I've done that in the past to check for regressions and check DLL compatibility. In that case, what should --about-build display? The build details of flac/metaflac, or of libFLAC? Both? Currently flac displays libFLACs version number which is exposed through the API. To display the build config of libFLAC in flac, this should be added to the API too.

I don't yet see the advantage of this.

Facilitating both reproducibility and comparability. If someone wants to build FLAC for themselves, they can use the information provided there either to achieve a build that ought to be identical to another one (could be useful for testing), or to compare the effect of different compile options or compilers.

Furthermore, there is the problem of shared libs. The flac project consists of a few distincts parts: the flac and metaflac command line tools and the libFLAC and libFLAC++ libraries. You can use libFLAC without flac but not the other way around.

It is very well possible to compile the flac command-line utility and link it with a very different version of libFLAC. I've done that in the past to check for regressions and check DLL compatibility. In that case, what should --about-build display? The build details of flac/metaflac, or of libFLAC? Both?

"Both" seems the most obvious - and useful - answer.

Currently flac displays libFLACs version number which is exposed through the API. To display the build config of libFLAC in flac, this should be added to the API too.

Oh come on ktf, don't start talking like a politician now. "Added to the API" sounds so much needlessly more dramatic, ominous and impactful than "just adding a new externally callable function which has absolutely no interaction with or impact to the rest of the codebase whatsoever", which is literally all that needs to be done here - the function just needs to return a static string which is generated at compile-time.

In that case, what should --about-build display?

I think that '--about-build' should give this info :

FLAC x.x.x / git
Commit & date
compiler
Possibly compile date

Oh come on ktf, don't start talking like a politician now. "Added to the API" sounds so much needlessly more dramatic, ominous and impactful

I'm just very cautious (maybe overly so) with changing anything about the API. Maybe it isn't a big deal for you, I still think it is.

I'm just very cautious (maybe overly so) with changing anything about the API. Maybe it isn't a big deal for you, I still think it is.

I have nothing against being cautious, but the problem is that the phrase "changing the API" without any clarification utterly belies the simplicity and inconsequentiality of what is being proposed, to the point of being misleading and dishonest.

Sure - technically, adding a function which

• doesn't do anything but return a static compile-time generated string, and
• has no impact whatsoever on the rest of the codebase

can be referred to as "changing the API", on account of the fact that a new function is being added. But both you and I know damn well that the default assumption people make about the impact on the codebase implied by the phrase "changing the API" is several orders of magnitude above that.

I think that it would be a bad design if this new function will just return a hardcoded string with unspecified format. If such function is added, it would be better if it allowed to get all fields separately (an enum could be used to request specific fields).

FLAC git-c157be0 20220425
Built on April 26, 2022, GCC 11.2.0

FLAC git-c157be0 20220425
Built on April 26, 2022, GCC 11.2.0

This build doesn't show the base version number anymore, neither in the -version switch nor in the writing library info of the FLAC file:

E:\Temp>flac -version
flac git-c157be0f 20220425

Writing library                          : libFLAC 20220425 (UTC 2022-04-25)

I think this is a bad idea, we should always know the base version number in any case like before.

I think that it would be a bad design if this new function will just return a hardcoded string with unspecified format. If such function is added, it would be better if it allowed to get all fields separately (an enum could be used to request specific fields).

Well, fair, then that. The same remarks apply.

Code: [Select]

Writing library                          : libFLAC 20220425 (UTC 2022-04-25)

Where from? I find a "reference libFLAC git-c157be0f 20220425" in the file.

Quote from: Brazil2 on 2022-04-26 12:33:32

Code: [Select]

Writing library                          : libFLAC 20220425 (UTC 2022-04-25)

Where from? I find a "reference libFLAC git-c157be0f 20220425" in the file.

From a WAV file I've just encoded using NetRanger's FLAC git-c157be0 20220425 x64 build he has posted. MediaInfo doesn't report the git info but you're right, I see the full string inside the file using an hex editor.
Anyway I think the base version number 1.3.4 is still needed:  "reference libFLAC 1.3.4 git-c157be0f 20220425"

OK, so this is MediaInfo that reports
reference libFLAC 1.3.4 20220220                          as           libFLAC 1.3.4 libFLAC (UTC 2022-02-20)
reference libFLAC git-c157be0f 20220425           as           libFLAC 20220425 (UTC 2022-04-25)
... in "Tree" view. Now select Debug -> Advanced Mode ... or "Text" view.

Looks like this is just a MediaInfo peculiarity? Any reason that other applications should make the same issue?

Quote from: ktf on 2022-04-22 18:56:56

I don't yet see the advantage of this.

Facilitating both reproducibility and comparability. If someone wants to build FLAC for themselves, they can use the information provided there either to achieve a build that ought to be identical to another one (could be useful for testing), or to compare the effect of different compile options or compilers.

Having had some time to ponder this, I've reconsidered: not a bad idea to add. Probably best to copy the approach ffmpeg has on what to output. Note that I don't consider this high-priority though, so it might take a while. Anyone is welcome to contribute a PR though.

This build doesn't show the base version number anymore, neither in the -version switch nor in the writing library info of the FLAC [...]
I think this is a bad idea, we should always know the base version number in any case like before.

Please elaborate why you think this is a bad idea.

I thought it a bad idea to leave any version number in. In my opinion version numbers belong a certain release, and these compiles are no releases, they are compiles straight from git, i.e. inbetween releases. ffmpeg uses the same approach: only specific releases have a version number, others a revision number. If you want to compare versions, I believe using the date provides a nice alternative.

I thought it a bad idea to leave any version number in. In my opinion version numbers belong a certain release, and these compiles are no releases, they are compiles straight from git, i.e. inbetween releases. ffmpeg uses the same approach: only specific releases have a version number, others a revision number. If you want to compare versions, I believe using the date provides a nice alternative.

Because I want to know at first sight which base version has been used.
For instance, in ten years time from now I won't have to waste time searching for the commit number or the date and the base version it refers to.

Because I want to know at first sight which base version has been used.
For instance, in ten years time from now I won't have to waste time searching for the commit number or the date and the base version it refers to.

I agree with ya also. It must not say 1.3.4 (for example) at the beginning but the code base should be there even if it's a git compile.

Example :
FLAC git-c157be0 20220425 (Code base : 1.3,4)

The git releases is still based on the previous stable release.

Shouldn't in the very least the YYYYMMDD go at the end? Like
reference libFLAC 1.3.4git-c157be0 20220425

1.3.4git-something means that it is based on 1.3.4 and blah blah blah

Thanks very much. 
I'm still in love with FLAC. 
Gotta love FLAC. 

FLAC git-3fc5ba4 20220501
Built on May 01, 2022, GCC 11.2.0
(Code Base : 1.3.4)

Thank you very much for the update.

FLAC git-1bec35e3 20220511
Built on May 11, 2022, GCC 11.3.0
(Code Base : 1.3.4)

FLAC git-1bec35e3 20220511
Built on May 11, 2022, GCC 11.3.0

Note that development is currently mainly focused on improving fuzzing to find security related bugs and as some sort of quality assurance for next releases, so there are few (if any) changes that affect end-users in these releases.

Quote from: NetRanger on 2022-05-11 11:30:56

FLAC git-1bec35e3 20220511
Built on May 11, 2022, GCC 11.3.0

Note that development is currently mainly focused on improving fuzzing to find security related bugs and as some sort of quality assurance for next releases, so there are few (if any) changes that affect end-users in these releases.

Thnx for the info :)

FLAC git-4dedae4f 20220522
Built on May 22, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

FLAC git-3528fa2 20220610
Built on June 11, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

FLAC 1.3.4 git-3528fa2, including dlls, now at Rarewares. :)

FLAC git-9b38260 20220612
Built on June 13, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

FLAC git-9b38260 20220612

The filename says 73cb63a, the post says 9b38260. 73cb63a is newer, it includes 32-bit PCM encoding and decoding

Quote from: NetRanger on 2022-06-13 14:44:24

FLAC git-9b38260 20220612

The filename says 73cb63a, the post says 9b38260. 73cb63a is newer, it includes 32-bit PCM encoding and decoding

That is a pretty major revision to the format if true! Does this apply to 32 bit floating point as well or just “normal” 32 bit samples?

I am sure I have (previously incompressible) examples of both somewhere in my archives, I will have to poke through and see if I can give this a try…

Quote from: ktf on 2022-06-13 16:01:52

[...] it includes 32-bit PCM encoding and decoding

That is a pretty major revision to the format if true! Does this apply to 32 bit floating point as well or just “normal” 32 bit samples?

Only 32-bit integer PCM, no floating-point. I wouldn't call this a revision to the format, the format always had room for this, it was just never implemented until now. The only change to the format is that a previously reserved symbol was assigned for 32-bit bit depth, so existing encoders will not try to decode this. Adding 32-bit floats would need a lot of change to the FLAC format itself, which is why it will probably never support them.

I am sure I have (previously incompressible) examples of both somewhere in my archives, I will have to poke through and see if I can give this a try…

Please do, let me know when you encounter any problems.

Quote from: NetRanger on 2022-06-13 14:44:24

FLAC git-9b38260 20220612

The filename says 73cb63a, the post says 9b38260. 73cb63a is newer, it includes 32-bit PCM encoding and decoding

A slight error on my side when i posted it.

FLAC git-73cb63a 20220612
Built on June 13, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master


----------------

Readme.txt file in archive have been updated

Quote from: MrRom92 on 2022-06-13 17:36:49

Quote from: ktf on 2022-06-13 16:01:52

[...] it includes 32-bit PCM encoding and decoding

That is a pretty major revision to the format if true! Does this apply to 32 bit floating point as well or just “normal” 32 bit samples?

Only 32-bit integer PCM, no floating-point. I wouldn't call this a revision to the format, the format always had room for this, it was just never implemented until now. The only change to the format is that a previously reserved symbol was assigned for 32-bit bit depth, so existing encoders will not try to decode this. Adding 32-bit floats would need a lot of change to the FLAC format itself, which is why it will probably never support them.

Quote

I am sure I have (previously incompressible) examples of both somewhere in my archives, I will have to poke through and see if I can give this a try…

Please do, let me know when you encounter any problems.

Thank you for the explanation!! I think this is a pretty big deal - one less reason to deal with WAVpack at least. I’ll be sure to report my findings if I come across any non-floating point files.
In search of some older 32 bit files, I did come across some WAVs that were previously (and probably still are) incompressible, however due to another reason entirely - they are 24/768kHz, and the max sampling rate the FLAC encoder allows is 655.35kHz

I believe (however I may be mistaken) that this is not truly a limitation of the format, just a current limitation of the encoder based on how it’s written, perhaps similar to how 32bit was not truly supported until now?
Is it possible that this is something that can be changed in a future update?

Not that I expect any commercial music releases to ever use such a high sampling rate, nor do I think it would have any practical application to most people, but it does seem that 768kHz is somewhat of a standard sampling rate for audio analysis and some other professional applications. It would be nice to have them compressible as well, as it would seem to be a much more appropriate format for this purpose.


I do know that the Domesday Duplicator / ld-decode folks are using FLAC compression in some nonstandard manner for recordings of RF captures sampled at 33.5MHz (yes, with an M) so theoretically this should be possible with the standard encoder too, if not for the limitation being baked in.

In search of some older 32 bit files, I did come across some WAVs that were previously (and probably still are) incompressible, however due to another reason entirely - they are 24/768kHz, and the max sampling rate the FLAC encoder allows is 655.35kHz

This limit has been raised to 1,048,575Hz in April, which is the true limit of the format. The previous 655,350Hz was the 'streamable' limit of the format, for some reason the reference encoder (libFLAC) didn't accept anything with a higher samplerate than that.

Not that I expect any commercial music releases to ever use such a high sampling rate, nor do I think it would have any practical application to most people, but it does seem that 768kHz is somewhat of a standard sampling rate for audio analysis and some other professional applications. It would be nice to have them compressible as well, as it would seem to be a much more appropriate format for this purpose.

Here's one such release on 768kHz (https://www.soundliaison.com/index.php/studio-masters/856-ray-carmen-gomes-inc).

I do know that the Domesday Duplicator / ld-decode folks are using FLAC compression in some nonstandard manner for recordings of RF captures sampled at 33.5MHz (yes, with an M) so theoretically this should be possible with the standard encoder too, if not for the limitation being baked in.

Yes, I've recommended them to place the sample rate in a vorbis comment or something similar. The samplerate is nothing to the FLAC format but a number, it doesn't do anything with it except including it in the frame headers and giving it back on decoding. It really is only necessary to be able to properly play back a file.

Here's one such release on 768kHz (https://www.soundliaison.com/index.php/studio-masters/856-ray-carmen-gomes-inc).

With a free track.
And it has been through digital to analog to digital (https://hydrogenaud.io/index.php/topic,93853.msg1006575.html#msg1006575). Here is the Studer in action: https://youtu.be/34jvCjrue40?t=80
Quite a nonsense recording/mixing process for showcasing hires - but "it exists on the market!" is a point for a lossless codec.

FLAC does that free track quite well, by the way. A percentage point off OptimFROG's max setting. But also ALAC does it well, so maybe it is just Monkey's that was taken out of its comfort zone and WavPack that needs a high -x setting (as often happens with high-resolution audio, that was confirmed here: http://www.audiograaf.nl/losslesstest/revision%205/Average%20of%20all%20hi-res%20sources.pdf )

I do know that the Domesday Duplicator / ld-decode folks are using FLAC compression in some nonstandard manner for recordings of RF captures sampled at 33.5MHz (yes, with an M) so theoretically this should be possible with the standard encoder too, if not for the limitation being baked in.

That is a reason to use WavPack. It handles 4 GiHz (like WAVE does).

768kHz is somewhat of a standard sampling rate for audio analysis and some other professional applications. It would be nice to have them compressible as well, as it would seem to be a much more appropriate format for this purpose.

I don't know how a standard is defined, but a quick Google search with keywords like 1536kHz DAC, there are about 367,000 results with links to actual products supporting 32-bit 1536kHz input.

Realtek chips on $50 PC motherboards for example support up to 24/192 with 6 to 8 channels, could be a popular low anchor in terms of hardware capabilities, if not putting actual analog performance into consideration.

a quick Google search with keywords like 1536kHz DAC, there are about 367,000 results with links to actual products supporting 32-bit 1536kHz input.

Google fools itself. Go to the bottom of the page and click at page number six.
https://www.google.com/search?q=(%221536+kHz%22+OR+%221536kHz%22)+AND+%22DAC%22&start=50
Drop the "&start=50" and I also get 367 k. But scrolling to the end, it is only 56. Click for the search to include the alike-hits, and I get 236 of them in total.

Replace both 1536 by 768 and the 56 grow to 88 and the 236 to 389.

Google fools itself. Go to the bottom of the page and click at page number six.
https://www.google.com/search?q=(%221536+kHz%22+OR+%221536kHz%22)+AND+%22DAC%22&start=50
Drop the "&start=50" and I also get 367 k. But scrolling to the end, it is only 56. Click for the search to include the alike-hits, and I get 236 of them in total.

Replace both 1536 by 768 and the 56 grow to 88 and the 236 to 389.

Don't know about Google's algorithms and quirks but it is rather popular for DACs (as a whole product) to support 32-bit 1536kHz via I2S with HDMI/RJ45 and such, providing the DAC chips themselves support the format.

Higher bit-depth or PCM sample rates are much less popular, perhaps require custom chips instead of generic ones.

That is a reason to use WavPack. It handles 4 GiHz (like WAVE does).

After receiving your comment about some Sound Liaison files, I tried to find a better way to skip unknown RIFF chunks. Another thing is I also added a check to nAvgBytesPerSec in WAVEFORMAT. nAvgBytesPerSec is a 32-bit value defining the average byte (not bit) rate of a file and therefore the maximum bitrate of a file must be smaller than 2 ^ 32 * 8. My check is ensure the combination of sample rate, bit depth and channel count in a uncompressed file does not exceed the maximum allowed nAvgBytesPerSec.

I found that quite a number of software don't check this and treat sample rate, bit depth and channel counts separately, and the combination can well exceed what nAvgBytesPerSec allows.

Also, I found that Audition 1.5 which I use shows negative sample rates for values beyond 2 ^ 31.

Here's one such release on 768kHz (https://www.soundliaison.com/index.php/studio-masters/856-ray-carmen-gomes-inc).

Wow... what a waste of space, recources, time, money. It contains almost HF-Noise.


(https://i.postimg.cc/44HzZ8n1/2022-06-14-10-36-55-Let-The-Good-Times-Roll-Carmen-Gomes-Inc-Free-768k-Hz.png)

Quote from: ktf on 2022-06-14 06:34:05

Here's one such release on 768kHz (https://www.soundliaison.com/index.php/studio-masters/856-ray-carmen-gomes-inc).

Wow... what a waste of space, recources, time, money. It contains almost HF-Noise.


(https://i.postimg.cc/44HzZ8n1/2022-06-14-10-36-55-Let-The-Good-Times-Roll-Carmen-Gomes-Inc-Free-768k-Hz.png)

The best part is some of their 24-bit files are actually 16-bit. Download the archive and check out the readme file.
https://hydrogenaud.io/index.php/topic,114816.msg1010860.html#msg1010860

almost HF-Noise

An extra octave of it added by going DXD to analog tape to double-the-Hz digital. Best of both worlds! ;-)
Apparently, all PR is good PR.

The best part is some of their 24-bit files are actually 16-bit.

Unlike an-octave-or-four of tape hiss, that need not cost anything; some of them are so cleanly 16-padded-to-24 that FLAC compresses it away.  (As well known: FLAC/WavPack/TAK/OptimFROG handle wasted bits. ALAC/Monkey's/TTA don't.)

Just for those curious: I'm not adding 32-bit int and >655350Hz handling to FLAC because I think it has any (audible) benefit. I also am not getting paid for this.

The only reason these features are added to libFLAC is because the standard allows them. Currently an IETF working group is writing a document on the FLAC specification which should at some point become a standards track RFC. One of the requirements of becoming a proper IETF standard is that there should be at least two implementations of each part of the standard. That means that IMO at least libFLAC should be able to use all features of the FLAC format. That means adding support for 32-bit PCM, but it will also mean libFLAC should at some point support variable blocksize encoding. (I can't yet guarantee that using a variable blocksize will be any improvement though)

Quote from: MrRom92 on 2022-06-14 01:30:24

In search of some older 32 bit files, I did come across some WAVs that were previously (and probably still are) incompressible, however due to another reason entirely - they are 24/768kHz, and the max sampling rate the FLAC encoder allows is 655.35kHz

This limit has been raised to 1,048,575Hz in April, which is the true limit of the format. The previous 655,350Hz was the 'streamable' limit of the format, for some reason the reference encoder (libFLAC) didn't accept anything with a higher samplerate than that.

Quote

Not that I expect any commercial music releases to ever use such a high sampling rate, nor do I think it would have any practical application to most people, but it does seem that 768kHz is somewhat of a standard sampling rate for audio analysis and some other professional applications. It would be nice to have them compressible as well, as it would seem to be a much more appropriate format for this purpose.

Here's one such release on 768kHz (https://www.soundliaison.com/index.php/studio-masters/856-ray-carmen-gomes-inc).

Quote

I do know that the Domesday Duplicator / ld-decode folks are using FLAC compression in some nonstandard manner for recordings of RF captures sampled at 33.5MHz (yes, with an M) so theoretically this should be possible with the standard encoder too, if not for the limitation being baked in.

Yes, I've recommended them to place the sample rate in a vorbis comment or something similar. The samplerate is nothing to the FLAC format but a number, it doesn't do anything with it except including it in the frame headers and giving it back on decoding. It really is only necessary to be able to properly play back a file.

Beautiful, I was totally unaware of that recent change as well! I’ll have to give these 24/768 files a shot on the newer compile now too.

The only practical application I know of for such high sampling rates in terms of music production is capturing the bias signal present on tape to digitally correct temporal distortions, ie. Plangent Process

I don’t foresee a time when there is any legitimate usage of that as a deliverable format. There will always be some nutty small label trying to experiment, but the one pointlessly printing digital to tape and back seems like they are alone in this regard and probably will be for some time…

As far as I am aware there is no PCM DAC that can truly operate at such frequency anyhow. Anything advertising sampling rates higher than 192kHZ is with all certainty using a delta-sigma chip. The non-oversampling converters capable of natively operating at 192kHz are already very few and far between.

Celemony Capstan doesn't require high sample rates to grab the bias signal, which means in case the original tape is already damaged or unavailable, the software can still analyze the audio data of an existing file to do the restoration.
https://www.soundonsound.com/reviews/celemony-capstan
https://www.celemony.com/en/capstan

For generic ADC chips, the 15+ years old TI PCM4222 for example has a 6-bit modulator running at maximum 6.912MHz. Of course, this requires a customized controller accompanied with the ADC chip, not via typical PCM or DSD methods. Judge from the age, processing power is indeed not a concern, but hiring someone to code the controller for a potentially very small market could be expensive.

FLAC 1.3.4 git-cbb039d, including dlls, now at Rarewares. :)

I’ll have to give these 24/768 files a shot on the newer compile now too.

I've posted some results already for the free file - now including -5 and -8p from NetRanger's build.

The "TransposedTo192k.nometadata" files are just that I changed the sampling rate in the .wav file and removed the 1265 MB metadata - reason for changing the sampling is to get a comparable TAK.  The 1265 makes an "error" in comparing FLAC/ALAC/TTA that don't (by default) store foreign metadata, to the others

969 129 022 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.wav
967 864 784 TransposedTo192k.nometadata.wav
778 734 183 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.7z
703 857 334 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.fj0.wv
673 615 462 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.fast.ape
666 519 575 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.tta
663 164 138 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.hx1.wv
653 129 918 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.normal.ape
652 911 634 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.high.ape
650 586 694 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.m4a
649 644 648 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-5.flac
649 459 286 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.extrahigh.ape
645 055 381 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.als-at-default-in-.mp4
643 043 026 TransposedTo192k.nometadata.-8p.flac
642 946 998 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-8p.flac
641 225 096 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.wv-hhx6.=37min=.wv
640 902 644 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.wv480-hhx6.=40min=.wv
637 544 165 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-z3.als
634 689 178 TransposedTo192k.nometadata.-p4m.tak
634 179 909 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-7-t2.ALS-in.mp4
632 366 679 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.ofr.max.ofr

(WavPack 5.40 is a bit faster than 4.80. The slightly bigger files are due to the new format with checksummed blocks, enabling fast integrity verification without decoding.)

FLAC git-c94b4f8f 20220626
Built on June 26, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

FLAC git-c94b4f8f 20220626
Built on June 26, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

Thank you for the new compile, Netranger. Doing gods work here!
Still have not had the chance to try any of the recent builds… office PC still inaccessible for the time being due to ongoing plumbing issues… 😩

FLAC git-633ab36e 20220701
Built on July 01, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

Thank you again NetRanger!

I finally got a chance to try this out however I still could not compress the 24/768kHz files I had. It immediately errored out both trying it with FLAC.exe directly as well as trying to start a conversion in Foobar. Not sure if it’s a “me” problem

You need to apply the --lax option. By command-line, you throw in " --lax " before or after all the other options.

You need to apply the --lax option. By command-line, you throw in " --lax " before or after all the other options.

Ahhh, therein lies the rub. Thank you for that!

The only practical application I know of for such high sampling rates in terms of music production is capturing the bias signal present on tape to digitally correct temporal distortions, ie. Plangent Process

Also, maybe for situations when it's not really about sound, just some physical processes, maybe radio frequency even. (archives/test cases for software-defined radio?) Possibly useful if the signal may share some statistical properties with that of sound, making it somewhat compressible by similar algorithms.
(But then, even ~1Mhz might not be a high enough upper limit)

Also, maybe for situations when it's not really about sound, just some physical processes, maybe radio frequency even. (archives/test cases for software-defined radio?) Possibly useful if the signal may share some statistical properties with that of sound, making it somewhat compressible by similar algorithms.
(But then, even ~1Mhz might not be a high enough upper limit)

--> over at the WavPack forum: https://hydrogenaud.io/index.php/topic,122626

WavPack handles "any .wav" sampling frequency, that is integers up to 4 GiHz. That covers most amateur radio bands. (There are radio bands above https://en.wikipedia.org/wiki/9-centimeter_band , and then ... well, out of luck :-o)

FLAC git-48d4f812 20220713
Built on July 13, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

FLAC git-3022dad8 20220806
Built on August 06, 2022, GCC 12.1.0
(Code Base : 1.3.4)

https://github.com/xiph/flac/commits/master

FLAC git-3022dad8 20220806
Built on August 06, 2022, GCC 12.1.0

The 64-bit build includes encoder speedups for CPUs with FMA (basically any CPU with AVX2) to help compensate for the speed loss that resulted from the autocorrelation precision increase. When https://github.com/xiph/flac/pull/407 is merged, I hope most recent Intel/AMD CPUs (running the 64-bit binary) will see encoding speeds similar to 1.3.4 but with higher compression.

So, ... 1.3.5 or 1.4.0 coming up in a not too distant future?

That's the idea, but I'm still working on a documentation overhaul and there are some fuzz results that need a fix.

Is there a summary of FLAC improvements somewhere that is more direct than the changelog on Xiph.org? IIRC the main improvements after the move to Xiph were related to multichannel support, but FLAC has had no major changes that broke backwards compatibility with older versions and no major improvements in compression efficiency for CDDA, either. Is that an outdated assessment?

As far as I am aware there is no PCM DAC that can truly operate at such frequency anyhow. Anything advertising sampling rates higher than 192kHZ is with all certainty using a delta-sigma chip. The non-oversampling converters capable of natively operating at 192kHz are already very few and far between.

Several GHz are now okay for a DAC and 192kHz is very low. Look at this:

https://www.keysight.com/us/en/product/M9484C/m9484c-vxg-vector-signal-generator.html

3 GHz in 16 bits. I can't believe it  :D

Is there a summary of FLAC improvements somewhere that is more direct than the changelog on Xiph.org?

Please explain what you mean by 'direct'.

but FLAC has had no major changes that broke backwards compatibility with older versions and no major improvements in compression efficiency for CDDA, either. Is that an outdated assessment?

I beg to differ. CDDA compression was improved by 0.3% in FLAC 1.3.1 (see here (https://hydrogenaud.io/index.php/topic,106545.50.html)) and probably by (on average) another 0.3% in the next release (see here (https://hydrogenaud.io/index.php/topic,120158.msg999746.html#msg999746)). That is pretty major I'd say.

Also, the addition of the 5-bit rice parameters in FLAC 1.2.0 and 1.2.1 was a breaking change, that was after the move to Xiph.org.

It’s been nearly 10 years since 1.3.0 and we may be inching closer to 1.4.0 !!!

I don’t know why I get so excited over version numbers, but I just do. It feels very significant. It’s like a birthday, but for insentient lines of code rather than a family member.

Talking about the version number, any news about this ?
https://hydrogenaud.io/index.php/topic,122179.msg1010410.html#msg1010410
https://hydrogenaud.io/index.php/topic,122179.msg1010420.html#msg1010420

Talking about the version number, any news about this ?
https://hydrogenaud.io/index.php/topic,122179.msg1010410.html#msg1010410
https://hydrogenaud.io/index.php/topic,122179.msg1010420.html#msg1010420

No, nothing has changed. I still feel it is a very bad idea to use git compiles for anything but experimentation and testing.

I'm still working on a documentation overhaul

So the recommendations of -fb/-fl/-fc/-fp/-fs/-fr might have to go, finally?  :))

it is a very bad idea to use git compiles for anything but experimentation and testing.

And that's exactly why we need a code base version number: for being able to easily compare different versions!
ffmpeg is a good example, after all it's just a pack of various libraries and filters. The git builds don't show a code base version number in the command prompt but they do print a version number in the file being made and the libraries print their own version number.

Writing application                      : Lavf57.66.102
Writing library                          : x265 2.3+9-820f4327ddac:[Windows][GCC 5.3.1][64 bit] 10bit

This is how it should be so everyone will be happy:
https://hydrogenaud.io/index.php/topic,122179.msg1010428.html#msg1010428

Please explain what you mean by 'direct'.

CDDA compression was improved by 0.3% in FLAC 1.3.1 (see here (https://hydrogenaud.io/index.php/topic,106545.50.html)) and probably by (on average) another 0.3% in the next release (see here (https://hydrogenaud.io/index.php/topic,120158.msg999746.html#msg999746)).

That's actually what I meant. For end users considering upgrading their FLAC version, the main points of interest are whether a new version either compresses faster or more effectively, but the changelog  tends to list changes that are relevant to developers, rather than statistical improvements. I doubt I would have found those threads on my own unless I searched HA for every FLAC thread since version 1.2.

Also, the addition of the 5-bit rice parameters in FLAC 1.2.0 and 1.2.1 was a breaking change, that was after the move to Xiph.org.

Really? FLAC 1.2.1 only outputs (C) Josh Coalson and does not mention Xiph at all.

Really? FLAC 1.2.1 only outputs (C) Josh Coalson and does not mention Xiph at all.

FLAC joined Xiph just after the 1.1.0 release, but Josh continued development. After he stopped around 2010, "Xiph" took over.

So the recommendations of -fb/-fl/-fc/-fp/-fs/-fr might have to go, finally?  :))

I don't follow?

Quote from: ktf on 2022-08-08 20:33:41

it is a very bad idea to use git compiles for anything but experimentation and testing.

And that's exactly why we need a code base version number: for being able to easily compare different versions!

Except that doesn't really say anything. Current git would be marked 1.3.4 but is probably closer to 1.4.0 or something. Whats wrong with using the commit date to compare?

ffmpeg is a good example, after all it's just a pack of various libraries and filters. The git builds don't show a code base version number in the command prompt but they do print a version number in the file being made and the libraries print their own version number.

Code: [Select]

Writing application                      : Lavf57.66.102
Writing library                          : x265 2.3+9-820f4327ddac:[Windows][GCC 5.3.1][64 bit] 10bit

It doesn't show 'FFmpeg 4.3' either, that would be a version number. Furthermore, those library version numbers change almost every week, while for FLAC they rarely change.

Quote from: Porcus on 2022-08-08 22:29:53

So the recommendations of -fb/-fl/-fc/-fp/-fs/-fr might have to go, finally?  :))

I don't follow?

From output of flac --explain:

===============================================================================
flac - Command-line FLAC encoder/decoder version 1.3.4
[...]
flac checks for the presence of a AIFF/WAVE header to decide whether or not to
treat an input file as AIFF/WAVE format or raw samples.  If any input file is
raw you must specify the format options {-fb|fl} -fc -fp and -fs, which will
apply to all raw files.  You can force AIFF/WAVE files to be treated as raw
files using -fr.

Seems that these options were dropped between flac 1.0.3 (of July 2002) and flac 1.0.4 (of September 2002).

You read it first at hydrogenaud.io  8)

Whats wrong with using the commit date to compare?

I already explain that: a commit number doesn't show the code base version it refers to. How will I know the code base version of commit 3022dad8 in ten years time ?
What Porcus has suggested is the way to go: libFLAC 1.3.4git-c157be0 20220425
Easier and faster for everyone to know at first sight that this build is the evolution c157be0 of code base v1.3.4 made on 2022-04-25.
I don't understand why it's a blocker for you. "1.3.4git-blabla" clearly shows it's not a release but a test version.

It doesn't show 'FFmpeg 4.3' either, that would be a version number. Furthermore, those library version numbers change almost every week, while for FLAC they rarely change.

We don't care about what ffmpeg is doing, seriously. ffmpeg is just sending arguments to the libraries it contains and these libraries DO have their own version numbers and they are printed out in output files. ffmpeg is not one single encoder but FLAC is.
There are several people who have asked you to preserve the code base version number. Maybe listen to your users ? We do use the encoder and the resulting files on a regular basis and over years.
Your users should be more your reference than ffmpeg ;)

Seems that these options were dropped between flac 1.0.3 (of July 2002) and flac 1.0.4 (of September 2002).

Never noticed. I was actually referring to the website and source code documentation, but removing this is probably also a good idea.

Quote from: ktf on 2022-08-09 12:15:48

Whats wrong with using the commit date to compare?

I already explain that: a commit number doesn't show the code base version it refers to. How will I know the code base version of commit 3022dad8 in ten years time ?

I understand that the commit hash is hard to keep track of, but what about the commit date.

I don't understand why it's a blocker for you. "1.3.4git-blabla" clearly shows it's not a release but a test version.

I'll quote myself:

Current git would be marked 1.3.4 but is probably closer to 1.4.0 or something.

The version number 1.3.4 belongs to a specific release. As soon as something is added or removed, it is no longer that release, and it is in my view no longer version 1.3.4. Having version number 1.3.4git-hash suggest it is 1.3.4, but it isn't.

We don't care about what ffmpeg is doing, seriously.

You are the one who came up with ffmpeg in the first place.

Maybe listen to your users ?

I've listened, and I didn't find the arguments compelling. I'm doing this in my own time, unpaid, because I like FLAC. It is taking up pretty much all of my free time, fixing bugs and security issues that most users will never notice. Maybe you rather have me stop doing any work on FLAC at all?

Having version number 1.3.4git-hash suggest it is 1.3.4, but it isn't.

The git bit clearly shows  it's not a release but a test version, as said before.

You are the one who came up with ffmpeg in the first place.

No, you are the one. Here:
https://hydrogenaud.io/index.php/topic,122179.msg1010055.html#msg1010055

I'm doing this in my own time, unpaid, because I like FLAC. It is taking up pretty much all of my free time, fixing bugs and security issues that most users will never notice. Maybe you rather have me stop doing any work on FLAC at all?

We are all coming here on our free time, we are all trying to help and share on our free time, so you blackmail to stop working on FLAC just because you have suddenly decided to remove the version number and you can't handle the users to disagree with that ? Tsss ::)
You want to do like ffmpeg, but ffmpeg does print the version numbers of the encoders in the output files, even test versions. That's a fact.
No need to answer now, I have understood you will not go back just because you are upset and don't want to give the impression you will somehow surrender.

We are all coming here on our free time, we are all trying to help and share on our free time, so you blackmail to stop working on FLAC just because you have suddenly decided to remove the version number and you can't handle the users to disagree with that ? Tsss ::)
You want to do like ffmpeg, but ffmpeg does print the version numbers of the encoders in the output files, even test versions. That's a fact.
No need to answer now, I have understood you will not go back just because you are upset and don't want to give the impression you will somehow surrender.

I think that to equate visiting the forum and posting a few comments and ideas with giving up considerable amounts of personal time in the refining and improvement of FLAC is pretty insulting, to be honest.

Unfortunately there are numbers of people around who seem to believe that those of us who contribute freely in time and effort are at everyones beck and call and that we should jump at their every suggestion. Instead, it would be great if you could just be grateful and thankful. Ideas are valued, but when they start to become demands, that is neither correct nor required.

Quote from: ktf on 2022-08-09 16:17:00

I'm doing this in my own time, unpaid, because I like FLAC. It is taking up pretty much all of my free time, fixing bugs and security issues that most users will never notice. Maybe you rather have me stop doing any work on FLAC at all?

We are all coming here on our free time, we are all trying to help and share on our free time, so you blackmail to stop working on FLAC just because you have suddenly decided to remove the version number and you can't handle the users to disagree with that ? Tsss ::)

I apologize for that post, it wasn't intended as any kind of threat, it was a genuine question. Reading it back, I agree it just doesn't read that way.

I have understood you will not go back just because you are upset and don't want to give the impression you will somehow surrender.

I disagree. I have given a reasoning as to why I don't want a version number in there and I haven't read anything to convince me to do otherwise. I don't feel like I'm unreasonable, and I think I've proven I can be persuaded even after long discussion. You can read back a lengthy discussion here (https://github.com/xiph/flac/pull/399) as an example.

The thing is, I haven't read any good reason as to why using the commit date isn't a good solution.

Once again, here is my reasoning: A FLAC version number belongs to a specific release. So, FLAC 1.3.4 is this specific set of files (https://github.com/xiph/flac/tree/1.3.4). That specific set of files is distributed as source code and compiles from "official" sources. As soon as anything is changed at all (I do not consider compiling a change, as it does not change anything to any file git tracks), that set of files is no longer FLAC version 1.3.4, so I think we should stop calling it version 1.3.4. I agree it could be called 1.3.4git-somehash, but I would very much like to make clear that that set of files is no longer 1.3.4 but something else. The change may be as tiny as a typo fix, but current git has had major breaking API changes compared to 1.3.4 and quite large additions which might contain serious bugs as there is continuous development and not much testing.

Why do I think naming shouldn't be 1.3.4git-somehash? Because I think many people read 1.3.4 and no further. I also think that using the commit date is a perfectly reasonable way to find out which version you're working with, and as long as I don't hear compelling reasoning that convinces me otherwise, I don't want to change this just because someone else wants it that way.

The thing is, I haven't read any good reason as to why using the commit date isn't a good solution.

Builds based not on the most recent highest-numbered official version, is that even a thing with FLAC? Or going to be?
If there is nothing such, I guess whoever can read what "git" means can also infer that a build with "20220626" would be 1.3.4 codebase.
But if a "1.4.0" will break an API or anything else that might make for a 1.3.x codebase to live on in new builds ... uh-oh.

that we should jump at their every suggestion.

John, we are not talking about something new to be added but about something which has been removed. To me it's a regression. There have been many suggestions about the format of this string since then but they have all been rejected.

Why do I think naming shouldn't be 1.3.4git-somehash? Because I think many people read 1.3.4 and no further.

Ok, have a break, two or three days, really, and read it again. It started here: https://hydrogenaud.io/index.php/topic,122179.msg1010029.html#msg1010029

Several different people have said it's very useful and makes things easier and faster to have the code base version being displayed. The people who are taking part of this thread are obviously not novices. The people who are able to display the encoder string do know what they are doing, and they do understand what the GIT bit means. Please.

It sounds like this may be an issue of changing how version strings are constructed for release vs non-releases and wanting to communicate/know if a given build is a a release with upcoming bugfixes vs something else.

From looking at the code repo - it really doesn't make sense to say a release is "based on 1.3.4" and have that "1.3.4+some-git-hash" version string, because there's been API changes and even spec updates since 1.3.4. It's really not 1.3.4 anymore, or even "1.3.x".

So what about utilizing branches in the versioning - meaning once an API change hits, create a 1.4.x branch. Then embed the version number as 1.4.x-githash/date/whatever.

It looks like there's a 1.3.x branch currently. I'm guessing at some point, a new branch will be split off master and named 1.4.x.

Since you're moving onto 1.4.0 (I see documentation in the repo for porting apps from 1.3.4 to 1.4.0), if you make a 1.4.x branch and update the build system to include the branch name on non-tagged released, so you get versions like 1.4.x+githash+date, I think the "1.4.x" naming makes it pretty clear this is an experimental release and not necessarily compatible with the older 1.3 releases. Especially since there's no 1.4.x releases yet, right. Users using the latest builds will know "oh, this is different."

I'm saying all this while assuming this is driven by git. I do see the CMakeLists file contains the 1.3.4 string as well. If that's what really drives all this, that could even be changed to something like "1.4.x".

However it's accomplished the main point is to give a version string that better communicates whether this is just 1.3.4+patches or an upcoming new release. I get where you're coming from of it's either a release, or it isn't - so what's the real point of including a version in non-releases, they're experimental, unofficial builds, stuff *could* break (though I'm assuming a total breakage is unlikely given all the testing). But based on these comments, users really want to know if they're looking at a patched release vs new, upcoming stuff.

I dunno, just some thoughts, things to think about. I hope it's useful.

I don't think you can label new commits as 1.4.0+hash when a decision to release 1.4.0 vs 1.3.5 hasn't necessarily been made yet. After 1.4.0 comes out, should future commits be labelled as 1.4.1+hash or 1.5.0+hash? The developers probably won't know until much later in the development process.

I don't think the hash method is particularly useful, because it doesn't really tell the user anything. The main benefit of the extra numbers is so you can tell whether revision A is newer than revision B, but since git hashes are meaningless to a human, you don't get that benefit unless you check the repo to see when that particular revision was released. It seems to me that ktf's idea to use the release date makes more sense, since it allows anyone to compare two revisions to easily see which one is newer without consulting git first.

The point is to keep, to preserve the code base version number.
Whatever you put after it, git, hash, date, else or all, is all good to me as long as I can know in one second which code base version is corresponding to a given evolution.

I agree that using the current version number + some other value to indicate that this build has changes is a common and reasonable approach to use between major release versions; however, since the person who's actually doing the development disagrees, neither you nor I really has any say in the matter.

I don't think you can label new commits as 1.4.0+hash when a decision to release 1.4.0 vs 1.3.5 hasn't necessarily been made yet. After 1.4.0 comes out, should future commits be labelled as 1.4.1+hash or 1.5.0+hash? The developers probably won't know until much later in the development process.

So I can't speak for FLAC but in most projects, the version number is usually indicative of what kind of changes are in that version. Like in my projects, I don't pick and choose numbers.

As an example, say I just released version 2.0.0 of something.

When I introduce code that just fixes a bug, but no feature changes - then the next version, whenever it releases, would be 2.0.1.

The second I introduce a commit that makes an API change or introduces new features - then the next version with that code has to be 2.1.0.

With this method, I don't really decide the next version number - the kind of change introduced dictates what the next number will be.

Ergo - the FLAC repo has new API features, I would be very surprised if they put those new API changes out as 1.3.5 and not 1.4.0.

Once 1.4.0 comes out - new builds would be labeled 1.4.1+hash as long as the changes are strictly bug fixes. Once you introduce a new feature, or an API change, etc, that's when you label 1.5.0+hash.

Ergo - the FLAC repo has new API features, I would be very surprised if they put those new API changes out as 1.3.5 and not 1.4.0.

That has been discussed (in this thread I think), but: the discussion that some appearently have strong opinions about, is rather how to label builds from git - builds that are not "versions".

Quote from: jprjr on 2022-08-11 13:34:27

Ergo - the FLAC repo has new API features, I would be very surprised if they put those new API changes out as 1.3.5 and not 1.4.0.

That has been discussed (in this thread I think), but: the discussion that some appearently have strong opinions about, is rather how to label builds from git - builds that are not "versions".

Correct - and my thought process here is, assuming you're following that versioning convention you wouldn't label builds from git as "1.3.4+hash" but rather "1.3.x+hash".

(in all this wherever I say "hash" I really mean hash and/or date, and if I say "API changes" I really mean an API change, or a new feature - any kind of "not bugfix" change).

I think part of the concern is users were asking to be labeled "1.3.4+hash" which, as a dev-type person myself - doesn't really make sense. 1.3.4 is 1.3.4, saying "1.3.4+(stuff)" is confusing and possibly misleading.

There's sort of a two-pronged approach here. The first issue is, once any API changes are introduced (which has happened), the version should be updated - none of these builds should contain "1.3.(anything)", the repo shouldn't contain the string 1.3.4 anymore, etc. Whatever pull request introduces an API change - should also change the version number.

Then once you adopt that policy - label the git builds as "1.3.x+hash", "1.4.x+hash" and so on.

The ".x" communicates this is not a tagged release while still addressing the user's concern of knowing which kind-of "family" that particular build is from. Like I mentioned earlier - it would be pretty obvious that a sudden, new "1.4.x+hash" build string means you're dealing with a more experimental build - and maybe you'd switch to an older build that you know is 1.3-compatible until a formal 1.4.0 release is complete. Or - maybe you see the 1.4.x and decide to test it and see if you discover bugs and report them back - whatever.

Point is - 1.3.x+hash, 1.4.x+hash addresses what the users want to know, while not including a tagged release number in a non-release build.

When https://github.com/xiph/flac/pull/407 is merged

Came to think of the limit of 31 functions (says "up to 32", but that apparently means "up to and including 31").
It is unclear how many functions a subdivide "(8)" will be counted as towards that bound.

Whether it is reasonable to use that high number and that many functions?
* Compare time and result against -8p and -8e and -8pe.
* The limitation to <32 is from a time of slower CPUs (and even slower encoding algorithm, I think? And in any case, more use of -p or -e due to not as good estimation)

And IF someone in the FLAC policy department says no, you cannot have as many as the "(8)", then:
* Consider whether subdivide_tukey(n) only shall mean to compute n and its divisors; that is, subdivide_tukey(8) splits into 8, recycles to form combinations of the 8 (that includes 1, 2 and 4 and would make for 15, am I right? The 8ths don't mean it computes all 2^8-1 combinations?). Downside is of course the absence of a function that is already in today's "--best" ... and to explain to the users why 5 makes for less functions than 4 and that the reasonable "higher than --best" ones are likely to be 6 (or maybe 8 but not 5 or 7) and then 12.
* Then documentation needs to be updated too, to explain why.

(Uh oh, and ... an (undocumented?) shortform --st=n would not be the worst when lazy HA testers don't write .bat files) 

Came to think of the limit of 31 functions (says "up to 32", but that apparently means "up to and including 31").
It is unclear how many functions a subdivide "(8 )" will be counted as towards that bound.

It will count as 1. Because of the data reuse, it is no longer split up into several apodization functions like with partial_tukey and punchout tukey. So there's no problem in specifying something as absurd as subdivide_tukey(250)

Challenge accepted. Awaiting the

c:\bin\timer64.exe flac -8f -A subdivide_tukey(250) Napalm_Death__1987__Scum__12__You_suffer.flac (https://en.wikipedia.org/wiki/You_Suffer)

FLAC git-c90b3ea3 20220820
Built on August 21, 2022, GCC 12.1.0

https://github.com/xiph/flac/commits/master

Challenge accepted. Awaiting the

c:\bin\timer64.exe flac -8f -A subdivide_tukey(250) Napalm_Death__1987__Scum__12__You_suffer.flac (https://en.wikipedia.org/wiki/You_Suffer)

*cough* The "CD version" is actually much longer. Which makes for a difference, when the above "250" encodes at 1/7th of realtime speed (-p to get it down to 1/34th)

With @NetRanger's freshly posted build.

Anyway, since @ktf doesn't consider that build to be an "1.3.4", it is far into the next version - and it implements some of the improvements drafted in the https://hydrogenaud.io/index.php/topic,120158.0.html thread, I'll post test results there.

FLAC v1.3.4-0bf7282 git compiles now at Rarewares. :)

FLAC v1.3.4-0bf7282 git compiles now at Rarewares. :)

I see you found the problem with the WinXP toolset in MSVC :( I didn't cross my mind this would also affect your compiles.

Did you stumble on anything else? If you have any additions for the CMake configuration specific for the Intel Compiler, let me know.

Some findings about -r. While -8 -r 8 doesn't help much on normal music (if at all) compared to -8, on noise-like material it can significantly improve compression, while it doesn't hurt speed much. Build from this post was used - https://hydrogenaud.io/index.php/topic,122179.msg1014061.html#msg1014061
Merzbow - Venereology
-8 - 505 926 247 bytes / 1341 kbps avg
-8 -r 8 - 478 585 859 bytes / 1269 kbps avg

Less extreme example - https://aylwin.bandcamp.com/album/farallon. Unlike Merzbow, this is music, just insanely compressed/distorted/clipped.
-8 - 405 730 765 bytes / 1229 kbps avg
-8 -r 8 - 394 267 319 bytes / 1195 kbps avg

Quote from: john33 on 2022-08-25 18:41:11

FLAC v1.3.4-0bf7282 git compiles now at Rarewares. :)

I see you found the problem with the WinXP toolset in MSVC :( I didn't cross my mind this would also affect your compiles.

Did you stumble on anything else? If you have any additions for the CMake configuration specific for the Intel Compiler, let me know.

To be honest, not having an XP system, real or VM, I really don't know, but I erred on the side of caution. ;)

I haven't found any other issues but, call me old-fashioned, I continue to use MSVS project files that I maintain and will amend as required. While I can see a benefit in the 'global' sense to using Cmake, it offers me no benefit when I can work with the MSVS project files 'in my sleep'. ;)

Thanks for keeping compatibility in mind. Keeping up with projects that constantly update their compilers and required runtime libraries can be tedious and frustrating, especially if you're using an older OS. :)

To be honest, not having an XP system, real or VM, I really don't know, but I erred on the side of caution. ;)

For anyone wondering: the only thing that could be noticed in day-to-day use is that the progress bar didn't display the compression ratio properly. However, some more advanced uses (with --skip and --until for example) didn't work because of this bug. Programs that used libFLAC directly found all sorts of weird behaviour. This went unnoticed for quite some time, but the way @john33 build now should evade all such problems.

The builds with MinGW (from @NetRanger) do not have these problems, as they do not use the platform toolset with the bug.

Less extreme example - https://aylwin.bandcamp.com/album/farallon. Unlike Merzbow, this is music, just insanely compressed/distorted/clipped.
-8 - 405 730 765 bytes / 1229 kbps avg
-8 -r 8 - 394 267 319 bytes / 1195 kbps avg

What the actual f**c?  This is the weirdest compression result that doesn't come from chiptune. (And people: the album is for free, so go ahead play with it!)
Look at these bitrates:

1230 for FLAC -5  <--- FLAC results measured with 1.3.1, as the new build doesn't make for much
1230 for TTA
1229 for CUETools.FLACCL (2.2.2) at -11 --lax
1229 for Monkey's "High"
1227 for TAK -p4m
1227 for FLAC -8pe
1227 for MPEG-4 ALS at default and at the only slightly smaller and utterly slow -7 -p
1226 for Monkey's "Insane"
1226 for ALAC by ffmpeg
1225 for ALAC by refalac
1213 for WavPack -hhx
1207 for WavPack -hx
1206 for WavPack -hx4 (397 757 506 is smaller than -hx6 at 397 833 058 is smaller than -hhx4 at 397 863 164 is smaller than -hhx6  at 397 957 370).
1195 for FLAC -r 8 (= -5 -r 8)
1187 for CUETools.Flake (2.2.2) at -11 --lax
1154 for OptimFROG --preset 5
1150 for OptimFROG --preset 8
1142 for OptimFROG --preset 10
1139 for OptimFROG default (= --preset 2!!)
1131 for FLAC -r 9 --lax
1090-ish for SAC at default. A codec that isn't usable for playback.
1073 for FLAC -r 10 --lax (only the Stellar Descent tracks benefit, the first track is to the byte same size)
1058 for FLAC -r 11 --lax (ditto) - and same byte count for -r 12. 1071 for -r 12,12 enforcing the "12" as minimum.
1058 for FLAC -8 -r 11 --lax -  and same byte count going to -r 12
1052 for FLAC -8pe -r12 --lax, didn't try 11. New FLAC build improves 12 kilobytes.

Stepping up "r" means the block is partitioned further, but interestingly: "partitioning" the block by -b 2048 does only harm (... as usual; as does -b 8192; FLAC seems well tuned for the default 4096 on CDDA.)

Now if you didn't think this was weird enough:
The results are even more extreme for the Stellar Descent tracks (2 and 3):
flac -8pe -r 12 improves 17.8 resp. 21 percent over -8pe
... and > 10 percent over OptimFROG and 7 percent over sac.


What kind of distortion are they applying?!



As for Venereology, the live track 3 "I Lead You Towards Glorious Times" is the least compressible piece of music I ever bought, so I've used it in a few tests:
https://hydrogenaud.io/index.php/topic,120158.msg1001917.html#msg1001917 and the next reply #51 (therein I also did something about -r)
https://hydrogenaud.io/index.php/topic,122040.msg1010086.html#msg1010086

What I want to know is what word is this supposed to be. :P

f**c

Hint: it is not "ALAC". And it is certainly nothing as offensive as something pronounced anywhere close to doubleyou-emm-ey-ell.


And I had my jaw dropped so much that ...

(And people: the album is for free, so go ahead play with it!)

... I forgot parentheses around "with".

What I want to know is what word is this supposed to be. :P

Quote from: Porcus on 2022-08-27 11:22:10

f**c

FLAC
Obviously :D

What kind of distortion are they applying?!

Looking at the waveform, it seems a large part of the track is almost a square wave. So, it isn't far from chiptune.

1131 for FLAC -r 9 --lax
1090-ish for SAC at default. A codec that isn't usable for playback.
1073 for FLAC -r 10 --lax (only the Stellar Descent tracks benefit, the first track is to the byte same size)
1058 for FLAC -r 11 --lax (ditto) - and same byte count for -r 12. 1071 for -r 12,12 enforcing the "12" as minimum.
1058 for FLAC -8 -r 11 --lax -  and same byte count going to -r 12
1052 for FLAC -8pe -r12 --lax, didn't try 11. New FLAC build improves 12 kilobytes.

Interesting. The r value goes up exponentially. So -r12 means: split the block up into 2^12 partitions, which is 4096 partitions. That is equal to the blocksize, and doesn't really make sense. Furthermore, FLAC limits r internally, as specified by the format. The number of samples in the first partition has the predictor order subtracted, and the number of samples in a partition cannot be zero. Therefore, -r12 can only lead to 4096 partitions when a fixed predictor with order 0 is used, which isn't very useful here. When a predictor order of 1 is used, -r12 is internally limited to -r11, and when a predictor order of 2 is used this is further limited to -r10, with a predictor order of 4 to -r9 and so forth.

It seems reasonable to assume -r12 won't differ from -r11.

However, the fact that -r11 is smaller than -r10 is really stunning indeed. It means that for each 2 samples, one rice parameter is stored, which is a 4-bit overhead AND it means the predictor order is no larger than 1. It is very rare this pays of, but it does here.

So, why does FLAC outperform very advanced codecs like SAC here? Because these high partition orders make FLAC able to 'switch' extremely quickly if the signal does so too. If you look at the signal, it is almost a square wave: you have some samples (about 10) with exactly the same value, then a upwards slope for a few samples, than some more samples with exactly the same value, then a downward slope. With an extremely high partition order, FLAC can spend few bits on the samples with the exact same value and spend more bits on the slopes. If you use -r6 like the presets do, all these samples need to use the same number of bits (more exact: the same rice parameter) to be described.

It seems this is something only FLAC does, apparently, if it beats all other codecs. It is however specific to certain kinds of music, it seems.

However, the fact that -r11 is smaller than -r10 is really stunning indeed.

The fact that -r 12,12 gives smaller files than -r 10 is even more jaw-dropping then?
(... on both tracks 2 and 3 and the average, but not on track 1)
Same thing happens on -b16384 -r 14,14 which improves over -b16384 -r12.

I didn't keep good enough track of what I tested -b 8192 on ... yes -r 12 improves on -b 8192 and so that makes sense.
Encoding the first file with --lax  -r 11 and the two Stellar Descent tracks with --lax -b 32768 -r 14, and we are down to 1057 even without -8ep.  Putting -8ep there doesn't improve enough to get it past 1057.

ffmpeg doesn't make magic here (I mean it still beats TAK -p4m so don't complain, but nothing near the flac -r 11 sizes). More figures:
1226 ffmpeg default and ffmpeg -compression_level 12
1206-ish for La -high
1204 ffmpeg -compression_level 12 -lpc_type cholesky -lpc_passes 9
 lowest git flac build without directly accessing -A
1080-ish for SAC with --sparse-pcm, ran overnight. It - and OptimFROG - outcompresses FLAC by 3 to 4 percent on the first track, so again it is 2 and 3 that are the big WTFs

FLAC git-5d1402ea 20220831
Built on August 31, 2022, GCC 12.2.0

FLAC git-5d1402ea 20220831
Built on August 31, 2022, GCC 12.2.0

For anyone interested, this can be considered a release candidate. I don't plan to change anything else except documentation, changelog etc. for the next release, except when new bugs are found.

FLAC-1.4.0.RC1-git5d1402e compiles at Rarewares.

For anyone interested, this can be considered a release candidate. I don't plan to change anything else except documentation, changelog etc. for the next release, except when new bugs are found.

Decision already made I guess, but I think the following deserves a second thought - admittedly, without giving a shot at my illiteracy at reading code:

* Consider whether subdivide_tukey(n) only shall mean to compute n and its divisors; that is, subdivide_tukey(8) splits into 8, recycles to form combinations of the 8 (that includes 1, 2 and 4 and would make for 15, am I right? The 8ths don't mean it computes all 2^8-1 combinations?)

(An alternative to 1,...,n and to "n and its divisors" could be the least common denominator of (1/1,...,1/n). 1, 2, 6, 12, 60 and then who cares that the next is 60 too.)

Reason for considering this:
My hunch is that the "3" would have to calculate "all three thirds" and "both halves" (five in total) before it starts re-using calculations - and those five aren't much less than calculating all six sixths and combining them for thirds and halves?

(On the other hand: if tapering is different on the "three thirds" routine than on the "two halves" routine - possibly too different from the "single" routine - what then? Is it? If so, it would mean that you fire three differently tapered "single tukey" windows at the block, and it is up to testing to tell whether that is bad use of time.)

Reason for considering this:
My hunch is that the "3" would have to calculate "all three thirds" and "both halves" (five in total) before it starts re-using calculations - and those five aren't much less than calculating all six sixths and combining them for thirds and halves?

No, that is not how it reuses calculations.

First is calculates a tukey window for the whole block, by default tukey(0.25) when using subdivide_tukey(2) and tukey(0.166) when using subdivide_tukey(3). Then, it calculates a tukey window for the first and second half of the block. No reuse here yet, but even this calculation is implemented faster then it was before. Then, (when using subdivide_tukey(3) or higher) it calculated a tukey window for 3 thirds of the block, and then subtracts each of these from the original tukey to get the 'punchout' variants. For subdivide_tukey(4) this is repeated. Practically, the punchout variants are now 'free' in a sense that they don't need to calculate autocorrelation by going over the samples but by simply subtracting previous calculations.

It is not possible to combine sixths to get halves and thirds because there is some overlap.

Practically, the punchout variants are now 'free' in a sense that they don't need to calculate autocorrelation by going over the samples but by simply subtracting previous calculations.

It is not possible to combine sixths to get halves and thirds because there is some overlap.

Dumb question but: if you tried to combine, it would not be the same - well then, wouldn't that mean you get more slightly different windowing functions pretty much for "free"? Say:
Does that "overlap" mean that adding up the two halves of the "partial_tukey(2)", would get you a different "whole block but tapered" windowing function than the tukey(.25) and the tukey(.5) already calculated - and it would be essentially "free" but isn't done? And if you simulated the first part of a "punchout_tukey(2)" by taking the the tukey(.25) and subtracting the second half - that would be different than taking the first half, and it would be essentially "free" but isn't done?

Dumb question but: if you tried to combine, it would not be the same - well then, wouldn't that mean you get more slightly different windowing functions pretty much for "free"?

I probably shouldn't have used the phrase "for free". Yes, flac doesn't have to calculate the autocorrelation but it still needs to calculate the residual and find the smallest possible rice partitioning, so it makes no sense to just try all possible combinations.

FLAC-1.4.0.RC1-git5d1402e compiles at Rarewares.

I used that to reencode a file I encoded with an 1.3.4 version from the last weeks (don't know which one, but the size of the flac.exe is 1.052.160 bytes), and the resulting file is *way* bigger (6.88MB vs. 7.2MB). I did it through the fb2k menu, so maybe there was a change where parameters get silently dropped somewhere? I used level 8.

Stupid question, but: sure it is level 8? Asking because many users have been playing around with different fb2k versions lately, major beta coming out.

I think Foobar 1.6.12 is using this for the max compression setting slider, flac.exe" -s --ignore-chunk-sizes -8p - -o ""

Out of boredom I'm doing a large compression comparison (15679 Tracks mainly Rock, Metal) of FLAC-1.4.0.RC1 and FLAC-1.3.1 using the above comandline. I'll post my results tomorrow to see the space savings.

Stupid question, but: sure it is level 8? Asking because many users have been playing around with different fb2k versions lately, major beta coming out.

I used the 1.6.12, not the new v2. I'm sure the GUI says 8, but it definitely gets dropped somewhere, since on the console, I get similar file sizes. But I noticed that a file with ratio below 1 is still bigger than when encoded with the earlier FLAC version. Was there some change in the file layout?

Did you set foobar2000 to transfer tags and album art?

You cannot expect every file to improve with the new build.
* It uses some double precision calculations where 1.3.4 uses single precision. That has been shown to improve quite a lot on certain signals. But if single precision was already good enough for the signal in question, you won't gain much.
* Also, it is not exact science: FLAC is not bad at guessing what makes for good compression, but every now and then it happens that a roundoff happens to be in a beneficial direction, so the rougher "single precision" might be coarser and make a difference - but by chance, it just happens to hit better.
* The windowing functions are now slightly different. More are tested, so should not be worse, but they are changed a little bit (to make for recycling of calculations and thus speeding up), and again: small changes may just by chance happen to be for the better.

When you test many files, those strange things will show up every now and then. Nothing weird.

Did you set foobar2000 to transfer tags and album art?

Yes, but it's not relevant, since I didn't change anything besides the flac.exe. So this is probably a bug in fb2k, or less likely some change in the FLAC interface.

Can you try again with the release here (https://ftp.osuosl.org/pub/xiph/releases/flac/) or here (https://github.com/xiph/flac/releases/tag/1.4.0)? You would need flac-1.4.0-win.zip

Can you try again with the release here (https://ftp.osuosl.org/pub/xiph/releases/flac/) or here (https://github.com/xiph/flac/releases/tag/1.4.0)? You would need flac-1.4.0-win.zip

Tried the first one, had to add the DLL, but the file was now ~10kb smaller. So now I'm not sure where the problem lies.

Here are the results of my testing.

Command line used; flac.exe" -s --ignore-chunk-sizes -8p - -o "xxxx"

1.3.4 (from Foobar2000 Encoder pack)

Duration : 5wk 6d 0:45:59.793
Sample rate : 44100 Hz (97.3%); 48000 Hz (2.7%)
Channels : 2
Bits per sample : 16 (96.8%); 24 (3.2%)
Avg. bitrate : 954 kbps
Codec : FLAC
Encoding : lossless
Tool : reference libFLAC 1.3.4 20220220
Embedded cuesheet : no

FLAC-1.4.0.RC1 (from Rarewares)

Duration : 5wk 6d 0:45:59.793
Sample rate : 44100 Hz (97.3%); 48000 Hz (2.7%)
Channels : 2
Bits per sample : 16 (96.8%); 24 (3.2%)
Avg. bitrate : 953 kbps
Codec : FLAC
Encoding : lossless
Tool : reference libFLAC 1.3.4 20220220
Embedded cuesheet : no

I'm running one more pass using NetRangers FLAC-1.4.0_Win_GCC122 compile which should be done in about 6 hours.

954 vs 953 - you might need file sizes to tell how small the difference is.

flac.exe" -s --ignore-chunk-sizes -8p - -o "xxxx"

FLAC 1.3.4

Total size : 393 GB (422 709 930 380 bytes)
Duration : 5wk 6d 0:45:59.793
Sample rate : 44100 Hz (97.3%); 48000 Hz (2.7%)
Channels : 2
Bits per sample : 16 (96.8%); 24 (3.2%)
Avg. bitrate : 954 kbps
Codec : FLAC
Encoding : lossless
Tool : reference libFLAC 1.3.4 20220220
Embedded cuesheet : no

FLAC 1.4.0

Total size : 393 GB (422 292 414 045 bytes)
Duration : 5wk 6d 0:45:59.793
Sample rate : 44100 Hz (97.3%); 48000 Hz (2.7%)
Channels : 2
Bits per sample : 16 (96.8%); 24 (3.2%)
Avg. bitrate : 953 kbps
Codec : FLAC
Encoding : lossless
Tool : reference libFLAC 1.4.0 20220909
Embedded cuesheet : no

1.3.4 = 403127.60 MB
1.4.0 = 402729.43 MB

Savings of 398.17 MB

It seems pretty clear that the new version is slightly better, but that foobar2000's interface won't result in the same command going through. I guess only Peter can check what's going on.

So the "954 minus 953" approximation happens to be nearly exact. (Just scaling 954 with the file size ratio yields 953.06.)

0.1 percent / .07 percentage points; that might be in the same ballpark as the s(h)avings gained from going -7 to -8 or -8 to -8p? 

foobar's parameter can be viewed by setting the GUI of an encoder, then immediately choose "Custom" in the drop down list. For example, setting the FLAC GUI to 8, then choose "Custom", it shows:
-s --ignore-chunk-sizes -8 - -o %d
-8p and is much slower than -8 so should be pretty easy to notice.

foobar's behavior can be further identified by setting up a more complex encoder like WavPack. For example, setting the GUI like this:


Then immediately choose "Custom", the parameter shows:
-i -q -h -x1 -b253 - %d

Comparing FLAC encoding time with console vs with fb2k is not easy. fb2k will use multi-core, but will transfer tags in the end, leading to full file rewrite which is fast on an internal SSD and slow on a NAS.

I meant comparing -p and without -p within foobar, in reply to post 175 (https://hydrogenaud.io/index.php/topic,122179.msg1015269.html#msg1015269). I don't think foobar uses -p.
[edit] Another way to view the used parameter is to actually convert a file, then open View > Console, this shows the used parameter.

Yup you're right, the Foobar2000 default FLAC max setting is "-s --ignore-chunk-sizes -8 - -o %d" minus the -p.

I must have customised my initial preset to include -8p.