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: Retune of FLAC compression levels (Read 16959 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Retune of FLAC compression levels

Reply #100
has about a 4 second advantage
about a 4 second disadvantage compared to Clang when enabled.
Second ... per what? (Did you mean percent?)

With this specific file (44.1/16 - 1h 43m), I get these times on average (+/- ~0.5s) when encoding with -8p

Clang/AOCC: 48s
Clang (w/o ASM): 112s
GCC (w/ASM): 52s
GCC (w/o ASM) 44s

Re: Retune of FLAC compression levels

Reply #101
On my Ryzen 5850U, building with AOCC 4.0 is the same performance as regular Clang 16.  Building with -march=znver3 or the generic x86-64-v3 doesn't make a difference either.  For 44.1/16 audio, GCC has about a 4 second advantage with my 1.2GB file over Clang with ASM optimizations disabled, and about a 4 second disadvantage compared to Clang when enabled.

Could you please share this AOCC version? It's the official AMD compiler, I am keen on testing it.

Thank you very much.

Re: Retune of FLAC compression levels

Reply #102
by the way, geniuses, with senior audiophiles, I wasn't referring to people with ears made up of gold... I was talking about people who are senior in age, the 50-60 year old crowd which isn't as computer savvy as us and are possibly using their 2002 marantz receiver because it's dac sounds warmer to them.. pun intended.. equipment like that is not made with intel processors smh... those Motorola or other Chinese chips could indeed mess up if you give them an input or a task too complex. The same goes for car receivers which are manufactured even today, except the extreme top of the line, none of them are using the latest and greatest in processing power or their operating system. A few lines of unoptimised code in their decoding mechanism and there you have a stuttering player that cannot decode a 256mb flac file without choking thrice every minute.. I have seen this happen, literally in my brand new car or in my friend's cars... just connecting them with AirPlay through a lightning cable sometimes makes the devices hang.. which is a fact.

Maybe start using a pragmatic lens and view the reality rather than throwing slurs and bookish know-how at me. No one is siding with anti-vaxxer style audiophiles that use gold-plated ram, but rather with actual human beings who seem to be stuck with inferiorly manufactured equipment. Those equipment would still be used by these people irrespective of what you tell them because they love the sound that the device is creating from other mediums and they'd rather not replace their beloved DAC just because they cannot get it to play some huge file properly. Same goes for car receivers, the airplay may very well not work in my car, but it is integrated really well with all the sensors present inside, due to which, no matter what anyone tells me, I'm not gonna change that device just because it performs poor in one area. There are other things to consider as well. That's what a practical view is. Tell me which part of this does not strike true in the real world. Rather than slurring or mocking a genuine perspective, maybe develop some patience and humility. Certain devices like these which are integrated have various other limitations as well, for instance, only supporting SATA1.0 hard drivers or the older IDE hard drives. Try doing benchmarks on such trash equipment. Seeking a file would crash you out in seconds. Yet these machines remain heavy in use because barring the particular problematic aspect, they perform reliably and excellently in all other facets.

No one is saying that your work is trash or that the audiophiles that behave like karens are right, rather all I'm saying is treat some of them with respect because even they have genuine points at times. Going all psycho on them is neither a pragmatic nor a humble way to treat anyone.

All of the above is not some fairytale or highly specific text book style example that has no relevance to the real world, but is literally a bunch of incidents that I keep striking with every now and then.. which is why some points do seem valid to me, and by now, hopefully to you as well.

I'm done posting on this particular facet, irrespective of whatever I just said about humility, I know that talking this further would only escalate it to hostile levels, which is clearly not my goal here. So I'm done talking about this topic.

Peace
If you have to mention IDE harddrive, the earlier ones using PIO are more like under 1GB, and my first Ultra DMA IDE harddrive was a 6.4GB IBM one. They are just too small for anything lossless, even >192kbps lossy was a luxury. In that era I just burn CDR for big files, with a SCSI PlexWriter using caddy. All of these products were released before the born of flac (pre-2000).

The last IDE HDD I had was a 120GB one and the first SATA HDD I had was a 160GB one, both are Seagate 7200rpm. In practical usage regarding lossless audio playback I couldn't find any difference and they definitely didn't have any issue when running benchmark and the benchmark results were comparable to what other online reviewers (e.g. Tom's hardware) got. The bad news is the SATA one started to get bad sector after 3 years of use, right after warranty period, yet the 120GB one lasted for like ten years, or until I bought a newer motherboard that no longer has any IDE connector.

The real issue of these harddrives is when they get really fragmented and when they are nearly full. In these cases they have high chance to choke. The whole thing has nothing to do with the transfer interface speed except when doing benchmark with sequential transfer backed by the drive's RAM buffer. Even the current 4TB HDD I have only has a sequential transfer of 190MB/sec or so, far below SATA3's slow (600MB/sec) interface speed. In actual use HDD generally can't constantly maintain maximum sequential speed so one can expect choking when doing things like editing uncompressed HD video, but those are skyrocket bandwidth compared to audio, even for things like 768kHz PCM or DSD1024.
 
And if you got unexpected freeze or crash it is not because the hardware is slow, it is not like Bill Gate's demo PC was intentionally made crappy to trigger a BSOD, it is just compatibility issues and bugs.
https://youtu.be/IW7Rqwwth84

In mid-late 90s when I fiddled with 3D Studio MAX, with the same hardware (Pentium 133, 80MB EDO RAM, 3DLabs Permedia 2 8MB PCI display card), Windows 95 just doesn't have enough "system resources" for 3D Studio MAX's highly complicated GUI. No matter how good your hardware specs are, Windows 95 still ran out of "GDI resources" because it is the OS's software limitation. At the time Windows NT4 had higher baseline (installation) requirements than Win 95, but the very same PC had no issue when running 3D Studio MAX. 80MB RAM was quite a lot in that era and the mainstream was like 32MB, but regardless of RAM size, Windows 95 just got unresponsive when GDI resources ran out, and it had nothing to do with the GPU's OpenGL specs and such because the GPU has nothing to do with the program's very complicated GUI with a lot of buttons, drop down boxes, dialogs and such.

https://www.techrepublic.com/article/monitor-windows-9x-me-system-resources-with-the-resource-meter/

So people have to realize where the limitations are. Performance and reliability are very different concepts, they may, but not always coexist.

Re: Retune of FLAC compression levels

Reply #103
On my Ryzen 5850U, building with AOCC 4.0 is the same performance as regular Clang 16.  Building with -march=znver3 or the generic x86-64-v3 doesn't make a difference either.  For 44.1/16 audio, GCC has about a 4 second advantage with my 1.2GB file over Clang with ASM optimizations disabled, and about a 4 second disadvantage compared to Clang when enabled.

Could you please share this AOCC version? It's the official AMD compiler, I am keen on testing it.

Thank you very much.

It seems AOCC is only available for 64-bit Linux.  I don't think I can build for Windows with it either (With GCC, I have to use MinGW to make Windows binaries).  If you're running Linux, I could share the FLAC binaries built with AOCC.

 

Re: Retune of FLAC compression levels

Reply #104
@ktf : Did the retune build do something to the algorithm that selects between apodization functions too?
Asking because I sometimes get a notable difference between 1.4.2 and retune. I didn't say significant in the sense that one should care about it, but of course way more than the seven bytes implied by the vendor string.


As for this:

* Going full -l32 on high sampling rates:
My first reaction was, this will shock those who use "-8e", I checked one high-resolution file that now takes 4x the time of 1.4.2. That is even if the reduced number of apodization functions speeds up -8el12 to half the time of 1.4.2.

But the thing is, -e still has a mission on some high sampling rates, that is the problem. At least it had on 1.4.2, I'll test this one

To take this a bit I ran a five minutes long stereo stupid-resolution 384/32 file (download link), same as mentioned here. FLAC can compress it to below 40 percent of WAVE, yay.  -l32 makes for bigger files (at three-ish times the time consumption!) but that is not the point here: the point is how the proposed -8 will likely get you complaints from -e users:
at -l 12, a "-e" increases time by a factor of five-ish; at -l 32, the "-e" increases time by a factor of 11-ish

(Actually -8el32 encodes slower than realtime on an i5 CPU. Even the retune, which is three times faster due to ... stepping down the subdivide_tukey I guess?)

-e has its merits at this sample rate: 1.4.2 at -8 vs -8e, the latter saves 7% file size. Would be good if the new order selection algorithm could do something about it - it is easier to reply "then don't use -e" if you can point at it not doing much anymore.

Re: Retune of FLAC compression levels

Reply #105
To take this a bit I ran a five minutes long stereo stupid-resolution 384/32 file (download link), same as mentioned here. FLAC can compress it to below 40 percent of WAVE, yay.  -l32 makes for bigger files (at three-ish times the time consumption!) but that is not the point here: the point is how the proposed -8 will likely get you complaints from -e users:
at -l 12, a "-e" increases time by a factor of five-ish; at -l 32, the "-e" increases time by a factor of 11-ish

(Actually -8el32 encodes slower than realtime on an i5 CPU. Even the retune, which is three times faster due to ... stepping down the subdivide_tukey I guess?)

-e has its merits at this sample rate: 1.4.2 at -8 vs -8e, the latter saves 7% file size. Would be good if the new order selection algorithm could do something about it - it is easier to reply "then don't use -e" if you can point at it not doing much anymore.
I didn't download but from the file name I think it is one of the files from this website:
https://samplerateconverter.com/free-audio-downloads
IIRC they are some really crappy quality junior MIDI sequencing stuff that makes -e shine. Generally things recorded through a mic and delta sigma ADC would have more high frequency noise which make -e much less effective and you can use some cheaper -A options to get better results.

Re: Retune of FLAC compression levels

Reply #106
Yes it is from there. I was a bit reluctant to giving it publicity ...

So the size impact of -e was a bit spurious - also indicated by what WavPack does: -hhx4 takes one third off the -hhx size.
On the other hand, all files this resolution have "weird" content. And since -e often does a job at those big Hz'es, I suspect there will be users who routinely throw it in, and they might be in for some surprises by the time impact.

Another example: the 768 kHz Sound Liaison / Carmen Gomes publicity stunt. retune build on some i5:
15 seconds for -8l12
55 seconds for -8el12 so a factor of nearly 4
30 seconds for -8 = -8l32, so -l32 doubles the time
438 seconds (!) for -8e = -8el32.

... size impact here? Fifty parts per million.

Re: Retune of FLAC compression levels

Reply #107
I think it is a perfect example to explain where MQA's money has gone: Pay some money so that you can use some better quality music files as demo. Talented musicians can make good music with toy-grade equipment:
https://keenonkeys.bandcamp.com/

For this "Wait for Spring", or "Wait for -e and -l32" on flac 1.4.2:
-8 -b16384 -A "subdivide_tukey(5);blackman;gauss(1e-2);flattop"

Basically, a set of narrower windows to deal with the mostly empty ultrasonic range.