Skip to main content ↑ ↓
Topic: WavPack 4.5 beta available (Read 57951 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.5 beta available

Reply #25 –
Quote from: bryant on
I just checked and it does not seem to retrieve the RG info from WavPack files. It seems to work at first because they have a -9 dB default gain, but I tried a song with a positive RG value and it still got softer when I turned it on... 

You're right, my mistake

WavPack 4.5 beta available

Reply #26 –
Quote from: bryant on
BTW, I have updated the beta package with an executable installer for the Winamp plugin instead of just having the DLL in there. The plugin itself is the same, but any testing on the installation is appreciated...thx!


I've tried installing it on XP 64 and installation went smoothly and everything seems to be working fine!

WavPack 4.5 beta available

Reply #27 –
I did a quick transcoding test using 4.5b . I wanted to test the upper 200k range.

I encoded a track - paradise lost - pray nightfall to lossless and to wavpack lossy 270 k -x. I encoded the two files to Lame -V5

I wanted a quick abx here and there and no more than 8 trials. This was not easy . The best I could do was 6/8 (a feeling) on one part and 7/8 on another. It was also hard to even find motivation to get to 8 trials as i started to tire. Everything just sounded nice  . Differences (my feeling and not easy to abx) is maybe a subtle over aggression on high hats - no obvious artifacts that we normally encounter with lossy.

I will try more with time but my impression is that 270 k is very usable and can very good quality for listening and also for transcoding to other lossy.
wavpack 4.8 -b256hx6c

WavPack 4.5 beta available

Reply #28 –
Quote from: soiaf on
I've tried installing it on XP 64 and installation went smoothly and everything seems to be working fine!

Thanks, I don't have easy access to any XP 64 installs! 


Quote from: shadowking on
I will try more with time but my impression is that 270 k is very usable and can very good quality for listening and also for transcoding to other lossy.

Thanks, this is a useful data point. Since I have added the dynamic noise shaping I have definitely been using 256 kbps more often.

I have even run some tests comparing that bitrate with various LAME (3.97) CBR bitrates using my 160 sample test corpus and EAQUAL (whose results obviously must taken in context). Anyway, the results show WavPack at 256 (-hx4) coming in somewhere between LAME 160 and 192. And even this might be conservative because EAQUAL is supposedly poor at detecting pre-echo which WavPack is immune to. For what it's worth... 

BTW, I have now added the CoolEdit / Audition filter to the beta package. This includes the dynamic noise shaping (obviously) and I also added an About button and promoted the Extra Processing from a checkbox (which gave -x3) to a slider allowing the full 0-6 range to be set. Enjoy...

WavPack 4.5 beta available

Reply #29 –
bryant, do you have plans to add information about the wavpack version and compression settings used into the WV header? It's something that would be useful for transcoding wavpacks of mixed compression to new wavpack encodes, so it's possible to skip redundant transcodes.

WavPack 4.5 beta available

Reply #30 –
Quote from: bryant on
[...]the results show WavPack at 256 (-hx4) coming in somewhere between LAME 160 and 192[...]
Could I consider that your recommended setting for 256 Kbps Hybrid please?
Relevant improvement over hx3?
Thank you.
WavPack 5.3.0 -b384hx6cmv / qaac64 2.69 -V 100

WavPack 4.5 beta available

Reply #31 –
Quote from: Fandango on
bryant, do you have plans to add information about the wavpack version and compression settings used into the WV header? It's something that would be useful for transcoding wavpacks of mixed compression to new wavpack encodes, so it's possible to skip redundant transcodes.

I have never been too keen on storing actual version information in WavPack files because the method I used to do regression testing is to simply compare the md5 sums of the results of various operations on a set of files between reference versions and the version under test. That said, I do occasionally bump the stream version so I can get some idea what era a stream came from (I did this for this version).

However, whenever a new feature or mode is introduced I will always provide enough information in the headers to identify such files. For example, in the 4.50 version of WvUnpack it will be possible to tell if a hybrid file uses dynamic noise shaping because I will add this to the list of modalities. Finally, I am also going to be adding the extra mode numeric parameter to the information stored because currently one can only determine whether or not the extra mode was used.

I think that in all reasonable situations this should be enough information to determine whether or not a WavPack file should be re-encoded.


Quote from: DARcode on
Quote from: bryant on
[...]the results show WavPack at 256 (-hx4) coming in somewhere between LAME 160 and 192[...]
Could I consider that your recommended setting for 256 Kbps Hybrid please?
Relevant improvement over hx3?

Well, I think I have always recommended the highest "extra" mode that you (and your computer) have the stomach for! 

I like -x4 because it generates custom filters that will in some rare cases fix things that -x3 won't catch, however I realize that there's a big hit in speed between -x3 and -x4. Maybe it's just because I spent so much time on the -x4 to -x6 codebase that I want to make sure that somebody is using it, even if it's just me! 

WavPack 4.5 beta available

Reply #32 –
Quote from: bryant on
... Maybe it's just because I spent so much time on the -x4 to -x6 codebase that I want to make sure that somebody is using it, even if it's just me! 

I've been a -x5 user so far together with normal mode. I don't care much about encoding speed, and it's fast enough on my system especially as it's not often that I encode losslessly. I've been thinking about going a bit lower like -x4 or -x3 (and maybe I'll do it), but to me encoding time of -x5 is no pain.
lame3995o -Q1.7
opus --bitrate 140

WavPack 4.5 beta available

Reply #33 –
Quote from: halb27 on
Quote from: bryant on

... Maybe it's just because I spent so much time on the -x4 to -x6 codebase that I want to make sure that somebody is using it, even if it's just me! 

I've been a -x5 user so far together with normal mode. I don't care much about encoding speed, and it's fast enough on my system especially as it's not often that I encode losslessly. I've been thinking about going a bit lower like -x4 or -x3 (and maybe I'll do it), but to me encoding time of -x5 is no pain.



Since I'm loathe to put in too much time into testing & research, I don't think one could do much worse than what the developer is doing for his own compression needs. -x4 must be the best compromise. Yeah, it slows things down...but just once during the encoding.

That said I'm very skeptical about the new dynamic noise shaping if only because I haven't read the source code and/or there is little layman's explanation about whats going on other than 'hey this really works great!!' kind of posts. I've been happy with 4.41 -s0 lossy mode at high bit rates if only because I understand whats going on. I always intellectually feel that it represents a better 'average' noise distribution...more of a jack of all trades sort of thing that I'm more comfortable with. It also seems to put out similar numbers using -hh with -s0 compared with any -x mode and with far better speed on encoding. I'm fascinated with the potential of DNS but have to admit that not being a good code decipherer I'm uncomfortable with something that I don't understand. Would it be possible to write up a small white paper on this technique geared more to the layman? That would be much appreciated.

dog

WavPack 4.5 beta available

Reply #34 –
David, thanks for the release =)

There's one feature I'd like to ask for improvement -- cuesheet storage. When creatimg wv-file with embedded cuesheet, the exact cuesheet info is stored in wv under the CUESHEET tag value. However, when retagging wv with e.g. foobar2000, it changes its value, so it may be imposible to restore original cuesheet later. Could wavpack create, for example, another field, which will store unmodified sheet, or maybe store it in some other way, so there'll be no need to keep separate cue-file with original content?

WavPack 4.5 beta available

Reply #35 –
Quote from: bigdog on
Quote from: halb27 on

Quote from: bryant on

... Maybe it's just because I spent so much time on the -x4 to -x6 codebase that I want to make sure that somebody is using it, even if it's just me! 

I've been a -x5 user so far together with normal mode. I don't care much about encoding speed, and it's fast enough on my system especially as it's not often that I encode losslessly. I've been thinking about going a bit lower like -x4 or -x3 (and maybe I'll do it), but to me encoding time of -x5 is no pain.



Since I'm loathe to put in too much time into testing & research, I don't think one could do much worse than what the developer is doing for his own compression needs. -x4 must be the best compromise. Yeah, it slows things down...but just once during the encoding.

That said I'm very skeptical about the new dynamic noise shaping if only because I haven't read the source code and/or there is little layman's explanation about whats going on other than 'hey this really works great!!' kind of posts. I've been happy with 4.41 -s0 lossy mode at high bit rates if only because I understand whats going on. I always intellectually feel that it represents a better 'average' noise distribution...more of a jack of all trades sort of thing that I'm more comfortable with. It also seems to put out similar numbers using -hh with -s0 compared with any -x mode and with far better speed on encoding. I'm fascinated with the potential of DNS but have to admit that not being a good code decipherer I'm uncomfortable with something that I don't understand. Would it be possible to write up a small white paper on this technique geared more to the layman? That would be much appreciated.

dog


You can't judge audio quality by the numbers. -S0 flat noise - less noise -  has little regard for human hearing. Therefore, --dns -  more noise - with intelligence where to put the noise = overall better perceived quality in most cases. -S0 isn't safer even at high bitrates unless you are going for extreme quality like 500k + range..even then. There is no reason to trust no psymodel over a basic one like --dns and joint stereo.
wavpack 4.8 -b256hx6c

WavPack 4.5 beta available

Reply #36 –
I wish I had the time for thorough testing but I trust better ears than mine. Given the posts above and given that one has ample time to encode then would something like -hb320x4 to -hb384x4 would be transparent for 99.9% of cases with the new dynamic noise shaping? Would anything higher than 384 kbps be absolute overkill? For the folks out there like myself who consider 'overkill' as a safety margin and still encode 320k MP3's, what would the optimum bitrate be? It seems that -hb384x4 with this new DNS one could have something as transparent as a 320k MP3 without the occasional oddity and also have superior transcoding if the need arose (i.e your lossless backup CD's went poof in a fire). Whats not to like about it?

Since I really do have poor ears I've often used a visual comparison like CEP spectral view to zoom in and compare lossy encoding to the wav file. For Wavepack, I've often needed to get the bitrates into the low to mid 400's before it looked visually 'perfect'. MP3's never look perfect no matter the bitrate, as I suppose is just the nature of a psy-model. How would the new DNS affect a visual comparison like this? I know one should use their ears as opposed to eyes for music but I'm just curious. Thanks.

dog

WavPack 4.5 beta available

Reply #37 –
Yes 320~384k will do it. 384k is probably my sweet spot for toughness vs size. Though paranoids could use higher rates for extra safety like 450..550. In reality you could go down to 350 -hx3 with high confidence. With correction files you could go much lower still - 260 k or so is 'roughly' 160~190k mp3 / aac.

spectral graphs show noise rising at higher freq especially at lower bitrates. With DNS or similar shaping, you might  see less noise higher up. Anyway I never paid much attention to graphs.
wavpack 4.8 -b256hx6c

WavPack 4.5 beta available

Reply #38 –
Thanks shadowking. I'm going to take your advice and use 384 bps (with -h and -x4) along with a correction file. Right now I have everything either lossless (wavpack) or lossy (wavpack 512k). I burn MP3's as I need them from this archive for portable use. In some cases all I have is MP3's so they're stuck there. I don't consider myself as having very good ears, but anything less than ~190-200 bps MP3s just sounds bad to me for most stuff(placebo or otherwise).

One other thing to note. Because I store a ton of drum loops, I've noticed that lossless wavpack often stores these files more efficiently than lossy (512k) so there's no point in compromising for these kind of audio files. It is an extra step, but it might be worth it to test a few files in both lossy and lossless before committing to compress an entire volume in lossy, with or without correction files.

Since we don't know the future, I still recommend folks store their important archives in some lossless configuration. Space might be tight, but its getting better (and cheaper) all the time. I can only surmise that wavpack will find its way to more and more portable players and perhaps even component DVD players. Having one's archive in hybrid lossless seems to be the best future-proof solution right now. Perhaps this new DNS will take off as the lossy format of choice for those of us who choose high bitrates (quality) over quantity in the portable arena. MP3 is not going away, especially for the <200 bps crowd, but wavpack's ability to handle higher resolutions and multiple channels with ease, its non-reliance on a (mean derived) psy-model and the sonic quirks that come along with that, along with its active development may give it an edge going forward. I look forward to further testing results of the new DNS from those with superior ears.

dog

WavPack 4.5 beta available

Reply #39 –
I've started to archive cd's using 270k -x (old slow pc) . I plan to dump the correction files to some small older hard drive  - I have many of these from older pc's. This way my PC and backup hdd is free of huge bulk. The quality is high even for transcoding to other formats. If I purchase a wavpack player I think these files will very suitable for portable playback too. Hopefully more wavpack players will come out esp flash ones.

I think with very quite music or simple artificial music lossless can be smaller than 512 k lossy, though I still think 512k is smaller than a lot of classical music. I see your point there is no use in lossy treatment there at very high bitrate. With 384 k you still have an upper hand in all cases I'd think. I re tested a few known samples and gave up around 350 k or so for what once needed 500k. No doubt in these cases dns has huge gains and modest gains with most other stuff. Anyway why  believe that zero modelling is safer because of some potential rare sample ? Its like with mp3 old belief than j stereo is bad so use more bitrate and remove that model - ditto VBR.  The problem is that without a basic model (n shaping, good j stereo) you will need very high bitrate to maintain constant good quality with any encoder.
wavpack 4.8 -b256hx6c

WavPack 4.5 beta available

Reply #40 –
shadowking, my paranoia about psy-models is more theoretical than practical. Psy-models are really the only way to get tolerable fidelity with low bitrates, and they make much sense in the streaming and portable world. They do seem to rely on one paradigm however...that humans can be tricked and ultimately get used to anything, lowering the bar so to speak. When I was young, before I could afford a decent stereo system I was quite happy with low grade consumer sound systems, 8 track tapes, bad car stereos, etc. Once I heard what I was missing there was no going back, and I don't even consider myself an audiophile being half deaf from rock n roll.

Without slight of hand, if one can get the signal to noise ratio high enough or the noise floor low enough while achieving acceptable compression levels (relative to each individual situation) without adding to or taking away signal from the original work, one gets closest to real transparency. Truth is subtly different than reality, although I don't want to start a philosophical debate here. True transparency is when someone fails to ABX and accepts the result as 'transparent'. It is their personal 'truth'. Real transparency is when the signals are so closely matched by anything we can measure with (including our ears) that no human could possibly tell the difference. I think MP3 comes closest to the former while the wavpack model comes closest to the latter. Of course your point about the necessity of higher bitrates for the latter is right on the money. Its always about how we choose to compromise at the individual level.

WavPack 4.5 beta available

Reply #41 –
Quote from: shadowking on
Yes 320~384k will do it. 384k is probably my sweet spot for toughness vs size. Though paranoids could use higher rates for extra safety like 450..550. In reality you could go down to 350 -hx3 with high confidence.


So, with the new --dns switch, we can go lower.  But what is the difference between using -h and/or using -x now?  Is there a quality (sound quality, not higher compression) improvement to using both, or should I use maybe just x3 or x4 for a good balance of optimum quality and encode/decode time?

Currently, I have been trying out -hmb350x3c --dns because -hmb350x4c --dns is a bit too long to encode.  But if I can increase the quality and speed by dropping the 'h' and bumping it to 'x4' instead of 'x3' and not lose sound quality...

I am in the stage of having too much to encode and may need to dump some correction files in the future.  I hate the thought, but I want to have as few regrets as possible.

WavPack 4.5 beta available

Reply #42 –
I'd leave it at -hx3 since -h already gives compression security by itself. -x4 is better for the normal / fast modes. If you don't mind slightly slower decoding (possible problems on DAP's) try -hhx. Not sure what --dns does in 4.5b as it is now -sd and on by default. Higher compression = higher quality in lossy since there is not yet a true VBR mode.
wavpack 4.8 -b256hx6c

WavPack 4.5 beta available

Reply #43 –
Ok, let me get this straight. ANY -x parameter will not cause problems on DAPs since the decoding is not slowed. However -hh might cause problems. Is there a possibility that -h might also cause problems?

If one didn't care about encoding time and were to go to the trouble of processing a collection for current and future use of wavpack on DAPs along with a correction file for lossless archiving, what are the best parameter(s) to be on the safe side not only for quality but for DAP compatibility? Normal mode with -x4? High quality mode with -x4?

Since the ONLY reason I would use hybrid mode is for simultaneous archiving and DAP use, and given all the posts above, I've concluded that something like -hb384x4c is the best compromise all around. Would normal mode (-b384x4c) be a better bet for DAP use? Is fast mode even safer? Thanks in advance.

dog

WavPack 4.5 beta available

Reply #44 –
If you can do -x4 normal mode then that is higher compression and fast decoding.  I haven't heard of problems with -h ever. David said he had some with -hh on an Ipod but he thinks some devices can handle even -hh easily these days.

I am also thinking with DAP possibility , therefore I'm trying to resist the high modes though I think -h would probably be the sweet spot for DAP decoding vs compression - I would like to find out one day. The other consideration is bitrate and the lower the better for DAP's in general. When using using correction files you can say what the heck and push the bitrate right down like I am doing. 270 k produces 275..285k which any DAP should handle with ease (i hope ! ). Another possiblity is fast mode when we are going for max battery / decoding performance: -b285fx4c instead of -b270x3c as an example.

In any case I think 400 k encoding will be much gentler on DAP than 800..1000k.
wavpack 4.8 -b256hx6c

WavPack 4.5 beta available

Reply #45 –
Thanks shadowking. Clearly I'm confused at how DAPs work. I had no idea that DAPs are sensitive to bitrate other than size of file=less files. So what I'm getting from you is not only is ease/difficulty of computation reflective in CPU use (=battery use) but also bitrate/length of file. This challenges the imagination. What I'm getting from your previous post is that there's an additional reason to keep files as small as possible beyond just storage space....that small files (=low bitrate) also affects battery life? I can see this per tune listened to but not for hours of listening.

I guess I'm not going to be able to avoid testing for a minimum bitrate tolerable. Bummer.

I agree that with correction files nothing is irreversible so why not go the smallest you can stand? I guess time is of some value although DAP battery life might be the real key here.

Thanks again

dog

WavPack 4.5 beta available

Reply #46 –
Quote from: bigdog on
.. not only is ease/difficulty of computation reflective in CPU use (=battery use) but also bitrate/length of file. This challenges the imagination.

Think about it like this, the device must read more bits and process (decode) them. The quoted statement holds when using the same algorithm.

The second variable: The more complex the decoding algorithm is, the more processing power is needed.
With WavPack each number gives a slightly more complex method (and better compression) the -x (extra) is only in effect at encoding.
In theory, there is no difference between theory and practice. In practice there is.

WavPack 4.5 beta available

Reply #47 –
@ David and shadowking: could you please, if it makes sense, narrows down which genres would benefit more from X4 than X3?
Thanks.
WavPack 5.3.0 -b384hx6cmv / qaac64 2.69 -V 100
 

WavPack 4.5 beta available

Reply #48 –
I don't mean to contradict anyone, but I just don't see how bitrate affects battery life. Of course the lower the bitrate the more tunes one can process in one hour of battery life, I understand that, but how can bitrate by itself tax the CPU?  I can totally understand that the more complex the decoding process (like using -hh) the more the CPU use (=battery use)....but bitrate? This really does challenge my imagination and I'd love for someone to chime in here with more particulars. I am open to being educated.

WavPack 4.5 beta available

Reply #49 –
Quote from: DARcode on
@ David and shadowking: could you please, if it makes sense, narrows down which genres would benefit more from X4 than X3?
Thanks.


In my tests really weird stuff. Extreme artificial / synth sounds. Differences can be huge over plain -x or -x3. -hx3 is way faster than than plain -x4 and better compression. But -hx4 has a special place for special cases though gains a very marginal most of the time over -hx3. Really -hx is very balanced.

Quote from: bigdog on
I don't mean to contradict anyone, but I just don't see how bitrate affects battery life. Of course the lower the bitrate the more tunes one can process in one hour of battery life, I understand that, but how can bitrate by itself tax the CPU?  I can totally understand that the more complex the decoding process (like using -hh) the more the CPU use (=battery use)....but bitrate? This really does challenge my imagination and I'd love for someone to chime in here with more particulars. I am open to being educated.


Something related to hard drive buffering. The bigger the file the more reads .. I read it somewhere here. there are some charts on the net showing reduced battery for higher bitrates. I read it on Creative's website and Apple also mention that files should idealy be no bigger than 10mb.
wavpack 4.8 -b256hx6c
 
SimplePortal 1.0.0 RC1 © 2008-2020