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.
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.
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.
> In other words, the fastest or the best compression maker alone does not matter.
Strictly true, but e.g. for archival or content delivered to many users compression speed and memory needed for compression is an afterthought compared to compressed size.
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.
You're right, but aren't you forgetting that for each image, the encode cost needs to be paid just once, but the decode time must be paid many many times? Therefore, I think it's important to optimize size and decode time.
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.
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 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.
Thanks Hakan. I know about HALAC as I follow both HydrogenAudio and encode.ru ( with a different user name I used 20 years ago ). I thought about posting HALIC on doom9 as well but I dont think they many would be interested there.
Anyway keep up the good work. And hopefully some day it gets open sourced.
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."
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.
> MS Windows, MS Office, Adobe, Autodesk, Oracle, Winrar and thousands of more wonderful software should not be taken seriously.
Apples and oranges. I don't need word processing software to be open source to understand how it works. A proportedly novel compression algorithm is a different story...
I can be totally honest with you: FLAC being open source is more valuable to me than any performance benefit you could ever possibly offer over it. It only becomes interesting if I can actually read the code and see what you did.
I am genuinely interested in what you've done here, and I sincerely hope you publish it.
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.
I think the results are very interesting: just to reiterate, I would love to see what you've done here, and I hope you publish it.
Obviously, it's your right to decide... but especially if you think of it as a hobby, why not release the source? It would make your work much more valuable for a lot more people.
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.
Autodesk has a monopoly because, oh, web browsers don't have to open Autocad drawings.
The amount of media playback and serving software out there is innumerable. If most of it doesn't handle some obscure format, that format is screwed.
Getting a new format everywhere is a difficult battle; the adoption barriers are high. Even if the thing is completely royalty free, and comes with a great, open source reference implementation.
Something that is closed, and has no backing of some corporate consortium or ITU type body or whatever, is basically fucked.
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 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.
>Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs.
Why not? And for what applications? Example: for a media streaming service, where each file is transferred many times, the bandwidth costs dominate, so it is worthwhile to spend a great deal of time on encoding to maximize efficiency. In the case of an archive, where a large amount of information is stored, accessed infrequently, storage space becomes the constraint, once again. In general, 1 marginal second of CPU time is usually cheaper than 10Mib of marginal storage (or whatever the figure works out to be). Finally, why not just write a fast FLAC encoder?
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.
