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.x Performance Tests (Read 73203 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.4.x Performance Tests

Reply #226 –
Try this with 24-bit and >= 88.2kHz, ideally with appropriate -b:

-8 -A "subdivide_tukey(3/2e-1);welch;hann;flattop"

Much faster than -8e and seems to give good results, including "real" and "fake" hi-res and DSD transcodes with appropriate ultrasonic filtering. May not work well with clipped and loudness war hi-res though. -8p for 24-bit is just too slow. -8e is about two times as fast but still slow.

Re: FLAC v1.4.x Performance Tests

Reply #227 –
Quote from: ktf on
Quote from: Porcus on
This is a slightly puzzling. -e being helpful in particular when there is no high frequency content suggests that here the guesstimation procedure isn't very good. Yet it is precisely in those cases where 1.4 makes for the bigg improvements.
The improvements in 1.4.0 weren't related to the guesstimation. 1.4.0 improved the accuracy with which predictors were formed, the guesstimation (that -e circumvents by brute-forcing) is in which order to pick.

Yes, but: for CDDA it seems you (& the rest of the developers) effectively killed the need for -e - and without touching the guesstimation algorithm, then how?
I can only guess that the better you hit (and double precision does that!), the closer you get to what FLAC reasonably can achieve, and the smaller are the improvements available by any means.
Now with the files I tested above, FLAC can beat TAK -p2. Not proving anything, but mildly suggesting that at least here, you really hit something close to optimum - but all for sudden there is a brute-force switch that appears more attractive than for CDDA.
And that is kinda puzzling.

Also -p not doing well ... actually, I might be fooled here by -p having become damn slow, which leads to writing it off as "not worth it". Question: are the new versions doing the -p routine entirely in double precision even after precision is truncated down to 15...5 bits - and can that explain the slowdown? (And if so: is that even necessary? Is there anything gained to stay in double precision after you have calculated a proto-predictor to be rounded off?)

Re: FLAC v1.4.x Performance Tests

Reply #228 –
Quote from: Porcus on
58.477%about -8e speed: -7r7 -A "flatopp;gauss(7e-2);tukey(7e-1);subdivide_tukey(7)" -l 14
58.475%-7r7 -A "flatopp;gauss(7e-2);tukey(7e-1);subdivide_tukey(7)" -l 14 -b 8192
Did you really type "flatopp"?

Re: FLAC v1.4.x Performance Tests

Reply #229 –
Quote from: ktf on
It is a bit tricky that the encoder accepts anything and silently drops stuff it doesn't understand.

If you want to know what it does, read the explanation at the bottom of this page: https://xiph.org/flac/documentation_tools_flac.html

TL;DR: for starters, just use whole numbers like subdivide_tukey(5) or something. If you feel like it, you can specify a second fraction between 0 and 1, like subdivide_tukey(5/0.2) The second value is locale-specific, so is subdivide_tukey(5/0,2) for many non-English PCs. Using scientific notation (2e-1) is a way around that. For other apodizations, see the linked document.

Quote from: Porcus on
Just a point: "/" is not a division slash, it is a separator between arguments, where the first is mandatory.
tukey(P) takes only one argument in, and that is a number between 0 and 1. The subdivide_tukey can be specified as subdivide_tukey(N) and optionally subdivide_tukey(N/P) - but then again, the "/P" has nothing to do with division. As ktf says, for starters stick to N and remember that higher N will slow down.

What this tukey function does? For the block of the signal - 4096 samples, typically - it keeps the middle 1-P fraction and it downweighs the beginning and end according to a cosine function. Turns out, it typically gives a much better predictor than not applying any weight - that would be "rectangle".
The subdivide_tukey "generates more functions" in a way that recycles lots of calculations. It takes time to try them all, but it doesn't make for more complicated decoding. They are several simple attempts, and the encoder picks the one that happens to fit best. The decoder doesn't know how hard the encoder tried.

Thanks for the information.  I did a test of different combinations of options, so see what kind of times vs compression I would get.  I started the test before I asked the question, and it took over a day to complete.  I had put in a couple random values for subdivide_tukey(X/Xe-1) It looks like "subdivide_tukey(21/15e-1)" shouldn't work, as that would exceed what should work for tukey, but it did seem to be helpful here.

Code: [Select]
Ratio:      Size:             Enc Time   Options used
59.41%   464.176M   8:32:57    -b 4096 -m -l 12 -r 8 -ep -A subdivide_tukey(21)   
59.41%   464.178M   5:15:19    -b 4096 -m -l 12 -r 7 -ep -A subdivide_tukey(21)   
59.41%   464.185M   5:34:39    -b 4096 -m -l 12 -r 8 -ep -A subdivide_tukey(17)   
59.41%   464.187M   3:29:06    -b 4096 -m -l 12 -r 7 -ep -A subdivide_tukey(17)   
59.42%   464.205M   3:15:35    -b 4096 -m -l 12 -r 8 -ep -A subdivide_tukey(13)   
59.42%   464.206M   2:03:37    -b 4096 -m -l 12 -r 7 -ep -A subdivide_tukey(13)   
59.43%   464.281M   31:07.50    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(21/15e-1)   
59.43%   464.281M   46:29.04    -b 4096 -m -l 12 -r 8 -p -A subdivide_tukey(21)   
59.43%   464.283M   31:08.72    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(21)   
59.43%   464.292M   30:45.12    -b 4096 -m -l 12 -r 8 -p -A subdivide_tukey(17)   
59.43%   464.293M   20:43.93    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(17)   
59.43%   464.297M   20:36.87    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(17/12e-1)   
59.43%   464.315M   18:20.15    -b 4096 -m -l 12 -r 8 -p -A subdivide_tukey(13)   
59.43%   464.316M   12:19.42    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(13)   
59.43%   464.320M   12:20.79    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(13/9e-1)   
59.43%   464.342M   1:35:41    -b 4096 -m -l 12 -r 8 -ep -A subdivide_tukey(9)   
59.43%   464.343M   23:23.17    -b 4096 -m -l 12 -r 6 -p -A subdivide_tukey(21)   
59.43%   464.344M   59:58.54    -b 4096 -m -l 12 -r 7 -ep -A subdivide_tukey(9)   
59.44%   464.352M   15:32.61    -b 4096 -m -l 12 -r 6 -p -A subdivide_tukey(17)   
59.44%   464.373M   9:18.64    -b 4096 -m -l 12 -r 6 -p -A subdivide_tukey(13)   
59.45%   464.444M   30:08.22    -b 4096 -m -l 12 -r 8 -ep -A subdivide_tukey(5)   
59.45%   464.447M   19:02.92    -b 4096 -m -l 12 -r 7 -ep -A subdivide_tukey(5)   
59.45%   464.466M   6:05.76    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(9/6e-1)   
59.45%   464.477M   9:01.27    -b 4096 -m -l 12 -r 8 -p -A subdivide_tukey(9)   
59.45%   464.479M   6:05.86    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(9)   
59.46%   464.525M   4:39.14    -b 4096 -m -l 12 -r 6 -p -A subdivide_tukey(9)   
59.47%   464.595M   2:00.80    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(5/3e-1)   
59.47%   464.598M   2:55.68    -b 4096 -m -l 12 -r 8 -p -A subdivide_tukey(5)   
59.47%   464.600M   2:00.44    -b 4096 -m -l 12 -r 7 -p -A subdivide_tukey(5)   
59.47%   464.644M   1:35.94    -b 4096 -m -l 12 -r 6 -p -A subdivide_tukey(5)   
59.48%   464.661M   6:08.93    -b 4096 -m -l 12 -r 8 -A subdivide_tukey(21)   
59.48%   464.663M   4:25.36    -b 4096 -m -l 12 -r 7 -A subdivide_tukey(21)   
59.48%   464.670M   4:09.56    -b 4096 -m -l 12 -r 8 -A subdivide_tukey(17)   
59.48%   464.671M   3:01.99    -b 4096 -m -l 12 -r 7 -A subdivide_tukey(17)   
59.48%   464.691M   2:34.32    -b 4096 -m -l 12 -r 8 -A subdivide_tukey(13)   
59.48%   464.692M   1:54.71    -b 4096 -m -l 12 -r 7 -A subdivide_tukey(13)   
59.48%   464.723M   3:34.07    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(21)   
59.48%   464.730M   2:28.18    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(17)   
59.49%   464.748M   1:33.87    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(13)   
59.50%   464.849M   1:21.94    -b 4096 -m -l 12 -r 8 -A subdivide_tukey(9)   
59.50%   464.850M   1:02.65    -b 4096 -m -l 12 -r 7 -A subdivide_tukey(9)   
59.51%   464.896M   0:52.11    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(9)   
59.51%   464.962M   0:32.64    -b 4096 -m -l 12 -r 8 -A subdivide_tukey(5)   
59.51%   464.963M   0:26.19    -b 4096 -m -l 12 -r 7 -A subdivide_tukey(5)   
59.52%   465.009M   0:22.85    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(5)   
59.54%   465.197M   0:12.73    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(3)   # Same as preset -8 #
59.59%   465.591M   0:08.72    -b 4096 -m -l 12 -r 6 -A subdivide_tukey(2)   # Same as preset -7 #
59.74%   466.717M   0:07.24    -b 4096 -m -l 8 -r 6 -A subdivide_tukey(2)   # Same as preset -6 #
59.90%   467.965M   0:05.40    -b 4096 -m -l 8 -r 5   # Same as preset -5 #
64.92%   507.177M   0:03.73    -b 1152 -l 0 -r 3 --no-mid-side   # Same as preset -0 #

Re: FLAC v1.4.x Performance Tests

Reply #230 –
Quote from: Wombat on
Nice. For 16-44.1 GCC 12.2.0 and disable asm is the fastest. Clang does bad with it disabled. Will be interesting how fast Case and his clean enviroment does. I depend on MSYS2.

I noticed this as well.  With asm enabled, Flac performs much better, but still a little behind Flac compiled with GCC.

Re: FLAC v1.4.x Performance Tests

Reply #231 –
Quote from: Replica9000 on
Thanks for the information.  I did a test of different combinations of options, so see what kind of times vs compression I would get.  I started the test before I asked the question, and it took over a day to complete.  I had put in a couple random values for subdivide_tukey(X/Xe-1) It looks like "subdivide_tukey(21/15e-1)" shouldn't work, as that would exceed what should work for tukey, but it did seem to be helpful here.

There is a complication particular to subdivide_tukey(N):
subdivide_tukey(1) is the same as a single tukey(.5), but subdivide_tukey(N) tapers off a fraction of .5/N (that slash is a division slash!).
It wants to generate N small tukey humps (and more!) - and with a small tukey hump, it doesn't make that much sense to taper away a big fraction of the total from every small one. But the consequence is that 21/15e-1 tapers off 1.5/21ths = 1/14ths or around 7 percent of the window, or around 3.5 percent at each end.

That  .5 divided by N is also the reason why I was testing something like
-A "subdivide_tukey(5/125e-1);tukey(666e-3)"
The subdivide_tukey tapers very little (that is, is fairly close to rectangle) so I combine it with a tukey that tapers a lot (that is, tapers as much as the left third and the right third and leaves only the middle third un-downweighted). Why do that? Making the functions different. There is no use trying two identical functions, and very little use trying two near-identical ones.
And that function is faster than subdivide_tukey(6/P).

Before partial_tukey, punchout_tukey and subdivide_tukey, you had to type in each and every function and it would only do one function per one you typed. subdivide_tukey(5) does a lot (and it does them faster than typing N individual into it).


Quote from: bennetng on
Did you really type "flatopp"?
Damn, only one way to find out, and that is not done in two minutes ...

Re: FLAC v1.4.x Performance Tests

Reply #232 –
I'd take a look at how the "best" settings compared to others with the attached simple signal :D

-b 4096 -m -l 12 -r 8 -ep -A subdivide_tukey(21)
4970861 bytes 3:22.843, 0.14x realtime

-b512 -r8 -q5
4583068 bytes 0:00.171, 175.43x realtime

WavPack hhx6
4376064 bytes 0:01.313, 22.84x realtime

APE insane
5018164 bytes 0:00.391, 76.72x realtime

Re: FLAC v1.4.x Performance Tests

Reply #233 –
Quote from: bennetng on
I'd take a look at how the "best" settings compared to others with the attached simple signal :D
If the signal is so simple that 7 zip outperforms all audio codecs, I don't think is fit for such a test
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.x Performance Tests

Reply #234 –
Merzbow Pulse Demon and Venereology fit into this catagory. xz even works better than 7z.

Re: FLAC v1.4.x Performance Tests

Reply #235 –
Quote from: bennetng on
Merzbow Pulse Demon and Venereology fit into this catagory. xz even works better than 7z.
Venereolog'ing the compressors: https://hydrogenaud.io/index.php/topic,122040.msg1010086.html#msg1010086

The ultra-useless sac compressor could shave more than a quarter off the smallest OptimFROG.
I got xz down to 40 972 856, not beating more than the second-smallest .sac file. Well xz took only 20 seconds.
7z was around ten percent bigger than xz.

There must be some long-term repeating patterns there. Long-term as far as audio goes. AFAIunderstand, an OptimFROG block can be several seconds long (and an insane monkey nearly half a minute, without being able to make any sense out of that track). In the very least, xz got the flac file down by ten percent.

Re: FLAC v1.4.x Performance Tests

Reply #236 –
With -l12 -r8 -b512 -q5 I got 424599071 bytes in Venereology at 207x speed.

Then the slow stuff:
424286964 bytes with subdivide_tukey(21)
424266692 bytes with subdivide_tukey(14)
424261436 bytes with subdivide_tukey(11/1)
424249707 bytes with subdivide_tukey(21/3)
424238652 bytes with subdivide_tukey(15/2)

11/1 is about two times faster than others, other settings have similar speed, at least in this test.

Re: FLAC v1.4.x Performance Tests

Reply #237 –
Quote from: Porcus on
* Monkey's Audio needs more bits than uncompressed PCM. TAK makes it below 1411 on a setting.
* 58176764: the .wav file
* 56535466 for the smallest .flac I could get
* 53920654 for the smallest .wv I could get
* 53222937 for the smallest frog
* 50613838 for sac at default
* 49046602 for the twelve-hour sac compression. But hey, it decodes in less than ten minutes. (Realtime playback? Please, no irrelevant questions! O:)  )
I see, only track 3 is used.
-l3 -b512 -r8 -q5 -e -A subdivide_tukey(15/2)
52292911 bytes
Higher -l does nothing for this track apart from slowing things down. The whole album would need a higher value though.

Re: FLAC v1.4.x Performance Tests

Reply #238 –
Quote from: bennetng on
Merzbow Pulse Demon and Venereology fit into this catagory. xz even works better than 7z.
I wouldn't call Merzbow proper material to base a test on, except when part of a well-rounded corpus. In this particular case, you have a signal for which 7z outperforms audio codecs by a factor of more than 10.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.x Performance Tests

Reply #239 –
Quote from: ktf on
I wouldn't call Merzbow proper material to base a test on, except when part of a well-rounded corpus. In this particular case, you have a signal for which 7z outperforms audio codecs by a factor of more than 10.
But you can see the potential of flac (vs other lossless audio formats, not 7z or xz) in these special signals when the optimal parameters are being used. Assume there is a multi-pass encoder (can't use pipe?) or a "long-term analyzer" does it mean there is no need for end users to guess the optimal settings? Not that I want something like this but just curious about it.
 

Re: FLAC v1.4.x Performance Tests

Reply #240 –
I think implementing variable blocksize encoding would solve most of it. However, as the recent problems with variable blocksize encoding in CUETools have shown, this is no easy task. Many other things in FLAC are already being 'brute-forced'. It is rather high on my list because it would make the reference encoder cover more of the FLAC specification, which is something I pursue because of the IETF standardization effort.

I think that is a better idea than encoding a file several times with different fixed blocksizes to see which one results in the smallest file. -q is already brute-forced per-subframe when you use -p.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.4.x Performance Tests

Reply #241 –
Quote from: ktf on
variable blocksize encoding [...] is rather high on my list
And I was about to write that well, this makes a case for variable block size, which is now waiting in line somewhere between positions 2048 and 4096 on the to do list ...

Actually, with in particular partial_tukey(2) and thus subdivide_tukey(2), I've been thinking: if that is what the encoder selects - just dropping half of the block when designing the predictor - then that is a case where you would try to split the block in two, keep the predictor where it is good, and look for another for the rest? Same goes for the (4).

Here I am making an assumption that could be fiddled with, namely that we are not using "adjacent" samples to calculate the predictor of a certain frame. That isn't god-given either.

As for CUETools, their solution is to remove the variable block size option, https://github.com/gchudov/cuetools.net/pull/223 . So without it finding its way into reference flac, it won't be ... anywhere?

Re: FLAC v1.4.x Performance Tests

Reply #242 –
... but for the Merzbow track, the magic is actually not in the -b, but in the -r. Try options
--lax  -r 15
That's right, no -8, no -p, no -e, no -b (edit: wrote that wrong!)
I got 51954953 bytes. Throwing in a -b 16383 reduces it slightly to 51923540 bytes.

The reason that -b512 looks so good, is not that it is a good block size - it is that it makes only a few samples per Rice partition within the subset's maximum order of 8. Relaxing that ...

So that gives another "potential case for" a variable block size.
* test -r9. If that improves, then dammit we are out of subset, and the easiest way to get back in is to halve the -b. One doesn't even have to recalculate the predictor to get that improvement.
* of course, a "smarter way" starting from current -7 and -8 would be to see if Rice pt order 6 is actually used and good for something for that frame. If it is, try order 7. If it helps, try 8. If that helps, ... previous item.

BUT: -r 8 only rarely improves, right?

Re: FLAC v1.4.x Performance Tests

Reply #243 –
Quote from: Porcus on
--lax  -r 15
That's right, no -8, no -p, no -e, no -b (edit: wrote that wrong!)
I got 51954953 bytes. Throwing in a -b 16383 reduces it slightly to 51923540 bytes.
Well 16384 "of course".
The reason for -r 15 was to try even bigger block size, but as I "discovered" that 65536 is invalid and max is 65535, a -1 snuck in when I typed it here. I wonder if anything can utilize the 15th order then, when 65536 is invalid.
51924581 for --lax -r 15 -b 32768.

So here is a weird thing:
51924584 for --lax -r 13,14 -b 32768
52709806 for --lax -r 13,13 -b 32768 and same for -r 12,13, and -r 12,12 is as "bad as" 54771887
52765170 for --lax -r 14,14 -b 32768 and unsurprisingly the same for -r 14,15. But ... but ... same also for -r 15,15?! (Maybe I need to compute some Rice encodings by hand?)

Now 16384
51923763 for --lax -r 12,13 -b 16384 (good!)
52710096 for --lax -r 11,12 -b 16384 which is lower than the next line, so here the 11 is used while for 32768 the 12 was ... well if it was, it didn't impact size.
52710316 for --lax -r 12,12 -b 16384
52763867 for --lax -r 13,13 -b 16384 and unsurprisingly the same for -r 13,14. Also for -r 14,14.

Well impact isn't monstrous. Still a bit strange.

Re: FLAC v1.4.x Performance Tests

Reply #244 –
Another example with non-experimental music:
https://youtu.be/wJW9AIwHSGY

40388588 16 Syvalion arrange MMIX.wav
38322604 xz.xz
34931072 7z.7z
33814392 --lax -l15 -8 -r15 -b32768.flac
33742999 --lax -l32 -8 -r15 -b32768.flac
33691294 --lax -l15 -8 -r10 -b8192.flac
33627273 -8.flac
33627254 -8 -r8.flac
33627254 -8 -r7.flac
33622698 --lax -l15 -8 -r8.flac
33617925 --lax -l15 -8 -r8 -b3456.flac
33602205 -8 -r7 -q7.flac
33597671 --lax -l32 -8 -r15 -b2304.flac
33594087 --lax -l15 -8 -r8 -q7.flac
33594087 --lax -l15 -8 -r7 -q7.flac
33588219 -8pe.flac
33578671 -8 -r7 -q7 -b2304.flac
33574773 --lax -l15 -8 -r7 -q7 -b2304.flac
33568744 --lax -l20 -8 -r7 -b2304 -q7.flac
33558642 --lax -l32 -8 -r7 -b2304 -q7.flac
33558642 --lax -l32 -8 -r15 -b2304 -q7.flac

Basically, Merzbow is mostly clipped at max/min PCM values.

Re: FLAC v1.4.x Performance Tests

Reply #245 –
I found another case where -e is much better than -p. I converted my test signal archive (sine, multitone, sweep etc) to flac from different sources including analog and digital I/O of sound cards, smartphones, cassette decks, disc players, motherboard codecs with GPU noise injected and so on. The sizes listed below are at -8.

 2371488 ALC892_44kHz.flac
 2551014 ALC892_48kHz.flac
 4632494 ALC892_96kHz.flac
11118051 Bifrost toslink_192kHz.flac
 7752605 Bifrost toslink_96kHz.flac
 8721549 Bifrost USB 96kHz.flac
 5805120 DN-C635 to Multiface II analog.flac
 2613358 headphone 44k.flac
 2791264 headphone 48k.flac
 5096341 headphone 96k.flac
 1305056 Hi Gain 24bit 44k.flac
 1405998 Hi Gain 24bit 48k.flac
 4874672 HTC one sv 1644.flac
 4954664 HTC one sv 1648.flac
  692250 imd sweep.flac
 1661020 MZ-R3 J-Test 1644.flac
 2064002 no gpu_44kHz.flac
 2189291 no gpu_48kHz.flac
 3859889 no gpu_96kHz.flac
 2504677 rca 44k.flac
 2676443 rca 48k.flac
 5714205 rca 88k asio 5ms.flac
 4838871 rca 96k.flac
 3478233 rca CD analog.flac
 9674809 rca dolby off 2496.flac
10425569 rca dolby on 2496.flac
 2328929 Result_44kHz.flac
 2420994 Result_48kHz.flac
 4837262 Result_96kHz.flac
 1994047 SMSL_48kHz.flac
 3280415 via2444.flac
 1433300 via2444spdif.flac
 3503452 via2448.flac
 1535871 via2448spdif.flac
 6628764 via2496.flac
 2459044 via2496spdif.flac

Total size:

-8
146195011 bytes

-8p
145864737 bytes

-8e
145252942 bytes

Re: FLAC v1.4.x Performance Tests

Reply #246 –
If you compress the at most 48 kHz vs > 48 kHz separately?
For 88.2 and up, my files compress to smaller size with -8e than -8p, although I see Wombat's 20 GB fare the opposite way.

Re: FLAC v1.4.x Performance Tests

Reply #247 –
I refined the list to exclude 16-bit files and digitally recorded files (SPDIF), and added more analog files that I found in my archive, so all of them are 24-bit now. 24-bit means the recording bit-depth, the playback device may only support 16-bit or has no bit-depth (e.g cassette deck).

88.2 to 192k, but mostly 96k:

-8
200533202 bytes
-8p
199737874 bytes
-8e
199401868 bytes

44 and 48k:

-8
118779872 bytes
-8p
118049531 bytes
-8e
117806233 bytes

Re: FLAC v1.4.x Performance Tests

Reply #248 –
These test files have no copyright concern so I uploaded them, I may remove them later though.
https://1drv.ms/u/s!AvzB71jO7t0-gYwqfkhypQsi5ZNCJQ?e=MIITzy
Some files are better with 8e while others are better with 8p. The archive above was encoded with --lax to reduce the upload size.

Re: FLAC v1.4.x Performance Tests

Reply #249 –
Just encoded the original digital signals...

H:\>flac -f *.wav -8e
Test signal (44 kHz 16-bit).wav: wrote 1742181 bytes, ratio=0.153
Test signal (44 kHz 24-bit).wav: wrote 2819275 bytes, ratio=0.165

H:\>flac -f *.wav -8p
Test signal (44 kHz 16-bit).wav: wrote 1820499 bytes, ratio=0.160
Test signal (44 kHz 24-bit).wav: wrote 2950729 bytes, ratio=0.173

H:\>flac -f *.wav -8
Test signal (44 kHz 16-bit).wav: wrote 1904695 bytes, ratio=0.168
Test signal (44 kHz 24-bit).wav: wrote 3007455 bytes, ratio=0.176

Looks like -e just likes clean and stable signals with a lot of empty spectral content regardless of bit-depth. Record through the analog chain will somewhat pollute these test signals, but not dirty enough to change the overall results that -e works better with these signals.