Skip to main content ↑ ↓

Notice

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

Re: FLAC v1.3.4

Reply #75 –
Quote from: Porcus on
Quote from: Brazil2 on
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"

Re: FLAC v1.3.4

Reply #76 –
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?

Re: FLAC v1.3.4

Reply #77 –
Quote from: doccolinni on
Quote from: ktf on
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.

Quote from: Brazil2 on
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.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #78 –
Quote from: ktf on
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.

Re: FLAC v1.3.4

Reply #79 –
Quote from: Brazil2 on
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.

Re: FLAC v1.3.4

Reply #80 –
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

Re: FLAC v1.3.4

Reply #81 –
Thanks very much. 
I'm still in love with FLAC. 
Gotta love FLAC. 

Re: FLAC v1.3.4

Reply #83 –
Thank you very much for the update.

Re: FLAC v1.3.4

Reply #85 –
Quote from: NetRanger on
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.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #86 –
Quote from: ktf on
Quote from: NetRanger on
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 :)
 

Re: FLAC v1.3.4

Reply #89 –
FLAC 1.3.4 git-3528fa2, including dlls, now at Rarewares. :)

Re: FLAC v1.3.4

Reply #91 –
Quote from: NetRanger on
FLAC git-9b38260 20220612
The filename says 73cb63a, the post says 9b38260. 73cb63a is newer, it includes 32-bit PCM encoding and decoding
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #92 –
Quote from: ktf on
Quote from: NetRanger on
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…

Re: FLAC v1.3.4

Reply #93 –
Quote from: MrRom92 on
Quote from: ktf on
[...] 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.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #96 –
Quote from: ktf on
Quote from: MrRom92 on
Quote from: ktf on
[...] 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.

Re: FLAC v1.3.4

Reply #97 –
Quote from: MrRom92 on
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.

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.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #98 –
Quote from: ktf on
Here's one such release on 768kHz.

With a free track.
And it has been through digital to analog to digital. 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 )

Quote from: MrRom92 on
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).

Re: FLAC v1.3.4

Reply #99 –
Quote from: MrRom92 on
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.