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 36651 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #150
@Hakan Abbas

Encoding fails with HALAC_ENCODE_V.0.2.9_x64_avx.exe. Using v0.2.8 worked fine.

HALAC_ENCODE_V.0.2.8_x64_AVX.exe
HALAC Decoder (foo_input_halac): https://foobar.hyv.fi/?view=foo_input_halac
Windows 11 Home
foobar2000 v2.1.5 x64

-Encoder file: HALAC_ENCODE_V.0.2.8_x64_avx.exe
-Extension: halac
-Parameters: %s %d -mt=8
-Format is: Lossless
-Highest BPS mode supported: 16bit
-Do not convert in multiple threads
SHURE SRH1840, SENNHEISER HD660S2, SENNHEISER HD620S, SENNHEISER HD 490 Pro Plus, beyerdynamic DT 1990 PRO, HiFiMAN Edition XS, Bowers & Wilkins P7, FiiO FT5, 水月雨 (MOONDROP) 空鳴 - VOID, Nakamichi Elite FIVE ANC, SONY WH-ULT900N (ULT WEAR) (made a Upgrade/Balanced Cable by myself)

Re: HALAC (High Availability Lossless Audio Compression)

Reply #151
There is almost no difference in the compression ratio and speed in HALAC 0.2.7, 0.2.8 and 0.2.9 versions. You can already see this by trying it externally. I did not have a problem with 0.2.8 or 0.2.9 in Foobar (Windows 10, x64). They only work slower while "Do not convert in multiple threads" is not selected. You have never worked 0.2.9. Interesting situation.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #152
HALAC Decoder (foo_input_halac) v0.1.4 (2024-06-13)
https://foobar.hyv.fi/?view=foo_input_halac

FLAC 1.4.3 → HALAC 0.2.9

Windows 11 Home
foobar2000 v2.1.5 x64

@Hakan Abbas and @Case Many Thanks.


SHURE SRH1840, SENNHEISER HD660S2, SENNHEISER HD620S, SENNHEISER HD 490 Pro Plus, beyerdynamic DT 1990 PRO, HiFiMAN Edition XS, Bowers & Wilkins P7, FiiO FT5, 水月雨 (MOONDROP) 空鳴 - VOID, Nakamichi Elite FIVE ANC, SONY WH-ULT900N (ULT WEAR) (made a Upgrade/Balanced Cable by myself)

Re: HALAC (High Availability Lossless Audio Compression)

Reply #153
I updated the foobar2000 decoder to use version 0.2.9, for now just using same lazy full-file decode method as has been used before.

I'm not certain what your intentions regarding your metadata routines are, I don't see your encoder or your player having any metadata support. You could consider not inventing your own metadata format and instead use a good, existing and quite widely supported APEv2 tags. FYI the foobar2000 component has full tagging support including album art using APEv2 tags.

I'm a bit confused about the function GET_INPUT_FILE_SIZE() as there doesn't seem to be a way to retrieve the original file anymore with the DLL.

Are you certain 32-bit unsigned integer is enough for the frame count field? Or is the idea that frames will be so large that anything will be made to fit?

I really recommend you to add error and sanity checks to your decoder. Just feeding the decoder wrong data makes it crash. For example feeding the function GET_FRAME_DATAS() the entire source file instead of data starting from offset retrieved by GET_FIRST_FRAME_START_POSITION() makes the decoder crash. Or altering the file header and increasing the frame count makes your player crash.

 

Re: HALAC (High Availability Lossless Audio Compression)

Reply #154
@Air KEN : Good News

@Case : Thanks again for your work, Case.

for now just using same lazy full-file decode method as has been used before
https://github.com/Hakan-Abbas/HALAC-Audio-Player/blob/8e5fbbdb4601cdd1b2aada6685f2174963549b6e/mainwindow.cpp#L621-L658

I'm not certain what your intentions regarding your metadata routines are, I don't see your encoder or your player having any metadata support.
I get the metadata data as it is from the source file. No external processing is done.

I'm a bit confused about the function GET_INPUT_FILE_SIZE() as there doesn't seem to be a way to retrieve the original file anymore with the DLL."
GET_INPUT_FILE_SIZE() returns the full file size by adding 8 bytes to the size information in the header of the source file (wav). Just like GET_INPUT_DATA_SIZE() but this is just raw data.

Are you certain 32-bit unsigned integer is enough for the frame count field? Or is the idea that frames will be so large that anything will be made to fit?
The new uncompressed frame size is 512 kbytes. The total input data size that can be supported is 512 * 1024 * 4,294,967,296 = 2,251,799,813,685,248 bytes. I thought that would be enough. It can be increased if necessary.

I really recommend you to add error and sanity checks to your decoder.
Some of the new functions have various controls. More powerful controls will be added in the future as the details become clearer.

I try to keep things as simple as possible. As I mentioned before, there are things that can be done for HALAC in terms of compression ratio. I can see the gap here, I need to focus a bit more.

Re: HALAC (High Availability Lossless Audio Compression)

Reply #155
Code: [Select]
BUSTA RHYMES(i7 3770k, 20 tracks, Total 829,962,880 bytes)
HALAC NORMAL 1 Thread (ANS) : 4.32 sec, 574,161,601 bytes
HALAC NORMAL 1 Thread (RICE): 3.66 sec, 567,469,774 bytes

Hi, Hakan.
If those numbers are close to real life averages, then HALAC w/Rice  will be  on par with FLAC -4  :)  while still being faster enc/dec.

After -4 Flac doesn't bring groundbreaking compression gains (<1%). 
http://www.audiograaf.nl/downloads.html
http://www.audiograaf.nl/losslesstest/revision%206/Average%20of%20CDDA%20sources.pdf

Given that I see myself  (and likely other FLAC users) choosing HALAC w/Rice  if/when format will be solid.
Looking towards  HALAC release 0.3  :)

Re: HALAC (High Availability Lossless Audio Compression)

Reply #156
Given that I see myself  (and likely other FLAC users) choosing HALAC w/Rice  if/when format will be solid.
Looking towards  HALAC release 0.3  :)
Thanks for the comment, @btc.

As I mentioned before, the compression ratio in lossless audio compression is really limited. I think the processing speed will be more important as we approach the end of silicon technology, because in recent years processors have not accelerated much on a single core basis. Multi-core solutions and parallel processing are becoming more prominent.

Looking at guruboolez's latest test, codecs at the slowest settings provide about 5% better compression on average than HALAC. However, we can't say that these are of practical use in real life. If we look at the practical use case, we can talk about a maximum gap of 3%. Some other codecs can do this at the cost of much more processing time than HALAC. I don't know how much of this gap HALAC can close at similar speeds, but Rice coding is full of surprises.

My work for HALAC v.0.3.x is not finished yet. And I don't want to share or rush it before I am fully sure of the results. The HALAC format will be much more robust in future versions (HD Audio, Multichannel...). As long as I take the necessary time and stay motivated.