HydrogenAudio

Lossless Audio Compression => WavPack => Topic started by: bryant on 2008-04-30 07:08:19

Title: WavPack 4.5 beta available
Post by: bryant on 2008-04-30 07:08:19
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=57390) and here (http://www.hydrogenaudio.org/forums/index.php?showtopic=58716).

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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=59109).

WavPack command-line encoder version 4.50b
WavPack plugin for Winamp version 2.5b
These two betas are together, download here (http://www.wavpack.com/wavpack_beta.zip).

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 (http://www.tvix.co.kr/kor/products/HDM6500A.aspx), but for some reason is not mentioned on the English version (http://www.tvix.co.kr/Eng/products/HDM6500A.aspx). 

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! 
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-04-30 08:50:26
Awesome !
Title: WavPack 4.5 beta available
Post by: halb27 on 2008-04-30 09:40:04
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!
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-02 07:36:04
Thanks guys. Here are the *nix packages for the beta and the latest xmms plugin:

wavpack-4.50.0-beta (http://www.wavpack.com/wavpack-4.50.0-beta.tar.bz2)
xmms-wavpack-1.0.2 (http://www.wavpack.com/xmms-wavpack-1.0.2.tar.bz2)

David
Title: WavPack 4.5 beta available
Post by: ChesterB on 2008-05-02 09:36:51
Nice, thank you for your work, David!
Title: WavPack 4.5 beta available
Post by: skamp on 2008-05-02 11:38:13
Thanks for not forgetting linux users!
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-02 18:06:16
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! 
Title: WavPack 4.5 beta available
Post by: skamp on 2008-05-03 07:18:30
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.

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?
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-03 22:45:21
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.
Title: WavPack 4.5 beta available
Post by: skamp on 2008-05-04 07:10:37
Thanks for the explanation!

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.

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 (http://www.intel.com/technology/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).
Title: WavPack 4.5 beta available
Post by: nthro on 2008-05-04 11:23:12
(http://forum.progressquest.com/images/smiles/not_worthy.gif)
Title: WavPack 4.5 beta available
Post by: callmeace on 2008-05-04 11:57:59
Title: WavPack 4.5 beta available
Post by: DARcode on 2008-05-07 19:41:42
Awesome news for us hybrid mode and WA users (see me sig)  !
Thanks a bunch, David!
Title: WavPack 4.5 beta available
Post by: DARcode on 2008-05-15 01:27:19
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 (http://www.tvix.co.kr/kor/products/HDM6500A.aspx), but for some reason is not mentioned on the English version (http://www.tvix.co.kr/Eng/products/HDM6500A.aspx). 

http://www.tvix.co.kr/eng/products/HDM7000A.aspx (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  !
Title: WavPack 4.5 beta available
Post by: xmixahlx on 2008-05-15 05:38:27
hi david,

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

thanks again!


later
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-15 14:06:22
http://www.tvix.co.kr/eng/products/HDM7000A.aspx (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  !

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


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

Thanks! 
Title: WavPack 4.5 beta available
Post by: soiaf on 2008-05-18 14:32:07
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).


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! 
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-20 05:14:52
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.

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!


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

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!
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-05-20 08:43:28
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.
Title: WavPack 4.5 beta available
Post by: skamp on 2008-05-20 10:42:38
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.
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-05-20 14:00:40
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 ?
Title: WavPack 4.5 beta available
Post by: skamp on 2008-05-20 14:26:03
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).
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-05-20 14:48:20
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.
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-20 14:52:49
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.
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-05-20 15:01:49
Thanks David.

I see 1.5 is now in Sid so hopefully a week away for me.
Title: WavPack 4.5 beta available
Post by: skamp on 2008-05-20 15:47:45
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
Title: WavPack 4.5 beta available
Post by: soiaf on 2008-05-24 11:56:57
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!
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-05-24 15:13:49
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.
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-25 05:37:55
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! 


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...
Title: WavPack 4.5 beta available
Post by: Fandango on 2008-05-25 17:02:00
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.
Title: WavPack 4.5 beta available
Post by: DARcode on 2008-05-26 11:45:00
[...]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.
Title: WavPack 4.5 beta available
Post by: bryant on 2008-05-26 21:12:46
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.


[...]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! 
Title: WavPack 4.5 beta available
Post by: halb27 on 2008-05-27 15:31:52
... 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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-05-29 17:34:32

... 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
Title: WavPack 4.5 beta available
Post by: NeXT on 2008-06-05 14:46:52
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?
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-06-05 15:07:49


... 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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-06 18:39:08
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
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-06-06 19:04:31
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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-08 13:25:33
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
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-06-08 15:29:36
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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-09 13:11:34
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.
Title: WavPack 4.5 beta available
Post by: sidewalking on 2008-06-10 05:03:29
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.
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-06-10 09:15:36
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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-10 13:07: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
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-06-10 13:22:20
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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-10 15:06:23
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
Title: WavPack 4.5 beta available
Post by: GeSomeone on 2008-06-10 17:24:23
.. 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.
Title: WavPack 4.5 beta available
Post by: DARcode on 2008-06-10 17:29:02
@ David and shadowking: could you please, if it makes sense, narrows down which genres would benefit more from X4 than X3?
Thanks.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-10 18:15:38
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.
Title: WavPack 4.5 beta available
Post by: shadowking on 2008-06-10 18:22:43
@ 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.

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.
Title: WavPack 4.5 beta available
Post by: bigdog on 2008-06-10 18:43:35
Perhaps its related to empty space, meaning the more tunes (=lower bitrate) the more empty space for the CPU to rest (=more battery life). That makes sense. Otherwise I can't see how 'wall to wall' music encoded to 270 bps would be any more efficient than 384 bps except that you wouldn't get all the music at 384 as you would at 270. This all assumes that the other parameters are the same.

I'll take your guys word for it because I'm pretty much a neophyte here but it still doesn't make much sense. No matter, the number of tunes one can fit on a given volume probably trumps most other issues anyhow for portable use. I think its worth figuring out the smallest bitrate one can stand...especially with correction files where you can always get back to square one.

peace

dog
Title: WavPack 4.5 beta available
Post by: GeSomeone on 2008-06-16 12:39:28
4.50 final has been released.
Here (http://www.hydrogenaudio.org/forums/index.php?showtopic=63987) is a link to the news thread.
Title: WavPack 4.5 beta available
Post by: mitchmalibu on 2008-06-20 14:35:55
Thanks for your hard work, WavPack never let me down and its cutting edge features are a pleasure to work with.

Keep up the good work.
Title: WavPack 4.5 beta available
Post by: B0RK on 2009-04-15 22:52:36
Thank you very much for the Update.

I Actually Need to Say Thanks for All the Years of using WavPack,
and so many years after it is STILL the only Lossless Format that can be used with professional audio data compression.

The only thing I Do Miss , is a Cutting Edge Directshow Decoder.

I, Like so many others, have never liked winamp , and Id Like to be able to use this latest version and enjoy all it has to offer, in Media Centre , Zoom Player ,
and other Directshow Based applications.

With a Great Directshow Decoder, preferrably released with updated capabilities for every new version that demands a decoder update , I think the Format will show susbstantial growth in Popularity , and reach a wider user base.

Please Consider it !
Thanks again !
Title: WavPack 4.5 beta available
Post by: Liisachan on 2009-04-15 23:37:37
ffdshow's WavPack support was indeed insufficient, and has been removed temporarily. But how about CoreWavPack? IIRC it even decodes a file encoded with --optimize-mono so it's almost up-to-date, I think. But admittedly it may not be cutting-edge...
Title: WavPack 4.5 beta available
Post by: jcoalson on 2009-04-16 01:40:49
and so many years after it is STILL the only Lossless Format that can be used with professional audio data compression.

nonsense like that doesn't fly here...  FLAC is supported in sound forge/vegas/sonar/audacity, it's used by EBU as the lossless distribution scheme for euroradio, most lossless sales are in FLAC, etc.
Title: WavPack 4.5 beta available
Post by: B0RK on 2009-04-16 03:36:19
and so many years after it is STILL the only Lossless Format that can be used with professional audio data compression.

nonsense like that doesn't fly here...  FLAC is supported in sound forge/vegas/sonar/audacity, it's used by EBU as the lossless distribution scheme for euroradio, most lossless sales are in FLAC, etc.


While I am also a Flac Fan, & admire & truly thankful for your wonderful work,
Let's agree to disagree about what flies where.

I have been in pro audio all my life one way or the other, will not bore you with the details, but let's just say that I had the misfortune of dealing with insane backup jobs.

Wavpack has been The Format used because of it's efficiency and ability to store / keep the metadata intact , Flac still has a problem with that to this very second.

As you know, Most professional Audio Data NEEDS to keep it's meta data intact.
I have enjoyed Both Wavpack & Flac in My personal music collection,

(Enjoyed Flac a lot more only after I found a replacement for the buggy Old CoreFlac Decoder, & btw Flac could use it's own reference inhouse Directshow decoder as well) ,

but For Work & Pro Audio Archive Jobs I Did , it was & Still is Wavpack.

Title: WavPack 4.5 beta available
Post by: DARcode on 2009-04-16 09:36:44
and so many years after it is STILL the only Lossless Format that can be used with professional audio data compression.

nonsense like that doesn't fly here...  FLAC is supported in sound forge/vegas/sonar/audacity, it's used by EBU as the lossless distribution scheme for euroradio, most lossless sales are in FLAC, etc.
I definitely agree with your point and do consider your work pretty brilliant, still Am I the only one who has noticed you've recently taken a decisively more aggressive approach at defending and promoting FLAC?
Title: WavPack 4.5 beta available
Post by: skamp on 2009-04-16 09:47:29
Wavpack has been The Format used because of it's efficiency and ability to store / keep the metadata intact , Flac still has a problem with that to this very second.

As you know, Most professional Audio Data NEEDS to keep it's meta data intact.

Doesn't --keep-foreign-metadata take care of that?
Title: WavPack 4.5 beta available
Post by: Skymmer on 2009-04-16 11:29:05
I Actually Need to Say Thanks for All the Years of using WavPack,
and so many years after it is STILL the only Lossless Format that can be used with professional audio data compression.


I can only agree here. WavPack's flt currently is the only filter for Adobe Audition which takes care of all regions, CUEs and other metadata from file you're working on.
Title: WavPack 4.5 beta available
Post by: B0RK on 2009-04-16 16:51:18
Wavpack has been The Format used because of it's efficiency and ability to store / keep the metadata intact , Flac still has a problem with that to this very second.

As you know, Most professional Audio Data NEEDS to keep it's meta data intact.

Doesn't --keep-foreign-metadata take care of that?


Flac can do so with partial success , (& I did Try ..) but it's implementation is incomplete.
Wavpack has been bullet proof for these pro tasks.

Even if Flac did get the foreign metadata right, Id still choose Wavpack for the pro jobs.

Reason is, in some Jobs, Wavpack's (brilliant) Hybrid Lossy+Correction File Method, has proved itself priceless for me, as it allowed to backup big projects and keep a reusable playable catalog of the Files(!) and do it in a Single Step (!).

I guess the one thing that wavpack lacks is good marketing.

A Reference inhouse Directshow decoder will be truly a great way to make the format more popular.
I truly Feel The Format has been in development for too long to go on without it.

Regarding Directshow playback Flac, the situation is slightly better , but If it had not been for some talented 3rd party coders doing a better job with Flac decoders then the old buggy coreflac, I would have never used/enjoyed my flac files.

I never made sense to me having Genius Lossless Format Encoders Developed 'Inhouse', but then leaving the Decoding out there "in the Wild " so to speak.

If I remember correctly, First Time I Could work with Wavpack in something like Wavelab,
was indeed thanks to a 3rd party (Hope my memory serves me right).

I truly feel that Perfect PC playback out of the formats was , & still is not guarenteed this way.

Anyway I got sidetracked by the previous posts.

So What im saying is:

Can't avoid thinking what a Reference Bulltproof Directshow Decoder (not to mention if it was bundled with Windows) could have done for the Wavpack format.

PLEASE consider it.
Title: WavPack 4.5 beta available
Post by: jcoalson on 2009-04-18 21:50:23
Wavpack has been The Format used because of it's efficiency and ability to store / keep the metadata intact , Flac still has a problem with that to this very second.

need more info (maybe in another thread).

Quote
As you know, Most professional Audio Data NEEDS to keep it's meta data intact.

flac does keep it's metadata intact.  it also optionally keeps wave and aiff metadata intact.

let's turn it around: when decoding from flac to wave, wave cannot keep all flac's metadata intact.  therefore wave cannot be used for professional audio work.  except for (just like flac) it actually is used quite widely in professional audio work, because maintaining other formats' metadata is not a widespread requirement in the vast universe of professional audio work.

p.s. I don't think I'm getting defensive about flac, more getting defensive about hydrogenaudio where people are coming by stating opinion as fact (check my tours of duty on some recent audiophool threads).  there are plenty of other megaforums for that, the reason I stay on HA is the stringent set of rules we play by.  I defend wavpack too from time to time