HakanAbbas

I have released the source code for the first version (0.1.9) of HALAC. This version uses ANS/FSE. It compiles seamlessly on platform-independent GCC, CLANG, and ICC. I have received and continue to receive many questions about the source code. I hope this proves useful.

HALIC's decode speed is already much faster compared to other codecs. When you look at the compression ratios, they are almost the same. There doesn't seem to be a problem with this. There are also issues where encode speed is especially important. But I think there is no need to spend a lot more energy to make a few percent more compression and decode it.

Storage is cheaper than it used to be. Bandwidth is also cheaper than it used to be (though not as cheap as storage). So high quality lossy techniques and lossless techniques can be adopted more than low quality lossy compression techniques. Today, processor cores are not getting much faster. And energy is still not cheap. So in all my work, processing speed (energy consumption) is a much higher priority for me.

I don't really understand what the new PNG does better. Elements such as speed or compression ratio are not mentioned. Thanks also for your kind thoughts ksec.

Apart from the widespread support in codecs, there are 3 important elements: processing speed, compression ratio and memory usage. These are taken into account when making a decision (pareto limit). In other words, the fastest or the best compression maker alone does not matter. Otherwise, the situation can be interpreted as insufficient knowledge and experience about the subject.

HALIC is very good in lossless image compression in terms of speed/compression ratio. It also uses a comic amount of memory. No one mentioned whether this was necessary or not. However, low memory usage negatively affects both the processing speed and the compression ratio. You can see the real performance of HALIC only on large-sized(20 MPixel+) images(single and multi-thread). An example current test is below. During operations, HALIC uses only about 20 MB of memory, while JXL uses more than 1 GB of memory.

https://www.dpreview.com/sample-galleries/6970112006/fujifil...

June 2025, i7 3770k, Single Thread Results

----------------------------------------------------

First 4 JPG Images to PPM, Total 1,100,337,479 bytes

HALIC NORMAL: 5.143s 6.398s 369,448,062 bytes

HALIC FAST : 3.481s 5.468s 381,993,631 bytes

JXL 0.11.1 -e1: 17.809s 28.893s 414,659,797 bytes

JXL 0.11.1 -e2: 39.732s 26.195s 369,642,206 bytes

JXL 0.11.1 -e3: 81.869s 72.354s 371,984,220 bytes

JXL 0.11.1 -e4: 261.237s 80.128s 357,693,875 bytes

----------------------------------------------------

First 4 RAW Images to PPM, Total 1.224.789.960 bytes

HALIC NORMAL: 5.872s 7.304s 400,942,108 bytes

HALIC FAST : 3.842s 6.149s 414,113,254 bytes

JXL 0.11.1 -e1: 19.736s 32.411s 457,193,750 bytes

JXL 0.11.1 -e2: 42.845s 29.807s 413,731,858 bytes

JXL 0.11.1 -e3: 87.759s 81.152s 402,224,531 bytes

JXL 0.11.1 -e4: 259.400s 83.041s 396,079,448 bytes

----------------------------------------------------

I had a very busy time with HALAC. Now I've given him a break, too. Maybe I can go back to HALIC, which I left unfinished, and do better. That is, more intense and/or faster. Or I can make it work much better in synthetic images. I can also add a mode that is near-lossless. But I don't know if it's worth the time I'm going to spend on it.

HALAC (High Availability Lossless Audio Compression) is now faster and denser with version 0.3.6. Also, for a long time, both encode and decode operations can be performed in multithread. This version now uses Rice coding instead of ANS. The Golomb-Rice coding for audio data is really excellent. And there are different things that can be done, both in terms of speed and compression ratio. However, at ultrafast speeds, in most cases we cannot move as freely as we would like. In the related link, versions 0.2.9 and 0.3.6 are compared. The results of the first version 0.1.9 are really behind.

Thank you for your attention. I'm trying to do my best. Regarding the open source, I answered the questions asked as follows (In HALAC Topic).

"Frankly, if I publish open sources now, I can't take care of them again. Because there will be no excitement. I say this because I know myself very well. When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone."

I need a little more time.

Thank you very much. Yes, this information is correct. Right now I have taken a break from the HALIC project and I am interested in HALAC(High Availability Lossless Audio Compression) project. I guess I will achieve the same success.

https://hydrogenaud.io/index.php/topic,125248.0.html

https://news.ycombinator.com/item?id=38838531

> Frankly, if I publish open sources now, I can't take care of them again. Because there will be no excitement. I say this because I know myself very well.

> When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

You say it's not worth spending time on such work, discovering new things and pondering. I understand.

Thank you for your valuable thoughts.

Thank you for your good thoughts

Thank you very much for valuable information.

When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

Frankly, if I publish open sources now, I can't take care of them again. Because there will be no excitement. I say this because I know myself very well.

When I bring my work to a certain stage, I would like to deliver it to a team that can claim it. However, I want to see how much I can improve my work alone.

Hmm. Of course, we don't need to know how Oracle is fast and secure, why Autodesk is a monopoly in the industry, winrar is still used a lot despite being paid, and how Adobe's artificial intelligence-powered filters work.

I am developing HALAC and HALIC as a hobby and I don't expect everyone to use them. I'm happy when I can get good results, and it's bad when I can't. I say this as someone who has been dealing with data compression for 9 years.

At this stage, what is taken seriously is quite personal. If the source code is a requirement to take it seriously; MS Windows, MS Office, Adobe, Autodesk, Oracle, Winrar and thousands of more wonderful software should not be taken seriously.

Some of the SIMD optimization make compilers automatically. The others can be manually. These speeds can be obtained without using SIMD. Then there may be more with manual SIMD. I think this is what should be loved.

I have no problem trying to kill criticism. I'm just trying to do what I love as a hobby(academic).

Or maybe it's better for me to do things like fishing, swimming as a hobby.

HALAC and HALIC really consume very little memory. The process speed is high at the same rate. And they offer a reasonable compression rate. Therefore, they can be used at high level and different areas.

The only reason Flac is the most popular sound code is that both compression and code -solving is faster than others. The same applies to many formats such as JPEG, MP4, MP3, Rar, Zstandart. What is fast is always advantageous and is a reason for preference. Even if they are not free. As you mentioned, of course, it does not apply to every situation.

Flac is already existing. There are also a lot of workers on it. I always want to try independent and different things.

The compression rate in audio compression is really limited. In most cases it is difficult to decrease below 50 percent.

Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs. As a result, high processing times are high energy.

Thank you so much.

Thanks for the information about the license and patent. It can work with any bitrates for Halac. However, more than 2 channels and 24/32 bit support outside 16 can be added.

My works are fully cross-platform. There is no restrictive situation. I also prepared Linux and ARM versions for HALIC, but I didn't compile new versions because it didn't get much attention. When my Linux test machine is ready(crashed), I compile the Linux version of HALAC.

Yes, I'm new in hydrogenaud.io. However, I have been active since 2018 in "encode.su".

This year, "3rd Global Data Compression(gdcc.tech)" organized by Huawei and Barcelona Autonoma University was held. In this competition, I have the world 3rd place in the "Professional Task 6 - Ultra Fast" category(JABBAR). And I spent only 2 weeks of the 5-month competition process for this degree.

We can only share and test such a specific work in specific environments.

Thank you so much.

Yes, the HALIC uses quite low memory. Because independent small blocks work. Of course, this situation negatively affects the compression rate. It is a fact that I compromise on the compression rate to ensure less memory consumption.

I am still at the beginning of the road in terms of compression rate and speed. There may be changes in subsequent versions.

There are things I should add to Halic and Halac. When I complete them and realize that it will really be used by someones, it will of course be open source.

In this regard, you can review the HALIC link if you want. https://encode.su/threads/4025-HALIC-(High-Availability-Loss...