WavPack Algorithm Support Freearc

[shazzla]

I think HALAC would be better. It outperforms all available lossless wav-packer algorithms. (in speed)
Compression ratio only a bit worse than others.
Real life example ,but it obviously depends on the source.

1.wav 58,245,620
1.flac 42,758,413 (max. compression)
1.tak 42,214,646
1.tta 42,339,162
1.halac 43,003,837

HALAC's compression time : 0.8 sec on Ryzen 7 9700x ,single thread.

Disadvantages : It has no stdio and stream processing feature.

Available at encode dot su ,look for Hakan Abbas.

[kj911]

HALAC: Yes, it really is an insanely fast codec. Can it be ported to Win XP?? Programs that use too new or rare CPU instructions will have to deal with a disadvantage in this case, which may hinder more widespread ones.

I am attaching the self-compiled binaries of the "prepack" compressor discussed on the previous page below. (Basically compiled with "-O3" flag + s/static switches) Interestingly, the "g++.exe" files are 2-2.5* larger than those generated by "gcc.exe". If the "-s/static" flag is not used, I get EXEs of ~291/470+ KB size. If you want a small size, there are UPX compressed versions.

[Carldric Clement]

Originally Posted by shazzla

I think HALAC would be better. It outperforms all available lossless wav-packer algorithms. (in speed)
Compression ratio only a bit worse than others.
Real life example ,but it obviously depends on the source.

1.wav 58,245,620
1.flac 42,758,413 (max. compression)
1.tak 42,214,646
1.tta 42,339,162
1.halac 43,003,837

HALAC's compression time : 0.8 sec on Ryzen 7 9700x ,single thread.

Disadvantages : It has no stdio and stream processing feature.

Available at encode dot su ,look for Hakan Abbas.

It looks like I can't compress all my project stuff song

[External compressor:halac]
header    = 0
packcmd   = "media\halac_e" $$arcdatafile$$.wav $$arcdatafile$$.halac -normal
unpackcmd = "media\halac_d" $$arcdatafile$$.halac $$arcdatafile$$.wav
datafile   = $$arcdatafile$$.wav
packedfile = $$arcdatafile$$.halac
solid = 0

MODERATORS please change the title: Suggestion codec to repack a wav file

[kj911]

HALAC supports from 2ch/16bit only audio files.

Did you test the current version or v0.1.9, or in the case of the latter, did you use your own compiled binary for the test?

Other theme/questions (English translated text):

Recently, an interesting idea came to my mind.

We have the well-known WAVPACK packager, with a unique feature. Moreover, the Hybrid compression mode. Has anyone used this in some repackaging? The idea would be that if the "Lossy RIP" theme has worn off the scene, when would it make sense to compress the "easily accessible" audio of a game in such a way? Especially if it takes up a lot of space, considering the game as a whole, we compress the WAVs in hybrid mode at a bitrate of 96-256kbps. Then the lossy encoded files are included in our main archive package, while the correction files necessary for lossless recovery are distributed in a separate compressed package, as many repackers do with files containing files in different languages.

Does this make any sense?

Hungarian text (az eredeti szöveg):

A közelmúltban, egy érdekes ötlet jutott, az eszembe.

Van ugyebár, a mindenki által ismert WAVPACK csomagolónk, egy egyedi tulajdonsággal. Még pedig, a Hibrid-tömörítési mód. Egyes újracsomagolásoknál, valaki használta már ezt? Az ötlet az volna, ha már a "Lossy RIP"-téma eléggé kikopott a szkénából, vajon mikor lenne értelme úgy tömöríteni egy játék "könnyen hozzá férhető" hanganyagát. Pláne, ha nagyon sokat is foglal, a játék egészét nézve, hogy a WAV-okat, hibrid-módban 96-256kbps-es bitrátán tömörítjük. Ekkor a veszteségesen kódolt fájlok kerülnek bele, a fő archiválandó csomagunkba, míg a veszteségmentes helyreállításhoz szükséges korrekciós fájlokat, külön tömörített csomagban terjesztjük, mint ahogy sok újracsomagoló teszi ezt, a külön féle nyelvű fájlokat tartalmazó állományokkal is.

Van ennek valami értelme?

[Carldric Clement]

Originally Posted by kj911

HALAC supports from 2ch/16bit only audio files.

Did you test the current version or v0.1.9, or in the case of the latter, did you use your own compiled binary for the test?

Other theme/questions (English translated text):

Recently, an interesting idea came to my mind.

We have the well-known WAVPACK packager, with a unique feature. Moreover, the Hybrid compression mode. Has anyone used this in some repackaging? The idea would be that if the "Lossy RIP" theme has worn off the scene, when would it make sense to compress the "easily accessible" audio of a game in such a way? Especially if it takes up a lot of space, considering the game as a whole, we compress the WAVs in hybrid mode at a bitrate of 96-256kbps. Then the lossy encoded files are included in our main archive package, while the correction files necessary for lossless recovery are distributed in a separate compressed package, as many repackers do with files containing files in different languages.

Does this make any sense?

I tested with HALAC 0.5.1, but it seems it failed to compress every WAV file I export from my DAW software. even though it's not the same as the WavPack we used before. For example, if we use the Hybrid compression from the original audio WAV file, that might ruin the original bits/samples unless you enable the correction file ".wvc". Instead of that, we don't need to use the Hybrid mode. It will keep the original bits/samples if you don't want to ruin the original audio.

Result:

TTA = 9,409,370 = 9,409,374
MSC_TAK = 9,409,370 = 9,409,382
Wavpack = 9,409,370 = 7,096,122
Wavpack -hh -x6 = 9,409,370 = 7,073,098
Wavpack Hybrid -b10 = 9,409,370 = 3,808,236

Don't be confused if you get these error if you uses Hybrid Compression:

[kj911]

The hipotetical installation files list:

Data.arc (main base game files)
Sound.arc (lossy *.wv files only)
Music.arc (other format and/or untouched "problematic" *.WAV sound files)
Sound_corr.arc (lossy to lossless *.wvc correction files only)
Bin.arc (exe/dll/other files)
Setup.exe
Setup_lossless_audio.exe (lossless audio installer or this functions built-in to main "setup.exe" file)


Scenario 1 (install lossy audio):

User install the game from listed installation files, except getting in "Sound_corr.arc" file. Aka, not downloaded, not presents. Game audio files installing "lossy" quality. (decompress *.wv files and decoded them to *.wav. Decoding in finished, the *.wv files will be deleted.)

Scenario 2: (all setup files presents):

User install the game from installation files normally, audio files in lossless quality. (decompress *.wv and *.wvc files. Decoded *.wv losslessly to *.wav files. Decoded in finished, *.wv/wvc files will be deleted)

Scenario 3: (Scenario 1 files downloaded in older times):

User in get "setup_lossless_audio.exe" (or use orig. "setup.exe" via "lossless audio" checkbox in presents) and "Sound_corr.arc" files in future times, reinstalling or replaceing lossy installed audio files to lossless files. Installation process will require original "Sound.arc" setup file package from during installation.


Extreme example:

Whole games completely on has 50GB size, contains 35GB's lossless audio.

Lossy files:

Data.arc (15GB other data compressed in few GB's.)
Lossy sounds shrinked to 2-4GB size and compressed it.
Other files in below 512MB-1024MB sizes.
Total size less than 5-8GB.

Lossless files:

Data.arc (15GB other data compressed in few GB's.)
Lossless sounds shrinked to 10-20GB size and compressed it or else:
lossless correction files separately shrinked to 8-16GB sizes.*
Other files in below 512MB-1024MB sizes.
Total size "probably" less than 15-25+ GB.

*the lossy case its needs smaller data traffic/storage sizes. (2-5* smaller.)

[Hakan Abbas]

Hello. I can help with HALAC.

First of all, HALAC with its latest version 0.5.1, accepts 16 bit PCM, 24 bit PCM and 32 bit Float type wav files as input. SampleRate is not important. And since I haven't added multi-channel support yet, it only supports 2 channels for now. And both encode and decode can work multithread(max 1024). In addition, HALAC's lossyWAV support is also very strong.

HALAC compression ratio is similar to other codecs. However, 24 bit provides much better results at higher samplerate values. And it is much faster than other codecs. 32-bit compression results are also almost the same as WAVPACK. However, it is 7x faster on average. Many codecs do not support 32-bit Float.

Also Windows XP support was mentioned. Previously, I had made compilations on this subject, 32 bit support and ARM. Since there was no interest, I didn't pay attention afterwards. There are no obstacles that will cause performance problems. HALAC does not use manual SIMD. It just automatically leaves control to the compiler. And there are no huge performance differences between SSE, AVX and AVX2 builds. In fact, the decoder is often compiled as SSE2 and offers similar performance to AVX512.

Due to its structure, it is compatible with HALAC streaming. I prepared .dll and .so for this before. I even developed a standalone GUI player. Of course, these are minor details and can be easily resolved.

If compression cannot be done in some files, this is due to the structure of the WAV file. So it must be a little bit outside the standards. "Channel count must be 2!" in the previous image. The message shows this. I've made a lot of improvements to this, but there may be more exceptions. If an example wav file that gives an error can be provided, we can solve the problem.

https://hydrogenaudio.org/index.php/topic,125248.0.html
https://encode.su/threads/4180-HALAC...io-Compression)

[Carldric Clement]

Originally Posted by Hakan Abbas

Hello. I can help with HALAC.

First of all, HALAC with its latest version 0.5.1, accepts 16 bit PCM, 24 bit PCM and 32 bit Float type wav files as input. SampleRate is not important. And since I haven't added multi-channel support yet, it only supports 2 channels for now. And both encode and decode can work multithread(max 1024). In addition, HALAC's lossyWAV support is also very strong.

HALAC compression ratio is similar to other codecs. However, 24 bit provides much better results at higher samplerate values. And it is much faster than other codecs. 32-bit compression results are also almost the same as WAVPACK. However, it is 7x faster on average. Many codecs do not support 32-bit Float.

Also Windows XP support was mentioned. Previously, I had made compilations on this subject, 32 bit support and ARM. Since there was no interest, I didn't pay attention afterwards. There are no obstacles that will cause performance problems. HALAC does not use manual SIMD. It just automatically leaves control to the compiler. And there are no huge performance differences between SSE, AVX and AVX2 builds. In fact, the decoder is often compiled as SSE2 and offers similar performance to AVX512.

Due to its structure, it is compatible with HALAC streaming. I prepared .dll and .so for this before. I even developed a standalone GUI player. Of course, these are minor details and can be easily resolved.

If compression cannot be done in some files, this is due to the structure of the WAV file. So it must be a little bit outside the standards. "Channel count must be 2!" in the previous image. The message shows this. I've made a lot of improvements to this, but there may be more exceptions. If an example wav file that gives an error can be provided, we can solve the problem.

https://hydrogenaudio.org/index.php/topic,125248.0.html
https://encode.su/threads/4180-HALAC...io-Compression)

Here's the sample WAV file that I provided to you.

[Hakan Abbas]

Just as I predicted. After the "WAVE" tag and before the "fmt " tag, there is the "JUNK" tag and its corresponding field. Normally, this and other similar fields come after the "fmt " tag. However, according to the RIFF standard, this is possible, I just learned. When this is the case, there is a shift in the header data.

If you save the same wav file differently without changing it with any audio converter, they will probably clear this space. Or, these 36 bytes can be deleted manually.
I will add this support to HALAC in the next version. Thank you very much Carldric.