IPB

Welcome Guest ( Log In | Register )

4 Pages V  < 1 2 3 4 >  
Reply to this topicStart new topic
WavPack 4.0 final released
bryant
post Jul 29 2004, 18:02
Post #26


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (Ruby @ Jul 29 2004, 08:40 AM)
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? unsure.gif
*

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... sad.gif
Go to the top of the page
+Quote Post
bryant
post Jul 29 2004, 18:11
Post #27


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



About the Linux builds, thanks for all the feedback guys! smile.gif

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.
Go to the top of the page
+Quote Post
kuniklo
post Jul 29 2004, 18:14
Post #28





Group: Developer (Donating)
Posts: 193
Joined: 9-May 02
From: Emeryville, CA
Member No.: 2010



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!
Go to the top of the page
+Quote Post
Ruby
post Jul 29 2004, 18:22
Post #29





Group: Members
Posts: 125
Joined: 20-November 03
Member No.: 9941



QUOTE (bryant @ Jul 29 2004, 07:02 PM)
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...  sad.gif
*


I found the reason for the files being so huge, apparently somewhere between two compressions my originally 16 bit files turned into 24 bit... blink.gif So, the problem was not with wavpack. Sorry for the false panic. crying.gif
Go to the top of the page
+Quote Post
bryant
post Jul 29 2004, 18:28
Post #30


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (Ruby @ Jul 29 2004, 09:22 AM)
[I found the reason for the files being so huge, apparently somewhere between two compressions my originally 16 bit files turned into 24 bit... blink.gif So, the problem was not with wavpack. Sorry for the false panic. crying.gif
*

No problem. My wife was able to talk me in from the ledge. smile.gif
Go to the top of the page
+Quote Post
jth
post Jul 29 2004, 18:33
Post #31





Group: Members
Posts: 157
Joined: 4-December 01
Member No.: 579



QUOTE (kuniklo @ Jul 29 2004, 10:14 AM)
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.
Go to the top of the page
+Quote Post
kuniklo
post Jul 29 2004, 18:39
Post #32





Group: Developer (Donating)
Posts: 193
Joined: 9-May 02
From: Emeryville, CA
Member No.: 2010



QUOTE (jth @ Jul 29 2004, 05:33 PM)
QUOTE (kuniklo @ Jul 29 2004, 10:14 AM)
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.
*



Cool. I can add the MAX_PATH test to the configure script. Thanks for testing.
Go to the top of the page
+Quote Post
bryant
post Jul 29 2004, 18:40
Post #33


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (kuniklo @ Jul 29 2004, 09:14 AM)
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!
*

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. smile.gif
Go to the top of the page
+Quote Post
kuniklo
post Jul 29 2004, 18:46
Post #34





Group: Developer (Donating)
Posts: 193
Joined: 9-May 02
From: Emeryville, CA
Member No.: 2010



QUOTE (bryant @ Jul 29 2004, 05:40 PM)
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.  smile.gif
*


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.
Go to the top of the page
+Quote Post
bryant
post Jul 29 2004, 18:46
Post #35


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (jth @ Jul 29 2004, 09:33 AM)
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.
*

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.
Go to the top of the page
+Quote Post
robUx4
post Jul 29 2004, 19:03
Post #36


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



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 biggrin.gif (hopefully you know how to use Linux)


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
kuniklo
post Jul 29 2004, 19:05
Post #37





Group: Developer (Donating)
Posts: 193
Joined: 9-May 02
From: Emeryville, CA
Member No.: 2010



QUOTE (bryant @ Jul 29 2004, 05:46 PM)
QUOTE (jth @ Jul 29 2004, 09:33 AM)
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.
*

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



I think it's more portable to use PATH_MAX instead of MAX_PATH. PATH_MAX should be defined on all Posix platforms.
Go to the top of the page
+Quote Post
singaiya
post Jul 29 2004, 20:17
Post #38





Group: Members
Posts: 365
Joined: 21-November 02
Member No.: 3830



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.
Go to the top of the page
+Quote Post
ak
post Jul 29 2004, 21:05
Post #39


Musepack Developer


Group: Members
Posts: 359
Joined: 17-October 01
Member No.: 309



QUOTE (NumLOCK @ Jul 29 2004, 04:14 PM)
What about submitting this ebuild to bugs.gentoo.org ? (I have done it with other ebuilds)
*

Submitted here: http://bugs.gentoo.org/show_bug.cgi?id=58817
I diff'ed kuniklo's zip, rather than linking directly, just in case.
Go to the top of the page
+Quote Post
bryant
post Jul 29 2004, 22:08
Post #40


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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

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.
Go to the top of the page
+Quote Post
kuniklo
post Jul 29 2004, 22:09
Post #41





Group: Developer (Donating)
Posts: 193
Joined: 9-May 02
From: Emeryville, CA
Member No.: 2010



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.
Go to the top of the page
+Quote Post
bryant
post Jul 29 2004, 22:17
Post #42


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (kuniklo @ Jul 29 2004, 01:09 PM)
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.
*

Thanks! It's also now here:

http://wavpack.com/wavpack-4.0.tar.bz2
Go to the top of the page
+Quote Post
kuniklo
post Jul 29 2004, 22:26
Post #43





Group: Developer (Donating)
Posts: 193
Joined: 9-May 02
From: Emeryville, CA
Member No.: 2010



QUOTE (bryant @ Jul 29 2004, 09:17 PM)
QUOTE (kuniklo @ Jul 29 2004, 01:09 PM)
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.
*

Thanks! It's also now here:

http://wavpack.com/wavpack-4.0.tar.bz2
*



Cool. I'll take my version down to avoid confusion.
Go to the top of the page
+Quote Post
indybrett
post Jul 30 2004, 14:41
Post #44





Group: Members (Donating)
Posts: 1350
Joined: 4-March 02
From: Indianapolis, IN
Member No.: 1440



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.

This post has been edited by indybrett: Jul 30 2004, 14:41


--------------------
flac>fb2k>kernel streaming>audiophile 2496>magni>dt990 pro
Go to the top of the page
+Quote Post
Zao
post Jul 30 2004, 22:36
Post #45





Group: Members (Donating)
Posts: 884
Joined: 25-September 03
From: Umeň, Sweden
Member No.: 9001



QUOTE (kuniklo @ Jul 29 2004, 10:05 AM)
QUOTE (bryant @ Jul 29 2004, 05:46 PM)
QUOTE (jth @ Jul 29 2004, 09:33 AM)
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.
*

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



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



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.
Go to the top of the page
+Quote Post
DavidHart
post Jul 31 2004, 03:31
Post #46





Group: Validating
Posts: 13
Joined: 17-December 03
Member No.: 10502



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

This post has been edited by DavidHart: Jul 31 2004, 03:46
Go to the top of the page
+Quote Post
bryant
post Jul 31 2004, 03:32
Post #47


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (indybrett @ Jul 30 2004, 05:41 AM)
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.
*

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... smile.gif
Go to the top of the page
+Quote Post
iehova
post Jul 31 2004, 14:40
Post #48





Group: Members
Posts: 81
Joined: 31-July 04
Member No.: 15910



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)
Go to the top of the page
+Quote Post
B
post Jul 31 2004, 19:46
Post #49





Group: Members (Donating)
Posts: 175
Joined: 6-May 02
From: The Netherlands
Member No.: 1985



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!


--------------------
http://digitalx.org
Go to the top of the page
+Quote Post
bryant
post Jul 31 2004, 21:36
Post #50


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (iehova @ Jul 31 2004, 05:40 AM)
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?
*
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 (BennyX @ Jul 31 2004, 10:46 AM)
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.
*
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 (BennyX @ Jul 31 2004, 10:46 AM)
Oh, and I have been test-driving this release quite alot already, and haven't encountered any errors so far. Nice!
*
Glad to hear it, thanks! smile.gif
Go to the top of the page
+Quote Post

4 Pages V  < 1 2 3 4 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th April 2014 - 16:56