Official site (http://www.wavpack.com/)
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
Great !
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?
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=22814), here (http://www.hydrogenaudio.org/forums/index.php?showtopic=21405) and here (http://www.hydrogenaudio.org/forums/index.php?showtopic=20335). 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.
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=22814), here (http://www.hydrogenaudio.org/forums/index.php?showtopic=21405) and here (http://www.hydrogenaudio.org/forums/index.php?showtopic=20335). 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.
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 (http://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!
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.
I hope the beta testing was of some use to you, and congrats on the new release
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.
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.
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)
Thanks for you hard work Bryant!
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.
Thanks much Bryant.
Zip is annoying on unix[a href="index.php?act=findpost&pid=229837"][{POST_SNAPBACK}][/a]
What's annoying about it?
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.
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.
* 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.
Autoconf and automake work just fine and aren't that hard to use.
I assume you were being sarcastic?
I have a small problem during the link stage:
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.
I believe you should add -DUSE_FSTREAMS to wvunpack flags.
I've got an ebuild here: http://4nykey.nm.ru/local/portage.tar.bz2 (http://4nykey.nm.ru/local/portage.tar.bz2) btw
I believe you should add -DUSE_FSTREAMS to wvunpack flags.
I've got an ebuild here: http://4nykey.nm.ru/local/portage.tar.bz2 (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)
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.
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
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?
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...
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.
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 (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!
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.
[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.
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 (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.
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 (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.
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 (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.
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.
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.
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)
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.
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.
What about submitting this ebuild to bugs.gentoo.org ? (I have done it with other ebuilds)
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=229981")
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.
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.
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.
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 (http://www.caddr.com/wavpack-4.0.tar.bz2)
This should be used in favor of the earlier version.
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 (http://www.caddr.com/wavpack-4.0.tar.bz2)
This should be used in favor of the earlier version.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=230129")
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]
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 (http://www.caddr.com/wavpack-4.0.tar.bz2)
This should be used in favor of the earlier version.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=230129")
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.
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.
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
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...
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...
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?
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!
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.
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.
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!
FWIW I have been converting some FLAC files to Wavpack. Average file size is 3% smaller with Wavpack. While that may not seem like much, it will mean an extra 6GB when I start to fill the 200GB drive I just bought.
Edit: I have been using Frontah for the conversion.
I'm not sure how many Apollo users there are here, but I have created a plugin for this Windows audio player. It supports all the features of the winamp plugin including ReplayGain. I added it to the standard package, but you can also download it alone:
http://wavpack.com/Apollo.zip (http://wavpack.com/Apollo.zip)
Apollo itself can be found here:
http://koti.welho.com/hylinen/apollo/ (http://koti.welho.com/hylinen/apollo/)
Thanks!
Thought maybe you might be interested in a WavPack project I just completed.
Tracks = 6217
Total Bytes = 195,222,372,573 (181GB)
Avg. Bitrate = 859
Not sure how many CD's it works out to be. MAC doesn't read WavPack 4.0 tags yet. It's well over 600.
Cost to do this was $133 US (shipped) for a 200GB Seagate SATA drive. Not counting the DVD-R drive and DVD-R discs it's all backed up on.
For those that are getting tired of re-encoding lossy formats, maybe these numbers are of some use if you're thinking about going lossless.
For my iRiver I can now select the whole drive and encode overnight to whatever lossy format I want. I can redo the whole thing the next day if a better encoder becomes available.
I have finally reached, nerdvana.
Avg. Bitrate = 859
Wow most of my FLACs average over 1000. That's actually pretty significant drop. If I could get down to 900 or 950 for me that would be great.
I have finally reached, nerdvana.
I'm really considering a larger hard drive and going totally lossless on my computer. I have a lot of lossless files already though, just not my entire collection.
Avg. Bitrate = 859
Wow most of my FLACs average over 1000. That's actually pretty significant drop. If I could get down to 900 or 950 for me that would be great.
I have finally reached, nerdvana.
I'm really considering a larger hard drive and going totally lossless on my computer. I have a lot of lossless files already though, just not my entire collection.
[a href="index.php?act=findpost&pid=232679"][{POST_SNAPBACK}][/a]
I calculated that it saved me somewhere between 3% and 4% in file size. That worked out to over 6GB in savings on a 200GB drive. Not a lot, but at least I have that warm fuzzy feeling that I am using the space efficiently.
I have encoded some of my music with WavPack also. Wavpack -h -x parameters gives me 20-30kbps bitrate savings from Flac -8. Decoding speed drops to 1/3 from flac but that's not so big deal with normal PC. Encoding is also quite slow altho I have been using ICL optimized binaries with my P4.
Logo discussion split: http://www.hydrogenaudio.org/forums/index....showtopic=25538 (http://www.hydrogenaudio.org/forums/index.php?showtopic=25538)
I've spotted a strange behavior with the Wavpack CUESHEET tag, in foobar. When I add such a tag, of course the file is virtually splitted in mutiple files in foobar, which is the intended behavior, but the original file remains in foobar's database.
Is this normal ? Because it's quite annoying to have some useless entries in the album list.
I know I can hide them, using some tricks with ape2 tags, but that would just be a workaround.
I've spotted a strange behavior with the Wavpack CUESHEET tag, in foobar. When I add such a tag, of course the file is virtually splitted in mutiple files in foobar, which is the intended behavior, but the original file remains in foobar's database.
Is this normal ? Because it's quite annoying to have some useless entries in the album list.
I know I can hide them, using some tricks with ape2 tags, but that would just be a workaround.
[a href="index.php?act=findpost&pid=233738"][{POST_SNAPBACK}][/a]
That's not the plugin. That's foobar not updating the album list after you reload the same file after tagging it with the cuesheet. The simplest way to handle it is to highlight the album in albumlist, right-click, select "remove from database." Presto, no more problem.
That's not the plugin. That's foobar not updating the album list after you reload the same file after tagging it with the cuesheet. The simplest way to handle it is to highlight the album in albumlist, right-click, select "remove from database." Presto, no more problem.
[a href="index.php?act=findpost&pid=233874"][{POST_SNAPBACK}][/a]
Thanks for your answer, but I think I am going to keep this. In fact it allows to convert easily a full album in a single file to another CUEESHEET supporting format. I will create a *sub-directory* with all my cuesheets in the Album List.
IMHO that's an interesting feature.
What about an update wavpack plugin for Nero? Current one is for 3.97 http://neroplugins.cd-rw.org/ (http://neroplugins.cd-rw.org/)
What about an update wavpack plugin for Nero? Current one is for 3.97 http://neroplugins.cd-rw.org/ (http://neroplugins.cd-rw.org/)
[a href="index.php?act=findpost&pid=234020"][{POST_SNAPBACK}][/a]
I did not create the original Nero plugin for WavPack, but I just downloaded the new version of Nero and have been looking into the SDK. This is a lot more complicated the the other plugins I have done (and I'm just coming up to speed with C++) but I think I can handle it. I'll post later this week with my progress.
What about an update wavpack plugin for Nero? Current one is for 3.97 http://neroplugins.cd-rw.org/ (http://neroplugins.cd-rw.org/)
[a href="index.php?act=findpost&pid=234020"][{POST_SNAPBACK}][/a]
I did not create the original Nero plugin for WavPack, but I just downloaded the new version of Nero and have been looking into the SDK. This is a lot more complicated the the other plugins I have done (and I'm just coming up to speed with C++) but I think I can handle it. I'll post later this week with my progress.
[a href="index.php?act=findpost&pid=234373"][{POST_SNAPBACK}][/a]
bryant, I know that some other guy has created all these nero plugins, I just don't know his e-mail. I hope that someone will inform him.
I just fixed a problem that could cause the Audition / CoolEdit filter to crash when saving mono files. So far it has only been seen with Audition 1.0 and Win2k, but it's possible that it could happen in other combinations. It's even conceivable that it could affect wavpack.exe, but I have not heard anything (and there's no chance of a corrupted file being created) so I'll wait until the next release before updating that. Here is the fixed plugin:
http://wavpack.com/Audition.zip (http://wavpack.com/Audition.zip)
Thanks to Kevin for reporting this!
I have finished up a beta version of the Nero plugin.
The decoder handles all WavPack files (including any "correction" files) and retrieves metadata from either ID3v1 or APEv2 tags. The encoder does not have any configuration available beyond that provided for wave files (so it always works in the default lossless mode) but it does write APEv2 tags.
Get it here: http://wavpack.com/Nero.zip (http://wavpack.com/Nero.zip)
I've ripped and burned a few CDs, but any additional testing is greatly appreciated!
Avg. Bitrate = 859
Wow most of my FLACs average over 1000. That's actually pretty significant drop. If I could get down to 900 or 950 for me that would be great.
My collection is smaller but large enough to make statistics. Using Wavpack 4 (of course!) I am even under 800. But do not forget that it depends greatly on the kind of music. E.g chamber music => aroung 650, pop music around 900...
Try JPop, where almost every track is over 1000 and some more potent remixes cross 1100 and I've even seen a 1200. Oh well, I just had to like a type of music that is such a pain to compress With WavPack 4 there is a slight reduction in size but it is still usually over 1000kbps average for the bitrate.
I just tried encoding a 96khz / 24bit (.wav) recording today, and even if the release info says that wavpack supports these rates, wavpack crashes immediately and produces a 0 byte file. Anyone else having problems with this type of audio-file?
I just tried encoding a 96khz / 24bit (.wav) recording today, and even if the release info says that wavpack supports these rates, wavpack crashes immediately and produces a 0 byte file. Anyone else having problems with this type of audio-file?
[a href="index.php?act=findpost&pid=238637"][{POST_SNAPBACK}][/a]
I assume it was mono? There is a bug in mono encoding that can cause a crash which I have fixed in the Audition plugin, and I have also now seen it in the WavPack executable. I am planning an experimental version with a new feature (for EAC) in a day or two and it will have that fixed also. Thanks for letting me know.
Has anyone tried the Nero plugin?
edit: awk
Ah yes 96/24/mono. Not a very common resolution though. Glad i could report something useful for once
I just tried encoding a 96khz / 24bit (.wav) recording today, and even if the release info says that wavpack supports these rates, wavpack crashes immediately and produces a 0 byte file. Anyone else having problems with this type of audio-file?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=238637")
I have created a beta that fixes this bug, has a solution for the EAC + correction file problem and adds a couple other nice features. Read more (and download) here:
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=24599&view=findpost&p=239544]http://www.hydrogenaudio.org/forums/index....ndpost&p=239544[/url]
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]
huge filesizes..
Maybe just leave it in Wav, if you like it really lossless.
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]
huge filesizes..
Maybe just leave it in Wav, if you like it really lossless.
[a href="index.php?act=findpost&pid=239567"][{POST_SNAPBACK}][/a]
This was a problem with the user input, with the files somewhere being requantized from 16 to 24-bit - i.e., there was no problem with WavPack. Even hybrid+correction should only be off by a few percent (in my tests, about ~2-3%) from pure lossless compression (which is always better than uncompressed wav).
I've tested your plugin for Nero. It seems to work fine too for encoding, but for decoding or transcoding, I've seen a strange bug in the info source box :
(http://kurtnoise.free.fr/misc/wv_input_db.gif)
The same file encoded with the Mausau plugin :
(http://kurtnoise.free.fr/misc/wv_input_ms.gif)
And this one is correct...
Always about Nero plugin...Why not merge the Mausau plugin ressource (http://neroplugins.cd-rw.org/) (we can use the hybrid mode + correction error file with it) and yours ??
And my last question : Which is Conifer Software ??
Thanks
I've tested your plugin for Nero. It seems to work fine too for encoding, but for decoding or transcoding, I've seen a strange bug in the info source box :
I think I see what's going on here. The Mausau plugin does not support WavPack 4.0 files at all (the format is completely different) and so shows bad information for files created with the new plugin. Both of your examples were
decoded with the Mausau plugin (I can tell because mine has an additional "format" parameter in the info list), and so the one
encoded with the new plugin shows bad data. If you are going to use WavPack 4.0 files I would suggest just using the newer plugin for everything.
Always about Nero plugin...Why not merge the Mausau plugin ressource (we can use the hybrid mode + correction error file with it) and yours ??
I would like to have a dialog box to set encoding parameters just like on the CoolEdit plugin, but it wasn't obvious to me how to do it with the Nero interface (I'm pretty new to C++ and COM). I also figured that most people don't use Nero as a ripper, but it's nice to have the lossless mode there just in case. If I get caught up with everything else I'd like to do, maybe I'll take a look at it again.
And my last question : Which is Conifer Software ??
Just a name I use for the software I write. I used to live on Conifer Street...
BTW, thanks for trying out the plugin!
I think I see what's going on here. The Mausau plugin does not support WavPack 4.0 files at all (the format is completely different) and so shows bad information for files created with the new plugin. Both of your examples were decoded with the Mausau plugin (I can tell because mine has an additional "format" parameter in the info list), and so the one encoded with the new plugin shows bad data. If you are going to use WavPack 4.0 files I would suggest just using the newer plugin for everything.
erff...yes, you're right. I delete Mausau plugin and with yours information is correct.
Are CUESHEET tags update-able in foo_wavpack ? Be cause I'm constantly losing my CUESHEET tags when I modify them
Perhaps there's an issue with foo_cue_ex.