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 51164 times) previous topic - next topic - Topic derived from FLAC v1.3.3
0 Members and 2 Guests are viewing this topic.

Re: FLAC v1.3.4

Reply #25 –
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".

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

Re: FLAC v1.3.4

Reply #26 –
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.

Re: FLAC v1.3.4

Reply #27 –
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.

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

Reply #29 –
Quote from: MrRom92 on
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.
Allegari nihil et allegatum non probare, paria sunt.

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

Reply #35 –
I think it has been abandoned! It probably needs to be taken down.

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

Reply #37 –
Quote from: MJmusicguy on
Great so i literally just ripped a cd today was unaware of this release do i need to re rip now?

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

Reply #42 –
@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.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #43 –
Personally, usually from a git clone.

Re: FLAC v1.3.4

Reply #44 –
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.

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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