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.4.0 (Release) (Read 30418 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.4.0 (Release)

Reply #1 –
FLAC v.1.4.0 compiles now at Rarewares. :)

Re: FLAC v1.4.0 (Release)

Reply #2 –
I didn't initially get the windows binaries on github to work via foobar2000's converter, and not in EAC either. Both just threw some errors. Only when I ran it from the commandline I got a dialog/popup telling that libFLAC.dll is missing. It's included in the zip, but I didn't think of extracting it since no previous version has needed it.
So for anyone running into mysterious errors, there's your solution to get it working.
I'll have to test the rarewares build too, now that it's out :)

Re: FLAC v1.4.0 (Release)

Reply #3 –
john33, your x64 binaries seem to report themselves as 1.3.4 still, and write "reference libFLAC 1.3.4 20220909" as the encoder.
 

Re: FLAC v1.4.0 (Release)

Reply #5 –
I'll summarize the changes here

- Improved compression. The difference is only small for CD audio, but can be very large (> 10%) for low-passed material like most "high-resolution" downloads that do not contain any material above 20kHz but are sampled at 96kHz or even higher.
- Presets 0, 1 and 2 got a little faster, 3, through 8 got a little slower.
- Many bug fixes of problems found by fuzzing. This is probably not something most users will notice, but it tries to ensure hard-to-find bugs will not creep in like this one.
- Encoding and decoding of 32 bps audio is now possible (integer, not float)
- Samplerates above 655'350Hz are now supported, up to 1'048'575Hz
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.0 (Release)

Reply #6 –
Quote from: Porcus on
I think the point of the "4" in "1.4.0" is that it breaks some interoperability?

I think it's that the flac.exe in the official release requires libFLAC.dll to be present or it won't run; they aren't static compiles like previous releases were.

Re: FLAC v1.4.0 (Release)

Reply #7 –
Quote from: Heliologue on
john33, your x64 binaries seem to report themselves as 1.3.4 still, and write "reference libFLAC 1.3.4 20220909" as the encoder.
I think @john33 forgot to change the version in the Visual Studio files
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.0 (Release)

Reply #8 –
Quote from: Porcus on
I think the point of the "4" in "1.4.0" is that it breaks some interoperability?

That's what I first thought, but it seems to work fine once I put libFLAC.dll in the same dir as flac.exe

Re: FLAC v1.4.0 (Release)

Reply #10 –
FLAC v1.4.0 (Release)
Built on September 09, 2022

GCC v12.2.0 compile attached.

Re: FLAC v1.4.0 (Release)

Reply #11 –
32bit build available on github asks for libgcc_s_dw2-1.dll. I'm on windows 7.

Re: FLAC v1.4.0 (Release)

Reply #12 –
Yes, I see now libFLAC++ also has a unwanted dependency. I'll fix and replace

edit: I've replaced on github, will ask to have the Xiph download replaced

edit2: updated once again, now libFLAC++.dll also doesn't have unwanted dependencies
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.0 (Release)

Reply #13 –
Quote from: ktf on
Quote from: Heliologue on
john33, your x64 binaries seem to report themselves as 1.3.4 still, and write "reference libFLAC 1.3.4 20220909" as the encoder.
I think @john33 forgot to change the version in the Visual Studio files
@ktf is quite correct!! Apologies to all. Corrected in current downloads.

Re: FLAC v1.4.0 (Release)

Reply #14 –
Clang compile from NetRanger is fastest on my machine (Core i3 3245, 32 bit Windows 7)
Compression -8
Rarewares and GCC from NetRanger ~110x
Official github ~120x
Clang from NetRanger ~155x

Re: FLAC v1.4.0 (Release)

Reply #15 –
A v1.3.4 managed to snuck into my CLANG 1.4.0 x64 archive in my previous post.

Correct archive contents here

FLAC v1.4.0 (Release)
Built on September 09, 2022, CLANG 14.0.6

Re: FLAC v1.4.0 (Release)

Reply #16 –
Quote from: john33 on
@ktf is quite correct!! Apologies to all. Corrected in current downloads.

File libFLAC_dynamic.dll inside flac_dll-1.4.0-x64.zip still reports version "reference libFLAC 1.3.4 20220909" when used from third party software like CueTools.

Re: FLAC v1.4.0 (Release)

Reply #17 –
On my i9-10850K

flac 1.3.4 clang NetRanger (https://hydrogenaud.io/index.php/topic,122179.msg1009962.html#msg1009962)
Total encoding time: 7:03.515, 76.59x realtime

flac 1.4.0 clang NetRanger (https://hydrogenaud.io/index.php/topic,122949.msg1015344.html#msg1015344)
Total encoding time: 10:05.329, 53.58x realtime

flac 1.4.0 gcc12.2 NetRanger (https://hydrogenaud.io/index.php/topic,122949.msg1015320.html#msg1015320)
Total encoding time: 5:52.078, 92.13x realtime

I'll stick with the 1.4.0 GCC Version ;-)

Re: FLAC v1.4.0 (Release)

Reply #18 –
Quote from: zfox on
Quote from: john33 on
@ktf is quite correct!! Apologies to all. Corrected in current downloads.

File libFLAC_dynamic.dll inside flac_dll-1.4.0-x64.zip still reports version "reference libFLAC 1.3.4 20220909" when used from third party software like CueTools.
Ooops! Sorry about that; all fixed now. More haste, less speed should be the maxim, I think. ;)

Re: FLAC v1.4.0 (Release)

Reply #19 –
According to the checksums, the 32-bit version is different, not the dll inside flac_dll-1.4.0-x64.zip which produces the wrong version info for me.

Re: FLAC v1.4.0 (Release)

Reply #21 –
@A_Man_Eating_Duck has been doing some testing on CDDA in the 1.3.4 thread. I've earlier posted results in the compression improvement thread, showing sometimes big impact on "high resolution" as ktf mentions above.
So with compression threads elsewhere, maybe one should refrain from posting here too, yet here might be where new users may look ... so a few speed figures.

I am running a test on a freshly selected CDDA corpus on a freshly acquired CPU that passes 10k at https://www.cpubenchmark.net/, I couldn't help myself playing with it. FLAC from CLI doesn't utilize more cores, but still. I started from -4, comparing 1.3.4 and 1.4.0, and the first question is how the (small) compression improvements relate to time taken. In particular:

How does 1.4.0 at preset N compare to 1.3.4 at the next preset N+1? (For N=8: compared to -8p.)

Corpus: 38 albums, FLAC-compressed sizes: 4 GB classical music, 4 GB hard rock / heavy synth, 4 GB neither (=poprockjazzsoulrap). So seconds on the same corpus, on internal SSD, FLAC to FLAC with -f:
270 for 1.3.4 @ -4
290 for 1.4.0 @ -4, beats 1.3.4 @ -5 at size
315 for 1.3.4 @ -5
333 for 1.4.0 @ -5, narrowly loses to 1.3.4 @ -6 by 0.008 percent size difference
400 for 1.3.4 @ -6
409 for 1.4.0 @ -6 cannot beat 1.3.4's -7, but -6 isn't a good preset.
427 for 1.3.4 @ -7
450 for 1.4.0 @ -7 beats 1.3.4's -8 by 0.17 percent. Even beats 1.3.4's -8p by nearly 0.1 percent!
569 for 1.3.4 @ -8
610 for 1.4.0 @ -8 Also beats 1.3.4's -8p, of course.
1501 for 1.3.4 @ -8p
1782 for 1.4.0 @ -8p (This starts to get expensive.)

Quote from: ktf on
- Presets 0, 1 and 2 got a little faster, 3, through 8 got a little slower.
That extra time is well spent, if it compresses faster to smaller size and we've had some years of Moore's law since the last compression change.

Re: FLAC v1.4.0 (Release)

Reply #22 –
Quote from: Porcus on
450 for 1.4.0 @ -7 beats 1.3.4's -8 by 0.17 percent. Even beats 1.3.4's -8p by nearly 0.1 percent!

That's absolutely nuts.

I know there's been some discussion regarding this already, but I forgot - is -8ep even marginally useful any more?

Re: FLAC v1.4.0 (Release)

Reply #23 –
Quote from: doccolinni on
I know there's been some discussion regarding this already, but I forgot - is -8ep even marginally useful any more?
On most music -ep is indeed way too slow, but some gains can be achieved on untypical music (like dark ambient, etc)

Stahlwerk 9 "I Am Become Death", almost same encoding speed:
23.645.595 bytes (ratio=0,294): -8 -A subdivide_tukey(9) -p
23.231.317 bytes (ratio=0,289): -8 -e -p

Btw, i found that welch can be useful in combination with subdivide_tukey.

Re: FLAC v1.4.0 (Release)

Reply #24 –
Quote from: doccolinni on
Quote from: Porcus on
450 for 1.4.0 @ -7 beats 1.3.4's -8 by 0.17 percent. Even beats 1.3.4's -8p by nearly 0.1 percent!

That's absolutely nuts.

I know there's been some discussion regarding this already, but I forgot - is -8ep even marginally useful any more?

-8ep took nearly six hours using 1.3.4 - only to lose at compression to 1.4.0 at -8. But hey, it got close enough to defeat -7. I need to run a -7p to see if ...  O:)  but not before 1.4.0 has done -8pe, which will take the night.

To give you an idea of how FLAC allows you to run in molasses with steel shoes:
-5 took five minutes fifteen sec
-7 took 7 minutes
-8 took 9 minutes and a half
-8p took 25 minutes - and 1.4.0 @ -7 gives you smaller file at > triple speed.
-8pe took 5h56.


As for -e, I found that it could help on high resolution material - but I also found that I could outdo it with high subdivide_tukey. For CDDA resolution, neither -e or very high subdivide_tukey made the same impact, but it does not surprise me to see some signals where it helps. Of course the issue is that FLAC cannot know in advance where to apply brute force.

As for welch, I am mildly surprised that it works with subdivide_tukey, as it doesn't look much different from the tukey function. But maybe that is the reason: slightly different from something good, could be even better. At https://hydrogenaud.io/index.php/topic,120158.0.html I also found that some signals like the welch. I would have been less surprised to find flattop useful, which is why I tested it ... bummer.