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
Site Related Discussion / Re: Please remove my account
Last post by 2012 -
Quote from: Brazil2 on
Nice complotist vocabulary.

Are you trying to out-drama the OP?

Quote
When some people have a different opinion than yours it's not propaganda, it's just a different opinion.

What do you think propaganda means?

It's just the organized/proselytized form of "different opinion".

It's not even necessarily wrong or evil.

Those who want words like "propaganda" and "agenda" to be automatically negatively-connoted, are the same who want to enjoy a monopoly of their use.
8
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Porcus -
Quote from: ktf on
I think it has to do with the extensive checks that have been added to FLAC 1.4.0 for handling corrupt audio.
Fair enough if so.
(I thought of that possibility, but it didn't strike me as something that should depend on the number of blocks. Like, if you decode something that exceeds 16 bit when it shouldn't, I was thinking that you probably check that per sample. But what do I know.)
9
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by ktf -
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.

Quote from: Porcus on
1.3 is much faster at the small block sizes! At the very smallest, 17 samples, it decodes at at 22 seconds, 1.4 needs 40, 1.4 32-bit needs 60. That is a little bit of difference?!
I think it has to do with the extensive checks that have been added to FLAC 1.4.0 for handling corrupt audio. Also, I think the binary is currently too fat, so it impacts branch prediction, which is most profound on small blocksizes.