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-git Releases (Code Base v1.4.x) (Read 47489 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #80 –
I'm planning to release 1.4.3 soon, so if anyone knows of any regressions, please let me know.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #82 –
Yes, I've come to the conclusion the gain isn't worth the hassle.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #83 –
hey, I used the flac-retune binary you shared here and without a doubt it's the fastest flac encoder I have ever used, by a wide margin

what exactly is so different between, say, the level 8 mode on your binary vs the standard one?

Quote from: ktf on
I'm planning to release 1.4.3 soon, so if anyone knows of any regressions, please let me know.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #84 –
There have been a lot of general speed-ups. Preset 8 from these binaries (the retune ones)  is pretty much as fast as flac 1.4.3 preset 7.

Anyway, the problem was, while for my inputs the new preset 8 was much faster and compressed better, there where quite a lot of audio files for which it performed worse. So, the general speed-ups stay, but the potentially better settings (on average, for a balanced pool of music) are left out.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #87 –
Quote from: Porcus on
Any reason to keep the 1152? After all, block size did make some speed impact for -0/-1.
-r also? At least if 4096-all-the-way is on the table (for the sake of speed), then bump up the -r to keep the partition size close to current partition size?

I don't know if my experience holds up in other scenarios, but from https://hydrogenaud.io/index.php/topic,123889.msg1024954.html#msg1024954 , finer partitioning appeared to be more or less "for free" in that build - that's a surprise. And if it is, then -8r7 makes a slight improvement over -8 = -8r6 on more abrasive material.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #88 –
I've changed my mind, I think the potential gains are too low (and too dependent on source material) to change behaviour that has been around for quite a while.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #89 –
@ktf - So u will push the new FLAC release soon then or?

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #90 –
Yes, date is set at 23-06-23, if nothing comes up.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #94 –
Quote from: Porcus on
Quote from: Porcus on
Any reason to keep the 1152? After all, block size did make some speed impact for -0/-1.
-r also? At least if 4096-all-the-way is on the table (for the sake of speed)
I did remember wrong, -b4096 was not at all fast - it was the 3000s that would speed up.
I did the test over again with Sunday's build in #93. -0b<BBBB> was not equally sensitive to block size this time. The penalty on 1152 and 4096 (and 4608) was still there, but much smaller.

Didn't test directly against official build, as we know build matters - just lazily took @ktf 's word that there have been speedups  ;)

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #97 –
Multithreading enhancement added yesterday to official git.
I attached a 64bit generic clang 17.0.1 version since i tried the newest package of clang. Still GCC versions are faster here.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!