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: lossyWAV 1.4.2 Development (was 1.5.0) (Read 128023 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #175 –
@Nick.C :
I don't know what is going on here, but when trying the setting in your signature, and compressing with MP4ALS (encoder here), it just becomes unresponsive. Which is a flaw in that software, but:

It works fine with 1.4.2-processed files!

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #176 –
It could be another manifestation of the padding bugs that have recently been bothersome, or it could be that the MP4ALS program does not deal with odd length chunks properly (and that the 'fact' chunk length is odd).

Are you processing to WAV then using the codec or are you piping direct? If the former then some issue with the 'fact' chunk is more likely to be the culprit.

[edit] After processing 55 sample test set to WAV with Beta 1.4.3e I can confirm that the length of the 'fact' chunk with the settings in my signature is odd, and correctly zero padded with one extra byte (that does not form part of the stated chunk length), and encoding with FLAC works perfectly - so I strongly suspect that the issue lies with MP4ALS not dealing with zero padded odd length chunks. [/edit]

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #177 –
Please find attached a new beta release of lossyWAV.

lossyWAV beta 1.4.3f, 26/05/2024 (expires 31/12/2024)
  • Due to two reported cases of apparent issues with encoders not dealing with odd length chunks properly a padding byte is now added to the end of the settings string contained in the 'fact' chunk of lossyWAV processed files, if the length of the string is initially odd, and the size of the 'fact' chunk will now always be even.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #178 –
Lossywav support was added to HALAC. In version 0.2.9, it will be shared with other arrangements. The Lossywav format is detected from the "fact" keyword in Header. And in this case a different mode is switched. If the "-fast" parameter is used, it is disabled.
However, I am currently sharing Encoder and Decoder, which is available for test. The results are not bad for starting in terms of speed/compression ratio. Encode speed is considered the same as HALAC Normal. However, the decode speed is much more (prediction process was not used)! Rice coding has not been used yet and the block size is 2048.
All other codecs are at the highest compression level in the default settings. And single thread results...
Code: [Select]
İskender Paydaş - Zamansız Şarkılar (2011)
10 Tracks, 469.385.056 bytes, i7 3770k, 16 gb ram, 240 gb ssd.
Wma      :  19.06,  11.26, 174,956,882
Flac     :  18.76,   4.73, 175,805,836
Halac    :   2.37,   1.81, 191,318,610
Tak      :  20.27,   7.18, 193,906,253
Wavpack  :  29.40,  16.38, 230,017,269
OptimFrog: 184.12, 111.69, 254,001,399
Monkeys  :  59.42,  63.83, 325,501,439
Alac     :  18.83,   8.87, 340,827,308

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #179 –
Some bitrates. Here I took the LossyWAV settings in Nick.C's signature. Lossy part only.
For those with a "+", then the first number is with block size set to 512, and the "+25" etc is the extra when using 2048 like HALAC does.
275   ...   ALS, smallest
287   +25   ALS -l
292    +9   TAK -p4m
318   +11   FLAC -5
327   +13   WavPack -hhx4
353   +27   FLAC -0r0
387     -   HALAC (2048 blocksize)
725         HALAC but without the identifying FACT chunk
1411        wav


Speeds then?

Comparing to FLAC encoded with -0r0 --no-md5sum --keep-foreign-metadata and block size set:
6.6 resp 7.9   FLAC encode to 2048 resp 512
9.0 HALAC encode

But HALAC decodes faster:
7.3 HALAC decode
11 FLAC decode these MD5-less files with --keep-foreign-metadata, maybe differing some tenths over block size used.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #180 –
According to the compression results of me with the music in me, the situation is similar to the majority of the tests I have performed. Of course this is the first trial. Better can be done. Lossywav is activated as a special mode for now.
They also perform low performance as I don't understand the reason for Alac, Optimfrog and Ape.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #181 –
The idea behind LossyWAV was to exploit FLAC's wasted bits feature. And IIRC the reason for 512 samples blocks, is that then the number of wasted bits can change rapidly enough as the signal does.
TAK handles wasted bits. MPEG-4 ALS does (but you need to invoke the "-l" switch). WavPack too - and it can also handle other "redundant LSBs patterns" ( https://hydrogenaud.io/index.php/topic,121770.msg1024689.html#msg1024689 , and WavPack's handling is also likely the reason why it does so well on the high resolution lossless corpus in ktf's test: see the Pokemon on page 7).

ALAC does not handle wasted bits. Either because ALAC generally sucks, or because Apple was worried about some patent.
Monkey's does not handle wasted bits. Unlike ALAC, which never was intended to be a heavy compressor, it is more of an oversight for Monkey's, I say: take a 16 bit signal, pad it to 24, and the ape compresses baaad.
OptimFROG does handle wasted bits, but it does not operate on such low block sizes. Indeed, both the animals seem to think that longer is better, and then there is this odd signal where they get outcompressed by FLAC's way to handle ultra-short changes in the signal. Here is one where OptimFROG does awesome, but only in its lightest mode (shortest blocks I guess): https://hydrogenaud.io/index.php/topic,124862.msg1038820.html#msg1038820
More: https://hydrogenaud.io/index.php/topic,122413.0.html

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #182 –
Many thanks for the illuminating information Porcus. According to the sample music in the link you show, the test results are as follows. There is no difference between the normal state of music and the lossy of the state.
Code: [Select]
00 - Dan Worrall - I Won The Loudness War
Halac (2048) :    466,531
Tak (512)    :    685,202
Flac -8 (512):    904,162
Wma          :    917,077
Flac -0 (512):  1,121,225
Wavpack (512):  1,321,353
Ofr          :  1,991,918
Alac         :  3,215,927
Ape          :  7,597,601
Wav          : 15,211,284

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #183 –
Yeah, so that is one where LossyWav doesn't zero out anything that wasn't already zero (you find F800 and 0800 all over, except some 0000 at the beginning) - so in one way it is off topic to a LossyWAV thread (my bad for bringing it up if so), and on the other it shows why there is LossyFLAC and LossyTAK, but not LossyAPE.

I do get the frog down to 224 399, attached. And WavPack down to 348 022.

HALAC doesn't have very expensive block headers?
 

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #184 –
I can get 339,316 when I increase the block size to 32k. However, we cannot generalize this to everything. As far as I understand, the optimfrog arithmetic coder should be using something. Because only Rice coding cannot go down from a certain limit.

Yes, HALAC uses tANS as an entropy encoder and contains considerable side information for each block. Therefore, very small blocks are not suitable in terms of both processing speed and compression ratio. In other words, this sample is created for the file for the 1900 blocks and there are probability distributions, etc. for each.