HALAC (High Availability Lossless Audio Compression)

Topic: HALAC (High Availability Lossless Audio Compression) (Read 17678 times) previous topic - next topic

Procrustean and 1 Guest are viewing this topic.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #75 – 2024-02-19 07:51:56

In a different forum, detailed tests on HALAC 0.2.6's compression ratio improvement and multithread performance can be found at the following link.

https://encode.su/threads/4180-HALAC(High-Availability-Lossless-Audio-Compression)?p=82158&viewfull=1#post82158

I would be happy for the dear members of this forum to do different tests as well (before switching to 24 bits audio). After all hydrogenaud.io it is a forum site specializing in audio.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #76 – 2024-02-20 00:25:36

Compared sizes of 0.2.4, 0.2.5 and 0.2.6 on the same 38 CDs.
0.2.6 does better overall, but not on the heavier part of the corpus, where it was worst on 8 of ten albums (both in normal and fast).

"&" to separate "normal & fast":

* 0.2.4 was never smallest. 0&0 of the 38&38 albums. It compressed worst on 21&21 and in total, but not on the ten heavier albums.
* 0.2.5 was smallest on 18&17 albums, and on the heavier corpus (beating 0.2.6 by 0.17&0.23 percent). It never compressed worst.
* 0.2.6 was smallest on 20&21 albums, and on the two other corpi: beating 0.2.5 by 0.77&0.19 percent at classical and 0.24&0.54 percent on the "other" genres.

For the ten heavy synth/rock/metal albums,
8+7: 0.2.6 was worst and 0.2.5 best.
0+1: 0.2.6 was worst and 0.2.4 best, although all within 0.015 percent.

I realize that the above is percent and the following are percentage points ... anyway you will get the idea.

Most significant impact from 0.2.6 - on all these, 0.2.5 and 0.2.4 were about the same:
From testing on FLAC, the two shortest ones - the Jordan Rudess EP and Wovenhand - could make big differences. So they did here: > 2.1 percentage points on normal mode, > 1.8 percent in fast.
Then a few where you got 0.8 to 1 percentage point-ish improvement:
Bach (Organ), Bruckner, Mozart, Vivaldi (normal; fast was ~half of that)
In fast only: Jan Johansson and Kraftwerk

Don't know what to take home from this.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #77 – 2024-02-20 10:44:20

Thanks for your concern, Porcus.
According to the latest tests, the speed of "HALAC-Normal" and "HALAC-Fast" remained almost constant. But there have been some improvements in compression ratios. I should point out that trying to increase the compression ratio more when working at these speeds is an extremely difficult thing. However, there is still some more space that can be compressed. I'm trying to close this gap without compromising on speed.

I didn't get any feedback from here about Multithread. So I understand that in this case the tests I have done and my results have been accepted. There are already tests that have been done by others on the link in the previous post. HALAC works quite efficiently depending on the number of threads.

Below is a test performed by a different source ( @a902cd23). Even if the thread count is 24, it seems that the processor does not get a full load. In this case, faster results can be achieved by increasing the number of threads.

Code: [Select]

Intel 13700k on ramdisk, 16 core, 24 thread
F540AC6E.wav : 1,062,989,800 bytes

          Normal encode        Fast encode          Normal decode        Fast decode
thread 1  Elapsed: 0:00:02,74  Elapsed: 0:00:01,61  Elapsed: 0:00:04,01  Elapsed: 0:00:03,26
thread 2  Elapsed: 0:00:01,92  Elapsed: 0:00:01,07  Elapsed: 0:00:02,34  Elapsed: 0:00:02,05
thread 3  Elapsed: 0:00:01,41  Elapsed: 0:00:00,80  Elapsed: 0:00:01,61  Elapsed: 0:00:01,42
thread 4  Elapsed: 0:00:00,93  Elapsed: 0:00:00,70  Elapsed: 0:00:01,24  Elapsed: 0:00:01,14
thread 5  Elapsed: 0:00:00,79  Elapsed: 0:00:00,62  Elapsed: 0:00:01,08  Elapsed: 0:00:00,93
thread 6  Elapsed: 0:00:00,68  Elapsed: 0:00:00,55  Elapsed: 0:00:00,93  Elapsed: 0:00:00,86
thread 7  Elapsed: 0:00:00,62  Elapsed: 0:00:00,52  Elapsed: 0:00:00,85  Elapsed: 0:00:00,76
thread 8  Elapsed: 0:00:00,66  Elapsed: 0:00:00,49  Elapsed: 0:00:00,78  Elapsed: 0:00:00,70
thread 9  Elapsed: 0:00:00,65  Elapsed: 0:00:00,48  Elapsed: 0:00:00,76  Elapsed: 0:00:00,71
thread 10 Elapsed: 0:00:00,64  Elapsed: 0:00:00,48  Elapsed: 0:00:00,77  Elapsed: 0:00:00,70
thread 11 Elapsed: 0:00:00,64  Elapsed: 0:00:00,47  Elapsed: 0:00:00,71  Elapsed: 0:00:00,67
thread 12 Elapsed: 0:00:00,60  Elapsed: 0:00:00,46  Elapsed: 0:00:00,68  Elapsed: 0:00:00,63
thread 13 Elapsed: 0:00:00,60  Elapsed: 0:00:00,44  Elapsed: 0:00:00,69  Elapsed: 0:00:00,62
thread 14 Elapsed: 0:00:00,57  Elapsed: 0:00:00,46  Elapsed: 0:00:00,65  Elapsed: 0:00:00,60
thread 15 Elapsed: 0:00:00,53  Elapsed: 0:00:00,40  Elapsed: 0:00:00,63  Elapsed: 0:00:00,57
thread 16 Elapsed: 0:00:00,54  Elapsed: 0:00:00,40  Elapsed: 0:00:00,63  Elapsed: 0:00:00,57
thread 17 Elapsed: 0:00:00,52  Elapsed: 0:00:00,42  Elapsed: 0:00:00,60  Elapsed: 0:00:00,58
thread 18 Elapsed: 0:00:00,51  Elapsed: 0:00:00,40  Elapsed: 0:00:00,59  Elapsed: 0:00:00,57
thread 19 Elapsed: 0:00:00,48  Elapsed: 0:00:00,38  Elapsed: 0:00:00,58  Elapsed: 0:00:00,55
thread 20 Elapsed: 0:00:00,45  Elapsed: 0:00:00,40  Elapsed: 0:00:00,55  Elapsed: 0:00:00,53
thread 21 Elapsed: 0:00:00,47  Elapsed: 0:00:00,41  Elapsed: 0:00:00,53  Elapsed: 0:00:00,53
thread 22 Elapsed: 0:00:00,44  Elapsed: 0:00:00,37  Elapsed: 0:00:00,52  Elapsed: 0:00:00,53
thread 23 Elapsed: 0:00:00,42  Elapsed: 0:00:00,37  Elapsed: 0:00:00,54  Elapsed: 0:00:00,53
thread 24 Elapsed: 0:00:00,41  Elapsed: 0:00:00,39  Elapsed: 0:00:00,51  Elapsed: 0:00:00,51

428 705 658  F540AC6E.hal
507 805 612  F540AC6E.fast.hal

Re: HALAC (High Availability Lossless Audio Compression)

Reply #78 – 2024-02-20 13:23:35

Quote from: Hakan Abbas on 2024-02-20 10:44:20

According to the latest tests, the speed of "HALAC-Normal" and "HALAC-Fast" remained almost constant. But there have been some improvements in compression ratios.

Yeah, except for metal music it seems - then it became worse.
It is not just about "dense music with high bitrate", because the Mahler's big orchestra symphony did improve.

Quote from: Hakan Abbas on 2024-02-20 10:44:20

I didn't get any feedback from here about Multithread.

I have not yet been able to run (reliable) speed tests, sorry.

Question: I understand that -mt=7 means seven "worker" threads + one "bookeeping" thread? My CPU is 4 cores 8 threads.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #79 – 2024-02-20 18:07:35

HALAC's multihread mode works a little differently. In fact, the thread numbers do not exactly reflect the threads. My previous work HALIC is much more greedy(autothread). It works at full capacity, but it also consumes a lot of system memory. I wanted to do something much less memory-consuming for HALAC. Because it should have been able to work even in the lowest systems. And I really liked the result.

HALAC redirects the data to be compressed to the specified number of threads in sequence. I say sequentially because the read/write operations from the file should be sequential for security reasons. In this case, since HALAC is already very fast, some threads may finish their tasks early. This also leaves a little rest allowance for the processor.

If this is not desired, that is, if we want to use the processor at full capacity as much as possible, we may need to set the thread number above the normal one. However, on very powerful processors and disks, this may not be necessary. We have seen this in some tests.

If we think according to the processor above (i7 13700k, 16 core, 24 thread), 60% of the processor has been used yet. So there is a little more space that needs to be used. For example, different results occurred on 5 different computers that I use. the i7 3770k(4-core, 8-thread) performed best on the system at 16 threads, the Ryzen 7 3700x(8-core, 16-thread) performed better at 64 threads, and the i7 9700k (8-core, 8-thread) performed better at 32 threads. You can try the most efficient situation according to the computer used. If in the normal case it is enough to set up the number of threads of the processor.

However, it should be remembered that the data to be tested should be one piece and large in order to get accurate results. 1 gb and more.

Code: [Select]

Ryzen 7 3700x(8-core, 16-thread), ~3 gb wav data
HALAC-Normal 16 thread encode time : 2.845
HALAC-Normal 128 thread encode time: 2.326

Left image is 16 Threads and right image is 128 Threads

Re: HALAC (High Availability Lossless Audio Compression)

Reply #80 – 2024-02-24 07:36:01

Finally had the computer free to run a rough multithreading timing. Encoding, normal mode. i5-1135G7, 8 threads on 4 cores, fanless computer.

* Graphed: median over three runs, and then the bars are standard deviation among the three.

* Run "from hot": three warm-ups discarding the timing, and then timed three. That might not have been enough on this computer:
Because -mt=10 was run first, the CPU might not have started throttling until 0.2.6 at -mt=9.

* Order: FOR threads in (10, ..., 0) <--10 first
DO FOR versions 0.2.4, 0.2.5, 0.2.6 in that order
DO encode the 38 CDs six times (deleting *.halac in between)

But it is hard to interpret without knowing how much it actually takes from each thread.

Sooo ... if I were to do this in fast mode, I don't even know if the relevant is to run it over a long time first to reach some thermal equilibrium numbers, or to let it cool down for a couple of minutes in between?

Re: HALAC (High Availability Lossless Audio Compression)

Reply #81 – 2024-02-24 11:34:34

Thank you, Porcus.

You just need to use 0.2.6. It is more stable and does not differ much from others in terms of speed. (mt=0 and mt=1 are the same)
Since HALAC is extremely fast and each track of music is processed separately, the processes end quickly. Therefore, it is impossible to go further when processing music tracks with an average size of 40-50 mb. In other words, the processed data fragments remain small. In my tests, the total processor usage is around 30% with an average acceleration of 2x. This is parallel to your results. In such cases, it can be worked much more efficiently by sending each music track to a separate thread.

Therefore, it is more appropriate to test on one piece of large music (1gb and over). If possible, you can make one or several CDs into one track and do the tests that way. And you can force HALAC up to 16 or even 32 threads on your processor.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #82 – 2024-02-24 11:54:07

Ah. 1 and 0 are the same, and the likely reason they took more time run with 0.2.4 and 0.2.5 is that the processor was still cooling down after -mt=2.
If so: I see the first timed 0.2.6 -mt=1 run was down in time while the last 0.2.5 was not, so it took six to nine of those runs to reach a thermal equilibrium where it would clock up again. That's 10 to 15 minutes. Of course, cooling down idle woud be quicker. But this is what I get for a fanless computer. I got what I paid for, and that was not reliable timing ...

Quote from: Hakan Abbas on 2024-02-24 11:34:34

Therefore, it is more appropriate to test on one piece of large music (1gb and over).

Up to 4 GB works in WAVE, but for later maybe support the RF64 and BW64 extensions to the WAVE format, to allow > 4 GB?
https://hydrogenaud.io/index.php/topic,123862.msg1036523.html#msg1036523 , replies forty-something: BW64 is set to obsolete RF64.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #83 – 2024-02-24 12:58:35

Yes, the WAV format has a 4GB restriction. However, the size of the file does not matter much for Halac. To do this, I can use the Libbw64 library in subsequent versions. You can perform your tests with WAV files below 4 GB.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #84 – 2024-02-24 18:17:48

@Hakan Abbas, by the way, I tried to use HALIC of yours, and it refused to work on my end for the same reason as HALAC. It remains a mystery to me how you managed to talk through 77 pages up to version 0.7.1 and ignore the pool of users without modern processors, whereas WEBP and JXL have no such restrictions and serve well. Perhaps you'll find a way to upload a binary there that does not require AVX instructions set.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #85 – 2024-02-24 19:25:08

@Kraeved Codecs developed by certain teams (Google, Cloudinary, Apple, AOM), such as WebP, AVIF, HEIF and JXL, work by choosing according to the processor architecture (SSE, AVX, AVX2). Of course, this option could have been added, but it was slightly behind in the order of priority. Because it really wasn't easy for me (speed/ratio/memory/mt) to cope with such powerful image codecs.

HALIC can run a little faster when compiled in AVX2 mode. However, despite the request, I did not do this in order to support slightly older architectures. I thought AVX (2011) would be enough. But until now, such a request had come from outside of you. However, it only takes me a few minutes to prepare a version for older processors. You can access the SSE2 version I compiled for HALIC from the link below.
https://github.com/Hakan-Abbas/HALIC-High-Availability-Lossless-Image-Compression-/releases

HALIC is by far the best Lossless Image Codec according to "F_Score (universal score)".
F_Score = C+2·D+(S+F)/10⁶
"Here, C and D are respectively the total compression and decompression execution time (in seconds), S is the total compressed size in bytes, and F is the submission packet size."

Re: HALAC (High Availability Lossless Audio Compression)

Reply #86 – 2024-03-01 08:00:52

Quote

It remains a mystery to me how you managed to talk through 77 pages up to version 0.7.1 and ignore the pool of users without modern processors, whereas WEBP and JXL have no such restrictions and serve well. Perhaps you'll find a way to upload a binary there that does not require AVX instructions set.

AVX has existed since Sandy Bridge, a 2011 CPU. I truly don't see how that's a problem.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #87 – 2024-03-01 08:37:47

Quote from: mudlord on 2024-03-01 08:00:52

AVX has existed since Sandy Bridge, a 2011 CPU.

Yes, but Intel also launched Tremont in 2021, which still lacked it. These CPUs are still actively being sold today. You could encounter them in HTPCs, which are certainly being used to decode audio.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #88 – 2024-03-01 11:35:40

Quote from: mudlord on 2024-03-01 08:00:52

AVX has existed since Sandy Bridge, a 2011 CPU. I truly don't see how that's a problem.

“There are more things in Heaven and Earth, Horatio, than are dreamt of in your philosophy” (Hamlet 1:5).

As Shakespeare accurately observed several centuries ago, the world is much more complicated than it seems. Are you aware that thousands of people in the UK are dying from the cold? Please note, this is not a former African colony or a place where the Americans brought democracy with bombs and coups. Also, do you know that the wealthy author of Game of Thrones writes in a DOS editor? The point is that upgrading equipment is not only a challenge for some people (more about that in 'Design for the real world' the book by an engineer Victor Papanek), it may not be a priority at all, since it works well enough for current needs and is in no hurry to become a waste (more about that in 'Samsara' the docufilm by Ron Fricke). Think about MD5 hashing algorithm, which is still used to verify audio data, while the progress, whatever that means, suggests using xxHash and Blake3. And what is AVX? It is an optimization to calculate underlying math faster and a way to beat the competitors in a synthetic benchmark, not a solution per se, whereas the world needs solutions first, i.e. widely accessible tools to ease the burden. FLAC and WavPack are two good examples of how an intellectual breakthrough can go hand in hand with humanitarian values.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #89 – 2024-03-01 13:48:21

It is kinda up to the author/developer to define goals, and sure if the purpose is to impress enthusiasts with the fastest possible encoding and decoding then why leave weapons on the table. And this has been impressive yeah.

But uses for an ultra-lightweight codec developed in 2024 - what would that be?
Suggestion: canned audio with low-power CPU on chip? In which case, sure post optimized compiles, but at least make one that works with "nothing sophisticated"?

FWIW, Intel's most recent Atom launch - one year ago - were these two CPUs, without AVX: 6W dual core and 9W quad core. More likely to be used in products like this than anything else, sure.
(No AVX ... but no nothing?)

Re: HALAC (High Availability Lossless Audio Compression)

Reply #90 – 2024-03-01 17:59:48

Quote from: Porcus on 2024-03-01 13:48:21

(No AVX ... but no nothing?)

Those two Atom CPUs have Tremont cores, which support all the usual SSE instructions (minus AMD's SSE4A), plus the new GFNI SSE instructions. One of those new instructions, GF2P8AFFINEQB, can accelerate all kinds of calculations. I wouldn't be surprised if HALAC is already using its AVX counterpart.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #91 – 2024-03-01 20:02:10

Code: [Select]

Busta Rhymes - 20 tracks - 829,962,880 bytes
Amd Ryzen 5825u, Encode and Decode Times
HALAC Normal AVX2 : 2.309 s, 3.621 s
HALAC Normal AVX  : 2.445 s, 3.429 s
HALAC Normal SSE2 : 3.084 s, 3.494 s
HALAC Normal SSE  : 3.130 s, 3.497 s

HALAC Fast AVX2 : 1.451 s, 2.780 s
HALAC Fast AVX  : 1.511 s, 2.995 s
HALAC Fast SSE2 : 1.756 s, 3.045 s
HALAC Fast SSE  : 1.751 s, 3.048 s

I hadn't done such a test before, but it was an interesting experience. According to these results, different command sets can have small positive and negative effects. It can be tried in SSE2 and AVX versions. However, there was no significant change as a result of the automatic vectorization of the compiler without manual SIMD operations.

For example, "HALAC Normal AVX2" lagged behind the others in the decode process. This is not normally expected. Probably, HALAC can be further accelerated by manual SIMD optimization. I am also considering HALAC for a wider use area, not narrow. My work on HALAC continues. It is only 4 months old.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #92 – 2024-03-22 20:17:47

Ran HALAC through one of my stupid-signals tests over at https://hydrogenaud.io/index.php/topic,125607.0.html . Not the upsamples, but the pitch shifted ones.
All are "nominally CDDA", but pitch shifted (preserving tempo) - created to emulate a lot of the same situation, signals lacking the top octave to the top 3+ octaves. The legend is the max frequency. For more description, see that thread.

It is hard to represent this without it getting turning into a mess, but log scale of file sizes gives reasonably close to straight lines. Numbers are compression ratio relative to WAVE:

You see that as the signals miss treble, HALAC fast is losing out - only moderately though - until "overtaken" for last spot by ffmpeg's WavPack encoder. HALAC normal keeps up against FLAC's fixed predictor scheme for ~an octave pitch shift, but not at all for two - but then, the fastest FLAC is surprisingly good.

So here I do everything relative to FLAC -0b4096 -r0; this is not log scale. 1.5 means 50 percent larger than FLAC, 0.75 means 25 percent smaller.

Horizontal lines means it "keeps its ratio to FLAC's fixed predictor size". You see HALAC normal does that in the beginning - and the simplest TAK and the most brutally slow ALS do that in the end.

This is obviously not WavPack-friendly material. Although nowhere near the upsamples, the impacts are huge: changing from WavPack to TAK usually doesn't halve the file size - but even still, there are so many that cluster up around fixed-predictor FLAC in the end.

(Why I used those extra parameters on -0? -b4096 for an apples to apples comparison to the same block size that the others use. -r0 to make sure I didn't get any too good results from that clever partitioning trick.)

Re: HALAC (High Availability Lossless Audio Compression)

Reply #93 – 2024-03-23 07:30:44

This was a good test, Porcus. You are really doing this sport

I have had to take a break to HALAC a little bit lately due to my different work intensity.

HALAC does not use a fixed estimator yet. That's why sometimes he can act quite aggressively. This situation is seen in your tests.
Fixed estimators give really good results in special cases. For example, the sample wav file on the "https://hydrogenaud.io/index.php/topic,125248.msg1038859.html#msg1038859" link can be compressed up to 397 kb with just one fixed estimator. It is really very difficult to get down to this size with other methods.

However, in the general case, the effect of fixed estimators cannot be noticed. That's why I didn't need to do calculations specifically for fixed estimators. Because every intervention made brings an extra processing load. I try to be as careful as possible not to compromise the speed. Because in ultra-fast situations, our hand is locked most of the time.

A slightly better version may come soon as a speed/compression ratio. And in this version I can now also use some fixed estimators for special cases. The new entropy coding phase that I will add in this version will be quite important. I just want to be absolutely sure about some things.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #94 – 2024-04-04 08:33:02

I have shared these results before, but since it was in the "News" title, the results of HALAC were removed.

Code: [Select]

AMD Ryzen 3700x (8 core, 16 thread)
Single Part Wav: 2,577,542,764 bytes

WAVPACK Normal Thread-1: 34.84 s, 30.45 s, 1,617,702,120 bytes // wavpack.exe --threads=1 input output
WAVPACK Normal Thread-12: 9.22 s,  5.88 s, 1,617,400,684 bytes // wavpack.exe --threads=12 input output
WAVPACK Fast Thread-1: 29.01 s, 26.29 s, 1,652,567,206 bytes // wavpack.exe --threads=1 -f input output
WAVPACK Fast Thread-12: 7.74 s,  5.55 s, 1,652,389,896 bytes // wavpack.exe --threads=12 -f input output

HALAC Normal Thread-1:  8.571 s, 11.580 s, 1,669,302,550 bytes // halac.exe input output -mt=1
HALAC Normal Thread-12: 2.225 s,  2.553 s, 1,669,302,550 bytes // halac.exe input output -mt=12
HALAC Normal Thread-32: 1.789 s,  2.253 s, 1,669,302,550 bytes // halac.exe input output -mt=32
HALAC Fast Thread-1:  5.095 s, 9.895 s, 1,755,209,521 bytes // halac.exe input output -fast -mt=1
HALAC Fast Thread-12: 2.074 s, 2.547 s, 1,755,209,521 bytes // halac.exe input output -fast -mt=12
HALAC Fast Thread-32: 1.959 s, 2.132 s, 1,755,209,521 bytes // halac.exe input output -fast -mt=32

I can run HALAC faster in multithread mode (autothread). Like this HALIC, it only consumes a little more memory. Below is the processor usage cases for 12 threads. HALAC is much less loaded on the processor.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #95 – 2024-04-04 10:51:15

Quote from: Hakan Abbas on 2024-04-04 08:33:02

I have shared these results before, but since it was in the "News" title, the results of HALAC were removed. I can run HALAC faster in multithread mode (autothread). Like this HALIC, it only consumes a little more memory. Below is the processor usage cases for 12 threads. HALAC is much less loaded on the processor.

Or the results were removed because HALAC is still the intellectual fun of its creator, and not a solution for the masses. Why don't the latter include this encoder in their comparisons, is it because they are unaware of its existence? But how can you miss an encoder whose executable name, including the extension, is capitalized? The trouble is that encoded files cannot be listened to, let alone edited, they can only be stored. The album of your favorite artist first needs to be unpacked, i.e. to take up a significant free space. A place in the hall of fame is earned not by charts illustrating your mathematical agility, but by bringing relief to our earthly vale of tears, as @bryant of WavPack has been doing for years. And the longer you stay at an academic distance, away from the daily torments and hopes of the masses, the more the masses become convinced that HALAC is nothing more than a touring exhibition of exotic animals — they can be brighter and fluffier than domestic cats and dogs, but they are picky about local food and can hardly be trained, so you can only take pictures with them as a souvenir.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #96 – 2024-04-04 19:58:59

@Kraeved; you have written some really nice things. However, it is quite easy for me to prepare a player, converter or plug-in for HALAC. It is true that I have received a lot of feedback on this issue. There are things that I have prepared earlier on the previous pages.

The priority thing for me at this stage is the compression ratio/speed situation. And this, to me, is the most important part of a codec. When I do this as well as I can, I can do other things by sipping my coffee. I can even transfer these stages to my students. But it's really not fun to deal with the algorithmic part of the work. You can be sure of that.

I had to give HALAC a break for a while because I've been working on a different project for the last month. In the coming weeks, I need to start where I left off and see what I can do.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #97 – Today at 14:11

Yes, after a little break, HALAC 0.2.7 version is ready. I need to get a little more warming to continue where I left off.
In this version, small structural changes and some small compression ratio improvement were made. But more importantly, it can now be decode as a DLL. I also had to prepare an Audio Player using this DLL because it was asked too much. This player can play .halac files and .wav files that are Encode with the version 0.2.7 version of HALAC. And in fact, many other audio formats can also be played builtly, but I haven't activated them at this stage. The player is suitable for the Cross platform. Only DLL/SO installation operations will need to be changed. If necessary, I try to prepare a .so version for Linux.
https://github.com/Hakan-Abbas/HALAC-Audio-Player

Player is presented as open source. If desired, other Audio Players can also integrate HALAC using this DLL. However, since HALAC is still in development, there may be structural changes in each version.

Code: [Select]

// Dll Function Prototypes //
typedef char* (*EXPORT_WAVFunc)(const char*, unsigned short); // Return .wav file to memory. Parameters -> "filename" and "thread count"
typedef unsigned int (*EXPORT_SIZEFunc)(const char*); // Return .wav file size. Parameters -> "filename"
typedef void (*EXPORT_DELETEFunc)(); // Delete .wav file from memory.

Notice