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.
Topic: HALAC (High Availability Lossless Audio Compression) (Read 26382 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #125 –
Quote from: MihaiPopa12346 on
Post the new version [0.2.8 maybe] of the encoder and decoder with lossyWAV support (lossyHALAC output format).
I can't make any firm promises for 0.2.8, but I might add LossyWAV support for the next version. And since a special work will be required for an option such as "LossyHALAC", I can think about this topic later.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #126 –
Quote from: Hakan Abbas on
Quote from: MihaiPopa12346 on
Post the new version [0.2.8 maybe] of the encoder and decoder with lossyWAV support (lossyHALAC output format).
I can't make any firm promises for 0.2.8, but I might add LossyWAV support for the next version. And since a special work will be required for an option such as "LossyHALAC", I can think about this topic later.
How did you do lossyHALAC in this image: https://hydrogenaud.io/index.php?action=dlattach;attach=30749;image?
Maybe with correct block size in lossyWAV, we could achieve lossyHALAC. With the default block size, it's not working correctly.  ???

Re: HALAC (High Availability Lossless Audio Compression)

Reply #127 –
Quote from: MihaiPopa12346 on
How did you do lossyHALAC ...
I do not have full information about the LossyWAV structure and I haven't fully examined. And I didn't do anything specifically for the content. I only disabled the prediction phase required for the lossless mode. However, I did not activate it for 0.2.8.
Considering the results in the list, the HALAC offers enough compression even in this form. For better results, the data structure needs to be examined and certain adaptations are required. Of course, time is necessary for this.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #128 –
If I understood it right, LossyWAV's default block size choice of slightly below twelve milliseconds, is to allow for swift changes in the number of decimated LSBs. Bigger blocks would mean you would have to keep that constant over a longer time. 512 samples in LossyWAV and say 1024 in a compressor that employs a per-block wasted bits strategy, would restrict it to choosing the "worst of two".

When I suggested to facilitate LossyWAV, I didn't know whether it would be easy for HALAC to employ a user-selectable block size.

FLAC does a trick that for some signals improve compression by quite a lot, namely the partitioning with different Rice parameters. If a block is size K*2^N, then a partition order of N means that the residual coding parameter is changed every K samples; immediately after K samples there are four bits with a Golomb-Rice exponent. This instead of a low block size which would require frame headers.
Of course, if one did intend a lossy usage like this, one could have partitioned it with different wasted bits too. 

The partitioning is one reason why FLAC does better with block size 4096 than 4095. Sure if you don't use the same residual coding methods, YMMV - but we know certain signals where the advantage of rapidly changing a residual coding parameter can actually make FLAC outcompress any OptimFROG.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #129 –
Thank you for the valuable information you gave, Porcus.
Since Flac or some other codecs act according to Rice encoding, there may be such exceptions based on block size. however, HALAC may act structurally more flexible. Rice coding definitely has strengths on audio data. Actually, I was thinking of partially using Rice coding in the next versions, but right now I'm trying to complete the DLL and Player issue in detail with 0.2.8 (as long as I can find the opportunity and concentrate).
 

Re: HALAC (High Availability Lossless Audio Compression)

Reply #130 –
I know you are using some 2010s algorithm, which is much newer than anything Golomb-Rice, but my point was not the particular method - rather, that FLAC has this way of partitioning blocks into different coding parameters without new block overhead.

If we compare to other codecs' "preset choices", all for CDDA, then ALAC defaults to 4096 samples, ffmpeg's FLAC to 4608, TAK's largest -p4 modes have 0.25 seconds blocks, WavPack's is 0.5 I think down from 1 in WavPack 4, TTA (no measure of quality) a bit above 1 second, OptimFROG up to several and Monkey's ... I think the "Insane" mode is closing in on half a minute, but Insane is insane and the developer recommends not to use it.

So FLAC is already one which doesn't use big blocks, but it so turns out that the option to change parameters even more often, does improve.
Whether anything such is any priority for HALAC, which (in my view) is about showing what a new compression algorithm can do fast ...