HydrogenAudio

Lossless Audio Compression => FLAC => Topic started by: o-l-a-v on 2022-02-21 07:29:03

Title: FLAC v1.3.4
Post by: o-l-a-v on 2022-02-21 07:29:03
v1.3.4 released, with Windows binaries even.

Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-21 09:46:54
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.

Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-21 09:55:46
I've sent in a news item with some details: https://hydrogenaud.io/index.php?topic=122177.0
Title: Re: FLAC v1.3.4
Post by: kode54 on 2022-02-21 11:11:05
Moved to validated news.
Title: Re: FLAC v1.3.4
Post by: Case on 2022-02-21 11:49:57
The official win32 binary reports its version as 1.3.3. Same version is embedded in the encoded files.
Title: Re: FLAC v1.3.4
Post by: john33 on 2022-02-21 11:53:04
Win32 and x64 compiles on Rarewares. They show 1.3.4. :)
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-21 12:58:15
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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-21 13:38:48
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.
Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-02-21 17:56:04
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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-22 07:31:19
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-22 10:39:48
Windows 10 assholery:

Code: [Select]
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"
Title: Re: FLAC v1.3.4
Post by: birdie on 2022-02-22 10:57:57
A bugfix release, please disperse.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-02-22 12:29:54
FLAC v1.3.4 (Release)
Built on February 22, 2022, GCC 11.2.0

https://gitlab.xiph.org/xiph/flac/-/releases#1.3.4
Title: Re: FLAC v1.3.4
Post by: Jurgga on 2022-02-22 22:35:25
EZ CD Audio Converter updated with FLAC 1.3.4

https://www.poikosoft.com
Title: Re: FLAC v1.3.4
Post by: Wombat on 2022-02-23 02:21:28
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 :)
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-23 08:35:51
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:
Quote
Fix 12 decoder bugs found by oss-fuzz, including CVE-2020-0499
Fix encoder bug CVE-2021-0561
Title: Re: FLAC v1.3.4
Post by: Makaki on 2022-02-23 20:49:07
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.
Title: Re: FLAC v1.3.4
Post by: Dave.L on 2022-02-24 07:34:27
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-24 08:04:25
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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-24 08:04:59
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:

Quote
FLAC 1.3.3 (4-Augs-2019)

 [...]
    flac:
        When converting to WAV, use WAVEFORMATEXTENSIBLE when bits per second is not 8 or 16 (erikd).
Title: Re: FLAC v1.3.4
Post by: john33 on 2022-02-24 08:54:18
It's only the header that's different, the PCM data is identical.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-24 09:00:08
Gosh, I didn't realize 1.3.2 is that old.

Quote
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?)
Title: Re: FLAC v1.3.4
Post by: Dave.L on 2022-02-24 12:26:21
Thanks all for quick response.
And many thanks for new release for Windows.
Title: Re: FLAC v1.3.4
Post by: MrRom92 on 2022-02-24 12:51:46
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?
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-24 13:27:18
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-24 13:47:50
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.
Title: Re: FLAC v1.3.4
Post by: MrRom92 on 2022-02-24 16:40:50
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.
Title: Re: FLAC v1.3.4
Post by: 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 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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-25 18:09:31
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
Title: Re: FLAC v1.3.4
Post by: ssjkakaroto on 2022-02-25 19:49:56
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/
Quote
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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-02-25 20:55:46
No, it doesn't: https://xiph.org/flac/faq.html#api__release_versioning

Quote
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.
Title: Re: FLAC v1.3.4
Post by: Replica9000 on 2022-02-25 22:12:45
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.

Code: [Select]
LD_LIBRARY_PATH=../flac/src/libFLAC/.libs
Title: Re: FLAC v1.3.4
Post by: bennetng on 2022-02-26 14:16:45
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
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-02-26 14:45:40
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
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-02-26 16:16:43
Is https://sourceforge.net/projects/flac/files/flac-win/ still supposed to be maintained?
Title: Re: FLAC v1.3.4
Post by: john33 on 2022-02-26 17:46:32
I think it has been abandoned! It probably needs to be taken down.
Title: Re: FLAC v1.3.4
Post by: MJmusicguy on 2022-03-02 01:00:31
Great so i literally just ripped a cd today was unaware of this release do i need to re rip now?
Title: Re: FLAC v1.3.4
Post by: Makaki on 2022-03-02 02:29:07
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-03-02 08:43:00
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.
Title: Re: FLAC v1.3.4
Post by: MrRom92 on 2022-03-02 12:22:04
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
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-03-02 12:47:51
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
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-09 21:49:15
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
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-11 16:06:46
@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.
Title: Re: FLAC v1.3.4
Post by: john33 on 2022-04-11 16:18:47
Personally, usually from a git clone.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-11 17:48:02
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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-11 18:34:50
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?

Code: [Select]
$ flac --version
flac git-c162eb9e

Code: [Select]
$ flac
===============================================================================
flac - Command-line FLAC encoder/decoder version git-c162eb9e

Code: [Select]
vendor string: reference libFLAC git-c162eb9e 20220411

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. For troubleshooting bugs, the git commit is way more important than the compiler used.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-11 19:23:03
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
Title: Re: FLAC v1.3.4
Post by: eddie.zato on 2022-04-12 04:28:03
flac git-c162eb9e
Can we keep the tag?

Code: [Select]
flac 1.3.4 git-c162eb9e
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-12 14:54:12
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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-12 14:54:41
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-12 16:24:30
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.
Title: Re: FLAC v1.3.4
Post by: eddie.zato on 2022-04-12 16:34:05
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
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-12 17:14:54
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
Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-04-12 17:22:49
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-12 17:45:57
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.  :)
Title: Re: FLAC v1.3.4
Post by: Ziengaze on 2022-04-13 08:17:01
How about just copying opus-tools' approach? Something like this would include all information necessary without too much clutter.
Code: [Select]
libFLAC 1.3.4-g179cdce 20220413
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-19 18:38:33
@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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-19 20:28:31
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-19 21:23:15
@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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-04-19 21:43:50
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?
Title: Re: FLAC v1.3.4
Post by: Aleron Ives on 2022-04-20 06:21:41
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.
Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-04-20 09:34:56
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-20 15:35:07
FLAC v1.3.4-git-1ca7b38 (2002-04-20)
Built on April 20, 2022, GCC 11.2.0
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-21 09:47:56
FLAC git-f579b163 20220420
Built on April 21, 2022, GCC 11.2.0

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


Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-04-22 13:09:53
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
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-22 18:56:56
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.
Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-04-22 20:55:12
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-22 22:13:40
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
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-24 09:06:01
Quote from: doccolinni
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.
Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-04-24 22:26:18
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
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.
Title: Re: FLAC v1.3.4
Post by: VEG on 2022-04-26 07:36:20
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).
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-26 10:31:52
FLAC git-c157be0 20220425
Built on April 26, 2022, GCC 11.2.0
Title: Re: FLAC v1.3.4
Post by: Brazil2 on 2022-04-26 12:33:32
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:
Code: [Select]
E:\Temp>flac -version
flac git-c157be0f 20220425
Code: [Select]
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.
Title: Re: FLAC v1.3.4
Post by: doccolinni on 2022-04-26 12:35:00
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-04-26 12:51:24
Code: [Select]
Writing library                          : libFLAC 20220425 (UTC 2022-04-25)
Where from? I find a "reference libFLAC git-c157be0f 20220425" in the file.
Title: Re: FLAC v1.3.4
Post by: Brazil2 on 2022-04-26 13:46:33
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"
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-04-26 14:06:07
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?
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-04-26 15:48:38
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.
Title: Re: FLAC v1.3.4
Post by: Brazil2 on 2022-04-26 17:01:58
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-04-26 18:57:23
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-04-26 21:17:08
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

Title: Re: FLAC v1.3.4
Post by: tapenade on 2022-04-28 04:10:45
Thanks very much. 
I'm still in love with FLAC. 
Gotta love FLAC. 
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-05-01 18:26:09
FLAC git-3fc5ba4 20220501
Built on May 01, 2022, GCC 11.2.0
(Code Base : 1.3.4)
Title: Re: FLAC v1.3.4
Post by: Verónica Thorn on 2022-05-02 21:50:02
Thank you very much for the update.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-05-11 11:30:56
FLAC git-1bec35e3 20220511
Built on May 11, 2022, GCC 11.3.0
(Code Base : 1.3.4)
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-05-11 18:41:31
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-05-11 22:14:09
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 :)
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-05-22 15:39:44
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
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-06-11 15:15:21
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
Title: Re: FLAC v1.3.4
Post by: john33 on 2022-06-11 16:51:30
FLAC 1.3.4 git-3528fa2, including dlls, now at Rarewares. :)
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-06-13 14:44:24
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
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-06-13 16:01:52
FLAC git-9b38260 20220612
The filename says 73cb63a, the post says 9b38260. 73cb63a is newer, it includes 32-bit PCM encoding and decoding
Title: Re: FLAC v1.3.4
Post by: MrRom92 on 2022-06-13 17:36:49
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…
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-06-13 19:04:37
[...] 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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-06-13 20:07:58
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.
Title: Re: FLAC v1.3.4
Post by: NetRanger on 2022-06-13 20:12:54
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
Title: Re: FLAC v1.3.4
Post by: MrRom92 on 2022-06-14 01:30:24
[...] 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.
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-06-14 06:34:05
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-06-14 08:44:52
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).

Title: Re: FLAC v1.3.4
Post by: bennetng on 2022-06-14 09:02:50
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.
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-06-14 09:18:34
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.
Title: Re: FLAC v1.3.4
Post by: bennetng on 2022-06-14 09:43:54
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.

Quote
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.
Title: Re: FLAC v1.3.4
Post by: .halverhahn on 2022-06-14 09:46:22
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)
Title: Re: FLAC v1.3.4
Post by: bennetng on 2022-06-14 09:59:50
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
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-06-14 11:06:00
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.)
Title: Re: FLAC v1.3.4
Post by: ktf on 2022-06-14 13:19:48
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)
Title: Re: FLAC v1.3.4
Post by: MrRom92 on 2022-06-14 15:03:08
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.
Title: Re: FLAC v1.3.4
Post by: bennetng on 2022-06-14 16:37:54
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.
X
Title: Re: FLAC v1.3.4
Post by: john33 on 2022-06-16 12:19:57
FLAC 1.3.4 git-cbb039d, including dlls, now at Rarewares. :)
Title: Re: FLAC v1.3.4
Post by: Porcus on 2022-06-16 13:29:59
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
Code: [Select]
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.)