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.3.0 Development Thread (Read 199593 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.3.0 Development Thread

Reply #175 –
After some bug-hunting (with a bit of brain-failure mixed in), I have concluded that any difference in added noise per channel Chris encountered processing stereo signals with similar energy / spectral shape in each channel can be put down to the clipping prevention kicking in and reducing the bits-to-remove for enough codec-blocks to make an observable difference.

[edit] Clarity [/edit]

Chris,

I would suggest that you repeat your test with "--maxclips 16" in your command line.

Nick.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #176 –
On another note:

Lossy WV is considered not efficient compared to flac. I am pleased to find that its more competitive (in some cases a lot) when using the -x switch. The sweetspot between size / speed seems to be the normal mode using -x levels 1-3.  The fast mode also benefits a lot. For some reason the high modes don't bring any gain except making encoding / decoding slower.

lossyWAV 1.3.0 Development Thread

Reply #177 –
Tonight, I completed a transcode of my music collection using beta v1.2.2s "-q -2 -A 96 -t" which resulted in 302kbps.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #178 –
Thanks, Nick, for the long explanation! So it is "slightly" more complicated than I thought

Quote from: Nick.C on
I would suggest that you repeat your test with "--maxclips 16" in your command line.


Did that, the result is bit-identical to not using the switch. The test item, SQAM #2, is far from clipping, anyway (peak level -34 dB).

Chris
If I don't reply to your reply, it means I agree with you.

lossyWAV 1.3.0 Development Thread

Reply #179 –
Right then, time to don the pest control gear and go bug-hunting again....
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #180 –
Took a look at SQAM 2 again, the channels actually have slightly different levels of DC offset/LF rumble. Could that be the reason? Which window function are you using in your FFTs?

Chris
If I don't reply to your reply, it means I agree with you.

lossyWAV 1.3.0 Development Thread

Reply #181 –
The Hanning window is used.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #182 –
Though the actual discussion might show up a problem with lossyWav, at least there is no obvious different treatment of the left and right channel for SQAM sample #2 within lossyWAV:
The error (the correction) file is bit-identical for 02.flac and the channel-swapped error-file of the channel-swapped 02.flac. I used sox for channel-swapping.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #183 –
Interesting. Thanks, halb27! So it must be related to either the LF or HF differences in the signal. Nick, what happens when you let the masking analysis start at, say, 40 Hz instead of 20 Hz?

Edit: That should fix it. I manually removed the (minimal) DC offset from the right channel, and now it looks better. 20 Hz is probably too close to DC when you use a Hann window.

Chris
If I don't reply to your reply, it means I agree with you.

lossyWAV 1.3.0 Development Thread

Reply #184 –
Quote from: shadowking on
Lossy WV is considered not efficient compared to flac. I am pleased to find that its more competitive (in some cases a lot) when using the -x switch. The sweetspot between size / speed seems to be the normal mode using -x levels 1-3.  The fast mode also benefits a lot. For some reason the high modes don't bring any gain except making encoding / decoding slower.

I agree that removing the -h from the example command-line and replacing it with a -x (or even -x3) would be a better trade-off for WavPack. Thanks for pointing this out!

BTW, the reason that the higher modes do not provide additional compression is because the block headers are significantly larger for the higher modes. With only 1 or 2 blocks per second this is insignificant, but with the extremely short blocks associated with LossyWAV these larger headers are no longer offset by the better compression of the data itself.

lossyWAV 1.3.0 Development Thread

Reply #185 –
In the lossyWAV wiki, there's a paragraph mentioned that lossyWAV may work with MLP via "Bit-Shifting". Has anybody ever tested it?

As I know, MLP (Dolby TrueHD) is designed for multi-channel lossless compression, which indicate that it might not work well with 2-ch music from CDs. I'm very curious to know if lossyWAV can work well with multi-channel audio streams together with FLAC and MLP.

Can anybody in this forum has the opportunity to do the corresponding tests?

lossyWAV 1.3.0 Development Thread

Reply #186 –
Looking to the next release:

Is anyone using -X, --sortspread? If not, I will remove it as it complicates the code and slows things down a little.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #187 –
If nobody uses it I welcome removing it.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #188 –
Sounds good to me - it's history....
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #189 –
lossyWAV beta 1.2.2t attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #190 –
Hi Nick,

i am working on a dedicated LossyWav codec for the next TAK release (quite a lot of work illustrating my appreciation for your and 2Bdecided's work  ). If it will be released depends on the advantage over TAK's standard codec i can achieve. Currently i am getting about 1.5 percent better compression and i am aiming for 2 percent (relative to the original file size). IMHO this would be worth a release.

Among other things this codec can process small frames more efficiently. This raises the question, how small LossyWav's block sizes can get, if a codec can process them without a significant penalty. Currently the new codec supports a minimum block size of 256 samples. Do you think, even less could be advantegous?

lossyWAV 1.3.0 Development Thread

Reply #191 –
A 2% reduction over TAK sounds like quite a challenge! Thank you for taking the time to implement lossyWAV specific algorithms in TAK.

Although smaller blocks may reduce specific output size (due to more bits being removed on average), the size of any block header should be taken into account. At present the codec-block-size for lossyWAV is 512 samples for 44.1/48kHz audio with a maximum of 4096 samples for 352.8/384kHz. I worry that you may get into a situation where the smaller block size is less efficient due to block related information rather than the compressed audio itself.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #192 –
Quote from: Nick.C on
Although smaller blocks may reduce specific output size (due to more bits being removed on average), the size of any block header should be taken into account. At present the codec-block-size for lossyWAV is 512 samples for 44.1/48kHz audio with a maximum of 4096 samples for 352.8/384kHz. I worry that you may get into a situation where the smaller block size is less efficient due to block related information rather than the compressed audio itself.

Of course, but the new codec can cope a lot better with small block sizes. If it requires only the modification of a constant, could you please send me a V1.2.0 with a block size of 256 samples for 44.1 KHz audio?

lossyWAV 1.3.0 Development Thread

Reply #193 –
I'll have a look and get something to you, hopefully this evening.

[edit] eig file attached, codec-block-size=256 samples. [/edit]

[edit2] file removed - not required. [/edit2]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #194 –
Quote from: Nick.C on
[edit] eig file attached, codec-block-size=256 samples. [/edit]

Thank you Nick. And sorry. I wasn't clear enough.

What i really need is a modified version of LossyWav V1.2.0 working with a block size of 256. I have to perform a lot of tests on my test corpus to be sure, if such a small blocksize is advantegous for the new codec.

It's not urgent.

Thank you

  Thomas

BTW: About 2 percent better compression is definitely possible, even with the default block size of 512. Currently i am close to 1.8 percent for my primary test corpus.

lossyWAV 1.3.0 Development Thread

Reply #195 –
I'll work on something not quite so agricultural as the version I created the test version of eig with. Please PM me your e-mail address so that I can e-mail you the test executable.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #196 –
lossyWAV beta 1.2.2w attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #197 –
Thank you, Nick, for the new version.

Though I decided to use mp3 (because of family/friend related compatibility issues) I'm still very excited about lossyWAV development.
I didn't have much time recently for lossyWAV (I was in hospital, and after that was busy with other things), but I hope I can do some more listening tests in the near future, especially as the new version is a good reason to do so.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #198 –
Again, many thanks for all of the testing that you have carried out over the period of development so far!
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.3.0 Development Thread

Reply #199 –
Hi,
I don't understand much of what LossyWav does, however one thing bothers me.  What is the purpose of --limit? Does it mean LossyWav ignores everything above 16kHz?