Skip to main content

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

0 Members and 1 Guest are viewing this topic.
  • Peter
  • [*][*][*][*][*]
  • Administrator
WavPack 4.0 final released
Official site

WavPack is a completely open audio compression format providing lossless, high-quality lossy, and a unique hybrid compression mode. Although the technology is loosely based on previous versions of WavPack, the new version 4.0 format has been designed from the ground up to offer unparalleled performance and functionality.

WavPack 4.0 Features (with latest enhancements in bold):

    * Compatible with virtually all PCM audio formats including 8, 16, and 24-bit ints; 32-bit floats; mono, stereo, and multichannel; sampling rates from 6 to 192 kHz
    * Multiplatform support including Windows, Linux, and OS X
    * Instantly seekable and streaming capable
    * Error-tolerant block format conducive to hardware decoding
    * Optional "asymmetrical" mode for improved compression
    * MD5 audio checksums for verification and identification

    * Unique hybrid mode (provides high quality lossy + "correction" file)
    * Hybrid mode now operates as low as 2.25 bits/sample (or 196 kbps for CD audio)
    * Free and open source with easier to use library interface and unrestrictive license (BSD)
    * Intuitive command line interface (with wildcards and destination directory)
    * Small, efficient executable (no large programs or dlls to install)
    * Fully backward compatible to WavPack 1.0
    * Self-extracting archives (Windows only)
    * Complete piping support
  • Last Edit: 28 July, 2004, 07:56:38 AM by zZzZzZz

  • tcmjr
  • [*][*][*]
WavPack 4.0 final released
Reply #1
Great !
Kind Regards , Tcmjr

Aka HellSnoopy

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #2
Congratulations!

Right now this is hard to build on Linux/Os X because it doesn't ship with a makefile.

Would you consider adding a Unix makefile to the standard distribution if I sent you one?

  • robUx4
  • [*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #3
There is a makefile in the wild, as I made it. And David has it. If the build is not complete that may be the reason why it's not official yet.

David knows how to post news (and get around the focking rules) about releases as he proved here, here and here. So if he didn't do it this time, there is probably a good reason. Even though some people may have a hard time figuring that out.

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #4
Quote
There is a makefile in the wild, as I made it. And David has it. If the build is not complete that may be the reason why it's not official yet.

David knows how to post news (and get around the focking rules) about releases as he proved here, here and here. So if he didn't do it this time, there is probably a good reason. Even though some people may have a hard time figuring that out.
[a href="index.php?act=findpost&pid=229763"][{POST_SNAPBACK}][/a]


I grabbed the makefiles from the files on your website and was able to get wavpack 4.0 final to build on Debian.  Thanks.  wvunpack didn't compile until I defined -DUSE_FSTREAMS in the wvunpack make file.

Would it be worth it to set up a standard autoconf/automake build for this?  It will probably be less work in the long run than maintaining makefiles by hand.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #5
There was no reason I did not post the 4.0 news other than the fact that by the time I got everything put together and uploaded it was late here and I was tired. And I also noticed that the user documentation doesn't look good at 800x600, so I'm still not actually done... 

I did not include the Linux makefiles because they had not been tested since the last beta and even though I tried to be careful, I had made enough changes that I was pretty sure they wouldn't work anymore. The package with the new sources and old makefiles is here:

www.wavpack.com/sources4.zip

I am not sure of the best way to handle this part since I can't build (or test) Linux stuff here, but I do have hosting space. But hopefully the release schedule will slow considerably now.

As for actual changes to the code since the last beta, most were internal ones related to going to reader callbacks for input and the few bug fixes mentioned in the beta thread. I have included the cuesheet enhancement in the foobar plugin (thanks, Case). I added the -e option to automatically make the self-extraction files (Windows only) and also made a significant improvement to the processing speed for 24-bit and floating point files.

Thanks to everyone for your testing and support! 

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #6
Quote
I am not sure of the best way to handle this part since I can't build (or test) Linux stuff here, but I do have hosting space. But hopefully the release schedule will slow considerably now.

As for actual changes to the code since the last beta, most were internal ones related to going to reader callbacks for input and the few bug fixes mentioned in the beta thread. I have included the cuesheet enhancement in the foobar plugin (thanks, Case). I added the -e option to automatically make the self-extraction files (Windows only) and also made a significant improvement to the processing speed for 24-bit and floating point files.

Thanks to everyone for your testing and support! 
[a href="index.php?act=findpost&pid=229781"][{POST_SNAPBACK}][/a]


If you really want to play like a nice Unix citizen there's a couple of small changes you should make:

1. Always package sources in a tar.gz file named something like wavpack-4.0.tar.gz that untars into a directory wavpack-4.0.

2. Include the standard gnu configure script to setup the build environment for the build platform and create the makefile.

3. Pull in a config.h header file that defines the standard #defines created by the configure script.

4. Include the standard NEWS, COPYING, ChangeLog files that declare the license conditions and document changes.

I'd be happy to help you out with this if you're willing to accept patches.  If you follow 1-3 then it shouldn't be too hard to get distros like Gentoo, Debian, and Freebsd to offer wavpack as a standard package.

  • Mac
  • [*][*][*][*][*]
WavPack 4.0 final released
Reply #7
I hope the beta testing was of some use to you, and congrats on the new release
< w o g o n e . c o m / l o l >

  • robUx4
  • [*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #8
I highly suggest never ever to use configure/automake/autoconf/autohell.

The makefile works on Linux and OS X without this problem trigger. There is really no need to use it. Especially since it works on Gentoo, Debian and FreeBSD that you mention. Making the OS packaging is not the job of the library maintainer.

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #9
Quote
I highly suggest never ever to use configure/automake/autoconf/autohell.

The makefile works on Linux and OS X without this problem trigger. There is really no need to use it. Especially since it works on Gentoo, Debian and FreeBSD that you mention. Making the OS packaging is not the job of the library maintainer.
[a href="index.php?act=findpost&pid=229809"][{POST_SNAPBACK}][/a]


Autoconf and automake work just fine and aren't that hard to use.  They're a well-defined standard and integrate trivially with all the packaging systems out there.  Most reasonably polished open source projects use them.  Buck the trend if you prefer but you're only making more work for yourself in the long run writing your own makefiles by hand.

The makefile actually doesn't work right now on Linux because it doesn't define -DUSE_STREAMS when building wvunpack.

  • rjamorim
  • [*][*][*][*][*]
WavPack 4.0 final released
Reply #10
Quote
1. Always package sources in a tar.gz file named something like wavpack-4.0.tar.gz that untars into a directory wavpack-4.0.[a href="index.php?act=findpost&pid=229782"][{POST_SNAPBACK}][/a]


Why not package in zip? These days, every single OS supports zip out of the box, and the same can't be said about tgz

Besides, tgz can be annoying on Windows, since most unpacking programs force you to first gunzip, then untar (unless you use WinRAR)
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • p0wder
  • [*][*][*][*]
WavPack 4.0 final released
Reply #11
Thanks for you hard work Bryant!

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #12
Quote
Quote
1. Always package sources in a tar.gz file named something like wavpack-4.0.tar.gz that untars into a directory wavpack-4.0.[a href="index.php?act=findpost&pid=229782"][{POST_SNAPBACK}][/a]


Why not package in zip? These days, every single OS supports zip out of the box, and the same can't be said about tgz

Besides, tgz can be annoying on Windows, since most unpacking programs force you to first gunzip, then untar (unless you use WinRAR)
[a href="index.php?act=findpost&pid=229833"][{POST_SNAPBACK}][/a]


Zip is annoying on unix but it's not a big deal.  The most important thing is that the version is clearly discernable from the filename and that the zip unpacks into its own subdirectory.  The current wavpack zip file doesn't do the latter, which is a hassle.

WavPack 4.0 final released
Reply #13
Thanks much Bryant.

  • Mac
  • [*][*][*][*][*]
WavPack 4.0 final released
Reply #14
Quote
Zip is annoying on unix[a href="index.php?act=findpost&pid=229837"][{POST_SNAPBACK}][/a]

What's annoying about it?
< w o g o n e . c o m / l o l >

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #15
Quote
Quote
Zip is annoying on unix[a href="index.php?act=findpost&pid=229837"][{POST_SNAPBACK}][/a]

What's annoying about it?
[a href="index.php?act=findpost&pid=229855"][{POST_SNAPBACK}][/a]


1. It's often not available in the stock install.
2. It can't deal with stdin/stdout.
3. It extracts the zipfile in place by default.
4. It doesn't handle unix permissions very well.
5. People that make zip files don't tend to make them so they unpack into a subdir so you always have to list their contents first so you don't wind up strewing files all over your current directory.

No real dealbreakers but real unix people never make zipfiles and always grumble when they have to use them.

This is getting pretty OT for Wavpack though.

  • den
  • [*][*][*][*]
WavPack 4.0 final released
Reply #16
Good stuff!

Gotta say I've been rather tardy in my testing on the last couple of beta releases after having a good look at the early alphas. Sorry about that, but real life ™ has been getting in the way.

Some time down the track I'll have another look at this final release, but I'm sure it's fine. 

Thanks again for your rather excellent contribution David.

Den.

  • xmixahlx
  • [*][*][*][*][*]
WavPack 4.0 final released
Reply #17
* when did you guys turn into big babies?  *&^# get over the compression thing...
* autoconf/configure makes it easy to package per ARCH, but it produces bloated code.

  • Garf
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #18
Quote
Autoconf and automake work just fine and aren't that hard to use. 


I assume you were being sarcastic?

  • NumLOCK
  • [*][*][*][*][*]
  • Developer
WavPack 4.0 final released
Reply #19
I have a small problem during the link stage:

Code: [Select]
gcc  -lm -lcurses -o wvunpack bits.o float.o metadata.o unpack.o unpack3.o utils.o wputils.o wvunpack.o words.o md5.o
wvunpack.o(.text+0x9f8): In function `unpack_file':
: undefined reference to `WavpackOpenFileInput'
collect2: ld returned 1 exit status
make[1]: *** [wvunpack] Error 1
make[1]: Leaving directory `/mnt/Transfer/downloads/wavpack4/unpacked'
make: *** [all] Error 2


When it is resolved I'll make a nice gentoo ebuild 

Edit:  this is while linking wvunpack. The wavpack executable is already linked at this stage.
  • Last Edit: 29 July, 2004, 04:53:30 AM by NumLOCK
Try Leeloo Chat at http://leeloo.webhop.net

  • ak
  • [*][*][*][*]
WavPack 4.0 final released
Reply #20
I believe you should add -DUSE_FSTREAMS to wvunpack flags.

I've got an ebuild here: http://4nykey.nm.ru/local/portage.tar.bz2 btw

  • NumLOCK
  • [*][*][*][*][*]
  • Developer
WavPack 4.0 final released
Reply #21
Quote
I believe you should add -DUSE_FSTREAMS to wvunpack flags.

I've got an ebuild here: http://4nykey.nm.ru/local/portage.tar.bz2 btw
[a href="index.php?act=findpost&pid=229974"][{POST_SNAPBACK}][/a]


Thanks -- confirmed to work well 
What about submitting this ebuild to bugs.gentoo.org ? (I have done it with other ebuilds)
Try Leeloo Chat at http://leeloo.webhop.net

  • kuniklo
  • [*][*][*]
  • Developer (Donating)
WavPack 4.0 final released
Reply #22
Quote
Quote
Autoconf and automake work just fine and aren't that hard to use. 


I assume you were being sarcastic?
[a href="index.php?act=findpost&pid=229936"][{POST_SNAPBACK}][/a]


No.

  • xmixahlx
  • [*][*][*][*][*]
WavPack 4.0 final released
Reply #23
Quote
No.
[a href="index.php?act=findpost&pid=230006"][{POST_SNAPBACK}][/a]


 


...oh, don't expect a debian build from me for a while. i'm busy ~atm...



later

  • Ruby
  • [*][*][*]
WavPack 4.0 final released
Reply #24
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?