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 51320 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 #125 –
Quote from: Aleron Ives on
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'.

Quote
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) and probably by (on average) another 0.3% in the next release (see here). 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.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Code: [Select]
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

Re: FLAC v1.3.4

Reply #131 –
Quote from: ktf on
Please explain what you mean by 'direct'.

CDDA compression was improved by 0.3% in FLAC 1.3.1 (see here) and probably by (on average) another 0.3% in the next release (see here).
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.

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

Re: FLAC v1.3.4

Reply #132 –
Quote from: Aleron Ives on
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.

Quote from: Porcus on
So the recommendations of -fb/-fl/-fc/-fp/-fs/-fr might have to go, finally?  :))
I don't follow?

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

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

Re: FLAC v1.3.4

Reply #133 –
Quote from: ktf on
Quote from: Porcus on
So the recommendations of -fb/-fl/-fc/-fp/-fs/-fr might have to go, finally?  :))
I don't follow?

From output of flac --explain:
Code: [Select]
===============================================================================
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)

Re: FLAC v1.3.4

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


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

Re: FLAC v1.3.4

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

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

Quote from: Brazil2 on
We don't care about what ffmpeg is doing, seriously.
You are the one who came up with ffmpeg in the first place.

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

Re: FLAC v1.3.4

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

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

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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


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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

Reply #145 –
Quote from: Aleron Ives on
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.

Re: FLAC v1.3.4

Reply #146 –
Quote from: jprjr on
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".

Re: FLAC v1.3.4

Reply #147 –
Quote from: Porcus on
Quote from: jprjr on
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.

Re: FLAC v1.3.4

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

Re: FLAC v1.3.4

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