Skip to main content

Topic: WavPack 4.0 final released (Read 43128 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #25
Quote
I was playing around with the hybrid mode when I noticed that wavpack's correction files are huge. For example, a song which compresses to 50,6MB with the lossless mode, compresses into a 23.3MB lossy and a 93.2MB correction file, so the final hybrid lossless is 116MB. Another song is 18MB lossless, 9.6MB lossy and a 35MB correction file...
(I used the switches -hmy for the lossless and -hb256mc for the hybrid compression.)

Is this normal? I don't know much about WavPack, but shouldn't the size of the lossless file roughly equal to the size of lossy+correction? Or is that just OptimFROG?
[a href="index.php?act=findpost&pid=230035"][{POST_SNAPBACK}][/a]

No, that's not normal at all! Are you using the Windows version? Do the files verify? The overhead of doing lossy+correction over pure lossless is around 1% at that bitrate, and can be 0.25% at higher bitrates. Something's very wrong... 

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #26
About the Linux builds, thanks for all the feedback guys!

I updated both source code packages to unpack in a folder called "WavPack". Also I updated the makefiles in the Linux version to include "USE_FSTREAMS". I assumed that they would require more work than that because of all the changes I made, but I guess not.

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #27
I've repackaged wavpack-4.0 to play more nicely on unix systems.  You can download the new version here:

http://www.caddr.com/wavpack-4.0-niceunix.zip

Bryant - I've only made a few small changes to the distribution to make this behave like a normal unix package.  No changes at all were made to any of the source code.  Would you consider rolling these into the main distribution?  The changes are:

1. include standard autoconf/automake files (4 tiny text files)
2. Package zip so that it unpacks into a subdir by default.

I've tested this and it builds without errors on my Debian Linux box and Panther Mac.

Thanks again for wavpack!

  • Ruby
  • [*][*][*]
WavPack 4.0 final released
Reply #28
Quote
No, that's not normal at all! Are you using the Windows version? Do the files verify? The overhead of doing lossy+correction over pure lossless is around 1% at that bitrate, and can be 0.25% at higher bitrates. Something's very wrong... 
[a href="index.php?act=findpost&pid=230040"][{POST_SNAPBACK}][/a]


I found the reason for the files being so huge, apparently somewhere between two compressions my originally 16 bit files turned into 24 bit...  So, the problem was not with wavpack. Sorry for the false panic.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #29
Quote
[I found the reason for the files being so huge, apparently somewhere between two compressions my originally 16 bit files turned into 24 bit...  So, the problem was not with wavpack. Sorry for the false panic.
[a href="index.php?act=findpost&pid=230046"][{POST_SNAPBACK}][/a]

No problem. My wife was able to talk me in from the ledge. 

  • jth
  • [*][*][*]
WavPack 4.0 final released
Reply #30
Quote
I've repackaged wavpack-4.0 to play more nicely on unix systems.  You can download the new version here:

http://www.caddr.com/wavpack-4.0-niceunix.zip


Thanks for those. I can confirm this also builds fine on NetBSD 1.6 i386.

It also compiles on Solaris 9 UltraSparc (big endian arch) but only after I define MAX_PATH to 1024 as Solaris doesn't define that constant.

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #31
Quote
Quote
I've repackaged wavpack-4.0 to play more nicely on unix systems.  You can download the new version here:

http://www.caddr.com/wavpack-4.0-niceunix.zip


Thanks for those. I can confirm this also builds fine on NetBSD 1.6 i386.

It also compiles on Solaris 9 UltraSparc (big endian arch) but only after I define MAX_PATH to 1024 as Solaris doesn't define that constant.
[a href="index.php?act=findpost&pid=230050"][{POST_SNAPBACK}][/a]


Cool.  I can add the MAX_PATH test to the configure script.  Thanks for testing.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #32
Quote
I've repackaged wavpack-4.0 to play more nicely on unix systems.  You can download the new version here:

http://www.caddr.com/wavpack-4.0-niceunix.zip

Bryant - I've only made a few small changes to the distribution to make this behave like a normal unix package.  No changes at all were made to any of the source code.  Would you consider rolling these into the main distribution?  The changes are:

1. include standard autoconf/automake files (4 tiny text files)
2. Package zip so that it unpacks into a subdir by default.

I've tested this and it builds without errors on my Debian Linux box and Panther Mac.

Thanks again for wavpack!
[a href="index.php?act=findpost&pid=230044"][{POST_SNAPBACK}][/a]

Thanks! Yeah I can update my "Linux" sources with that. And I don't mind those being something besides zip if that's what Linux people are most used to.

However, for now I want to keep this separate from the standard release sources because I simply don't feel comfortable enough with them yet. I beat the hell out of the Windows version before a release (and I'm sure a lot of other people did too). While robUx4 and I ran some verification batch files and everything seemed to work fine, it still is not the same. So for now (at least in my mind) the Linux versions are still beta.

Thanks again. 

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #33
Quote
Thanks! Yeah I can update my "Linux" sources with that. And I don't mind those being something besides zip if that's what Linux people are most used to.

However, for now I want to keep this separate from the standard release sources because I simply don't feel comfortable enough with them yet. I beat the hell out of the Windows version before a release (and I'm sure a lot of other people did too). While robUx4 and I ran some verification batch files and everything seemed to work fine, it still is not the same. So for now (at least in my mind) the Linux versions are still beta.

Thanks again. 
[a href="index.php?act=findpost&pid=230057"][{POST_SNAPBACK}][/a]


Makes sense to be cautious.  Thanks.

tar.gz files are preferrable but it's not a big deal.  I'm happy to help put together linux packages of wavpack as you make releases if you want.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #34
Quote
It also compiles on Solaris 9 UltraSparc (big endian arch) but only after I define MAX_PATH to 1024 as Solaris doesn't define that constant.
[a href="index.php?act=findpost&pid=230050"][{POST_SNAPBACK}][/a]

BTW, the md5 module requires HIGHFIRST to be defined on big-endian machines (the WavPack code itself seemes to be endian-safe). If "sgi" or "sun" are defined then that will do it, but robUx4 had to add something for OS X.

  • robUx4
  • [*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #35
The pb with automake is that is may not work when mixed with .zip files. As you need some files to be executed. (unless unzip set every file to executable) In that case the source package should be done on UNIX only (to get the +x flag only for the needed files, ie "configure").

BTW .tar.bz2 is the best format to distribute source files, the files are much smaller than .tar.gz and .zip too.

David, if you need I can give you an account on my Linux box that is always connected to the net. It runs a slow machine (Via C3 733MHz) but that's what I used for testing Wavpack anyway  (hopefully you know how to use Linux)

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #36
Quote
Quote
It also compiles on Solaris 9 UltraSparc (big endian arch) but only after I define MAX_PATH to 1024 as Solaris doesn't define that constant.
[a href="index.php?act=findpost&pid=230050"][{POST_SNAPBACK}][/a]

BTW, the md5 module requires HIGHFIRST to be defined on big-endian machines (the WavPack code itself seemes to be endian-safe). If "sgi" or "sun" are defined then that will do it, but robUx4 had to add something for OS X.
[a href="index.php?act=findpost&pid=230063"][{POST_SNAPBACK}][/a]


I think it's more portable to use PATH_MAX instead of MAX_PATH.  PATH_MAX should be defined on all Posix platforms.

  • singaiya
  • [*][*][*][*]
WavPack 4.0 final released
Reply #37
This is great news for Wavpack users. Just one question though: I just got done encoding a lot of albums using the 4.0 beta encoder. Is it recommended to redo them with this version? Looking at the changes in the first post, I can't tell if that's needed.

  • ak
  • [*][*][*][*]
WavPack 4.0 final released
Reply #38
Quote
What about submitting this ebuild to bugs.gentoo.org ? (I have done it with other ebuilds)
[{POST_SNAPBACK}][/a]

Submitted here: [a href="http://bugs.gentoo.org/show_bug.cgi?id=58817]http://bugs.gentoo.org/show_bug.cgi?id=58817[/url]
I diff'ed kuniklo's zip, rather than linking directly, just in case.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #39
Quote
David, if you need I can give you an account on my Linux box that is always connected to the net. It runs a slow machine (Via C3 733MHz) but that's what I used for testing Wavpack anyway (hopefully you know how to use Linux)
Thanks, I might take you up on that! First I want to try this account at sourceforge that gives me access to all sorts of various Linux machines (including OS X) but I have been too lazy (busy?) to get going on it, and I suspect it might be a little slow. I used Unix regularly about 10 years ago and recently tried to do a couple things with vi on Linux. Not too smooth at first, but it started to come back. Just like riding a bike...

Of course, when I do the XMMS plugin you'll have to sit there and listen for me. 

Quote
I just got done encoding a lot of albums using the 4.0 beta encoder. Is it recommended to redo them with this version? Looking at the changes in the first post, I can't tell if that's needed.
Probably not. If you're using lossless then absolutely not, all the betas were fine. If you're using hybrid then there was a little improvement in the noise shaping between beta 2 and beta 3, but I am not re-encoding my files.

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #40
Here's a slightly better version of the linux package, with a simplified and cleaned-up autoconf config that should automatically define HIGHFIRST on big-endian architectures:

http://www.caddr.com/wavpack-4.0.tar.bz2

This should be used in favor of the earlier version.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #41
Quote
Here's a slightly better version of the linux package, with a simplified and cleaned-up autoconf config that should automatically define HIGHFIRST on big-endian architectures:

http://www.caddr.com/wavpack-4.0.tar.bz2

This should be used in favor of the earlier version.
[{POST_SNAPBACK}][/a]

Thanks! It's also now here:

[a href="http://wavpack.com/wavpack-4.0.tar.bz2]http://wavpack.com/wavpack-4.0.tar.bz2[/url]

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #42
Quote
Quote
Here's a slightly better version of the linux package, with a simplified and cleaned-up autoconf config that should automatically define HIGHFIRST on big-endian architectures:

http://www.caddr.com/wavpack-4.0.tar.bz2

This should be used in favor of the earlier version.
[{POST_SNAPBACK}][/a]

Thanks! It's also now here:

[a href="http://wavpack.com/wavpack-4.0.tar.bz2]http://wavpack.com/wavpack-4.0.tar.bz2[/url]
[a href="index.php?act=findpost&pid=230133"][{POST_SNAPBACK}][/a]


Cool.  I'll take my version down to avoid confusion.

  • indybrett
  • [*][*][*][*][*]
  • Members (Donating)
WavPack 4.0 final released
Reply #43
Just transcoded some FLAC files to Wavpack. When I look at the properties in Foobar2000, there is nothing that indicates what version of Wavpack was used to encode the files.

Is there any way to determine what version was used? I know it is 4.0, but I like to be able to verifiy it so that in the future I will be able to know what versions I have used.
  • Last Edit: 30 July, 2004, 09:41:46 AM by indybrett
flac>fb2k>kernel streaming>audiophile 2496>magni>dt990 pro

  • Zao
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #44
Quote
Quote
Quote
It also compiles on Solaris 9 UltraSparc (big endian arch) but only after I define MAX_PATH to 1024 as Solaris doesn't define that constant.
[a href="index.php?act=findpost&pid=230050"][{POST_SNAPBACK}][/a]

BTW, the md5 module requires HIGHFIRST to be defined on big-endian machines (the WavPack code itself seemes to be endian-safe). If "sgi" or "sun" are defined then that will do it, but robUx4 had to add something for OS X.
[a href="index.php?act=findpost&pid=230063"][{POST_SNAPBACK}][/a]


I think it's more portable to use PATH_MAX instead of MAX_PATH.  PATH_MAX should be defined on all Posix platforms.
[a href="index.php?act=findpost&pid=230078"][{POST_SNAPBACK}][/a]


PATH_MAX is defined in <unistd.h> on the Solaris box I compiled on.
SunOS shaka 5.8 Generic_117000-05 sun4u sparc SUNW,Ultra-250 Solaris
Zao shang yong zao nong zao rang zao ren zao.
To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

  • DavidHart
  • [*]
WavPack 4.0 final released
Reply #45
Forget this post in its previous form. If anybody read it before, I'm was an idiot. I can't believe I confused Musepack and WavPack...
  • Last Edit: 30 July, 2004, 10:46:23 PM by DavidHart

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #46
Quote
Is there any way to determine what version was used? I know it is 4.0, but I like to be able to verifiy it so that in the future I will be able to know what versions I have used.
[a href="index.php?act=findpost&pid=230324"][{POST_SNAPBACK}][/a]

That was something that I wanted to put in and I just never quite got to it before the release. Another thing that I wanted in there was the feature from 3.97 that allowed copying the timestamps between files (-t) and the support of raw files (-r). These will all be in the next version. Thanks for reminding me... 

  • iehova
  • [*][*]
WavPack 4.0 final released
Reply #47
Thanks Bryant. This release exactly was the news I was looking for, when starting today's pilgrimage to HA.

On testing the new release I noticed that the foobar2k plugin is easily to fool.  One thing, that corrupted playback was the presence of an old correction file for a newly encoded stream. Maybe generating random serial numbers and storing them in both files on encoding would be suitable to avoid this?
Friends don't let friends use lossy codecs.  (char0n)

  • B
  • [*][*][*]
  • Members (Donating)
WavPack 4.0 final released
Reply #48
Storing/showing used compression options can be usefull too IMO. That way you can see right away if you can squeeze out some more bits, instead of doing it by trial and error. This can be usefull when doing cd/dvd backups, and space is short.

Oh, and I have been test-driving this release quite alot already, and haven't encountered any errors so far. Nice!

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #49
Quote
On testing the new release I noticed that the foobar2k plugin is easily to fool.  One thing, that corrupted playback was the presence of an old correction file for a newly encoded stream. Maybe generating random serial numbers and storing them in both files on encoding would be suitable to avoid this?
[a href="index.php?act=findpost&pid=230562"][{POST_SNAPBACK}][/a]
Thanks for the suggestion. Yes, I thought about doing something like that because I often get errors from incompatible .wvc files because I do so much testing. However, I figured that this wouldn't actually happen too often in regular use, and when it does happen it's pretty obvious (and doesn't cause a blow up or anything). Whenever I get a CRC error I immediately delete the .wvc file! I will look into this, though.

Quote
Storing/showing used compression options can be usefull too IMO. That way you can see right away if you can squeeze out some more bits, instead of doing it by trial and error. This can be usefull when doing cd/dvd backups, and space is short.
[a href="index.php?act=findpost&pid=230639"][{POST_SNAPBACK}][/a]
Most of that information is stored already, I just haven't got around to displaying it except in the Audition filter (which needed it so that a file loaded in "high" mode with save in "high" mode). This is on my list for the next go round.

Quote
Oh, and I have been test-driving this release quite alot already, and haven't encountered any errors so far. Nice!
[a href="index.php?act=findpost&pid=230639"][{POST_SNAPBACK}][/a]
Glad to hear it, thanks!