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

lossyWAV 1.3.0 Development Thread

Reply #350
Unless I trip up on any bugs in the code, I will not be changing anything between RC10 and final release of 1.3.0.

Thanks (yet again) for the testing - encouraging results!
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 #351
Hi, as I have been using lossyWAV/FLAC almost from the begining (currently lossyWAV 1.2.0) for my FM radio archives. I decided to check the last 1.2.3 RC10. My typical 1.2.0 command line switch is only --altpreset and q. For my purpose I decided to use q=3.3 witch gave me compression ratio about 0.3 (compression 70% of the original WAV), and bitrate about 430 kbps. Complete process of compressing a 50 minutes file lasts for 50 seconds (lossyWAV + FLAC).

Now, as I checked  lossyWAV 1.2.3o RC10 I realized that I should use q -1.5 to have 430 kbps in the resulting FLAC. What more preprocess time rises to about 2 minutes 50 seconds, that is almost 3 times longer than for version 1.2.0!

What would be the advantage of using version 1.3 vs 1.2 when the resulting efects for the given bitrate are (?) comparable, but preprocessing runs 3 times longer then in lossyWAV 1.2.0?
I think I should stay with lossyWAV 1.2.0. Am I right?

lossyWAV 1.3.0 Development Thread

Reply #352
The quality preset system has been revamped - --standard is now -q 2.5; --portable is now -q -2.5.

The extra processing time is due to the adaptive noise shaping (which involves the creation and application of one 64-tap FIR filter per channel, per codec-block). This takes time.

Adaptive noise shaping does, however, change where the added noise due to bit removal (i.e. rounding off lower significant bits) goes. With no adaptive noise shaping the added noise is white and is applied pretty much evenly across the spectrum. With adaptive noise shaping the added noise is reduced in the audible range and enhanced above the audible range.

You could use 1.3.0 using "--adaptive off" - but you would probably be fine sticking with 1.2.0.
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 #353
Thank you, Nick, for quick explanation

lossyWAV 1.3.0 Development Thread

Reply #354
Full transcode of my collection, using beta 1.2.3o RC10 --quality extraportable --maxclips 0, results in 309kbit/s / 104GiB (lossless source 882kbit/s / 299GiB).
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 #355
50 downloads and no adverse comments - should I take this as a good sign?
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 #356
Yes, I tried all possible RC.. For me, the best is RC8. Closest to the original.
Best ratio (quality / size)
24bit/96kHz - lossywav - -q 10.0 --static 19 --silent --stdout | Takc -e -p4m -fsl16384 -ihs
16bit/44kHz - lossywav - -q 3.0 --static 16 --silent --stdout | Takc -e -p4m -fsl2096 -ihs

lossyWAV 1.3.0 Development Thread

Reply #357
Can you give us those parts of the tracks on which you can hear differences to the original?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #358
Forget all what i said. Finally i decided to convert to lossless only. (becauce i not want to hear difference, even any piece of sample Diversity in audio)

lossyWAV 1.3.0 Development Thread

Reply #359
Are you saying that you have successfully ABXed 24 bit 96kHz? If so, please provide a sample.

What you said is not so easily forgotten as you have made (as yet unproven) allegations regarding lossyWAV output created at settings which have been (up to now) considered to be transparent (due to lack of evidence to the contrary).
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 #360
How does it look for a final 1.3.0? More bug hunting?
No problems with casual use here.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.3.0 Development Thread

Reply #361
Most of the last few weeks has been devoted to the presentational side of output. I have put in place a new parameter -W, --width which allows the user to select the maximum width of various output information in the range 80 to 255 characters.

Prompted by Woodinville's histogram related post, I implemented a simple sample value count which outputs a histogram 64 bins wide.

Some major structural changes in the way the determination of bits-to-remove processing itself is carried out have been implemented - I'm much happier with the code now.

A few changes have been made to the adaptive noise shaping method. After reading the development thread again I have taken both the short FFT (default=64 samples for 44.1/48kHz) and long FFT (default=1024 samples for 44.1/48kHz) results into account when creating the desired shape of the filtered noise. This has had a few knock on effects on the code but no real impact on processing speed. The noise difference in critical samples (eig, furious) is (I believe) improved using this variant.

These small changes necessitate a small final beta test - volunteers?
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 #362
Thanks for the update. Sorry, I don't trust myself with ABX.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.3.0 Development Thread

Reply #363
lossyWAV beta 1.2.3p RC11 attached to post #1 in this thread. I sincerely hope that this is the last RC.
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 #364
First of all, thank you for this wonderful program.
My question is not close related to the development but as i see the creator of WavPack is also reading this topic so maybe this is the best way to ask you both.
To get to the point: i'm considering to encode my lossless collection into lossyWAV in hybrid mode. As far as i know i have to say during encode that i need a correction file and i have to encode the correction file also into some kind of lossless format (eg. FLAC). My biggest problem with this is that none of the PC software players can use these correction files currently. I have to do the restoration manualy if i need the original file.
On the other hand, i had some tests with WavPack hybrid lossless, and it works fine with Foobar and even with Winamp. If the correction file presents the player decodes the audio in lossless mode. Without the correction file i can listen to the lossy part (this way i can quickly copy some music to my Android phone without encoding anything). I'm wondering is it possible to feed the lossy and correction WAVs produced by lossyWAV to WavPack somehow to encode a WV/WVC pair or the lossy and lossless part encode algorithms are so sticked together in WavPack that this can't be done? This way you could use lossyWAV to produce the lossy/lossless part (with all of the improvements and the quality based mode) but you also have the compatibility of the WavPack hybrid format.

lossyWAV 1.3.0 Development Thread

Reply #365
My question is not close related to the development but as i see the creator of WavPack is also reading this topic so maybe this is the best way to ask you both.

What you are asking for makes sense, but (as you guessed) the algorithm for WavPack hybrid is not compatible with lossyWAV.

It would be possible to port the algorithm in lossyWAV that calculates “bits to remove” and create WavPack hybrid files that were equivalent to lossyWAV, but they would not actually have the LSBs zero like lossyWAV does, so you would lose the clever advantage of lossyWAV audio that it can be unpacked and compressed equally well with another lossless codec. Also, the adaptive noise shaping would not port directly (WavPack’s adaptive noise shaping is much simpler).

That said, if you like the way the WavPack correction file can be used by various players, why not just use WavPack hybrid mode? It does not adapt the bitrate to the actual audio like lossyWAV does, but I believe that WavPack still gives somewhat higher quality for the same bitrate. If you use a bitrate of 384 kbps for 16/44 audio it should always be transparent, and that can’t be much greater than the average you are getting from lossyWAV.

lossyWAV 1.3.0 Development Thread

Reply #366
why not just use WavPack hybrid mode?

I do so. However i don't like the idea to encode with an average bitrate. I already made a mistake in the past with using ABR MP3.  I'm using a 4bit/sample WavPack encoding setting for the lossy part now. It's only a matter of taste, it would be better for me to use a constant quality setting, at least it seems that bitrate fluctuates much more with a lossyFLAC file, than with a WavPack.  I know that setting post processing on WavPack encoding do some bitrate boost on cricital samples (i'm using x3 as suggested in the documentation)
I would sacrifice the lossless transcoding capability of the lossy part if i could store lossyWAV files in a "working" lossy+correction form. However as you describe this is already a lot of work to do.

 

lossyWAV 1.3.0 Development Thread

Reply #367
@darkbyte,

it sounds like a good question for the fb2k developer(s) - "can you support lossyFLAC+correction files please?"

some talented person could even make an input plug-in for Winamp.

It's "just" finding the correction file (if it exists) that corresponds to the current file, ? verifying it really does match ?, launching a second FLAC (or whatever) decode, and adding the results to the file that's already being decoded. And handling everything that you currently have to handle once (e.g. seeking), twice simultaneously and in sync.


If you're using FLAC for example, this would be a replacement FLAC decoder (that would fall back to standard FLAC decoder when there was no correction file, and when the input wasn't lossyWAV).

It may be worth considering if there's a more efficient way of doing this (and/or a more efficient way of storing correction date) before programming this.

Cheers,
David.

lossyWAV 1.3.0 Development Thread

Reply #368
it sounds like a good question for the fb2k developer(s) - "can you support lossyFLAC+correction files please?"

Okay, moved my question there  I found a similar topic here. It was created more than a year ago and there's no reply at all. Hopefully it could catch more attention this time.

lossyWAV 1.3.0 Development Thread

Reply #369
Don't like the --altpreset switch being eliminated. Also don't like the "new & improved" (AKA "Slow") adaptive noise shaping method. Telling somebody, also, to just turn it off isn't great, either. White noise getting applied "pretty much evenly across the spectrum" just isn't good enough. Compared to the official version, LossyWAV 1.3.0 comes off as a downgrade. Especially when I can use v1.2.0 to create files using the --extreme --altpreset --shaping switches to produces files that cut file sizes in half and give me the high quality transparency that I want, with encoding speeds that are 50% faster.

lossyWAV 1.3.0 Development Thread

Reply #370
White noise getting applied "pretty much evenly across the spectrum" just isn't good enough

I think you misunderstood the effect of the adaptive noise shapping. See bellow:

With adaptive noise shaping the added noise is reduced in the audible range and enhanced above the audible range.

Nobody is saying that 1.3.0 suites you better and, repeating what Nick.C said, "you would probably be fine sticking with 1.2.0".

lossyWAV 1.3.0 Development Thread

Reply #371
Don't like the --altpreset switch being eliminated. Also don't like the "new & improved" (AKA "Slow") adaptive noise shaping method.

The --altpreset lost it's meaning (in the new version) as all presets are newly tuned and the quality scale has changed. It would be more confusing to have old and new quality scales and trying to bring those into some kind of relation. Apples and Oranges kind of thing.
The speed penalty for Adaptive Noiseshaping is maybe unfortunate, but at least Nick is trying to push the limits of the lossyWav method. I suppose it's up to you if you'd like to stick with 1.2.0.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.3.0 Development Thread

Reply #372
.... but RastaMan's comment has prompted a potential development:

to implement a fixed shaping method which would disable adaptive noise shaping and

- use the old fixed noise shaping; [not my preferred option]

or

- use a newly implemented FIR version of Sebastian G's IIR shaping method (using the new method of bit-removal with FIR shaping). [my preferred option]
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 #373
Finished a full collection transcode using beta 1.2.3p RC11 with "-q X --maxclips 0" resulting in 307kbit/s (from 882kbit/s lossless FLAC).
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 #374
I tested 1.2.3p RC11 -q X in my usual way.
With eig I arrived at 6/7 which turned into 7/10.
With furious, sec. 0 ... 0.8, I had no chance and stopped at 1/5.
With furiuos, sec. 1.9 ... 2.8, I arrived at 4/4 which turned into a 7/10.
So, as with more or less all my latest tests, I can't ABX my usual problem samples, though I guess people with better ears are able to ABX at least eig.

Anyway, for -q X it's a great result to me.
lame3995o -Q1.7 --lowpass 17