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
4
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Porcus -
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.)
5
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by ktf -
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.

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.
7
Listening Tests / Re: Personal blind sound quality comparison of xHE-AAC, Ogg Vorbis, and TSAC
Last post by C.R.Helmrich -
... I think it would be more useful if:

* Samples used in tests are not handpicked for being challenging, but picked for being representative of average everyday use (talk show, pop music, ..etc).

* Classical codecs are tested at a much lower bitrate than in this test. Maybe a something in the range of 32-48kbps.

Fair points which generally apply to the design of blind listening tests, but (1) the handpicked critical samples are challenging for classical audio codecs* - notice how no sample really stands out with a particularly bad score for TSAC, (2) we have several blind tests of classical codecs at 32, 40, and 48 kbps by Kamedo2 and guruboolez - even there, the scores average way above 2.0 IIRC.

* The most challenging content for AI codecs that I know of, Glockenspiel and triangle, isn't included in Kamedo2's test(s), by the way.

Chris
9
Support - (fb2k) / Re: Foobar2000 v2.* playback sound quality lower than v1.X
Last post by fooball -
The sound quality of Foobar2000 2.X is lower than version 1.X...

To underline the point: go to the toolbar at the top of every Hydrogen Audio forum page and click "Terms of Service" (ie the forum rules), then scroll down to TOS 8:

Quote
All members that put forth a statement concerning subjective sound quality, must - to the best of their ability - provide objective support for their claims.  Acceptable means of support are double blind listening tests (ABX or ABC/HR) demonstrating that the member can discern a difference perceptually, together with a test sample to allow others to reproduce their findings.  Graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable means of providing support.