Suggestion codec to repack a wav file
 

I'm exporting some music tracks and noticed there are several **WAV codec options** available when packing a project.

Which one do you think is the best choice for **packing your audio WAV files**?

🔹 Original
🔹 ALAC
🔹 WAVPACK
🔹 FLAC
🔹 HALAC

Feel free to vote or share your experience.

Thanks for the help! 🎶

The point? TAK in MSC has better compression and is lightning fast.

Nice.. but you need to test WavPack
 

Your point is MSC to get faster compression. But my point is to get a slow to a huge compression like WavPack... :D:D

Can you provide a link to wav(s), on which WavPack beats TAK in terms of compression. Lossless, I mean.

msc_frog will even achive better then msc_tak itself... bt may take little bit more time
bt if u consider more on compression then i don't think increase in time can give you the pain in ur a**

hmm... :confused:
I've never used that before but it's good to use it msc_frog... :cool:
but Wavpack was really perfect lossless about it. :D

As the Msc... it is totally lossless

one drawback of ur method i can see is that it works for masks only, meaning any wavs that is embedded in an archive, it will not gonna work. similarly game developers and our gaming rigs are now wealthy enough to use files with more complexity for example mp3 and handle them perfectly, i saw tons of mp3s embedded in game archives nowadays.So i see more scope of discussion over mp3 compression rather then on wav.

bt the case of MSC is different means it doesn't go for masks bt for the headers, it scans whole things first meaning the data u asked arc to compress, make a log of what it found and then extract things one by one and process it with "special" compressors, put it back in another archive.

about the msc_frog and msc_tak, actually MSC provide choice between two compressors for compression of wav files i.e Frog and Tak, frog provides somewhat better compression then tak on the cost of speed, I divided MSC on these basis in MSC_frog and MSC_TAk in Masked Compression v2.5.1 for the sake of decompression as they requires different versions of cls for decompression.

Conclusion : i think masks compression doesn't a go for compression lovers, doing things manually will yields u much better results. means scanning each file manually with dragon unpacker or something like that, extracting file, processing things with "special" compressors or simply u can use MSC, it has also a compressor for mp3 and for wav as well. Even the MSC itself has the feature of extracting things that can be processed with "special" compressors, but the injection feature didn't work for me.

Pls correct me if u thing i got wrong somewhere or my whole thinking is creepy s***.

Best regards,
Prince Gupta

More result...
I think you should go a rest time to get more information about it.
But it's good to me your information was perfect. Unfortunately msc_tak was failed about decompression like this:
think about it. :rolleyes:

frog gives better ratio than tak. but sometimes using -f giving error in both of them. not always but you must test archive with decompres it.actually it gives more error with reflate and a bit precomp

not for me, i hardly got any error from Msc side unless you consider the Bmf part

[External compressor:WavPack] Not Work
Please Help

Oh yep it works, add the mask as in the example, add and set the external compressor in the arc.ini file, and you'll see it works, better than "msc" (now no longer updated from years).
Use these settings, "-hh -x5" for wav files.;)

isn't built-in TTA algo compress better than wavpack?

TTA is much faster than wavpack for the same result:

----------------------------- START 14:06:32 -----------------------------
[2017/04/20:14:06:32] Creating archive: Data-01.bin (1/1)
[2017/04/20:14:06:32] IntputPath: C:\Users\JRD\Downloads\0905.wav
[2017/04/20:14:06:32] InputSize: 65,93 MB
[2017/04/20:14:06:32] FilesCount: 1
----------------------------- METHOD -----------------------------
[2017/04/20:14:06:32] Step Method Count: 1
[2017/04/20:14:06:32] MaskedMethod: -mfreearc_tta
[2017/04/20:14:06:32] FullMethod: -mtta
----------------------------- COMPRESSORS -----------------------------
[2017/04/20:14:06:32] Compressors count: 1
[2017/04/20:14:06:32] Compressor: tta
----------------------------- RESULT -----------------------------
[2017/04/20:14:06:36] OutputSize: 29,56 MB
[2017/04/20:14:06:36] Ratio: 44,84 %
[2017/04/20:14:06:36] Status: Operation success
[2017/04/20:14:06:36] Compression time: 00:00:03
----------------------------- FINISH 14:06:36 -----------------------------

----------------------------- START 14:06:54 -----------------------------
[2017/04/20:14:06:54] Creating archive: Data-01~1.bin (1/1)
[2017/04/20:14:06:54] IntputPath: C:\Users\JRD\Downloads\0905.wav
[2017/04/20:14:06:54] InputSize: 65,93 MB
[2017/04/20:14:06:54] FilesCount: 1
----------------------------- METHOD -----------------------------
[2017/04/20:14:06:54] Step Method Count: 1
[2017/04/20:14:06:54] MaskedMethod: -mwavpack_x64
[2017/04/20:14:06:54] FullMethod: -mwavpack_x64
----------------------------- COMPRESSORS -----------------------------
[2017/04/20:14:06:54] Compressors count: 1
[2017/04/20:14:06:54] Compressor: wavpack_x64 -hh -x5 - -
----------------------------- RESULT -----------------------------
[2017/04/20:14:07:51] OutputSize: 29,56 MB
[2017/04/20:14:07:51] Ratio: 44,83 %
[2017/04/20:14:07:51] Status: Operation success
[2017/04/20:14:07:51] Compression time: 00:00:57
----------------------------- FINISH 14:07:51 -----------------------------

----------------------------- START 14:11:58 -----------------------------
[2017/04/20:14:11:58] Creating archive: Data-01~2.bin (1/1)
[2017/04/20:14:11:58] IntputPath: C:\Users\JRD\Downloads\0905.wav
[2017/04/20:14:11:58] InputSize: 65,93 MB
[2017/04/20:14:11:58] FilesCount: 1
----------------------------- METHOD -----------------------------
[2017/04/20:14:11:58] Step Method Count: 1
[2017/04/20:14:11:58] MaskedMethod: -mwavpack_x64
[2017/04/20:14:11:58] FullMethod: -mwavpack_x64
----------------------------- COMPRESSORS -----------------------------
[2017/04/20:14:11:58] Compressors count: 1
[2017/04/20:14:11:58] Compressor: wavpack_x64 -h -x5 - -
----------------------------- RESULT -----------------------------
[2017/04/20:14:12:40] OutputSize: 29,56 MB
[2017/04/20:14:12:40] Ratio: 44,84 %
[2017/04/20:14:12:40] Status: Operation success
[2017/04/20:14:12:40] Compression time: 00:00:41
----------------------------- FINISH 14:12:40 -----------------------------

if we compare with the same level of compression I can not see the difference in speed.

tta r3.4

wavpack 5.1.0

But calculations do not come back, increasing the compression level, time increases, but the ratio varies little or nothing.:mad:

i was build this prepack for wav and raw(image).
is in c lang. but i cant fix to unpack. if anyone can help.
check the attach.

freearc contains tta 3.2 which afaik compress better but slower than 3.4

so it's better to run freearc/fazip itself rather than use tta executables

and compression time probably isn't important for repacks, only dec. speed and ratio matters. check all 3 levels - from tta:m1 to tta:m3

OK Guys... if you want to know about TTA and wavpack are same but was almost different.

TTA is smooth compression and lightning style. but the level was not to fit loss to combine before and after.

wavpack is slow compression and support algorithm with a huge calculate. but the level was good to fit. almost not fit or whatever combine before and after.

see?? it just same.

Can anyone give me wavpack 5.1's pack and unpackcmd?

You can replace {compressor} with the name of the executable

"-h -x5 -q" are additional parameters...

btw whats the unpackcmd?
What if I use hybrid? :(

You can use with hybrid. Anyway try it.

Try its use "-hh -x6" (not "-h -x5"!) its probably best compression ratio. WavPack v4.80.0 its minimally faster and better comp. rate compare to v5.3.0 release. (The finish build support from WinXP! 5.4.0 its dropped support.)

Testing my day in few hours, these big 2 hours lenght vhs-audio tracks compression.

Carldric/ChronoCross posted packages testing in next times via two games: MSTS with pure WAV's and probably compress SCPT game *.LS0 files only.

Tested the Hybrid mode with the huge file. Its *.wv compressed file only smaller than lossless copy. Use ("-bn -c" switches) and added *.vvc restoration file its *.wv files during compression. This *.wv+vvc packages biggest than losslessly compressed *.wv fille only!

Works from ONE WAV-file compression. Multiple WAV compression not handle properly via switches and Arc.exe its crashed. Manually updating arc file use one WAV file its added again and again its very impossible.

More methods, use separated WAV->WV compression and put all *.WV file to one archive its works! See te attached packages. Required properly encoded WAV source files from during compression. The "MISSING FILES" directory contain three uncompressible, damaged WAV's not compressing the MSTS game files sets. (4998 file its work via 5001 files set. CRCs it OK!)

Mini compare (from my big test):

WAVPACK 4.80.0 x86 with "-hh -x6" + FreeArc 0.67 with "-mx" switches:
Results: 674 635kB (FreeArc temporary file: 673 358kB)**
with -mrep:512m switches: 673 414kB
Comp. time: ~155+20min; Decomp. time: ~10min

WAVPACK 4.80.0 x86 with "-f" + FreeArc 0.67 with "-mx" switches:
Results: 674 635kB (FreeArc temporary file: 709 262kB)**
with -mrep:512m switches: 711 083kB**
Comp. time: ~10+20min; Decomp. time: ~10min!

**Missing 3 files!!! Yes, don't use LZMA compression!

MSC+SREP: 634861kB (In last time.)

UPDATE: New results are posted it --> https://fileforums.com/showpost.php?...postcount=2597

Here's the arc setting useful.
The only works by using one method. No need to add srep or lzma.
:)

Carldric! Use very higher files sets from compression! Works?? (Testing now in few hours.)

Found the BUG! See the pictures. YES! That was the problem. WvUnpack.exe glitch! 50-50 percentage its really to extract properly! Internally ARC file test its OK!

https://i.kek.sh/QxRGNgmjd45.png
https://i.kek.sh/AOGsQ63uXnk.png

Tested from my 5001 WAV files sets. Don't work. The WAVPACK compressor no tolerance its incompressible, not standard and/or damaged WAV files. Found first error and compression progress exiting now with Errorlevel=1 message. This MSC and FreeArc with TTA-method tolerance any errors and will compress properly!

Compression error: https://i.kek.sh/723SkDDMPn5.png

Its probably fully proper switches from decompression:
See picture: https://i.kek.sh/1OGVCcvdYsl.png

The "-z" switch its cosmetic usage from CMD Window title.

The third pic that I saw was like "Too many channels" right now. Maybe it was because the WAV encode was an unknown issue. I've tried to figure some other params without using "-hh" to make it work. :)

EDIT: Use "tta" method on FreeARC to compress a WAV files if it works.

Carldric: It looks like we're pretty much done with this WavPack compression, with all its limitations.

Yes, TTA or MSC/TAK method its best and favorized methods usage in future time. Compression ratio and any results barely better then WavPack versions. Good luck.

With the properly configured "arc.ini" file, it works fine.

Looking through GitHub's commits, I found, in one of them, the author's compiled binaries! There are no binaries available on the "prepack" main page or in the "Releases" branch.

The package you uploaded reflects the status as of 2016.03.12., if everything is correct. The package below, in principle, reflects the status as of 2016.03.10. and the "prepack.c" source code, if everything is correct, also contains the very first version from 2016.03.04. (it is in a separate small *.7z file, inside the larger 7z archive.)

Note: The compiled 32-bit EXE can be shrunk to under 20kB during compilation. With UPX, even further.

Arc.ini settings (from original authors posted EXE file, try edit its from used EXE name different):
The filters, works from *.wav/others audio/few data files. (*.mpg files tested, 0 byte gain.) Technically very lightweight category compared from FreeArc delta/tor,etc.. filters.

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.

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.

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

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

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?

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:
Don't be confused if you get these error if you uses Hybrid Compression:

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.)

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.

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.