WavPack has a new site design (thanks to Ariakis and Roberto) and version 4.2 has been released with the following enhancements:
- new option (-i) added to ignore length in header of wav files (for foo_clienc and CDex)
- new option (-w) added to write APEv2 tags from command-line (including cuesheets)
- bug fixed that caused problems with wav files over 2 gigabytes (new limit: 4 gig)
- improved encoding and decoding speeds in common modes (16-bit, stereo)
- added winamp media library support to winamp plugin
- added mode to decoding library for streaming support
- updated source code to compile on 64-bit machines
http://www.wavpack.com (http://www.wavpack.com)
To everyone who contributed to this release and to everyone who uses and supports WavPack: Thanks!
Wow, great!
Keep up the good work, bryant!
WavPack iz da best!
many thx bryant
Thank you!
Great! Thanks Bryant.
You might want to add VUPlayer http://www.vuplayer.com (http://www.vuplayer.com) to your list of WavPack supporting players. I am not sure if the author of that player knows about your 4.2 update. He is pretty good about including updates, if you let him know.
Impressive, as every update so far. Thanks for your work, bryant.
Good news. Thanks Bryant.
Yay!
Just for kicks and giggles, I uploaded a Solaris SPARC compile of WavPack 4.2 to RareWares. Hopefully soon, Kuniklo will provide a MacOS X compile.
Regards;
Roberto.
Thank you very much!
Beautiful. Thank you!
BTW. Are Kuniklo's XMMS plugin getting mature enough for the regular user now?
And would it in that case be useful to include it on WavPacks official site?
WavPack has a new site design (thanks to Ariakis and Roberto) and version 4.2 has been released with the following enhancements:- new option (-i) added to ignore length in header of wav files (for foo_clienc and CDex)
- new option (-w) added to write APEv2 tags from command-line (including cuesheets)
- bug fixed that caused problems with wav files over 2 gigabytes (new limit: 4 gig)
- improved encoding and decoding speeds in common modes (16-bit, stereo)
- added winamp media library support to winamp plugin
- added mode to decoding library for streaming support
- updated source code to compile on 64-bit machines
http://www.wavpack.com (http://www.wavpack.com)
To everyone who contributed to this release and to everyone who uses and supports WavPack: Thanks!
[a href="index.php?act=findpost&pid=289484"][{POST_SNAPBACK}][/a]
Thank you. WavPack is a great program - I like the new features- keep up the good work !
WavPack 4.2 binaries for Mac OS X uploaded here:
http://www.hydrogenaudio.org/forums/index....pe=post&id=1453 (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=1453)
Feel free to host it at Rarewares.
WavPack 4.2 binaries for Mac OS X uploaded here:
http://www.hydrogenaudio.org/forums/index....pe=post&id=1453 (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=1453)
Feel free to host it at Rarewares.
[a href="index.php?act=findpost&pid=289568"][{POST_SNAPBACK}][/a]
Excellent! Thank-you very much.
Just uploaded it, and announced at the index page.
Just uploaded it, and announced at the index page.
[a href="index.php?act=findpost&pid=289573"][{POST_SNAPBACK}][/a]
Page says
WavPack V.4.2b3 for MacOS X 2005-04-10
Guess that should be V.4.2 now....
As always your hard work on WavPack is very much appreciated bryant
the new site layout is lightyears better than the older one IMO, much more appealing and way better structured, well done (finaly)
ah, and thx for the update
Page says
WavPack V.4.2b3 for MacOS X 2005-04-10
Guess that should be V.4.2 now....
You beat me on this one. They certainly are 4.2 (no beta) binaries...
Ooops. Fixed. Thanks for pointing that out.
Many thanks
Bryant for this great codec.
If people is interested,
Toff has made a new package (http://www.matroska.org/~toff/WavPackDS-20050405-2.zip) of directshow filters (a splitter and a decoder) for wavpack and matroska files. It's not finalized yet but works fine with stereo files...even in WMP.
Status (2005-04-05) :
---------------------
Alpha .wv splitter added, should works with lossless and hybrid file (autoload .wvc file if present)
24 bits PCM and 32 bits floats should now works.
More than 2 channels support not implemented yet.
Improved seeking from .mka file (require last Haali's Splitter version)
Any plans for a commandline replaygain scanner for Wavpack? A wvgain or wavpackgain or something?
Beautiful. Thank you!
BTW. Are Kuniklo's XMMS plugin getting mature enough for the regular user now?
And would it in that case be useful to include it on WavPacks official site?
[a href="index.php?act=findpost&pid=289553"][{POST_SNAPBACK}][/a]
The sporadic performance bug has been fixed, so I'd consider it at beta level now.
Any plans for a commandline replaygain scanner for Wavpack? A wvgain or wavpackgain or something?
[a href="index.php?act=findpost&pid=289620"][{POST_SNAPBACK}][/a]
Yes. But it seems David plans to now prioritize ASM optimizations of some routines for several target platforms, at first M68K (for the iRiver RockBox) and TI DSP (for the Neuros).
But a replaygain scanner is definitely in his todo list
If people is interested, Toff has made a new package (http://www.matroska.org/~toff/WavPackDS-20050405-2.zip) of directshow filters (a splitter and a decoder) for wavpack and matroska files. It's not finalized yet but works fine with stereo files...even in WMP. [{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=289619")
The sporadic performance bug has been fixed, so I'd consider it at beta level now.
[a href="index.php?act=findpost&pid=289624"][{POST_SNAPBACK}][/a]
Excellent! That warrants an update to the lossless comparision thread.
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=29655]http://www.hydrogenaudio.org/forums/index....showtopic=29655[/url]
"Software support" for WavPack goes from "average" to "good".
If people is interested, Toff has made a new package (http://www.matroska.org/~toff/WavPackDS-20050405-2.zip) of directshow filters (a splitter and a decoder) for wavpack and matroska files. It's not finalized yet but works fine with stereo files...even in WMP.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=289619")
If you want to test an even newer version is available here :
[a href="http://www.matroska.org/~toff/WavPackDS-20050410.zip]http://www.matroska.org/~toff/WavPackDS-20050410.zip[/url]
Status (2005-04-10) :
---------------------
Added more than 2 channels support for splitter and decoder
Tested only with 5.1
rjamorim: you could add LAMIP (http://lamip.sourceforge.net/) to your list, too
XMPlay (http://www.un4seen.com/) are another player that has gotten a native (http://support.xmplay.com/Plugins_native.html) WavPack input plugin now.
Long life to WavPack !
The only thing preventing me from switching is teh command-line replaygain scanner. Nice work!
Just hopping in to add my thank you to Bryant as well.
Very nice to see a lossless codec with so much active development going on and a developer taking user feedback into account so much.
Hope you can keep up the good work. It seems to me that for quite a few people I know wavpack has become the new lossless codec of choice.
A couple little nits to pick about the new wavpack site design (I'm not sure if this is the most appropriate page, but it should work ):
Under the Software section on the main page, there are no links. For example, it says "Plugin available here", but there's no link to the plugin or anything.
In the Links page, there's a column that says "Link", with "Visit" links underneath. It'd make a bit more sense just to make the names of the pages (under the Names column) hyperlinks?
About these quirks in the site design... I designed it a while ago when there was much less content, and Roberto has adapted it since.
The reason the "Software" table is it its current state, is because it was a direct content copy from the old WavPack site. David just had a list before, so it got stuck on the main page. When the content was all on one page, it was just a list to advertise the diverse support of the format, not necessarily provide links there.
Also, the reason the "Links" tables are so strange is that they used to be in the same section as the "Downloads" tables, and so followed the same column layout. Since they're now separated, it would make perfect sense to just link the name of the site to the site itself, just as you said.
Basically, there's a little bit of confusion because the content layout has changed since the layout was designed, and Roberto and I haven't really corresponded except for me to send him the content template when he began filling the content.
Hopefully Roberto can work on these items, and David can decide what to do about the software list. I'd also be glad to copy the current content and submit an updated content set to Roberto, if he's busy. Just let me know.
Bryant, a really great codec. Changed from Ape to Flac and then turned to Wavpack - good compression, fast and full of features and open source.
These are properties and attitudes I like
Hi,
Nice to see this great format progressing. I'm wondering what program do most of you use to encode and tag your files? I'm currently using FLAC and encoding/tagging happens in once pass with speek's frontend. (I'd like to keep ripping seperated)
Speek's Wavpack frontend doesn't seem to have tagging capabilities, so I'd have to use another program to do the tagging which would mean more work/programs for me :-p.
Thanks for the update Bryant!
I'm having some problems compiling 4.2 on NetBSD and Solaris Sparc (64 bit/big endian). Version 4.1 compiled on these platforms fine. If I'm able to fix, I'll send any patches/advice your way.
I'm having some problems compiling 4.2 on NetBSD
[a href="index.php?act=findpost&pid=289975"][{POST_SNAPBACK}][/a]
I tried compiling it on FreeBSD too, and couldn't get past the ./configure part.
About the web page: thanks for your remarks, I'll try fixing it. But feel free to do it Ariakis, I can't webdesign for toffee
Nice to see this great format progressing. I'm wondering what program do most of you use to encode and tag your files? I'm currently using FLAC and encoding/tagging happens in once pass with speek's frontend. (I'd like to keep ripping seperated)
Speek's Wavpack frontend doesn't seem to have tagging capabilities, so I'd have to use another program to do the tagging which would mean more work/programs for me :-p.
[a href="index.php?act=findpost&pid=289939"][{POST_SNAPBACK}][/a]
You can encode and tag all at once using Foobar2000. Or using the -w switch in wavpack.exe...
I personally use Tag on the encoded files.
I tried compiling it on FreeBSD too, and couldn't get past the ./configure part.
[a href="index.php?act=findpost&pid=289993"][{POST_SNAPBACK}][/a]
Oh, Oh!
Pretty many people are moving over to FreeBSD these days, so "Yes, it compiles easily on FreeBSD" will be a necessary sales pitch when I start evangelising for WavPack. Hope this are easily fixed...
I personally use Tag on the encoded files.
What Tag is that Roberto?
The latest official version can be downloaded here:
http://www.saunalahti.fi/~cse/files/ (http://www.saunalahti.fi/~cse/files/)
I have adapted Tag so that you can set tags from the contents of a text file, much like WavPacks new -w "<tag>=@<file>" format. My version can be found here:
http://www.neilpopham.pwp.blueyonder.co.uk....html#downloads (http://www.neilpopham.pwp.blueyonder.co.uk/tag.html#downloads)
Edit: I may as well take this opportunity to thank bryant for his continuing sterling work.
I think picmixer summed it up very well:
Very nice to see a lossless codec with so much active development going on and a developer taking user feedback into account so much.
There are 2 GUI frontends for it too:
Tag frontend (http://members.home.nl/w.speek/tag.htm) by Speek.
Tagger (http://www.tagger.de.vu/) by Börek.
A couple little nits to pick about the new wavpack site design [...]
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=289912")
I came up with this:
[a href="http://www.rarewares.org/rja/wavpack/index.html]http://www.rarewares.org/rja/wavpack/index.html[/url]
Hopefully this fixes all those issues. Thank-you for bringing them to my attention.
Now let's wait and see if David approves it for upload to wavpack.com...
jth & rjamorim. Any error codes to report?
I had to edit autogen.sh to get it to build on Mac OS X, so it may not work straight out of the box for you either.
Hi,
Nice to see this great format progressing. I'm wondering what program do most of you use to encode and tag your files? I'm currently using FLAC and encoding/tagging happens in once pass with speek's frontend. (I'd like to keep ripping seperated)
Speek's Wavpack frontend doesn't seem to have tagging capabilities, so I'd have to use another program to do the tagging which would mean more work/programs for me :-p.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=289939")
If you like Speek's FLAC Frontend and want something similar that can encode WavPack then you might like [a href="http://members.home.nl/w.speek/multi.htm]Speek's MultiFrontend[/url]. This tags (using Case's Tag) in the same way as FLAC Frontend: the Tag setup is under "Options" rather than "Tag Conf".
jth & rjamorim. Any error codes to report?
I will have to look up the FreeBSD error. But I got this weird error in Solaris X86, already in the make part:
/bin/bash ./libtool --mode=link --tag=CC gcc -g -O2 -o libwavpack.la
-rpath /usr/local/lib -lm libwavpack_la-bits.l o libwavpack_la-float.lo
libwavpack_la-metadata.lo libwavpack_la-unpack.lo
libwavpack_la-unpack3.lo libwavpack_la-utils .lo libwavpack_la-wputils.lo
libwavpack_la-words.lo libwavpack_la-md5.lo libwavpack_la-extra1.lo
libwavpack_la-extra2.l o libwavpack_la-pack.lo -lm
mkdir .libs
false cru .libs/libwavpack.a libwavpack_la-bits.o libwavpack_la-float.o
libwavpack_la-metadata.o libwavpack_la-unpack. o libwavpack_la-unpack3.o
libwavpack_la-utils.o libwavpack_la-wputils.o libwavpack_la-words.o
libwavpack_la-md5.o libwa vpack_la-extra1.o libwavpack_la-extra2.o
libwavpack_la-pack.o
make: *** [libwavpack.la] Error 1
I wonder what's that false cru thing...
I had to edit autogen.sh to get it to build on Mac OS X, so it may not work straight out of the box for you either.
Is your autogen.sh including these lines?
if test "`uname -s`" = Darwin; then
glibtoolize --automake
else
libtoolize --automake
fi
I always forget to submit it to Bryant...
Ah, the *BSD error:
checking for stdint.h... yes
checking for unistd.h... yes
checking iconv.h usability... no
checking iconv.h presence... no
checking for iconv.h... no
configure: error: Can't find iconv headers.
rjamorim: you will probably have to add the libiconv package from FreeBSD's package collection.
Here's the NetBSD error:
gcc -DPACKAGE_NAME=\"wavpack\" -DPACKAGE_TARNAME=\"wavpack\" -DPACKAGE_VERSION=\"4.2\" "-DPACKAGE_STRING=\"wavpack 4.2\"" -DPACKAGE_BUGREPORT=\"bryant@wavpack.com\" -DVERSION_OS=\"NetBSD\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBM=1 -I. -I. -DPACK -DUNPACK -DUSE_FSTREAMS -DTAGS -DSEEKING -DVER3 -g -O2 -c utils.c -Wp,-MD,.deps/libwavpack_la-utils.TPlo -fPIC -DPIC -o .libs/libwavpack_la-utils.o
utils.c: In function `AnsiToUTF8':
utils.c:627: parse error before `converter'
utils.c:628: `converter' undeclared (first use in this function)
utils.c:628: (Each undeclared identifier is reported only once
utils.c:628: for each function it appears in.)
gmake: *** [libwavpack_la-utils.lo] Error 1
I think the root cause is that NetBSD's libiconv package is slightly broken in some way. It might not be a wavpack problem. In config.log:
configure:20348: checking iconv.h presence
configure:20358: gcc -E conftest.c
configure:20364: $? = 0
configure:20384: result: yes
configure:20419: checking for iconv.h
configure:20426: result: yes
configure:20431: checking for iconv
configure:20452: gcc -o conftest -g -O2 conftest.c -lm >&5
/var/tmp/cc1SVkZo.o: In function `main':
/home/jth/wavpack-4.2/conftest.c:28: undefined reference to `libiconv_open'
/home/jth/wavpack-4.2/conftest.c:29: undefined reference to `libiconv'
configure:20458: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "wavpack"
| #define PACKAGE_TARNAME "wavpack"
| #define PACKAGE_VERSION "4.2"
| #define PACKAGE_STRING "wavpack 4.2"
| #define PACKAGE_BUGREPORT "bryant@wavpack.com"
| #define VERSION_OS "NetBSD"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_LIBM 1
| /* end confdefs.h. */
| #include <stdlib.h>
| #include <iconv.h>
| int
| main ()
| {
|
| iconv_t cd = iconv_open ("","");
| iconv (cd, NULL, NULL, NULL, NULL);
| ;
| return 0;
| }
configure:20483: result: no
For Solaris 10/SPARC, there are more fundamental build issues. I updated to the latest libtool and automake, but this problem still persists:
# bash autogen.sh
You should update your `aclocal.m4' by running aclocal.
libtoolize: `config.guess' exists: use `--force' to overwrite
libtoolize: `config.sub' exists: use `--force' to overwrite
libtoolize: `ltmain.sh' exists: use `--force' to overwrite
Makefile.am:4: Libtool library used but `LIBTOOL' is undefined
Makefile.am:4:
Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
Makefile.am:4: to `configure.ac' and run `aclocal' and `autoconf' again.
I'll continue to try and find the root cause for these problems. I think I've eliminated the obvious problems, like linker settings and tool paths.
Is your autogen.sh including these lines?
if test "`uname -s`" = Darwin; then
glibtoolize --automake
else
libtoolize --automake
fi
I always forget to submit it to Bryant...
Almost correct. I had to rename
libtoolize --copy to
glibtoolize --copy to get it going.
Unsure about the rest of these errors on Solaris x86.
On *BSD did autogen.sh complete without errors?
I wonder, because I had errors almost like this when I ran ./configure the first time (before i edited autogen.sh)
OK - Solaris build problems have been fixed. There was a problem in the libtool/automake setup where the libtool .m4 files were not installed into the proper location. wavpack now compiles and runs fine. The NetBSD problem is proving a little more elusive.
You might have to set CFLAGS to look in /usr/local for the iconv stuff on bsd, like so:
export CFLAGS="-I/usr/local/include -L/usr/local/lib"
sh autogen.sh
./configure
You might have to set CFLAGS to look in /usr/local for the iconv stuff on bsd, like so:
export CFLAGS="-I/usr/local/include -L/usr/local/lib"
sh autogen.sh
./configure
[a href="index.php?act=findpost&pid=290056"][{POST_SNAPBACK}][/a]
Thanks. I'll try that. I'm using the SourceForge Compile Farm, so I can't install iconv myself...
NetBSD compiles work if you use the --with-iconv argument to configure (I didn't notice that the first time). Free/OpenBSD will probably need that too.
$ bash configure --with-iconv=/usr/pkg
So, no real problems with either Solaris or NetBSD - all user error. I'm going back under my rock for now.
rjamorim: You're welcome; the changes look great.
One other thing I noticed:
"Comparisions" <-- second "i" is erroneous.
rjamorim: You're welcome; the changes look great.
One other thing I noticed:
"Comparisions" <-- second "i" is erroneous.
[a href="index.php?act=findpost&pid=290164"][{POST_SNAPBACK}][/a]
Okay, thanks, I updated the links page. And the help with the various *nix ports is great! I'm sure we'll get them all straightened out in no time.
I deeply appreciate the encouraging words from everyone; I hope I continue to live up to them.
just adding some more encouraging words ...
even some people that don't actually use wavpack as default, like me, are seriously following its evolution since instant seeking version 4 ...
Why I still use Flac C5:
1: Xiph
2: Vorbis Comment
3: Not Hybrid
4: Portable Support
Why at each new wavpack version I consider switching nowadays:
1: Around 10 meg saved by album
(Actually I lose 4gigs of HD with flac C5 over wavpack high)
2: Better "Speed Vs Compression" Settings
3: Stores the Compression Setting
after 100+gig of flac C8 encodes I switched to C5 as the -e option is too greedy,
after one year of flac using, flac has became a "one setting only codec", C5 default ...
when wavpack 4 came out, I have seriously considered using wavpack because its highest compression setting "Speed Vs Compression", wavpack -high, is much better than flac C8, but finally I only switched to flac C5 ...
why I didn't switch to wavpack ? because I don't need space actually, I don't actually need these 4gigs I could save ... furthermore due to the clean way my collection is sorted all it takes me to convert all my flac to wavpack is 3 clicks in frontah + 200 free gigs ...
I don't use wavpack as default actually ... but when I will buy a new empty 200gigs HD I will most likely do the step & convert all to wavpack high in one night ... & re-convert wavpack to flac when I will need portable playback ...
Wavpack+Flac is becoming a single codec for me ...
like other people use lossless for backup & lossy for portable ...
I use:
1: Wavpack High for HD backup
2: Flac C5 for portable playback if I ever need it (I want iRiver Support !!!)
3: Vorbis Q5 for all lossy use ...
Xiph may need two lossless codecs afterall ... why ? :
1: one codec that never breaks hardware portable compatibility, despite compression freeze: flac
2: one codec that always increase compression despite breaking hardware compatibility: wavpack
... you may disagree with me as I know many people here don't like Xiph & would do everything to avoid Xiph ...
but that's how I use Wavpack+Flac ... & as wavpack is open source it's already an unofficial Xiph codec in my heart ... in the same way Xiph is an unofficial part of Gnome in my heart ...
there is two types of lossless codecs: Compression Oriented: Ape & Hardware Support Oriented Support: Flac ...
wavpack may be the actual perfect compromise between ape & flac,
if wavpack start getting hardware support its compression will most likely freeze like flac ... & a new codec breaking hardware compatibility with better compression will rise & then power-users will ask portable hardware support for it like they will soon ask for wavpack portable support ... it's an endless game ...
so we need either 2 codecs for 2 uses (compression/portable) or 2 settings for these 2 uses in the same codec ... something like a non-portable friendly mode for flac to compete with wavpack for pure compression)
... that's why I use (or actually plan to use ...) both flac for hardware & wavpack for backup ...
my 2 main problems with wavpack actually are:
1: lossless newbies are scared by the word "hybrid", so spliting hybrid encoder from the lossless one may be clever (losslesswpack.exe vs hybridwpack.exe) & joining wavpack encoder/decoder (wavpack.exe+wvunpack.exe) so that in the end we have only 2 encoder/decoder one for lossy, one for hybrid might be clever ... specially as many wavpack lossless user favors lossy over hybrid ... so they would have the choice of not downloading hybridwpack.exe at all ...
2: Vorbis Comment, as a Vorbis User I feel home with vorbis comments, with ape tags I fell like I am using MPC & I dislike it much ;( lol
but maybe that's just my personnal taste ...
anyway congratulations for this great lossless codec
I'm suprised about the rapid progress (not just in technical terms) of wavpack recently. I wouldn't have expected that with FLAC becoming almost the de-facto lossless standard. But i guess, it shows that its never too late :) I can understand very well that bryant will now focus on hardware support and compatibility in general - that priority makes sense.
BTW: i disagree with the previous poster on the hybrid-topic....... some recent threads have shown, that the hybrid-mode may after all be one of wavpacks biggest strenghts...... because it can be interesting when lossless is too big, yet you still want a HQ-source for transcoding.
- Lyx
2: one codec that always increase compression despite breaking hardware compatibility: wavpack[a href="index.php?act=findpost&pid=290207"][{POST_SNAPBACK}][/a]
I strongly believe Bryant isn't interested in breaking hardware compatibility
Thanks bryant
Too bad that I can't download it currently in order to update my comparison. Were there changes (in speed) since beta 4?
Roberto:
yes, ... once a lossless codec gets a small user database & the dev judges his codec "mature" he freezes the codec compression for hardware compatibility ... it happened to flac ... it will happen to wavpack if we all switch to wavpack ... that's why I didn't make the step yet ... so far I favor waiting for Josh to break portable compatibility like Monty will do with Vorbis II over switching to wavpack ...
Instead of fast-standard-high compression settings, it would be better IMHO to have 2 setting one for with frozen specification for compatibility with portable player ... & one freelance for pure compression backup ...
I know several guys that used to do ape image+cue for backup while they favor flac+splitted for playback ... the paradox is not new ...
the battle between top-compression & frozen-codecs-for-hardware will never ends if dev don't split their codec in 2 uses from within ...
flac 1.11 & 1.12 have bring nothing new for me ... like vorbis 1.01 have bring nothing new to me ... it's bugfix release, bugfixing is enought as long as you're the best ...
if Josh doesn't come to parity with wavpack 4 I will switch to wavpack ... sorry but flac portable hardware support is not so big that flac is the de-facto standard ...
the problem is that if we switch to each new codec with better compression, no lossless codec will never have a big enougth user database so that hardware compagny like iRiver & co will seriously consider supporting it ...
so it's to codec developper to break their holy portable compatibility when their codec is not state-of-the-art anymore ... it's not to end-user to switch to new codec for better compression each 2 years ...
actually I dunno what to do ... using wavpack for compression or flac for portable ...
I think that I will switch to wavpack but I push that time to "the later possible the better" because I wanna push iRiver to support Flac the more I can ...
lossless codec dev thinking portable support is the holy grail are wrong ... because even a lossless user like me would use lossy if I would have the choice between Flac & Vorbis for my iRiver portable ...
most user want portable hardware support for flac-wavpack because they want to have the possibility to do this ... it's a question of freeness ... it's not an absolute need ...
When I see I can save 4gigs with wavpack righ now, & flac iRiver support is non-existant ... at some point I will be realistic ... I will switch ...
... if flac is zip & wavpack is 7z ... then sorry but I use 7z ...
the countdown to wavpack has begun for me ...
I'm sorry, OggZealot, I don't see how breaking FLAC's backward compatibility will improve its compression. The latest flac release might have not given you anything new, but that doesn't mean the developers are not actively trying to implement new compression schemes because they're afraid of breaking backwards and hardware compatibility. I believe FLAC developers value backwards compatibility, streaming, and stability more than highest compression levels.
As for wavpack4, it is fully backward compatible to WavPack 1.0, as every release so far, and new compression algorithms and features were added in every release. This probably means the codec is robust enough to handle such changes without breaking backwards compatibility and hardware support.
In my opinion, what Monty's doing with Vorbis hardware support is not a good thing, like you seem to believe. Breaking backwards compatibility is not mandatory to improve a codec.
emtee:
yes maybe flac reached its wall ... I prefer not even think about it because then it's a wide open door to wavpack ...
Quote:
I believe FLAC developers value backwards compatibility, streaming, and stability more than highest compression levels.
I favor general features over compression too ... the problem is that wavpack does almost all that flac does ... & it does it with better compression ... wavpack is not ape, it doesn't miss any major features ...
I favor flac 1.10 over wavpack 3.97 or any ape version ... due to better general features ... but I favor wavpack 4 over flac 1.10
The problem is that wavpack 4 is a ape/flac killer joining the strenght of both world without any major flaws ... you cannot be blind to this eternally
I still use flac C5 in the same way people use zip over 7z or mp3 over vorbis ... lazyness ... not because I am convinced it's the best overall lossless codec ...
Like many flac users I don't consider switching at every new "last fashion" codec is a good thing ... but wavpack is here since a long time ... the only reason flac 1.10 was more popular than wavpack was wavpack 3.97 missing instant seeking feature ...
I don't happily break my Flac C5-Vorbis Q5 couple ... but following xiph for more than a year I know for sure Xiph skeleton rely on the Vorbis+Theora in ogg couple much more than Speex+Vorbis+Flac trio ... see how Ogg-Flac is a joke so far & how Josh is often in xiphmeet ... each month I hear: Rillian "Flac News: Is Josh Here ?" -Big Silence Rillian: "It seems not ... next topic" ...
sorry but the link between Flac & Xiph is not as close as it first seems ... flac was a perfect replacement for shorten when wavpack was not ready ... it's popularity came from there ...
now that wavpack is ready it's really hard to still use flac ... unless you're really a flaczealot ... which I am not ... or have a lot of free HD space ... which I actually have that's why I still use flac C5 so far ... but space goes down day by day making me look toward wavpack more & more ...
Finally yes I think Monty breaking Vorbis backward compability is a wonderfull thing ... for Vorbis I updates we have aoyumi ... I almost consider aoyumi as the official Vorbis I developper nowadays ... I wait his beta 4 final ... Monty himself also mainly rely on aoyumi for vorbis I updates now ... it's obvious if you read last xiphmeet logs & I like it that way ... 2 vorbis dev for 2 vorbis codec is better than 1 dev for 1 vorbis codec no ? ... it was obvious Monty wasn't really interested in tuning vorbis I for high bitrate so it's better that he codes a new codec which willl potentially be natively better on high bitrates than that he only updates vorbis I once by year ... see how 1.01 was interesting ...
Monty had a problem with vorbis I as with experience he realized there were misstake in the vorbis design he couldn't fix ... instead of slowly losing interest Monty decided to code vorbis II so that nobody ever complaint portable player battery have a longer life with mp3 than vorbis ... you should be happy of it ...
plz start complaining about Vorbis II if it ends in vaporware like bitrate peeling ... or if it ends to be worst in ABX test than vorbis I ... not just because it's new ...
I decided to try out the excellent new WavPack 4.2 release to day with the new options. Here are my encoding speed/size comparisons this morning, for those who may be interested. Not sure if I should have posted this as a separate topic but it isn't a "listening" test, so here it is:
Equipment: WinXP P4 3.0 GHZ HT w/512 DDR RAM
Clips:
Green Day - American Idiot -- Chosen because it is short and loud (not acoustic by any means). 2 minutes 54 seconds - WAV is 30,030 kb (29.3 MB)
Tom Waits "I Hope That I Don't Fall in Love With You" (quiet and should compress well) - 3 minutes 54 seconds - WAV is 40, 403 kb (39.4 MB)I used the following options:-h
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 01 - American Idiot.wv in 7.67 secs (lossless, 24.89%)
-------------------------------------------------------------------------------
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 02 - I Hope That I Don't Fall in Love With You.wv in 14.58 secs (lossless, 47.68%)
-------------------------------------------------------------------------------
Press any key to continue . . .
Resulting sizes:
Green Day: 22.0 MB
Waits: 20.6[/color]
========================================
-x1
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 01 - American Idiot.wv in 5.71 secs (lossless, 23.97%)
-------------------------------------------------------------------------------
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 02 - I Hope That I Don't Fall in Love With You.wv in 12.76 secs (lossles
s, 46.68%)
-------------------------------------------------------------------------------
Press any key to continue . . .
Resulting sizes:
Green Day: 22.2 MB
Waits: 21.0[/color]
==============================
-x6
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 01 - American Idiot.wv in 127.62 secs (lossless, 24.41%)
-------------------------------------------------------------------------------
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 02 - I Hope That I Don't Fall in Love With You.wv in 164.17 secs (lossle
ss, 47.20%)
-------------------------------------------------------------------------------
Press any key to continue . . .
Resulting sizes:
Green Day: 22.1 MB
Waits: 20.8[/color]
=====================================
-hx1
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 01 - American Idiot.wv in 24.76 secs (lossless, 24.89%)
-------------------------------------------------------------------------------
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 02 - I Hope That I Don't Fall in Love With You.wv in 19.97 secs (lossles
s, 47.89%)
-------------------------------------------------------------------------------
Press any key to continue . . .
Resulting sizes:
Green Day: 22.0 MB
Waits: 20.5[/color]
==========================================
-hx3
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 01 - American Idiot.wv in 96.82 secs (lossless, 24.93%)
-------------------------------------------------------------------------------
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 02 - I Hope That I Don't Fall in Love With You.wv in 122.24 secs (lossle
ss, 48.00%)
-------------------------------------------------------------------------------
Press any key to continue . . .
Resulting sizes:
Green Day: 22.0 MB
Waits: 20.5[/color]
==========================================
-hx6
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 01 - American Idiot.wv in 516.29 secs (lossless, 24.95%)
-------------------------------------------------------------------------------
WAVPACK Hybrid Lossless Wavefile Compressor Win32 Version 4.2 2005-04-02
Copyright (c) 1998 - 2005 Conifer Software. All Rights Reserved.
created 02 - I Hope That I Don't Fall in Love With You.wv in 683.51 secs (lossle
ss, 48.02%)
-------------------------------------------------------------------------------
Press any key to continue . . .
Resulting sizes:
Green Day: 22.0 MB
Waits: 20.5[/color]
So, the sizes didn't change much, but as stated in the documentation, the encoding time here shows that it is much higher. I wonder if I am using the right settings? The file sizes are sometimes larger than the -h standard....
Scott
oggzealot, no need to stir the pot. there is no "battle" among open codecs. we put everything out there and users decide what to use.
are users going to switch because of a couple percent difference in file size? a few, but not many. mp3 is far from state-of-the-art but is the most used because is plays everywhere, is reasonably good and has been around longer. wma and aac are only even noteworthy seconds because of big companies with big infrastructures behind them.
unless a lossless codec comes around that has a significant size advantage (I think at least 15-20%), codec usefulness will be the dominant factor. one useful thing is the variety of software/devices on which it plays, availability of material, etc. another may be a hybrid mode, I don't know.
getting support for an open codec is a long process of slow adoption. for FLAC it has taken years (1.0 was almost 4 years ago), even though it had the advantage of filling a void. now there is no void, now it's like unseating an incumbent. it has to be blown away on features. it can be partially shut out by apple+alac+itunes or ms+wmalossless+drm but there will always be a niche for something non-proprietary. somehow I doubt that mpeg4-als will emerge unencumbered despite the best efforts of Tilman.
all that stuff you said about xiph, I can't make any sense of it.
and there's nothing 'holy' about portable hardware compatibility. but to break backward compatibility and totally disrupt and piss-off users, you had better be getting more than a couple % extra compression. it's not just about portables. it's about home stereo equipment, car stereo, anything outside the PC. no current codecs that get more than a few extra % can play outside the PC.
none of this is disparaging wavpack, which I think is a great codec. for windows-PC-centric lossless I think it is the top right now. but I don't think you are connected with the reality of what's beyond that.
Josh
unless a lossless codec comes around that has a significant size advantage (I think at least 15-20%), codec usefulness will be the dominant factor. one useful thing is the variety of software/devices on which it plays, availability of material, etc. another may be a hybrid mode, I don't know.
[a href="index.php?act=findpost&pid=290355"][{POST_SNAPBACK}][/a]
hybrid mode, embedded cue sheets, asymmetrical compression/decompression are all usefulness factors that drew me to wavpack...
Any plans for a commandline replaygain scanner for Wavpack? A wvgain or wavpackgain or something?
[a href="index.php?act=findpost&pid=289620"][{POST_SNAPBACK}][/a]
would this make it so when i ripped my cd's w/ eac to a wavpack image, i could have it automatically replaygain my cd? and then when i transcode to mp3 w/ foobar2000, id still have the original replaygain values?
if so, that would be awsome! it would eliminate the extra step of replaygaining in fb2k.
would this make it so when i ripped my cd's w/ eac to a wavpack image, i could have it automatically replaygain my cd?
[a href="index.php?act=findpost&pid=290373"][{POST_SNAPBACK}][/a]
Yes, except that in that case you would only have album gain, not track gain...
Thanks bryant
Too bad that I can't download it currently in order to update my comparison. Were there changes (in speed) since beta 4?
[a href="index.php?act=findpost&pid=290243"][{POST_SNAPBACK}][/a]
No, the only difference between beta 4 and the release was the 2 gig fix.
On your tables you give the WavPack version as 4.2, so I assume that it was beta 3. The encoding speed improvement from beta 3 that I am measuring here is 11% in
fast, 15% in normal, 30% in
high, and 15% in all the
extra modes. Unfortunately the improvement from 4.1 is less because there was actually a performance
degradation in the beta 3 compared to the 4.1 release (except in the
extra mode).
Any plans for a commandline replaygain scanner for Wavpack? A wvgain or wavpackgain or something?
[a href="index.php?act=findpost&pid=289620"][{POST_SNAPBACK}][/a]
would this make it so when i ripped my cd's w/ eac to a wavpack image, i could have it automatically replaygain my cd? and then when i transcode to mp3 w/ foobar2000, id still have the original replaygain values?
if so, that would be awsome! it would eliminate the extra step of replaygaining in fb2k.
[a href="index.php?act=findpost&pid=290373"][{POST_SNAPBACK}][/a]
My thinking on the ReplayGain scanner would be that it would
not handle the embedded cuesheets because foobar2000 is the only program that can currently play the image files as individual tracks and it has a fine ReplayGain scanner. When something else can handle cuesheets (I don't know how to make my winamp or nero plugins do it) then maybe I would add that.
For now I am imagining a command-line utility called WvGain that would accept a wildcard specification of WavPack files (just like WvUnpack does) and apply track gain to each one and album gain to the whole list. ID3v1 tags would be converted to APEv2. Is that enough for most people?
It won't be right away, but I think I think it's easy enough that I could squeeze it in with other stuff sometime soon.
For now I am imagining a command-line utility called WvGain that would accept a wildcard specification of WavPack files (just like WvUnpack does) and apply track gain to each one and album gain to the whole list. ID3v1 tags would be converted to APEv2. Is that enough for most people?
It won't be right away, but I think I think it's easy enough that I could squeeze it in with other stuff sometime soon.
[a href="index.php?act=findpost&pid=290683"][{POST_SNAPBACK}][/a]
That would be awesome!
Thank you, bryant! WavPack is just what I need for Adobe Audition.
I do have a question, though:
Using the plug-in for Audition, I have the option to "Normalize" the 32-bit float file. I know that in the accompanying text file it states:
This does not affect the file's usability in either Audition or other WavPack compatible programs.
What is the difference made to the file by normalizing? If the decompressed files are identical, what is the reason for the option? Why
wouldn't one use the "Normalize" option?
Sorry if this is a silly question...
I'm just wondering if there's some benefit in
not using the "Normalize" option.
Thanks, again!
~esa
On your tables you give the WavPack version as 4.2, so I assume that it was beta 3. The encoding speed improvement from beta 3 that I am measuring here is 11% in fast, 15% in normal, 30% in high, and 15% in all the extra modes. Unfortunately the improvement from 4.1 is less because there was actually a performance degradation in the beta 3 compared to the 4.1 release (except in the extra mode).
[a href="index.php?act=findpost&pid=290682"][{POST_SNAPBACK}][/a]
I don't know what beta version I used for my wavpack test. I've tried yesterday the beta 4 and compared the speed with the value currently present on my comparison, and there were no changes (tested with -fx5 and with defaulted mode). Are the modifications dependant on a CPU? Mine is old (Duron 800), and it maybe expain the lack of changes.
Anyway, I'll wait to download 4.2 final before updating my comparison.
Thank you, bryant! WavPack is just what I need for Adobe Audition.
I do have a question, though:
Using the plug-in for Audition, I have the option to "Normalize" the 32-bit float file. I know that in the accompanying text file it states:
This does not affect the file's usability in either Audition or other WavPack compatible programs.
What is the difference made to the file by normalizing? If the decompressed files are identical, what is the reason for the option? Why wouldn't one use the "Normalize" option?
Sorry if this is a silly question...
I'm just wondering if there's some benefit in not using the "Normalize" option.
Thanks, again!
~esa
[a href="index.php?act=findpost&pid=290763"][{POST_SNAPBACK}][/a]
First of all, it's not a silly question at all. It is however, somewhat difficult to clearly explain.
The reference in the Audition filter settings to "type 1" or "type 3 normalized" refers only to the type of wav file you will get if you unpack the resulting WavPack file with the command-line program. The WavPack files themselves are basically identical, except for the information on what kind of wav file to make if unpacked.
The type 1 files are non-standard because the float data ranges +/- 32768 and the type tag of 1 indicates integers. These were natively created by CoolEdit, and can generally only be loaded by CoolEdit or Audition. I suspect that they got lots of complaints about this and so decided to switch Audition's native format to type 3 (float) files which have the correct range of +/- 1.0 (i.e. normalized) and so can be correctly recognized by other programs.
So, basically this means that if you select type 1 files, the wav file that will result from unpacking will be native to CoolEdit and the type 3 files will be native to Audition. Although either program will load and save in either format, they work faster with their native format (I imagine because they must do a lot of internal conversions). The type 3 files are compatible outside of CoolEdit and Audition, so that's a big advantage.
So, to answer your central question, the only disadvantage to using the type 3 normalized option would be if you unpacked the resulting files back to wavs and then used them in CoolEdit they would operate slower than if you saved in type 1. Now that I think about it, that should probably be the default behavior.
Glad the filter is working out for you!
On your tables you give the WavPack version as 4.2, so I assume that it was beta 3. The encoding speed improvement from beta 3 that I am measuring here is 11% in fast, 15% in normal, 30% in high, and 15% in all the extra modes. Unfortunately the improvement from 4.1 is less because there was actually a performance degradation in the beta 3 compared to the 4.1 release (except in the extra mode).
[a href="index.php?act=findpost&pid=290682"][{POST_SNAPBACK}][/a]
I don't know what beta version I used for my wavpack test. I've tried yesterday the beta 4 and compared the speed with the value currently present on my comparison, and there were no changes (tested with -fx5 and with defaulted mode). Are the modifications dependant on a CPU? Mine is old (Duron 800), and it maybe expain the lack of changes.
Anyway, I'll wait to download 4.2 final before updating my comparison.
[a href="index.php?act=findpost&pid=290802"][{POST_SNAPBACK}][/a]
Well, I just did the comparison on another system and got different results, so I guess it is somewhat system dependent. In this case there was nice improvement from 4.1 to 4.2b3, but then no change from 4.2b3 to 4.2, and the
extra option wasn't improved at all.
Let's just say that 4.2 is
as fast or faster than any previous version.
edit: added a missing word
The reference in the Audition filter settings to "type 1" or "type 3 normalized" refers only to the type of wav file you will get if you unpack the resulting WavPack file with the command-line program. The WavPack files themselves are basically identical, except for the information on what kind of wav file to make if unpacked.
The type 1 files are non-standard because the float data ranges +/- 32768 and the type tag of 1 indicates integers. These were natively created by CoolEdit, and can generally only be loaded by CoolEdit or Audition. I suspect that they got lots of complaints about this and so decided to switch Audition's native format to type 3 (float) files which have the correct range of +/- 1.0 (i.e. normalized) and so can be correctly recognized by other programs.
So, basically this means that if you select type 1 files, the wav file that will result from unpacking will be native to CoolEdit and the type 3 files will be native to Audition. Although either program will load and save in either format, they work faster with their native format (I imagine because they must do a lot of internal conversions). The type 3 files are compatible outside of CoolEdit and Audition, so that's a big advantage.
So, to answer your central question, the only disadvantage to using the type 3 normalized option would be if you unpacked the resulting files back to wavs and then used them in CoolEdit they would operate slower than if you saved in type 1.
Thank you, bryant!
That makes perfect sense.
...and thanks again for WavPack!
:edit:One more question:
Is the command-line parameter "-a" the same as "Normalize (type 3)" in Audition?
TIA!
One more question:
Is the command-line parameter "-a" the same as "Normalize (type 3)" in Audition?
TIA!
[a href="index.php?act=findpost&pid=291043"][{POST_SNAPBACK}][/a]
It's related to it. That option just causes WavPack to properly recognize those non-standard wav files generated by CoolEdit that indicate in the header that they're integers but are actually floats. If you don't use this then the resulting WavPack might be unusable, and will definitely be unplayable. Since you use Audition (not CoolEdit), you should never need this unless you save your wav file in one of the non-standard formats (which you shouldn't).
Bryant,
You asked me to remind you about adding a link to http://www.vuplayer.com/vuplayer.htm (http://www.vuplayer.com/vuplayer.htm) to your new WavPack.com re-designed site. You might also want to put a link to the new DirectShow filter for WavPack 4.2 that just recently got released (in another thread here on HA).
Now that VUPlayer and WMP (using the Directshow filter) both playback using WavPack 4.2 code, and VUPlayer also encodes to WavPack 4.2 format, WavPack seems to be picking up a nice expanded "following" of support and users. it is good to see these "extra apps" bundling in WavPack support. I am sure people will love both of these fine programs.
Is the command-line parameter "-a" the same as "Normalize (type 3)" in Audition?
It's related to it. That option just causes WavPack to properly recognize those non-standard wav files generated by CoolEdit that indicate in the header that they're integers but are actually floats. If you don't use this then the resulting WavPack might be unusable, and will definitely be unplayable. Since you use Audition (not CoolEdit), you should never need this unless you save your wav file in one of the non-standard formats (which you shouldn't).
Thank you for all the info! I think that covers it....
So far, I found this software supporting WavPack:
* Custom Windows Frontend (by Speek)
* NullSoft Winamp (plugin w/ ReplayGain & Media Library support)
* Foobar2000 (official encoding/decoding addon, w/ ReplayGain & Cuesheets support)
* VUPlayer (official plugin, supports encoding)
* Windows Media Player (with CoreWavPack directshow filter)
* XMMS (with Kuniklo's plugin)
* LAMIP (official plugin)
* Adobe Audition (and CoolEdit) (filter w/ 32-bit floats & extra info save support)
* dBpowerAMP (official addon)
* Apollo Audio Player (plugin w/ ReplayGain support)
* Ahead Nero Burning Rom (with addon)
* Mr. QuestionMan / Audio Identifier
* Mp3tag Universal Tag Editor
I'm compiling that list for the Wiki. If you know of more apps supporting WV, please mention them.
Regards;
Roberto.
There are also GX:Transcoder (http://www.board-24.de/) and UniversalFront (http://www.unifront.boereck.de/), Frontah (http://home.vxu.se/mdati00/frontah/), Mareo (http://mareo.monkeydev.org/) working with the CLI of course .
It's maybe worth to mention that most (if not all) players based on directshow are also able to decode wavpack: MPC, TCMP, RadLight... Windows Media Player is just one of them. Many thanks to Toff for this
Also missing :
mkvtoolnix
For wavpack muxing into matroska files ..... ....
Christian
matroska project admin
P.S. We also decided to concentrate on wavpack for our future video editing tools, because unless other lossless formats it will allow for sample precise cutting. First tests showed that by compressing the PCM audio in DV AVI files, when being transmuxed into MKV files with Wavpack, you can save 15 - 20% on filesize, and without any quality loss ....
As I mentioned (http://www.hydrogenaudio.org/forums/index.php?showtopic=33135&view=findpost&p=289693), XMPlay have gotten a native WavPack plugin now...
And I don't know whether other players that that will utilize the Winamp input plugin for playback are worth mentioning? In that case you got 1by1, coolplayer, maybe others....(?)
Seems Quintessential got a plugin (http://www.quinnware.com/list_plugins.php?params=&page=3&type=input). For WavePack, though....
It's maybe to early to mention Kuniklo's Xist (http://www.caddr.com/xist/) for OS X...(?)
EDIT: Typo.
There are also GX:Transcoder (http://www.board-24.de/) and UniversalFront (http://www.unifront.boereck.de/), Frontah (http://home.vxu.se/mdati00/frontah/), Mareo (http://mareo.monkeydev.org/) working with the CLI of course .
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=291249")
Added them all, thanks
It's maybe worth to mention that most (if not all) players based on directshow are also able to decode wavpack: MPC, TCMP, RadLight... Windows Media Player is just one of them. Many thanks to Toff for this
[a href="index.php?act=findpost&pid=291253"][{POST_SNAPBACK}][/a]
Good point, added that.
Also missing :
mkvtoolnix
For wavpack muxing into matroska files ..... ....
Christian
matroska project admin
P.S. We also decided to concentrate on wavpack for our future video editing tools, because unless other lossless formats it will allow for sample precise cutting. First tests showed that by compressing the PCM audio in DV AVI files, when being transmuxed into MKV files with Wavpack, you can save 15 - 20% on filesize, and without any quality loss ....
[a href="index.php?act=findpost&pid=291279"][{POST_SNAPBACK}][/a]
That's very interesting. Great news!
I mentioned mkvtoolnix at the list
As I [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=33135&view=findpost&p=289693]mentioned[/url], XMPlay have gotten a native WavPack plugin now...
And I don't know whether other players that that will utilize the Winamp input plugin for playback are worth mentioning? In that case you got 1by1, coolplayer, maybe others....(?)
Added XMplay and mentioned about winamp-compatible players. Thanks.
Seems Quintessential got a plugin (http://www.quinnware.com/list_plugins.php?params=&page=3&type=input). For WavePack, though....
Considering the date that plugin was added (September 2003) I would guess it won't support WavPack4 files. Unless that is the date the entry was created and the author later updated his code...
Did anyone test it?
It's maybe to early to mention Kuniklo's Xist (http://www.caddr.com/xist/) for OS X...(?)[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=291291")
Yes, let's wait at least until he considers it beta.
Big thanks for all your contributions. This is how the software support section looks like now:
[a href="http://wiki.hydrogenaudio.org/index.php?title=WavPack#Software_support]http://wiki.hydrogenaudio.org/index.php?ti...oftware_support[/url]
Please keep contributions coming.
Best regards;
Roberto.
I've add burrrn (http://www.burrrn.net/) in CD burner software, and self-extracting mode in features.
I've add burrrn (http://www.burrrn.net/) in CD burner software, and self-extracting mode in features.
[a href="index.php?act=findpost&pid=291344"][{POST_SNAPBACK}][/a]
Ah, good ones. Thanks.
Did anyone test it?
[a href="index.php?act=findpost&pid=291338"][{POST_SNAPBACK}][/a]
No. Of those I mentioned I've only tested XMPlay (with native plugin) and 1by1 (with 4.2 Winamp plugin). They both work well.
Aren't XMPlay plugins the same as Winamp?
Aren't XMPlay plugins the same as Winamp?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=291353")
It can use Winamp plugins too and it used to ([a href="http://support.xmplay.com/Plugins_input.html]look here[/url]), but as of version 3.2 there's been native plugins (look here (http://support.xmplay.com/Plugins_native.html)) also. So for WavPack playback with XMPlay you can now choose between xmp-wv.dll and in_wv.dll.
Ah, I see. It's just I was getting all my plugins to use in 1by1 from an XMPlay download site.
Could someone please explain for me the differences between the WavPack binaries available on the WavPack website & those made available on RareWares.org. I notice filesize is different, are they compressed? is performance better or more reliable on one compile over the other. Any explanation of differences would be greatly appreciated. Thanks.
Could someone please explain for me the differences between the WavPack binaries available on the WavPack website & those made available on RareWares.org.
[a href="index.php?act=findpost&pid=291980"][{POST_SNAPBACK}][/a]
Files at RareWares have been compiled with the Intel compiler. Should be faster, but could also be less reliable (WRT crashes, not WRT creating non-lossless files)
Could someone please explain for me the differences between the WavPack binaries available on the WavPack website & those made available on RareWares.org. I notice filesize is different, are they compressed? is performance better or more reliable on one compile over the other. Any explanation of differences would be greatly appreciated. Thanks.
[a href="index.php?act=findpost&pid=291980"][{POST_SNAPBACK}][/a]
I tested the ICL versions tonight and they do seem a few percent faster than my compiles (at least on my P4) and in the cases I tried they produced the identical output.
As you guessed, I suspect that the reason they're so much smaller is that they're compressed with UPX.
I did some tests with ICL and Wavpack sources at my P4. I got over 15% faster decoder (foobar2000 plugin) and the encoder was also a bit faster than the default binary.
You might have to set CFLAGS to look in /usr/local for the iconv stuff on bsd, like so:
export CFLAGS="-I/usr/local/include -L/usr/local/lib"
sh autogen.sh
./configure
[a href="index.php?act=findpost&pid=290056"][{POST_SNAPBACK}][/a]
NetBSD compiles work if you use the --with-iconv argument to configure (I didn't notice that the first time). Free/OpenBSD will probably need that too.
$ bash configure --with-iconv=/usr/pkg
So, no real problems with either Solaris or NetBSD - all user error. I'm going back under my rock for now.
[a href="index.php?act=findpost&pid=290087"][{POST_SNAPBACK}][/a]
Thanks for the ideas, but none of the solutions is working for me.
@kuniklo: Using special CFLAGS, I get this error message:
checking iconv.h usability... yes
checking iconv.h presence... no
configure: WARNING: iconv.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: iconv.h: proceeding with the preprocessor's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-autoconf@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
checking for iconv.h... no
configure: error: Can't find iconv headers.
@jth: The FreeBSD at SourceForge doesn't even have a /usr/pkg folder. I tried using your command line neverthless, and later tried --with-iconv=/usr/local/include (sinca I saw iconv.h was there), and I always got the error message:
checking iconv.h usability... no
checking iconv.h presence... no
checking for iconv.h... no
configure: error: Can't find iconv headers.
Any ideas? Maybe it's just Sourceforge's FreeBSD compiling environment that is broken?
Thanks for any hints.
Regards;
Roberto.
Edit: I get the same errors on compile farm's NetBSD and OpenBSD
Hi Roberto,
Since it looks like the iconv library has been installed by hand onto your test NetBSD system, rather than using the pkg utilities - try this to compile:
$ bash configure --with-iconv=/usr/local
This should pick up iconv.h in /usr/local/include and libiconv.so in /usr/local/lib. Without those libraries the compile won't work. I don't have experience on Free or Open BSD, but I'd imagine the iconv issue is similar.
@kuniklo: Using special CFLAGS, I get this error message:
checking iconv.h usability... yes
checking iconv.h presence... no
configure: WARNING: iconv.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: iconv.h: proceeding with the preprocessor's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-autoconf@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
checking for iconv.h... no
configure: error: Can't find iconv headers.
That's a weird one. Never seen that before. Can I get access to this shell somehow?
Since it looks like the iconv library has been installed by hand onto your test NetBSD system, rather than using the pkg utilities - try this to compile:
$ bash configure --with-iconv=/usr/local
This should pick up iconv.h in /usr/local/include and libiconv.so in /usr/local/lib. Without those libraries the compile won't work. I don't have experience on Free or Open BSD, but I'd imagine the iconv issue is similar.
[a href="index.php?act=findpost&pid=308383"][{POST_SNAPBACK}][/a]
Ah, it works now. Thank-you very much
Well, configure works. make outputs several colorful errors.
I think the issue can be pinpointed to the fact that SourceForge's FreeBSD is hopelessly outdated. The current production release is 5.4, and they are still at 4.8
Same applies to NetBSD (Stable version is 2.0.2, they use 1.6.1) and OpenBSD (current 3.7, they use 3.4). Bleh.
That's a weird one. Never seen that before. Can I get access to this shell somehow?[a href="index.php?act=findpost&pid=308394"][{POST_SNAPBACK}][/a]
Yes, it's at the Sourceforge compile farm. If you are developer at any SF project, you already have access to it, you just need to enable it through your account's control panel. If you're not developer yet, create an account there and PM me.
Well, I got as far as I could. Some errors were just gcc being a bitch about #define newlines (\). I removed these newlines and left others where they were, and the code passed through without problem.
But then, iconv came haunting me again:
utils.c: In function `AnsiToUTF8':
utils.c:627: syntax error before `converter'
utils.c:628: `converter' undeclared (first use in this function)
utils.c:628: (Each undeclared identifier is reported only once
utils.c:628: for each function it appears in.)
*** Error code 1
Line 627 in utils.c starts here:
iconv_t converter = iconv_open ("UTF-8", "");
err = iconv (converter, &inp, &insize, &outp, &outsize);
iconv_close (converter);
setlocale (LC_CTYPE, old_locale);Oh well... the HP TestDrive servers seem to be down at the moment (I pray to God it's not some stupid script kiddie putting an end to this great resource), but later I'll try to compile there. They have FreeBSD 5.4 and NetBSD 2.0, so then I'll be able to find out if the fault is on SF's deprecated BSD installations.
Thanks for all your help.
Regards;
Roberto.
OK. As it turns out, the fault was indeed in SourceForge's deprecated systems at the compile farm. WavPack compiled without problem whatsoever at HP TestDrive's up-to-date FreeBSD and NetBSD installations - not even requiring the #define newline fixes -, as you can see by taking a look at RareWares...
Interestingly, the --with-iconv=/usr/local trick also worked when compiling WavPack on Tru64 Unix! As it turns out, their standard iconv was also deprecated and was generating a linker error.
Very big thanks to kuniklo and jth for helping out.
Best regards;
Roberto.
New platform added for WavPack playback, I guess... At least I don't think you could play it under (pure) DOS before. Now MPXPlay have added WavPack decoding with the DOS4G version with DLL handling and IN_WAVPA.DLL. Haven't tested the WavPack decoding yet (don't have that possibility right now), but previously I have successfully tried running MPXPlay on both MS-DOS and FreeDOS (http://www.freedos.org/) (GPL), playing mp3, mpc, ogg, flac, m4a and ape... (Thinking about making a "jukebox" out of junkyard hardware running this player on FreeDOS, just for the hell of it.....)
Relevant links:
http://mpxplay.net/ (http://mpxplay.net/)
http://forum.supergamez.hu/listazas.php3?a...y&id=1016579331 (http://forum.supergamez.hu/listazas.php3?azonosito=mpxplay&id=1016579331)
http://forum.supergamez.hu/listazas.php3?a...y&id=1016578491 (http://forum.supergamez.hu/listazas.php3?azonosito=mpxplay&id=1016578491)
Thanks for mentioning it! I just added it to the Wiki.
I updated "Software support" at Wikipedia's WavPack article.
http://en.wikipedia.org/wiki/Wavpack (http://en.wikipedia.org/wiki/Wavpack)
I updated "Software support" at Wikipedia's WavPack article.
http://en.wikipedia.org/wiki/Wavpack (http://en.wikipedia.org/wiki/Wavpack)
[a href="index.php?act=findpost&pid=313133"][{POST_SNAPBACK}][/a]
Just some notes:
- from version 1.53a the WavPack decoding is linked into the exe, so we don't need external DLL
- Mpxplay plays other audio files and containers too: AAC,AC3,APE,AVI,DTS,FLAC,MP2,MP3,MP4/M4A,MPC,OGG,WAV,WMA
thnx anyway
Attila
That's great news. Thank-you very much, Mr. Padara.
I was wondering, could you possibly provide an OpenWatcom makefile for wavpack and wvunpack? Or maybe some precompiled binaries? I would love to host WavPack for DOS at RareWares.
That's great news. Thank-you very much, Mr. Padara.
I was wondering, could you possibly provide an OpenWatcom makefile for wavpack and wvunpack? Or maybe some precompiled binaries? I would love to host WavPack for DOS at RareWares.
[a href="index.php?act=findpost&pid=330462"][{POST_SNAPBACK}][/a]
I use the tiny WavPack decoder source (wvfilter) in Mpxplay and it needs some modifications to work with Watcom (and some others to work with Mpxplay: the original decoder is not re-entrant).
I'll also test/check the wvpack and wvunpack and then I'll see what can I do for you. Maybe a makefile is not enough (requires an DPMI extender too), if I have to modify the source then I cannot promise too much...
I'll also test/check the wvpack and wvunpack and then I'll see what can I do for you. Maybe a makefile is not enough (requires an DPMI extender too), if I have to modify the source then I cannot promise too much...[a href="index.php?act=findpost&pid=330481"][{POST_SNAPBACK}][/a]
That's OK. Thank-you very much anyway
So, no real problems with either Solaris or NetBSD - all user error. I'm going back under my rock for now.
[a href="index.php?act=findpost&pid=290087"][{POST_SNAPBACK}][/a]
Oh, please don't. You can share your knowledge:
OK - Solaris build problems have been fixed. There was a problem in the libtool/automake setup where the libtool .m4 files were not installed into the proper location. wavpack now compiles and runs fine.
[a href="index.php?act=findpost&pid=290052"][{POST_SNAPBACK}][/a]
On a completely different setup; RedHat 7.1 Linux 2.4.12 I get the same error:
%automake --add-missing
Makefile.am:4: library used but `LIBTOOL' not defined in `configure.in'
How did you fix this? I don't seem to find the right place for
aclocal.m4, which is the only
.m4 generated by
libtoolize --copy on this setup?
Since then I have tried a different approach. I tried all servers I had access to and compiled the package statically. The HP TestDrive servers had all the libraries needed. I used a dual P3 server, a
configure and
make followed by:
gcc -static -O2 -o wavpack wavpack-wavpack.o -lcurses ./.libs/libwavpack.a -lm
gcc -static -O2 -o wvunpack wvunpack-wvunpack.o -lcurses ./.libs/libwavpack.a -lm
did the trick. The static compiles are only 626kB and 610kB, and they should work on Linuxes of many flavours.
If someone is having similar problems on an old Linux box, with
glibc 2.2.x, a static compile on a remote server with
glibc 2.3 might help.
Edit: This was accomplished using the 4.3 source.
Sorry for the slow replay!
The earlier version of WavPack encoder didn't want to work at me, but yesterday I've successfully compiled the WV v4.31 source with the OpenWatcom 1.3 for DOS and I've put the result here:
executables: http://www.mpxplay.net/wavpack/WVDOS431.ZIP (http://www.mpxplay.net/wavpack/WVDOS431.ZIP)
the modified source:http://www.mpxplay.net/wavpack/WVSRC431.ZIP (http://www.mpxplay.net/wavpack/WVSRC431.ZIP)
(maybe the author of WavPack can add my modifications to the official source release(s) too)
I haven't tested the exes too much, let me know if something wrong.
Please make a copy to your site, don't use link to these files directly, because maybe later I'll delete them (when I'll make a WV output plugin for Mpxplay)...
regards
Attila
Sorry for the slow replay!
The earlier version of WavPack encoder didn't want to work at me, but yesterday I've successfully compiled the WV v4.31 source with the OpenWatcom 1.3 for DOS
Shite, I didn't see this post before!
Thank-you very much, Mr. Padar. I'll upload those to RareWares today.
Edit: damn, the files aren't there anymore
go to
http://www.freewebtown.com/mpxplay/ (http://www.freewebtown.com/mpxplay/)
And please copy the files to your site, don't use link to my page/files!
hy.
is there any .dll for using the new version with Easy Cd-Da Extractor?
Thank you
go to
http://www.freewebtown.com/mpxplay/ (http://www.freewebtown.com/mpxplay/)
And please copy the files to your site, don't use link to my page/files!
Thanks, I already downloaded it and will upload it to RareWares soon. You can delete it now if you want...
Seems Quintessential got a plugin (http://www.quinnware.com/list_plugins.php?params=&page=3&type=input). For WavePack, though....
Considering the date that plugin was added (September 2003) I would guess it won't support WavPack4 files. Unless that is the date the entry was created and the author later updated his code...
Did anyone test it?
It got updated this February (http://www.quinnware.com/list_plugins.php?plugin=43), this version works with WavPack 4.3 files (APE tags are apparently only supported in the QMP dev builds though).
Thanks, I already downloaded it and will upload it to RareWares soon. You can delete it now if you want...
I can't seem to locate those packages on RW... did you forget to upload?
I can't seem to locate those packages on RW... did you forget to upload?
I talked to David recently, and he mentioned he was concerned there would be several issues in a DOS port of WavPack, specially in the high modes.
I didn't have time yet to test them myself either. If I host the binaries, I'll probably put a big warning about them being experimental.
I talked to David recently, and he mentioned he was concerned there would be several issues in a DOS port of WavPack, specially in the high modes.
I didn't have time yet to test them myself either. If I host the binaries, I'll probably put a big warning about them being experimental.
If the decoder works and produce working wavfiles it's hopefully useful and kind of safe. The encoder is probably more of a question and should require extensive testing to be declared "safe".... But hosting them with a "experimental, possibly not safe" tag should be ok, I would think.....
I talked to David recently, and he mentioned he was concerned there would be several issues in a DOS port of WavPack, specially in the high modes.
I just wonder, why do he think this?
I don't think so that DOS causes problems, rather the Watcom compiler.
(ie: the LAME encoder is much slower compiled with Watcom than with MSVC)
btw. now I've made an output plugin for Mpxplay too, and I've made some test encodings with it
in high and extra modes too (encoding, decoding, binary comparing), but I didn't see any bugs
(but it's true that I haven't tested it on thousand of different files)...
Attila
ps. the WavPack DOS encoder (and the output plugin) is still here:
http://www.freewebtown.com/mpxplay (http://www.freewebtown.com/mpxplay)
I just wonder, why do he think this?
He was afraid the extra modes (and not high modes - my mistake) would run out of memory. He didn't know you were using dos32a.
Now he just has some minor concerns about an issue with wildcards - IIRC - and such. Anyway, he gave me the go-ahead, and I'll see if I can upload it to RW this weekend.
He was afraid the extra modes (and not high modes - my mistake) would run out of memory. He didn't know you were using dos32a.
I see.
Can we (or the author) know what is the memory requirements of the extra modes?
The sent/uploaded Wvpack uses DOS32a with 256mb memory limit (if I remember well).
But the plugin for Mpxplay requires the DOS/4G version of Mpxplay, and the DOS/4G
extender has a 64mb (or 32?) memory limit...
Attila
Can we (or the author) know what is the memory requirements of the extra modes?
The sent/uploaded Wvpack uses DOS32a with 256mb memory limit (if I remember well).
But the plugin for Mpxplay requires the DOS/4G version of Mpxplay, and the DOS/4G
extender has a 64mb (or 32?) memory limit...
DOS/32a is limited to XMS's limit - 2GB.
The free versions of DOS/4G are limited to 32mb (http://www.tenberry.com/dos4g/watcom/4gwtable.html)
But that's surely plenty. David was worried about real mode's limitation to 640k - which would be enough for non-extra modes anyway!
He was afraid the extra modes (and not high modes - my mistake) would run out of memory. He didn't know you were using dos32a.
I see.
Can we (or the author) know what is the memory requirements of the extra modes?
The sent/uploaded Wvpack uses DOS32a with 256mb memory limit (if I remember well).
But the plugin for Mpxplay requires the DOS/4G version of Mpxplay, and the DOS/4G
extender has a 64mb (or 32?) memory limit...
Attila
As Roberto said, I wasn't originally aware that this was using an extender. The "extra" modes use a lot of memory, but probably no where near even 16 mb, and probably a lot less than that.
I did run into a couple other things when I tried this, however. The first was that it seems to be using the "linux" command-line syntax with the -o option for specifying output name/folder. I'm not sure this was on purpose or just because WIN32 was not defined, but it seems to me that following the Windows syntax makes more sense for a DOS version. This assumes that wildcards are not being expanded by the shell (via the extender) which is why I had to go to a different format for Linux. Also, I had trouble doing wildcard operations in other folders; I suspect this might be pathname differences in utils.c because of the WIN32 not being defined.
A more serious problem I ran into was whenever I got the "Overwrite (yes/no/all)?" message the program would not accept a response and would instead do a crash that required a hard reboot.
Other than those two things, I was pleasantly surprised with this and really appreciate you taking the time to make it available. Thanks!
David
It seems I haven't spent enough time with the testing...
Thnx, I will check and correct these bugs asap.
(and yes, usually I've followed the WIN32 defs, maybe I've missed some of them )
The older DOS/4GW can handle 32mb only, maybe the newer DOS/4G 2.xx series can handle more.
And I've limited/configured the used DOS32a extender to 256Mb, because else (using 2G limit) it eats too much conventional memory (more than 400k), but maybe it's problem with Mpxplay only (uses conv mem for some funtions).
regards
Attila
Ok, it's corrected and updated. You can find it on my page (http://www.freewebtown.com/mpxplay (http://www.freewebtown.com/mpxplay))
changelog:
removed: -o option (for Win32 (non-Linux) compatibility)
fixed: -t option
fixed: "overwrite (yes/no/all)" handling
fixed: filenames in subdirs (subdir\*.wav)
fixed: -u option
fixed: native UTF8 encoding (at -w)
btw. these bugs didn't hurt the quality of the encoded WV files, just the functionality of the program was not complete...
A.
Ok, it's corrected and updated. You can find it on my page (http://www.freewebtown.com/mpxplay (http://www.freewebtown.com/mpxplay))
changelog:
removed: -o option (for Win32 (non-Linux) compatibility)
fixed: -t option
fixed: "overwrite (yes/no/all)" handling
fixed: filenames in subdirs (subdir\*.wav)
fixed: -u option
fixed: native UTF8 encoding (at -w)
btw. these bugs didn't hurt the quality of the encoded WV files, just the functionality of the program was not complete...
A.
Hi again, and thanks for working on this again. I've downloaded it and I'll test it out in the next couple days and let you know. Sorry for the delay, I've been a little swamped...