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.
Killing all relevant details makes your plugin just a kid toy.
While there is some merit for 1/3rd octave bands and 1/1st octave bands as well as the smoothing of the spectrum visualization (e.g. reducing the visual clutter) especially when you focused on the spectral trends instead, unnecessary smoothing do kill off some of the relevant details
Last post by Porcus -
There are situations where encoding speed is more important than decoding speed, and vice versa so out of curiosity: Does your methodology allow you to spend more encoding effort to decrease decoding load, without the trade-off being as skewed as "more brute-forcing"?
Last post by Porcus -
This has probably been well covered over the last nearly-nineteen pages, but: Is there any particular reason why 64-bit flac.exe should be so much faster than 32-bit?
Could you release a new version with a "-high" argument which gets a bit higher compression ratio than default but 25-50% slower compression and decompression speed?
The graph above shows the change of compression ratio since the first version of HALAC. HALAC is a speed-oriented study and the last thing I want to compromise on speed is. The lossless compression rate of audio data is really limited in most cases.
SQUEEZE CHART is an archive that also contains different types of music used in audio compression tests. It gives an idea in a general sense. Since the first version, there has been an improvement of about 1% in the compression ratio at the same speeds (encode has been slightly faster). At extremely high speeds, this is really not bad. Depending on the current situation, it is a little difficult to predict how much further progress can be made.
HIGH mode has been requested from different people before. I will focus on the compression ratio in later versions. Because I've already mentioned that there is a little more space in this regard.
I started to get interested in the compression ratio with version 0.2.6. However, I had to enter the Player and DLL topic in accordance with the incoming requests. Now, as soon as I have time, I am trying to complete the new dynamic library I have developed for HALAC in a flexible and error-free way. Changes are also made to the file structure and working style in accordance with incoming requests.
Total 15 diverse music sound samples, including highly critical samples.
Hardware: Sony PSP-3000 + AKG K712.
Results (only traditional codecs, at around 134 kbps):
Results (including AI codec at 7.5kbps, it is not a bitrate-equalized comparison):
Conclusions & Observations:
MPEG-4 xHE-AAC (eXtended High-Efficiency AAC), encoded by exhale (Ecodis eXtended High-efficiency And Low-complexity Encoder), had very high fidelity at around 134kbps, with average score over 4.5.
Ogg Vorbis, encoded by aoyumi's aoTuV beta6.03(latest version as of 2024 May), also had very high fidelity at around 134kbps, with average score more than 4.4.
It's not clear which encoder, xHE-AAC or Ogg Vorbis, was better, from this test alone. The difference was small.
Both xHE-AAC and Ogg Vorbis at around 134kbps were better than the TSAC: Very Low Bitrate Audio Compression at 7.5kbps, at its maximum bitrate setting as of 2024-04-08 version. TSAC used 94.4% less disk space, and this test not meant to be a filesize-wise fair comparison.
FRIEDMAN version 1.24 (Jan 17, 2002) http://ff123.net/ Blocked ANOVA analysis
Number of listeners: 15 Critical significance: 0.05 Significance of data: 0.00E+000 (highly significant) --------------------------------------------------------------- ANOVA Table for Randomized Block Designs Using Ratings
Source of Degrees Sum of Mean variation of Freedom squares Square F p
Surely, IIR filter bank can be made wider (lower Q parameter as there is no FFT size parameter for this filter bank-based analysis) while having larger number of bands per-octave to get a smoother spectrum with improved time resolution or responsiveness on lower frequencies (as we can't have narrow bandwidth while having good time resolution on lower frequencies at the same time obviously), try it out yourself by tinkering with "Bandwidth" parameter on my own AudioWorklet-based filter bank spectrum analyzer project
BTW, what I meant by "low detail mode" (BTW the name is borrowed from an option in Geometry Dash that improves performance on lower end PCs) is that when enabled, it tries to avoid drawing more lines if the distance between two points in pixel coordinates in terms of X-axis is within subpixel level (much like foobar2000's built-in "Oscilloscope" visualization), which makes it look more like "Line/Area graph" mode in audioMotion-analyzer than " Spectrum analyzer and spectrogram using custom FFT" especially at higher FFT size like 32768
