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: WavPack VBR (quality oriented) mode (Read 40000 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack VBR (quality oriented) mode

bryant, are you going to implement some quality mode in WavPack? Three years ago you wrote: "I would someday like to add a VBR “quality based” mode to WavPack hybrid (which would counter one advantage of LossyWAV)". Maybe the time for it has come? I do not see, how it is possible to be satisfied with ABR, because for some files 192 kbps is enough, and some needs 400+ kbps. Using 400+ kbps for all files hits file size, while using lower bitrate hits quality.

WavPack VBR (quality oriented) mode

Reply #1
I would like this too. I still think you will end up with 350..400k for normal signals but critical signals could get a lot more. Moreover, quality differences between the modes will be eliminated.

ABR is less flexible but not really worse than VBR in the higher bitrates. As you said 400+k would suffice but is wasteful. For lossywav I find that without noise shaping you also need a similar rate and 350k at the very least. I think with these codecs to cannot achieve consistently good quality and make it alternative to the TC: you need double the rate  - 300k or more.

Currently I find a setting of -b4 -x5 to be sufficient so far on my collection of 400 cd's. This yields 370k on average.

WavPack VBR (quality oriented) mode

Reply #2
Although i'm testing Opus nowadays for portable use i vote for this. It would be still awesome if the achievements of LossyWAV could be more tightly intergrated with WavPack hybrid for example.

WavPack VBR (quality oriented) mode

Reply #3
Currently I find a setting of -b4 -x5 to be sufficient so far on my collection of 400 cd's. This yields 370k on average.

Do you remove .wvc files (permanently)?

WavPack VBR (quality oriented) mode

Reply #4
I still would like to work on this as an enhancement to the lossy mode some day, but the problem is that I really don't know how to go about it. I tried a real psychoacoustic hearing model early on but abandoned it when it didn't work well. I have thought about adding some simple analysis that would tweak up or down the bitrate (maybe based on a tonality estimate) but I'm not sure if that would work well either. I don't have the time to get involved with the level of testing and tweaking that LossyWAV went through, and I don't think I can use the LossyWAV algorithm directly because I would end up with the exact same bitrate.

If anyone else wanted to give this a shot I would be happy to help and bounce ideas around, but at this point I don't have the spare time to put any effort into it myself.

WavPack VBR (quality oriented) mode

Reply #5
Currently I find a setting of -b4 -x5 to be sufficient so far on my collection of 400 cd's. This yields 370k on average.

Do you remove .wvc files (permanently)?



I think its not a bad idea to back them up (.WVC) to external HDD or optical media. Use only .WV as your main collection and include them in your backup routine.


To be clear I am usually happy with lame 150..200k as long as you don't use DSP, transcode, have unusual listening habit, have or listen to particular troublesome samples. In that sense lossless offers little to no benefit and ripping straight to Lame -V3 is fine with me. I would however like the ability to transcode to another format, bitrate or even CBR.  I would like high quality - some thing a bit more than mp3. At the same time like yourself I consider lossless excessive: 370k vs 870k. The ability to go lossless may also be important and mp3, mpc, acc ,ogg don't make that easy or possible at all.

-

WavPack VBR (quality oriented) mode

Reply #6
I still would like to work on this as an enhancement to the lossy mode some day, but the problem is that I really don't know how to go about it. I tried a real psychoacoustic hearing model early on but abandoned it when it didn't work well. I have thought about adding some simple analysis that would tweak up or down the bitrate (maybe based on a tonality estimate) but I'm not sure if that would work well either. I don't have the time to get involved with the level of testing and tweaking that LossyWAV went through, and I don't think I can use the LossyWAV algorithm directly because I would end up with the exact same bitrate.

If anyone else wanted to give this a shot I would be happy to help and bounce ideas around, but at this point I don't have the spare time to put any effort into it myself.

It is sad, because if you don't do it, probably nobody will. Some first step is needed, then, at least, some testing will be possible. Currently there is nothing to work with.

I think its not a bad idea to back them up (.WVC) to external HDD or optical media. Use only .WV as your main collection and include them in your backup routine.

This is not my case, I would like to drop it permanently.

WavPack VBR (quality oriented) mode

Reply #7
Perhaps making an experimental encoder using simple tonality estimation would be a start. Maybe if it works with the current DNS quality might be better than expected.

WavPack VBR (quality oriented) mode

Reply #8
Currently I find a setting of -b4 -x5 to be sufficient so far on my collection of 400 cd's. This yields 370k on average.

Do you remove .wvc files (permanently)?


I would too. But keeping them is not always for quality reasons. It just adds flexibility . One thing is that these days I am against using the -hh or even -h for lossy mode as I find a normal mode + -x to work better without altering decoding speed. I still have old encodes with -hh and cannot reverse it.

I find it easy to move the correction files to a zip archive dump that file offline.

I don't think one has to distrust ABR.  Its true that a proper tuned VBR is ideal, but the current system is also safe even for high demand using -b350x5 . The -x and -dns are doing constant analysis to prevent quality from falling too much. So there is a very basic 'psymodel' in place.

WavPack VBR (quality oriented) mode

Reply #9
I've experimented further this time with the aim to find *consistent* behavior at 'economical bitrates' < 400+k . The aim is high-extreme high quality for those who dont want to keep correction files, a possibility to transcode to mp3 or other lossy and a substitute to lossywav.

I arrived at -b320hhx6 as the lower end economy setting and -b380hhx6 as the top end setting. The lower setting is probably enough for nearly all commercial CD's . Bad cases may be a slight elevation of hiss probably not perceptible at normal listening situations  -b380hhx6 can be used for rare CD's or paranoid needs. Of course 500k will also do but the aim is economy and quality without correction files. -h may be used instead of -hh for those concerned with portable use. There may be a slight quality decrease. For PC archiving / use I'd go with -hh. -x5 also works well and can save %20 encode time. To minimize CPU load when multitasking , the -l switch can be used.  I also noted a positive improvement using -b320hhx6 --blocksize=4410.

 

WavPack VBR (quality oriented) mode

Reply #10
I've experimented further this time with the aim to find *consistent* behavior at 'economical bitrates' < 400+k . The aim is high-extreme high quality for those who dont want to keep correction files, a possibility to transcode to mp3 or other lossy and a substitute to lossywav.

Thanks for documenting your experiments, shadowking! These pretty much match my expectations and matches what I use (except I use 384 kbps just because it's a “standard”, which is a little silly on my part because WavPack lossy does not hold the bitrates that tight anyway).

One thing interesting though is your observation about short blocks helping. I have suspected that the “extra” modes might benefit from shorter blocks because that would allow the predictors to be tuned more quickly to changing audio. However, you might want to check the actual resulting bitrates because the overhead associated with each block will be greater, especially with -hh (the higher modes have longer headers).

David

WavPack VBR (quality oriented) mode

Reply #11
I did some more tests. --blocksize=4410 adds 6 /8 / 9 kbps to normal / -h / -hh.  So yes its not a lot but the -hh seems to suffer more than default mode with bloat.  I started wondering about an alternative route using the normal mode. This decreases decoding overheads and allows faster encoding. I still want economical bitrates if possible. I know in the past I used an inflated bitrate to counter the quality loss going from high modes to normal.  I started with 350x6 and 410x6 as the upper limit.

I also tested the Atem lied sample again at medium volume. I could abx 320hhx6, 350hhx6 and the --blocksize=4410 variant. There is one spot that is not to hard to abx. I felt --blocksize=4410 was better but could not prove it with this sample. At 384hhx6 i was defeated several times in abx but -b384x6 was much inferior. Using my upper end alternative of -b415x6 was the solution. I tried -b415x4 and was equally impressed.  I tried -b384x6 which was easy to abx, this time with --blocksize=4410 and there was really an improvement. I arrived at 6/8 vs 9/10 for -b384x6.

My alternative [faster] but higher bitrate version using the normal mode:

350 ~ 415k using at least -x4.  --blocksize=4410 may also help - bitrate increases by 1.5 %.  Average bitrate is 367 ~ 433.

WavPack VBR (quality oriented) mode

Reply #12
At 384hhx6 i was defeated several times in abx but -b384x6 was much inferior. Using my upper end alternative of -b415x6 was the solution. I tried -b415x4 and was equally impressed.  I tried -b384x6 which was easy to abx, this time with --blocksize=4410 and there was really an improvement. I arrived at 6/8 vs 9/10 for -b384x6.
Very interesting indeed, thank you very much.
I know you're trying to steer clear of high modes, but do you think you could find the time to test -b384hx6 with default block size (or even better -b4hx6)?
That's what I'm using, since my Android smartphone can handle the workload with just a minor hit on battery life, and your ears are waaay better'n mine, thanks.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack VBR (quality oriented) mode

Reply #13
I wonder if it's feasible to achieve good quality with WavPack lossy in the 275-320kbps bitrate range on CD audio. That's what i am using for high quality lossy setting at the moment (lame3100k -V1 --cvbr 8 or Ogg Vorbis q8) and because i'm listening to more and more music with A2DP on my car headunit i thought i could achieve better sound quality by using a non transform codec encoded audio on my phone which doesn't do spectrum manipulation which propably makes the stupidly simple SBC codec's job harder. PowerAMP already decodes WavPack very well, i've used such lossy files in the past but maybe a 384kbps wv lossy is overkill in portable environment or in a noisy car, so i wonder how safe is to move lower in bitrate. From WavPack's doc i can see that a 256kbps WV is quality wise somewhere between a 160kbps and 192kbps mp3. Is that still true? How about a 275kbps wavpack? Can it achieve a quality of a 224kbps mp3? I know it's all theoritical without ABX-ing but maybe somebody already tried this.

WavPack VBR (quality oriented) mode

Reply #14
I think quality should be excellent down to 285k and similar to high VBR mp3. Experiment and use your own music rather than test signals. If encoding time isn't critical you can use a high -x setting alone or in conjunction with -h for additional headroom.

WavPack VBR (quality oriented) mode

Reply #15
I'll give it a try, thanks.

I know the general opinion is to avoid -h when coding for portable devices but i wonder how big the penalty is when i use this switch? WavPack is a simpler codec than mp3 so decoding should be less CPU demanding. Using the -h switch should be still in the same or lower class than decoding and mp3, right? If i'm thinking right using the -h switch is not so evil considering the quality boost it provides on lossy encoding, especially on such low bitrates what we are talking about here.

WavPack VBR (quality oriented) mode

Reply #16
@darkbyte: As mentioned in my previous post I use -b4hx6 lossy files on my Android smartphone (HTC One SV) with a really minor hit on battery life.

@shadowking: I know you're trying to steer clear of high modes, but do you think you could find the time to test -b384hx6 with default block size (or even better -b4hx6)?
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack VBR (quality oriented) mode

Reply #17
Thanks DARcode! I'll give it a try

Not closely related but i've wondered if it's possible to modify WavPack lossy in such way to allow different sampling rate in the lossy layer. Say i have a 88.2Khz 24bit audio file but i only want 44.1Khz in the lossy layer encoded with 4bits but keep the 88.2Khz 24bit audio with the correction applied. Currently i can't do this because the lossy layer's sample rate must match the correction file's one. This yields a lot higher bitrate in my case. I wonder if this difference could be handled somehow.

WavPack VBR (quality oriented) mode

Reply #18
At 384hhx6 i was defeated several times in abx but -b384x6 was much inferior. Using my upper end alternative of -b415x6 was the solution. I tried -b415x4 and was equally impressed.  I tried -b384x6 which was easy to abx, this time with --blocksize=4410 and there was really an improvement. I arrived at 6/8 vs 9/10 for -b384x6.
Very interesting indeed, thank you very much.
I know you're trying to steer clear of high modes, but do you think you could find the time to test -b384hx6 with default block size (or even better -b4hx6)?
That's what I'm using, since my Android smartphone can handle the workload with just a minor hit on battery life, and your ears are waaay better'n mine, thanks.



I've done some more tests and I'll report in the next few days.

WavPack VBR (quality oriented) mode

Reply #19
I'll give it a try, thanks.

I know the general opinion is to avoid -h when coding for portable devices but i wonder how big the penalty is when i use this switch? WavPack is a simpler codec than mp3 so decoding should be less CPU demanding. Using the -h switch should be still in the same or lower class than decoding and mp3, right? If i'm thinking right using the -h switch is not so evil considering the quality boost it provides on lossy encoding, especially on such low bitrates what we are talking about here.



I don't think adding -h will have a negative effect on any modern device. Bryant made it for portable use when -hh gave an ipod some trouble so the advice was to avoid -hh  . My old pentium 550mhz easily played wavpack lossy -hh and monkeys audio (high). I tested poweramp last year and -hh wavpack lossy was no problem at all (25 % vs 18 % normal mode cpu) . -h is probably somewhere in between. Transcoding is faster with normal and fast modes though . If I want to make quick mp3s the normal mode has the advantage.

WavPack VBR (quality oriented) mode

Reply #20
Ok I tested atemlied and other problem samples over the last few weeks. Taking into account the original goal of lowest possible bitrate for archiving - there is  concern at using 450..500k bitrates to achieve constant quality &  different settings for different samples.
I found that combining -h / -hh with -x6 / x5 brings much more stable quality across the board that becomes apparent starting from 380k. In other words extreme high quality kicks in at that level. Average bitrate is 390..400  . I believe even the worst cases are either eliminated or greatly reduced close to nil while normal signals are always perfect. For me that is acceptable for archiving. I

results of atemlied:

b4hx6 = 13/16
b384hx6 = 10/16
b380hhx5 = 11/16
b380hhx6 = 2/9
b380hhx4 = 11/16

WavPack VBR (quality oriented) mode

Reply #21
Thank you very much shadowking, appreciated.
Now let's see if I got it right: since you've never scored 12/16 or better with anything else besides b4hx6 it means all other settings produce actual transparency to your ears right?
b4hx6, my choice, and b384hx6 are pretty close in terms of average bitrate produced, so how come the difference you think?
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack VBR (quality oriented) mode

Reply #22
The 30kbit difference is around 2db noise. That could be significant when noise within hearing threshold.

I also tested the lower redesigned x-1 ~ 3. These were supposed to be used for daily tasks and offer a practical improvement in compression / speed / quality. I find that the defensive mechanisms kicks in at -x2 and its much faster than -x3 and yields similar quality or compression. In comparison to -x(1) -x2 is always better to my ears , compresses better and still fast.  It seems to work well with -h and -hh  .

WavPack VBR (quality oriented) mode

Reply #23
Compression speed with b380hhx6  is very slow so i wonder how much bitrate should i spend if i like to use the fast mode instead but still achieve transparency in hybrid mode. I'm curious about fast mode because encoding my whole collection takes a lot time and i'm also working on a Wavpack decoder written in Dart and i can achieve considerably lower CPU usage by decoding fast mode encoded files.

I've tried b420fx4 yesterday and it gave a very good 45x compression speed on my computer instead of 6-12x compression speed with b380hhx6.
I wonder how transparent is this setting for you shadowking? In the final average bitrate it's only 40-50kbps higher for me than the what you suggested which is acceptable (around 448kbps for me) but it's a lot faster.

WavPack VBR (quality oriented) mode

Reply #24
I would not presume to speak for shadowking, but my initial reaction would be to not recommend the “fast” mode if quality is a high concern (and that is definitely the point of shadowking's testing). The “fast” mode only provides two decorrelator passes for the “extra” mode to work with, so it's pretty limited in what it can do in difficult situations. However the default mode provides five, which gives it a lot more flexibility.

Without a comment from shadowking, my guess is that b420x4 would provide the same quality margin as his version, and still be reasonably fast to encode and easy to decode.