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

Re: FLAC v1.4.0 (Release)

Reply #100 –
Quote from: bennetng on
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
Free encoder pack with the same test:
-7 1m
-8 1m21s

Re: FLAC v1.4.0 (Release)

Reply #101 –
@Porcus: What does the "f" do in your compression setting (other than -f, --force : Force overwriting of output files)?

Re: FLAC v1.4.0 (Release)

Reply #102 –
Quote from: doccolinni on
I'm curious to see if the improvements persist if the bit depth is reduced to 16 (perhaps without dithering?).
Go ahead folks, download for free - and buy some other Lustmord first Friday in October  :)

Quote from: bennetng on
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.
If using foobar2000 for speed testing, beware the tag transfer options - if checked, that takes the extra time of writing the file anew. Likely nothing to talk about on RAM drive, likely not much on a SATA SSD.
(For a "real-life timing", one should likely do all the tag transfers, because that is what you would do in practice. But that is another story.)

@sundance : Yes, overwrites. flac -f filename.flac will "recompress" the flac file: Write to a temp, and then delete the .flac and rename the temp.
I just discovered that flac -f filename.wav will first delete filename.flac and start writing filename.flac anew, not using a temp. If process aborts, this will leave you with a corrupted flac, while aborting recompression will leave you with the old one.

Re: FLAC v1.4.0 (Release)

Reply #104 –
The Lustmord & Karin Park album - 48/24 indeed - has some extreme measurements that I would not expect at that sample rate:

size, % 24-bit as downloaded
100,0WAVE
53,3WavPack-default
52,8ALAC
48,3WavPack-hx
46,3FLAC1.3.1-5
45,6FLAC1.3.1-8pe
42,8TTA
40,4ape-high
39,4TAK-p2
38,9TAK-p4m
38,7FLAC1.4.0-5
38,5ape-insane
36,9FLAC1.4.0-7
36,6FLAC1.4.0-8pe
36,5WavPack-hhx4
35,5OFR-2
34,8OFR-7
OK, reading down to TAK, it isn't that outrageous. Not the most WavPack friendly album - and TAK usually doesn't beat Monkey's High with that much of a margin. But still ... sure, not every album makes for the average size order.

But then? WavPack's "x4" doing well happens to high resolution. But FLAC ... is let's say it is usually not there in the order. And that improvement? The "-8" windowing functions have changed, but 1/6th at -5 is a lot.

And since you asked for 16 bit undithered:
size, % 16 undithered
100,0WAVE
31,4WavPack-default
29,3ALAC
27,1WavPack-hx
26,9FLAC1.3.1-5
26,1FLAC1.3.1-8pe
25,0TTA
23,9WavPack-hhx4
23,9FLAC1.4.0-5
23,5FLAC1.4.0-7
23,1ape-high
22,9FLAC1.4.0-8pe
22,7ape-insane
21,4TAK-p2
20,6TAK-p4m
20,2OFR-2
19,4OFR-7
... still 12 percent size gain from 1.3.1 at -5 to 1.4.0 at -5, and now also beating WavPack -hhx4.



Quote from: doccolinni on
Quote from: Porcus on
Go ahead folks, download for free

Well, I did, and they aren't 44.1/24 but 48/24. I'm not really sure how you managed that blunder. :P

Well, you know, second line I wrote ...

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

[...]
OK, so this was the one I actually googled for - and it is 44.1/24.

The remix/tribute album is 44.1/24. The Lustmord & Karin Park album - with the giant differences - is 48/24. But from 44.1 to 48 isn't an ocean ...?

Re: FLAC v1.4.0 (Release)

Reply #105 –
Quote from: Porcus on
Well, you know, second line I wrote ...

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

[...]
OK, so this was the one I actually googled for - and it is 44.1/24.

Ah, I misremembered what you wrote. Sorry about that.

Either way, for this album, it is really not surprising that 1.4.0 does so much better than 1.3.4. This is the spectrum of a rather representative section around the middle of song #2 on the album:

Spoiler (click to show/hide)

Some sections are even more extreme, like this one in song #3:

Spoiler (click to show/hide)

Generally these songs are fairly lacking in high frequencies.

Re: FLAC v1.4.0 (Release)

Reply #106 –
Could those humps around 22k be artefacts from what once was (re) sampled at 44100?
Not necessarily so that the final product is an upsample, it could be, say, the vocal tracks.

Re: FLAC v1.4.0 (Release)

Reply #107 –
Quote from: Porcus on
Could those humps around 22k be artefacts from what once was (re) sampled at 44100?

I don't think so. It looks like it's just shaped dither noise from when they were converted from the recording/editing precision of 32-bit to 24-bit. That exact same profile appears with perfect consistency throughout all the tracks. Here's the spectrum of the last 17.2 seconds of the last song of the album (#8):

Spoiler (click to show/hide)

Re: FLAC v1.4.0 (Release)

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

I get why you asked because if that were true the speed would be a lot less. but It's 40 standard (16/44.1) FLAC music files of 3hr4min2sec in total re-encoded to FLAC v1.4.0 (from about half at FLAC v1.3.3 and other half at FLAC v1.3.2) with the Foobar2000 Endoder's Pack. so it's multi-threaded. I got a i5-3550 CPU (Foobar2000 is running through Wine v6.13-staging as I suspect different Wine versions may change speed a bit(?)) which is four cores and you can see the CPU load is high during conversion.

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

I found the Xiph's FLAC v1.4.0 and used the 'flac.exe' in the 'Win64' folder and had to extract the 'flac.exe' along with 'libFLAC.dll' to Foobar2000's 'encoders' folder as just the 'flac.exe'(64bit) alone would throw errors.

but at least based on reading the files from a 6TB hard drive and writing to another 5TB hard drive, the time is pretty much the same... "0:41.522, 265.93x realtime", ran it again "0:40.479, 272.79x realtime". so generally 40-41 seconds which is basically the same as the default from 'Encoders Pack'. so I might as well stick with the default 'Fobar2000's Encoders Pack' FLAC version given there is no real differences, at least on standard hard drive usage.

but just as a quick test I decided to try converting back to WAV temporarily. so basically the WAV files are on 6TB hard drive and then from there I converted those WAV files back to FLAC8 to a 5TB hard drive and pretty much same results (i.e. "0:41.710, 264.74x realtime"). but converting from FLAC (on 6TB HDD) back to WAV (on 5TB HDD) things, as expected, were faster "0:23.562, 468.65x realtime" as you could see the speed really shoot up at times and then pause briefly and resume etc, which I suspect might be the CPU waiting for hard drive to catch up(?). but the average speed is what it shows there at 468x.

but I figure if the hard drive becomes the bottleneck, and one needs a RAM drive or SSD to get true max speed, at that point it's probably not worth proceeding further simply because I typically use my hard drives over the SSD (my main boot drive is a Samsung 850 EVO 250GB SSD (SATA)) for general data writing like FLAC or other larger files like video etc.

thanks for that info.

p.s. but using the default Foobar2000's encoders pack LAME(32bit) vs the 64bit one, the 64bit does shave some time off by about 5-6 seconds at LAME V5. so there is a legitimate difference here even though not much.
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 #109 –
Yeah, I just used the 64 bit build of 1.4.0 from Rarewares on one long file on an i7-4770 with a SSD and an unreasonable amount of RAM using Wine 5.0.3 on Debian stable and got something like 100x or so using -8.

I'm kinda curious how much better/worse a native compile of FLAC would do, but not enough to actually try to build FLAC myself.

Honestly, though, I'd still use -8 if I was ripping CDs as in practice you'd probably only be talking a second or two difference per CD given that unless you're ripping from multiple drives at once the CD drive is more or less always the bottleneck except for the last track.

If you're, say, encoding 10 Grateful Dead shows in one batch, though...

Re: FLAC v1.4.0 (Release)

Reply #110 –
Noise / experimental album by Henrik Nordvargr: both -r 8 and high subdivide_tukey works very well here
268 597 254 bytes (~932 kbps): flac -8 -e -p
266 886 449 bytes (~926 kbps): wavpack -hhx6
266 472 563 bytes (~924 kbps): flac -l 12 -b 4096 -m -r 8 -A subdivide_tukey(3) -e -p
265 899 335 bytes (~922 kbps): flac -l 12 -b 4096 -m -r 8 -A subdivide_tukey(9) -p

Re: FLAC v1.4.0 (Release)

Reply #111 –
Times? In particular, which was the slowest of the two latter? The size gains of -e seem to have dwindled on most CDDA-resolution material.
Also, CPU ... and album, Sir Björk(k) has released a few.

(The two latter are synonymous to the following, "-8" already covering the rest
-8ep -r 8
-8p -r 8 -A subdivide_tukey(9)
)

Re: FLAC v1.4.0 (Release)

Reply #112 –
Quote from: Porcus on
Times? In particular, which was the slowest of the two latter? The size gains of -e seem to have dwindled on most CDDA-resolution material.
Also, CPU ... and album, Sir Björk(k) has released a few.
Album is "Otyglad Best". -8 -r 8 -A subdivide_tukey(3) -e -p is slowest, -8 -r 8 -A subdivide_tukey(9) -p slightly faster and ~2.5 times slower than hhx6.

Re: FLAC v1.4.0 (Release)

Reply #113 –
Quote from: Gravity Stupor on
~2.5 times slower than hhx6.
Oh, but ... https://hydrogenaud.io/index.php/topic,120158.msg1015896.html#msg1015896 .  speed=4.08e-06x

Anyway, this speed is impractical and shouldn't be of much use (though, interesting for testing purposes). There is material where -r 8 helps, but at https://hydrogenaud.io/index.php/topic,120158.msg1003738.html#msg1003738 I found the size impact atop -8 -A lotsofthem to be very small (~ 1/1000 of a percent) and of ambiguous sign. Note that the "4" in "Ax4" is my big misinterpretation, and anyway obsoleted by subdivide_tukey; my point was anyway how the double precision fix has killed -e.
Which was also the reason why I asked about those timings of yours, and they agreee: there is a way to outcompress -e in less time.

Re: FLAC v1.4.0 (Release)

Reply #114 –
Quote from: ThaCrip on
but at least based on reading the files from a 6TB hard drive and writing to another 5TB hard drive, the time is pretty much the same... "0:41.522, 265.93x realtime", ran it again "0:40.479, 272.79x realtime". so generally 40-41 seconds which is basically the same as the default from 'Encoders Pack'. so I might as well stick with the default 'Fobar2000's Encoders Pack' FLAC version given there is no real differences, at least on standard hard drive usage.
So around 46MB/sec, unlikely to bottleneck transfer between two separate HDDs unless the disks are nearly full. Running the same set of files repeatedly also reduces I/O bottleneck due to OS caching.
Quote from: https://xiph.org/flac/changelog.html
Speedups for x86_64 CPUs having the FMA instruction set extention are added
I don't know about Wine but i5-3550 does not support FMA, which the Xiph build uses. However single thread speed may not be as simple as dividing the results by 4 due to Intel Turbo Boost and other unknown factors.
Quote from: ThaCrip on
but just as a quick test I decided to try converting back to WAV temporarily. so basically the WAV files are on 6TB hard drive and then from there I converted those WAV files back to FLAC8 to a 5TB hard drive and pretty much same results (i.e. "0:41.710, 264.74x realtime"). but converting from FLAC (on 6TB HDD) back to WAV (on 5TB HDD) things, as expected, were faster "0:23.562, 468.65x realtime" as you could see the speed really shoot up at times and then pause briefly and resume etc, which I suspect might be the CPU waiting for hard drive to catch up(?). but the average speed is what it shows there at 468x.
For decoding speed test (foobar does not use flac.exe for decoding), one may use foo_benchmark as it does not write files to disk. Someone's results with i5-3210M at around 800x with single thread:
https://www.audiosciencereview.com/forum/index.php?threads/wav-pcm-vs-flac.26171/post-896508

Re: FLAC v1.4.0 (Release)

Reply #115 –
If decoding from a slow drive (or over a slow connection), then recompressing flac -> flac means that less data has to be transferred compared to compressing wave/aiff -> flac. So flac -> flac could be faster in real-life conditions.

800x decoding speed at CDDA translates is very fast indeed, translating to 141 megabytes per second; yet that falls short of SATA throughput figures. But how are those in a real-life condition if you use the same bus to read and write?

Re: FLAC v1.4.0 (Release)

Reply #116 –
The test below used this SSD, 256GB version, which I purchased in 2015:
https://www.anandtech.com/show/7908/adata-sp920-128gb-256gb-512gb-1tb-review

The files used are 5 separate CDDA flac images without metadata (they are on separate .cue files), total duration 4:32:22

The flac files are copied to the SSD, then Windows is rebooted to eliminate cache, and converted by foobar using Case's flac.exe with -8. Windows is also installed in the same SSD because I only have 1 HDD and 1 SSD in my machine.
Code: [Select]
Total encoding time: 0:22.250, 734.46x realtime
As a test control the same 5 images are also converted to .wav, rebooted, and encoded to flac -8.
Code: [Select]
Total encoding time: 0:20.969, 779.32x realtime

Re: FLAC v1.4.0 (Release)

Reply #117 –
That encodes a month of audio in an hour.  Which is ... uh ... fast.

And you had five images, but you surely don't have five CPU cores/threads. If you have four, then fb2k will encode the first four and start on the fifth when the first is done - it won't parallelize in the end, so "if all four are equal then five take the same time as eight"?

(Sure it might be that the otherwise-least-busy core will finish first and then the fifth will get the presumed fastest, blah blah blah.)

Re: FLAC v1.4.0 (Release)

Reply #118 –
Quote from: ktf on
Believe it or not, I've had people complaining that FLAC defaults to requiring SSE2, which was introduced in 2000.

That is true for Intel. AMD introduced SSE2 I think in 2004? But still a lot of time ago...

Re: FLAC v1.4.0 (Release)

Reply #119 –
Quote from: Porcus on
That encodes a month of audio in an hour.  Which is ... uh ... fast.

And you had five images, but you surely don't have five CPU cores/threads. If you have four, then fb2k will encode the first four and start on the fifth when the first is done - it won't parallelize in the end, so "if all four are equal then five take the same time as eight"?

(Sure it might be that the otherwise-least-busy core will finish first and then the fifth will get the presumed fastest, blah blah blah.)
The SSD currently has 107GB of free space, and I don't have over 100GB of lossless CDDA files unless I also convert my MIDI, chiptunes and game rips to audio with over one year of duration. Of course I won't do this, it will significantly shorten the life of my 7 years old SSD.

i3-12100 is 4C8T, with standard CPU-Z benchmark like this in my previous post:


For Intel, AVX2 and FMA3 were introduced in Gen4 Core i Haswell CPUs in 2013, and my CPU looks like this in AVX2 benchmark:
X

In either case, they have similar Multi Thread Ratio. My results are similar to others too:
https://wolflsi.pixnet.net/blog/post/69948036-intel%E7%AC%AC%E5%8D%81%E4%BA%8C%E4%BB%A3alder-lake-core-i3-12100%E7%B0%A1%E6%B8%AC
X

I upgraded in February and only bought the minimum required hardware (CPU, mainboard, 2x8GB DDR4 3200), everything else is old and the m.2 slot is still empty. For a brand new system I would probably get a 1TB NVMe SSD.

I don't know / remember the encoding settings of the old flac files, but here are the file sizes:

wav
2882686684 bytes

Old flac
1566101628 bytes

New flac 1.4.0 at -8
1559797419 bytes

CD1: Loud pop songs + some speech tracks.
https://vgmdb.net/album/69558

CD2: Decently mastered pop songs.
https://vgmdb.net/album/5216

CD3: Decently mastered synth music, mainly fast-paced.
https://vgmdb.net/album/1253

CD4: Decently mastered synth music, but more calm.
https://vgmdb.net/album/2155

CD5: Classical music, sometimes contain narrations.
X

Re: FLAC v1.4.0 (Release)

Reply #120 –
That CPU has 4 physical cores and 8 threads. fb2k encoded all five albums at once then? Not unlikely it would be even faster if you had run eight albums.

No wonder people use -p.
(And -e, but they shouldn't for 1.4.0. Preliminary testing suggests that even -8pe can be equaled at size in shorter time.)

Re: FLAC v1.4.0 (Release)

Reply #121 –
Again simply using flac.exe within CUEtools on a long album ends at following speeds for a Ryzen 5900x using -8 -p.

Xiph official 98x
Netranger GCC 12.2 90x
Case 83x
john33 Intel 2022 76x
Netranger CLANG 15 52x
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.4.0 (Release)

Reply #122 –
Without Ryzen, Intel i3 could still be 2C4T in 2022, and Meltdown hurt Intel's reputation a lot too. So I wonder why Wombat is the only one who posted Ryzen results until now.
 

Re: FLAC v1.4.0 (Release)

Reply #123 –
I once even was official AMD Reseller when Slot A was king. I still have an AMD file folder around here. This is more than 20 years back when i had my own business.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.4.0 (Release)

Reply #124 –
Some size results from some overnight runs, aggregates over 38 CDs.

-e is dead, did I say that loud enough?
-8pe made bigger files and is five times slower than -8p -A subdivide_tukey(5) (you can increase to subdivide_tukey(7) and still save time).
-8e made bigger files slower than -8p.  And in line with the previous, yes -A subdivide_tukey(5) could beat -e at size here too.
"-p" has something for it. The size differences aren't big at this level, but -8 to -8p size difference was pretty much spot-on double the one from -8 to -8e.
I didn't get any -8 -A subdivide_tukey(N) to touch -p size-wise, and I stopped at (8) when it looks like it got slower than -p

-r, tested only on -7, -7p, -8, -8p.
As should, -r8 makes smaller files than -r7 than -r 6 [which -7 and -8 use] than -r 5. I've earlier had ambiguous results with -r 7 vs -r 8.
The size effect of changing -r is small. Smaller than -p and smaller than going -7 to -8 and -8 to -8 -A subdivide_tukey(4) (which is the next).


Quote from: bennetng on
I wonder why Wombat is the only one who posted Ryzen results until now.
Week-end crash. Will find some.