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.
Recent Posts
2
Listening Tests / Re: Personal blind sound quality comparison of xHE-AAC, Ogg Vorbis, and TSAC
Last post by Julien -
Quote from: Julien on
Thanks a lot Kamedo for yet another very interesting listening test.

Nice to see Vorbis being tested and yielding quite impressive results in the ~128kps range. Is there any particular reason why you chose Vorbis in this test?
Quote from: Kamedo2 on
Quote from: Julien on
Nice to see Vorbis being tested and yielding quite impressive results in the ~128kps range. Is there any particular reason why you chose Vorbis in this test?

Because it hasn't been tested for some years.

This is a great idea. Thanks a lot for your hard work.
3
3rd Party Plugins - (fb2k) / Re: foo_skip: skip tracks that match a specified search query
Last post by Sergey77 -
Quote from: Case on
@Sergey77 - new version released with the bookmarking fix. Also contains some other small changes, including behavior change for automatic DSP insertion that ApacheReal complained about.
Case, I tested it. In the new version, these components work fine for these items. Thank you!
Are you planning to add "Add Skip Track bookmark" to the right-click context menu? - other component commands are already there, it would be convenient.
7
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by cid42 -
Quote from: ktf on
Quote from: cid42 on
There should be intel CPU's late this year with APX at earliest.
And fragmentation continues. AVX10 is hailed to "clean up the mess of AVX-512" but all I see is even more fragmentation. flac on x86 will be an incredibly fat binary with SSE2, SSSE3, SSE4.1, AVX2, AVX512 and AVX10 code paths. Because while Intel is dropping AVX512 for AVX10, AMD just started on AVX512 and CPUs without any AVX are still being sold, so it is not like SSE can be dropped anytime soon.

APX is mostly unrelated to AVX10. Being a general core improvement instead of another SIMD category I quite like the idea of APX, it seems long overdue. But it does beg the question, can you have a fat binary containing both an APX and x86_64-non-APX path? I've just assumed there'll have to be 3 binaries, x86 x86_64 and APX. With luck it's not as fragmented as it sounds, anything with APX should have AVX10.256 or AVX10.512 right? Surely...

For intel AVX10 is about hitting the snooze button on SIMD given that they failed to make AVX512 good for years to the point that AMD ate their lunch with Zen4. Technically AVX10 256 bit is superior to AVX2, however all projects for which SIMD is relevant already have an AVX2 path so its impact will be minimal for many years. There should be some workloads that do benefit, the same ones that already benefit from AVX512 for the non-512 bit additions it has.

For full coverage there would have to be an AVX10.256 and AVX10.512 path, although OTOH I can't remember if there's much difference between AVX10.512 and AVX512. Thanks intel, clearly this wasn't an obfuscating table flip move at all. At least the AVX10.256 path can probably be adapted relatively easily from the AVX512 or AVX10.512 paths, in the same way anything prior to and including AVX2 follow the same kind of patterns.

intel CPU's haven't had a very good half decade really. They're screwing up SIMD, heterogeneous CPU's are IMO a mistake at least the way they're doing it, the CPU's run at insane power draw OOTB which is starting to prematurely degrade the latest generations all to gain a few poxy points in benchmarks. Not exactly ideal.
9
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Replica9000 -
Quote from: ktf on
Also, I think the binary is currently too fat, so it impacts branch prediction, which is most profound on small blocksizes.

Too fat in binary size or amount of code?  For me, FLAC built with GCC 12.x produces the smallest binary, and at least on my system has the best performance, even if by a very small amount.

Static binary size for x86_64:
 GCC-11 = 701.4k
 GCC-12 = 689.4k
 GCC-13 = 733.4k
 GCC-14 = 733.4k