Finally, the betas are available for the WavPack command-line encoder and the Winamp plugin.

The most important improvement for the encoder is dynamic noise shaping which improves the quality of WavPack hybrid mode, especially for those HF-rich samples that used to cause trouble with previous versions. The --dns option from the alpha version has been deprecated and the feature is enabled in most situations (and can be forced with the new option -sd if required). This was discussed in detail here and here.

The Winamp plugin is basically all new with much better integration with the newest versions of Winamp, including transcoding and Auto-Tag and full Unicode support. More here.

WavPack command-line encoder version 4.50b

• dynamic noise shaping standard in hybrid mode (except when -cc specified or high sampling rates)
• param added to -s option (-sd) to force dynamic shaping when not otherwise selected (--dns from the alpha deprecated)
• added --channel-order option to specify channel order when it doesn't match Microsoft standard
• added --merge-blocks option for use with --blocksize option when compressing LossyWAV output or decoded HDCD audio
• increased minimum for --blocksize option to 128 (or 16 when combined with --merge-blocks)
• reformatted and expanded --help display

WavPack plugin for Winamp version 2.5b

• added transcoding API (allows CD burning, format conversion, Replaygain calc)
• allow standard Winamp metadata display and editing to work
• added API for writing metadata from Winamp (for Auto-Tag, etc.)
• Unicode support for info box (older Winamps) and media library
• added option to pass multichannel audio to output
• added option to pass all audio as 16-bit (for better compatibility)
• added option to output 24-bit audio when ReplayGain is active
• changed high-resolution output from 32-bit to 24-bit (allows winamp EQ to work, and probably other things)
• improved performance of adding tracks to library, especially from network drives
• fixed bug that caused the seek bar to sometimes vacillate when moved
• added genre display to info box (for older Winamps)

These two betas are together, download here.

Also, I happened upon another hardware product with WavPack support! It's the TViX HD M-6500A, a HD media server for home use, and it looks like a pretty nice unit. The WavPack support is mentioned on the Korean version of the product description, but for some reason is not mentioned on the English version.

Thanks to everyone for your continued support and especially to those who helped with the alpha test and suggested features and improvements and, of course, benski for your invaluable help on the Winamp stuff!

Awesome !

Though I'm into lossyWAV now instead of wavPack lossy (but partially use wavPack for lossless encoding) I welcome most any progress with wavPack which is a great piece of software.

Thank you for your new version!

Thanks guys. Here are the *nix packages for the beta and the latest xmms plugin:

wavpack-4.50.0-beta
xmms-wavpack-1.0.2

David

Nice, thank you for your work, David!

Thanks for not forgetting linux users!

It would be hard for me to forget Linux users because I am a Linux user! I have been dual-booting Windows 2000 and Ubuntu for a couple years now and I only run Windows for testing and development of the Windows tools and to do my taxes (no TurboTax for Linux yet).

BTW, I forgot to mention that there's an issue with the build when specifying --enable-mmx with gcc 4.3.x. This will hopefully be fixed soon.

Thanks ChesterB!

I was wondering about that. It seems the only codec that actually makes use of ASM code on my platform (x86_64 linux) is Monkey's Audio. LAME's ASM is *86 only, and disabling ASM with ./configure had no effect on performance with either FLAC or WavPack…

Edit: --enable-mmx does have an effect with GCC 4.2.x, but a rather modest one. I wonder why Monkey's Audio's x86_64 MMX code improves performance so much (2x encoding speed with the Extra High preset)? Is it because its base C++ code is so much slower (and/or more complex) than FLAC's and WavPack's code?

There are a lot of things going on here, and there are serious gaps in my knowledge of this, but this is what I do know.

WavPack is, for the most part, pure C. There are some MMX enhancements (created by Joachim Henke) but these are done as intrinsics (as opposed to pure ASM) and only used for encoding (not decoding). Unfortunately, as you notice, these provide only a modest improvement (at best) with 16-bit audio, but they do provide a nice improvement for 24-bit (and higher) audio (especially with the -x mode, which is where they were first implemented). My understanding is that the intrinsics work for 64-bit compiles as well, which is not true when pure ASM code is used (but don't quote me on that!)

I have written pure ASM versions of WavPack decoding for both the ColdFire (68k) and ARM CPUs and got very nice improvements and would be very interested to try this with x86 to see what improvements I could get, but have never had the time. This is particularly interesting because the only lossless codecs that currently decode faster than WavPack (FLAC and TAK) use this extensively...

My understanding of Monkey's Audio is that the format itself was designed with SIMD in mind (and MMX in particular) which is why you see the significant improvement for that case. This allows relatively fast operation on PCs, but the disadvantage is that these gains are lost on non-SIMD processors like those used on Rockbox and other portable devices. This is part of the reason that Monkey's Audio support on portable devices is generally limited to the normal and fast modes. BTW, my understanding is that the situation with LA is similar, although since it's not open source people are not generally aware of this.

Thanks for the explanation!


Well, like I've said before, I don't see much point in lossless audio on portable devices. What I'd be more concerned about is the other types of hardware appliances, such as standalone players for the living room. But now that Intel's Atom low power CPU is right around the corner, that might change. It's cheap, draws very little power, and you get to run existing x86 code on it. More to the point, you get SIMD instructions (SSE2, SSE3 and SSSE3).

Let's not forget the forthcoming VIA Isaiah, which I have big hopes for!

Lossless audio for all, even low-power consumption (traditionally 'mobile' portable device) CPUs!

http://www.pcper.com/article.php?aid=511&type=expert


Thankyou very much Bryant

Awesome news for us hybrid mode and WA users (see me sig) !
Thanks a bunch, David!

http://www.tvix.co.kr/eng/products/HDM7000A.aspx

The HD M-7000A supports our fav audio lossless codec too and DViCO Inc. adertises that merrily !

hi david,

i packaged 4.50.0beta (from svn, actually) and it's at rarewares/debian ... NOW!

thanks again!


later

Very interesting, thanks!

I think that the 7000 is just a 6500 in a different case (and I'm not sure it's going to be available everywhere) but it's certainly good news that they're not shy about advertising WavPack (no matter how they spell it). I've got to get a link to them up...



Thanks!

Yes, the firmware releases are the same for the 7000 as they are for the 6500, so its the same functionality. The 6500 definitely does playback WavPack files, but theres a few bugs in their implementation at the moment e.g. some songs get cut short (among other bugs). Still Dvico seem to be doing a lot of work improving the overall firmware quality so hopefully they'll get everything sorted in the next couple of months.

Anyway, thanks for the 4.5 beta release, looking forward to the full release!

Thanks for the info on the TViX units. I'm glad to hear they are working on problems; hopefully they'll get the WavPack support rock solid at some point. Once I get a HDTV I will certainly look into getting one!



So am I!

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!

Its working good in Linux with Aqualung player .. yes it is gapless and RG is detected ! . Bitrate always show 1411k even for lossy ..

Audacious - Plays okay but cannot get RG to work even though the plugin has it turned on. Not gapless although one can use the crossfader.

With audacious and the xmms-crossfade plugin (works with audacious as well), you can get true gapless playback, despite what the plugin's name suggests.

Thanks for that info. Any ideas about replaygain activation ?

With XMMS at least, the plugin bypasses any alteration to the audio that the player (and other plugins) may apply (which means, no replay gain). But Audacious 1.5.0 seems to have a plugin-independent RG implementation which does work with xmms-crossfade (I just tried). Just make sure NOT to check the "Bypass all of signal processing if possible" option in Preferences > Audio.

Edit: to be clear: configure Replay Gain in its dedicated panel (Preferences > Replay Gain), NOT in the input plugin's configuration panel (Preferences > Plugins > WavPack Audio Plugin).

Thanks again. My version is 1.4.6 maybe that explains why some features are missing. I Will eventually end up with 1.5 since my Debian testing is a rolling distro or I might just try to compile. From what you are saying I think i can forget foobar (not that I even use it much in nix). Audacious , aqualung and rubbyripper will eventually do it for me.

The Audacious plugin for WavPack is based on the original XMMS one put together by Kuniklo. That plugin displayed the ReplayGain selection (it came from the Musepack plugin) but it was not enabled (i.e., turning it on didn't do anything).

Later I added ReplayGain support to the XMMS plugin (along with several other improvements) but that has not been ported into the Audacious version. However, that doesn't sound like a great idea because Audacious (at least 1.5.0) uses its own RG implementation outside of the input plugins, but 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...

I'll see if I can get a chance to look into the Audacious sources and see if there's a quick way of getting that working; it should be trivial.

Thanks David.

I see 1.5 is now in Sid so hopefully a week away for me.

You're right, my mistake

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

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.

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



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...

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.

Could I consider that your recommended setting for 256 Kbps Hybrid please?
Relevant improvement over hx3?
Thank you.

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.



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!

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

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?

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.

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

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.

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

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.

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.

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.

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.

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

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.

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

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.

@ David and shadowking: could you please, if it makes sense, narrows down which genres would benefit more from X4 than X3?
Thanks.

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.

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.



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.