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 31517 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.4.0 (Release)

Reply #75 –
Hm.  I just aborted a test run on the CLANG15 because the timings were unreasonably high. It didn't make it to the following nightly FOR loop, so I started it during lunch time today, saw the timings and went oh, daytime temperature must have made the laptop CPU throttle much earlier. But only on -7p, the results were anywhere as .halverhahn's.

Anyway, here are some timing differences based on several runs of each.  The CLANG15 compile is the only that wasn't done nighttime.
On this CPU, an 11th generation i7 mobile, I would have stuck to official build because well official is official and I use -8 regularly, but those who care so much more about speed as to stick to default -5 could have time to save on Case's build.

-5
256   Case compile (x64) from reply 57
271   Xiph (x64 only)
300   Rarewares-x64 from john33's Reply 34 (first link)
321   NetRanger CLANG14-64 from Reply 15
328   Rarewares-x86-nonXP from john33's Reply 34 (first link)
330   Rarewares-x86 from john33's Reply 34 (second link)
336   NetRanger GCC-32 from Reply 10
344   NetRanger GCC-64 from Reply 10
347   NetRanger CLANG14-32 from Reply 15
366   NetRangerCLANG15-w64 from Reply 68
395   NetRangerCLANG15-w32

The >400 numbers disappeared, likely less CPU throttling likely because the computer had been only running FLAC encoding previously - or possibly lower temperature at night.

-7p
 831   Xiph (x64 only)
 880   Case compile (x64)
 882   NetRanger GCC-64
1006   NetRanger GCC-32
1015   NetRanger CLANG14-64
1035   Rarewares-x64
1089   Rarewares-x86
1170   NetRanger CLANG14-32
1284   Rarewares-x86-nonXP
1508    NetRanger CLANG15-64
aborted: NetRanger CLANG15-32

What I did for -7p:
* .bat file which would first warm-up with FLAC encoding, to make sure the CPU heated up and the fan started running already before the first to go; then it would loop through three iterations
* I would select the median.  I would also take note that the median isn't unreasonably close to the minimum, so that any weird incident would have to manifest itself in three consecutive runs.

For -5 I did the same, except that the loop that was supposed to run -5 and -7p had a whitespace missing between the output name and the "-7p", instead running six iterations of -5. I picked the third fastest.

Re: FLAC v1.4.0 (Release)

Reply #76 –
Also interesting here: what files are bit-identical? Files/music posted at https://hydrogenaud.io/index.php/topic,122960
For 76 files per encoder (38 albums, -5 and -7p), I put a duplicate finder to work.

* Rarewares x64 and Rarewares x86 produce files bit-identical to each other - but never identical to anything else.
(For x86, that means the "non-XP" files - they overwrote the other x86 files since I'm clumsy.)
If you are interested in what size difference it makes: The Rarewares files are now 24 003 098 799 bytes, which is 55 bytes smaller than the official build.

* Each NetRanger CLANG file (14 or 15, though 15-x86 was aborted after FLAC -5) was bit-identical to some GCC-compile generated file.
Deleted all.

* NetRanger GCC compiles: Out of 2*38 albums (two FLAC presets), 43 duplicate groups were generated between the x64 and x86 compiles.
Deleted down to 109 files.
* Remaining 109 GCC compiles: 53 were bit-identical to official x64 compile. A further two were distinct from the Xiph build but bit-identical to Case's build.

* Case's build (x64) matches official (x64) build in 66 of 76 files
Deleted down to 10 files. These ten are very close in size to official-generated files - max difference is seven bytes (Jordan Rudess), the nine others between 0 and 3. Bytes, not kilobytes!


After this carnage, we are left with full Rarewares file set, full official file set, and about a quarter of the Case and NetRangerGCCx86 and NetRangerGCCx64 file set (10+29+24 files left).
The Wovenhand album is there in five of six possible versions - only one bit-identical to official build is Case at -7p. Size differences are nothing to talk about, typically in the single-digit byte count, sometimes twenty - and the biggest difference seems to be 177 bytes for the the Philips {1990} High Tech Choruses at -7p. That thing has test signals including sines that haven't been FLAC faves ... and I am slapping my hands not to dig more into those possibly spurious combinations. (Anyway, you want the numbers? 339 152 854 NetRangerGCC32, ...951 for GCC64, 339 153 016 for Case, ...017 for the official, ...031 for Rarewares.)

Re: FLAC v1.4.0 (Release)

Reply #77 –
I also noticed some minuscule size differences between different encodes (made with different builds) of the same files. The only data that differs between these encodes when running metaflac --list is the seektables, and more specifically the stream_offset values which differ with what seems like random values, all other values are exactly the same. The only 2 bit-identical files were produced by NetRanger's GCC and CLANG14 builds.
In practice, the seektable and tiny filesize differences probaly mean absolutely nothing. Of course of interest here is why different builds produce different seektables? I don't have enough (as in: none at all) technical knowhow to figure this out :)

The builds I tested were (all 64-bit versions on Win10)
Xiph build from GitHub
NetRanger GCC from post #10
NetRanger CLANG14 from post #15
John33/RareWares Intel 19.2 from post #34
Case's build from post #57
NetRanger CLANG15 from post #68

Run from the commandline and a simple flac -8 -V as that's how my entire collection is done (on various version of flac).

Re: FLAC v1.4.0 (Release)

Reply #78 –
Quote from: Paul Eye on
Of course of interest here is why different builds produce different seektables?
Didn't even think of the possibility ... but anyway, I stripped everything such from the hundredandforty (?) "other-than-official" and none of them became identical. Didn't bother to check that against official.

Re: FLAC v1.4.0 (Release)

Reply #79 –
metaflac --list .txt dumps from one test case, just in case someone's interested
The track: https://supersillyus.bandcamp.com/track/the-enigmagician (edit: downloaded the WAV version of course)
Chosen for eclectic reasons and also because it's free / name your price, and 96 kHz / 24-bit
Also, file sizes just out of interest:

Case: 225 374 563
CLANG14: 225 374 556 (bit-identical with the GCC build)
CLANG15: 225 374 558
GCC: 225 374 556
Intel 19.2: 225 374 531 (edit2: official RareWares Intel 19.0 build from https://www.rarewares.org/lossless.php is bit-identical with this build)
Xiph: 225 374 562

Re: FLAC v1.4.0 (Release)

Reply #80 –
As you can all see, different CPUs handle the different compiles all very... differently. That makes profiling optimizations rather difficult: gains of less than about 10% might not be gains on other CPUs at all.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.0 (Release)

Reply #81 –
Quote from: Paul Eye on
The only data that differs between these encodes when running metaflac --list is the seektables, and more specifically the stream_offset values which differ with what seems like random values, all other values are exactly the same.
Can you check again whether they are the same when seektable is removed? As far as I read the format spec, the stream_offset should be where the sample's frame starts, and if every frame is equal between two files, the respective frame must obviously start at the same byte count.

As for timing the compiles: that new laptop of mine is throttling at its own discretion, and when looping the damn thing it seems to matter whether the previous encoding was more or less CPU intensive. Dell models come and go, Dell fan speed control remains a mystery.
Still I suggest that the timings numbers I posted in #75 might be sane, as they did repeated -5 after -5 after -5 and then repeated -7p after -7p after -7p (and then nothing after that presumed higher load). Not the other way around, when long cooldown time and short execution time might have tainted the numbers more - and the fastest run was deleted too. So I think they are a pretty good indication - at this CPU and at this pretty fast storage medium.

Re: FLAC v1.4.0 (Release)

Reply #83 –
@ktf: Sorry for the n00b question:
November last year you posted a graph showing the performance of flac_currentgit and your subblock variant. Is v1.4.0 encoding performance equal/similar to the subblock-newsettings?

Re: FLAC v1.4.0 (Release)

Reply #84 –
Quote from: sundance on
Is v1.4.0 encoding performance equal/similar to the subblock-newsettings?
No, it is not. However, a few posts further down, those of August 2022 are up-to-date. See reply #90 and #94.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.0 (Release)

Reply #85 –
Thanks for the hint. It's easy to loose track when threads get longer...
Confirms my findings that new -7 is faster and at the same time better compressing than old -8. A real "sweet spot" with top speed and compression close to the max.

Re: FLAC v1.4.0 (Release)

Reply #86 –
Quote from: sundance on
Confirms my findings that new -7 is faster and at the same time better compressing than old -8. A real "sweet spot" with top speed and compression close to the max.

-7 is good indeed. I've been singing its praises since the test builds, suggesting that -8 needed a beef-up to get a proper difference. (-8 did since change, running a test to see if it makes for much. Oh, and for the reply #72 table: the numbers are basis points - 1/100ths of a percentage point.)


-7 also beats ffmpeg "at any setting within subset", even those spending > 10x the time:

In my test, at least: Of the 38 CDs used, -7 won each and every one even when I tried -compression_level 8 -prediction_order_method search -exact_rice_parameters 1 combined with -lpc_type cholesky -lpc_passes 3/6/9 or 12; 9 made for smallest files, took a hour and a half and lost on every CD. Although one was so close that I had to metaflac away padding to be sure -7 won.
Not tested though: I quickly aborted the multi_dim_quant option, as it brought the speed down to 1/1000 of -7.

Even outside subset, ffmpeg at -compression_level 11 ended up about as -7 in size, and took more time than -8. I wonder if any ffmpeg can get to 1.4.0 at -8 sizes.  But if subset can be sacrificed, there are better options still. CUETools seems to have done brighter development on Flake than ffmpeg did, and if you have a decent GPU ... that test was done on a laptop.

Re: FLAC v1.4.0 (Release)

Reply #87 –
Quote from: Porcus on
Can you check again whether they are the same when seektable is removed?

Nope. They're not the same. I ran metaflac --remove-all --dont-use-padding on all the files, then metaflac --list (which is obviously the same since only the streaminfo block is left intact and that's identical for all files).

File sizes after the operation:
Case: 225 365 123
CLANG14: 225 365 116 (bit-identical with GCC)
CLANG15: 225 365 118
GCC: 225 365 116
Intel 19.0: 225 365 091 (bit-identical with 19.2)
Intel 19.2: 225 365 091
Xiph: 225 365 122

I also tested the Intel 2022 build, metaflac --list dump included
Before metadata removal: 225 374 529
After: 225 365 089

Re: FLAC v1.4.0 (Release)

Reply #88 –
Quote
-7 is good indeed.
... and -7 was very good in the v1.3.x days. That's why I still use it today: With the speed of v1.3.3 in mind, I could not find a 1.4.0-setting that is at least as fast and compresses as well as its predecessor on -7.
Code: [Select]
WAV size = 1.907.269.136 Bytes
flac133_case.exe -7:  Global Time = 24.826 sec, FLAC size: 1.168.025.916 Bytes
flac140-case.exe -7:  Global Time = 29.569 sec, FLAC size: 1.167.014.383 Bytes (= 61,188% of WAV size) -> slower, but better compression
flac140-case.exe -6:  Global Time = 25.919 sec, FLAC size: 1.170.517.594 Bytes, still slower & worse compression
And with new -6 being slower and worse compressing than old -7, it's probably hard to find something "in between" being able to match old -7. But that's almost nitpicking.

Re: FLAC v1.4.0 (Release)

Reply #89 –
Quote from: john33 on
Here is another compile that certainly appears faster on my system although no empirical measurements taken. It is compiled using the Intel c++ 2022 compiler.
www.rarewares.org/files/lossless/flac-1.4.0-x64-Intel-2022.zip
No difference from the one posted on Reply #34 on my PC.
And yes, NetRanger's CLANG15 is the slowest one in the whole thread on my i3-12100. Would like to see some Ryzen results.

Re: FLAC v1.4.0 (Release)

Reply #90 –
Quote from: ktf on
As you can all see, different CPUs handle the different compiles all very... differently. That makes profiling optimizations rather difficult: gains of less than about 10% might not be gains on other CPUs at all.
It may be the different compilers differ more these days alone for the fact mitigating CPU vulnerabilities at compiler level if i understand the mitigations correctly.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!
 

Re: FLAC v1.4.0 (Release)

Reply #91 –
v1.4.0 from the Foobar2000 'Encoders Pack' (on Wine v6.13-staging) on a i5-3550 desktop quad-core CPU on some random music I got of 3hr4min2sec in length and just going by what I last see in the Foobar2000 window for current time shown before the window disappears...

-5 / 26sec / 1,064,210,521 bytes
-6 / 31sec / 1,063,104,966 bytes
-7 / 33sec / 1,058,278,040 bytes
-8 / 42sec / 1,057,783,228 bytes

Takeaways...

-FLAC7 is probably the sweet-spot when it comes to time vs file size combo as it's barely larger (a bit shy of 0.5MB) than FLAC8 but is 9 seconds quicker as you would have to go to FLAC5 for a worthwhile speed improvement, but then you would lose a bit over 5.9MB in size.

-FLAC6 is useless given it's barely faster (2 sec) than FLAC7 but is 4.8MB larger.

-While a bit more debatable, FLAC5 is probably better than FLAC6 given the 5sec speed improvement but only sacrifices about 1.1MB. so if someone goes with this mindset, FLAC6 don't really win any category here because FLAC8 wins in smallest file size, FLAC7 wins comfortably in the 'time vs file size' combo and FLAC5 has a worthwhile compression speed improvement where as FLAC6's best chance is against FLAC5 but even this is not really clear cut, but would probably favor FLAC5's time savings over the small enough file size difference between the two. although I guess a scenario that would favor FLAC6 over FLAC5 would be if someone was uploading it on a slower internet line, but then again at this point, FLAC7/8 would save even further, which still makes FLAC6 useless.

so while FLAC7 looks good, in the end, with modern computing power and storage space, it's not really going to matter too much on what someone chooses unless maybe if you plan on uploading a fair amount of that stuff online for backup in which case the smallest file size will be best, especially if you don't have a fast upload. but I guess if someone had a boatload of WAV files to compress or FLAC to re-compress, then FLAC7 might be slightly preferred.

p.s. still, I pretty much prefer FLAC8 in general since it's not like we spend tons of time compressing in general and I might as well get smallest file size (especially when compression times are still easily fast enough as there ain't much real world difference for there to be any real negative by using -8) for storage efficiency sake.
For music I suggest (using Foobar2000)... MP3 (LAME) @ V5 (130kbps). NOTE: using on AGPTEK-U3 as of Mar 18th 2021. I use 'fatsort' (on Linux) so MP3's are listed in proper order on AGPTEK-U3.

Re: FLAC v1.4.0 (Release)

Reply #92 –
Quote from: bennetng on
Quote from: john33 on
Here is another compile that certainly appears faster on my system although no empirical measurements taken. It is compiled using the Intel c++ 2022 compiler.
www.rarewares.org/files/lossless/flac-1.4.0-x64-Intel-2022.zip
No difference from the one posted on Reply #34 on my PC.
And yes, NetRanger's CLANG15 is the slowest one in the whole thread on my i3-12100. Would like to see some Ryzen results.
Just tried -7 on a concatenated CDDA file, 4h43m29s. All previous tests were also using a long single file and therefore single threaded.
Case: 49s
Xiph: 51s
NetRanger GCC v12.2.0: 1m1s
NetRanger CLANG15: 1m2s

Here are -8:
Case: 1m8s
Xiph: 1m8s
NetRanger GCC v12.2.0: 1m23s
NetRanger CLANG15: 1m32s

Re: FLAC v1.4.0 (Release)

Reply #93 –
Ryzen? Coming up in a few days, a friend's Acer laptop is running over the week-end while they are away ... under the all-too-bold assumption that I didn't make my usual .bat bug.

I recall my once fascination for compiling on own platform, before laziness got the better of me - anyone else remembering how long to took to get a Gentoo compiling its way through everything in the early noughties? Fast forward to this Windows 10 work laptop, which even with OS preinstalled took a week of updates and reboots, I guess history surely rhymes.

Re: FLAC v1.4.0 (Release)

Reply #94 –
Quote from: ThaCrip on
v1.4.0 from the Foobar2000 'Encoders Pack' (on Wine v6.13-staging) on a i5-3550 desktop quad-core CPU on some random music I got of 3hr4min2sec in length and just going by what I last see in the Foobar2000 window for current time shown before the window disappears...

-5 / 26sec / 1,064,210,521 bytes
-6 / 31sec / 1,063,104,966 bytes
-7 / 33sec / 1,058,278,040 bytes
-8 / 42sec / 1,057,783,228 bytes
Was this one big file (making encoding effectively singlethreaded?)

EDIT: My calculations suggest -8 is 262x, which means over 4 minutes of audio encoded per second.  If this is singlethreaded, if you use -8 with 4 threads, then you'd probably get over 1000x.

EDIT#2: If you're ripping CDs, given that ripping the CD is likely to be the bottleneck by far even on lesser CPUs, I'd recommend -8 in almost all those cases.

Re: FLAC v1.4.0 (Release)

Reply #95 –
Quote from: binaryhermit on
EDIT#2: If you're ripping CDs, given that ripping the CD is likely to be the bottleneck by far even on lesser CPUs, I'd recommend -8 in almost all those cases.
Depends on the application? Does EAC still run the compression after ripping the entire CD? I don't remember whether you can start ripping the next while it still compresses ...?
dBpoweramp works tracks-based. IIRC, only the paid version uses multiple CPU threads (one for each track), so at worst you will have to wait for the last to complete.

In any case, won't be ripping more CDs in a day than you can re-encode with -8p overnight. Well maybe if you use automated CD changers, when you will surely be busy verifying the metadata.

Re: FLAC v1.4.0 (Release)

Reply #96 –
Quote from: john33 on
Here is another compile that certainly appears faster on my system although no empirical measurements taken. It is compiled using the Intel c++ 2022 compiler.
www.rarewares.org/files/lossless/flac-1.4.0-x64-Intel-2022.zip

Practically tied to your earlier x64 bild. Compared to the figures in reply 75, this one gets -5 down from 300 to 298, and -7p down from 1035 to 1029.
Again, median of three runs. Pretty consistent numbers - 1016, 1029, 1036 seconds for -7p.

Re: FLAC v1.4.0 (Release)

Reply #97 –
Extreme (> 20 percent) 1.4.0 benefits found in the wild - by coincidence, and without going to 88.2 kHz or higher. 
Yes 48/24 files, but also a few 44.1/24 that save some ten percent.

https://lustmord.bandcamp.com/album/alter is available at "name your price".
(If you want to buy at Bandcamp, wait until "Bandcamp Friday" where they waive their cut. I've started buying from Boomkat instead after Bandcamp canceled my purchase post payment just because.)

A bit trying back and forth suggests they used -6, that gives straight 1.000 ratios.

Now look at 1.4.0 at -3:
Code: [Select]
C:\tmp\Lustmord & Karin Park - ALTER> C:\bin\flac-1.4.0-win\Win64\flac.exe -3f *.flac

flac 1.4.0
Copyright (C) 2000-2009  Josh Coalson, 2011-2022  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

Lustmord & Karin Park - ALTER - 01 Hiraeth.flac: wrote 52035408 bytes, ratio=0,981
Lustmord & Karin Park - ALTER - 02 The Void Between.flac: wrote 59625894 bytes, ratio=0,899
Lustmord & Karin Park - ALTER - 03 Perihelion.flac: wrote 32100437 bytes, ratio=0,845
Lustmord & Karin Park - ALTER - 04 Twin Flames.flac: wrote 83337766 bytes, ratio=0,914
Lustmord & Karin Park - ALTER - 05 Entwined.flac: wrote 75526535 bytes, ratio=0,956
Lustmord & Karin Park - ALTER - 06 Kindred.flac: wrote 53892745 bytes, ratio=0,839
Lustmord & Karin Park - ALTER - 07 Song of Sol.flac: wrote 55486784 bytes, ratio=0,898
Lustmord & Karin Park - ALTER - 08 Sele.flac: wrote 64500002 bytes, ratio=0,879
... saves nearly ten percent on the total.

Deleting, re-extracting from .zip, and running -8p (no "e" ...)
Code: [Select]
PS C:\tmp\Lustmord & Karin Park - ALTER> C:\bin\flac-1.4.0-win\Win64\flac.exe -8pf *.flac

flac 1.4.0
Copyright (C) 2000-2009  Josh Coalson, 2011-2022  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

Lustmord & Karin Park - ALTER - 01 Hiraeth.flac: wrote 47871959 bytes, ratio=0,903
Lustmord & Karin Park - ALTER - 02 The Void Between.flac: wrote 53662309 bytes, ratio=0,809
Lustmord & Karin Park - ALTER - 03 Perihelion.flac: wrote 28090623 bytes, ratio=0,739
Lustmord & Karin Park - ALTER - 04 Twin Flames.flac: wrote 71762047 bytes, ratio=0,787
Lustmord & Karin Park - ALTER - 05 Entwined.flac: wrote 65022030 bytes, ratio=0,823
Lustmord & Karin Park - ALTER - 06 Kindred.flac: wrote 48006888 bytes, ratio=0,748
Lustmord & Karin Park - ALTER - 07 Song of Sol.flac: wrote 48319869 bytes, ratio=0,782
Lustmord & Karin Park - ALTER - 08 Sele.flac: wrote 55920678 bytes, ratio=0,763
... and no, the 1.3.4 at -8pf doesn't do wonders, it is the 1.4.0. Download and test for yourself.
-e not tested. Probably makes a difference for 1.3.4.

I came up with this by the following coincidence: Spotify on my soon-falling-apart desktop computer suggested a new Lustmord tribute/remix CD with some damn interesting names, and then a crash. Went to laptop, googled, found it at "name your price" together with the one above: https://lustmord.bandcamp.com/album/the-others-lustmord-deconstructed

OK, so this was the one I actually googled for - and it is 44.1/24. Again, testing with -6 gives straight 1.000 ratios, and let's hit it with 1.4.0 at -8pf (again, no "e" here):
Code: [Select]
Lustmord - The Others -Lustmord Deconstructed- - 01 Enslaved - Eon.flac: wrote 42854726 bytes, ratio=0,922
Lustmord - The Others -Lustmord Deconstructed- - 02 MONO - Er Eb Os.flac: wrote 76787106 bytes, ratio=0,873
Lustmord - The Others -Lustmord Deconstructed- - 03 Ihsahn - Dark Awakening.flac: wrote 39634289 bytes, ratio=0,923
Lustmord - The Others -Lustmord Deconstructed- - 04 Jo Quail - Prime.flac: wrote 74264091 bytes, ratio=0,900
Lustmord - The Others -Lustmord Deconstructed- - 05 Bohren & der Club of Gore - Plateau.flac: wrote 118575065 bytes, ratio=0,986
Lustmord - The Others -Lustmord Deconstructed- - 06 hackedepicciotto - Trinity Past.flac: wrote 65398218 bytes, ratio=0,905
Lustmord - The Others -Lustmord Deconstructed- - 07 Ulver - Godeater.flac: wrote 113619735 bytes, ratio=0,981
Lustmord - The Others -Lustmord Deconstructed- - 08 Jonas Renkse - Er Eb Os.flac: wrote 70867405 bytes, ratio=0,971
Lustmord - The Others -Lustmord Deconstructed- - 09 Zola Jesus - Prime.flac: wrote 37000037 bytes, ratio=0,889
Lustmord - The Others -Lustmord Deconstructed- - 10 Spotlights - Of Eons.flac: wrote 76565255 bytes, ratio=0,935
Lustmord - The Others -Lustmord Deconstructed- - 11 The Ocean - Primal -State of Being-.flac: wrote 116101117 bytes, ratio=0,994
Lustmord - The Others -Lustmord Deconstructed- - 12 CROWN - Element.flac: wrote 58738240 bytes, ratio=0,999
Lustmord - The Others -Lustmord Deconstructed- - 13 Jaye Jayle - Er Eb Es.flac: wrote 44316148 bytes, ratio=0,928
Lustmord - The Others -Lustmord Deconstructed- - 14 Godflesh - Ashen.flac: wrote 70261802 bytes, ratio=0,979
Lustmord - The Others -Lustmord Deconstructed- - 15 Steve von Till a.k.a. Harvestman - Testament.flac: wrote 79120831 bytes, ratio=0,994
Lustmord - The Others -Lustmord Deconstructed- - 16 Årabrot - The Last Days -See the Light-.flac: wrote 86782738 bytes, ratio=0,997
Still three tracks do hit the ten percent mark. Again, it is the 1.4.0 that makes the difference; recompressing the download by 1.3.4 at -8pf gives at best .992.

Re: FLAC v1.4.0 (Release)

Reply #99 –
Quote from: binaryhermit on
EDIT: My calculations suggest -8 is 262x, which means over 4 minutes of audio encoded per second.  If this is singlethreaded, if you use -8 with 4 threads, then you'd probably get over 1000x.
The results are obviously multithreaded and foobar does it by default, otherwise a 2012 Ivy Bridge (no AVX2 support if relevant) would be faster than a 2022 Alder Lake.
https://hydrogenaud.io/index.php/topic,122949.msg1015750.html#msg1015750

Even a 2017 Kaby Lake i7 is slower than a 12th Gen i3 in both single and multithread performance.
https://cpu.userbenchmark.com/Compare/Intel-Core-i7-7700K-vs-Intel-Core-i3-12100/3647vs4126
X

Quote from: ThaCrip on
v1.4.0 from the Foobar2000 'Encoders Pack' (on Wine v6.13-staging) on a i5-3550 desktop quad-core CPU on some random music I got of 3hr4min2sec in length and just going by what I last see in the Foobar2000 window for current time shown before the window disappears...

-5 / 26sec / 1,064,210,521 bytes
-6 / 31sec / 1,063,104,966 bytes
-7 / 33sec / 1,058,278,040 bytes
-8 / 42sec / 1,057,783,228 bytes
With foobar, go to View -> Console after encoding, this shows the encoding time and speed (x). It is also necessary to know the source formats and types of used storage media, these factors affect speed too. My tests used .wav source and RAM drive. If there is not enough RAM then at least SATA SSD should be used.

flac.exe in the Free Encoder Pack is x86 and slower than Case/Xiph's x64 builds on my PC as well.