The beta release of WavPack 4.70 is available and assuming no bugs are found or last-minute changes suggested, this is essentially final. The impetus for this release was to incorporate some bug fixes that had accumulated since 2009, but I decided to also include a few new features that I had been thinking about.
The most interesting new feature is the ability for the wavpack command-line executable to accept existing wavpack files as input (i.e., transcoding). This allows users to easily change the settings of files in their lossless collection, or convert from older WavPack versions. The process copies all tag information from the source, and even allows modification of the tags. Temp files are also used now when overwriting and a verify option has been added, so it's possible to safely do transcoding
in-place (although this
is a beta version, so be careful!)
Note that care should be taken when transcoding to and from lossy files, and lossy to lossless transcoding is not allowed.
This release should generate identical files to the previous release (other than changes from bug fixes) and the performance should be similar (excepting differences from compiler revisions). I also built 64-bit versions for Windows, but they actually perform slightly worse than the 32-bit versions (at least on my system) so I'm not sure how useful they are or whether they will make it to the final release...any opinions?
New features:- transcoding from existing WavPack files (with tag copy)
- option to verify WavPack file integrity on creation (-v)
- use temporary files for safer overwriting
- detect UTF-16LE encoding for tag text files (mostly a Windows thing)
- transition to Visual Studio 2008 and 64-bit version (Windows)
- option to allow up to 16 MB APEv2 tag data (--allow-huge-tags)
- option for wvunpack to suppress audio decoding (useful for extracting only tags with -cc and -xx) (-n)
- experimental, undocumented option to store float16 and float24 audio data as integers (--store-floats-as-ints)
- allow channel-order specification on WAV files with WAVEFORMATEXTENSIBLE headers that contain zeroed channel masks
Bug fixes:- seeking to last block failure (after finishing file)
- memcpy() not always used correctly (Linux targets)
- unsigned char issue (ARM targets)
Windows features ported to Linux:- clean handling of ^C
- console title (with -z to defeat)
- wildcards in tag specifications
- 4GB file support on 32-bit OS
Updated manual (http://www.wavpack.com/wavpack_doc_470.html)
Windows 32-bit executables (http://www.wavpack.com/wavpack-4.70.0-beta-x86.zip)
Windows 64-bit executables (http://www.wavpack.com/wavpack-4.70.0-beta-x64.zip)
Linux distro (http://www.wavpack.com/wavpack-4.70.0-beta.tar.bz2)
Thanks in advance for any testing and/or suggestions!
Thanks! Works great, the memcpy() bug is gone indeed.
Thanks for this!
BTW. I see that FreeBSD has one patch on wavpack 4.60.1. It's to make it build with clang. I don't know if this holds any interest. Clang is being used more now here and there...
http://svnweb.freebsd.org/ports/head/audio...amp;view=markup (http://svnweb.freebsd.org/ports/head/audio/wavpack/files/patch-src__wavpack_local.h?revision=304164&view=markup)
Oh right, Debian has two small patches as well: http://patch-tracker.debian.org/package/wavpack/4.60.1-3 (http://patch-tracker.debian.org/package/wavpack/4.60.1-3)
Thanks for the patches! I had one of the Debians (the largefile, because they sent it to the mailing list) but not the other one or the Clang one. I'll get them in.
The WavPack package on Arch Linux is orphaned, so here's my PKGBUILD (https://wiki.archlinux.org/index.php/PKGBUILD) for version 4.70.0-beta:
pkgname=wavpack
pkgver=4.70.0b
pkgrel=1
pkgdesc="Audio compression format with lossless, lossy, and hybrid compression modes"
arch=('i686' 'x86_64')
url="http://www.wavpack.com/"
license=('custom')
depends=('glibc')
options=('!libtool')
source=("http://www.wavpack.com/${pkgname}-4.70.0-beta.tar.bz2")
md5sums=('5405ff4fd021059059b334962e218fb7')
build() {
cd ${srcdir}/${pkgname}-4.70.0
export CFLAGS="${CFLAGS/-O2/-O3}"
export CXXFLAGS="$CFLAGS"
./configure --prefix=/usr --enable-mmx --disable-static
make
}
package() {
cd ${srcdir}/${pkgname}-4.70.0
make DESTDIR=${pkgdir} install
}
With the PKGBUILD file in the current directory, type "makepkg -c" to build the package, then "sudo pacman -U <package>" to install.
I have corrected the Arch Linux PKGBUILD in order to comply with packaging rules, and have it accepted by the automatic package submission code on AUR (you can find it here: https://aur.archlinux.org/packages/wavpack-beta/ (https://aur.archlinux.org/packages/wavpack-beta/)). Basically I renamed the package from "wavpack" to "wavpack-beta", and added the appropriate "provides" and "conflict" variables. This release will be short-lived, it is only meant to allow easy installation of the beta version, until 4.70.0 final is released (which will be available in the usual "extra" repository, via pacman
- ).
- Edit: from the current maintainer - I'm not taking over.
Here's a local copy of the new PKGBUILD:
pkgname=wavpack-beta
pkgver=4.70.0
pkgrel=3
pkgdesc="Audio compression format with lossless, lossy, and hybrid compression modes"
arch=('i686' 'x86_64')
url="http://www.wavpack.com/"
license=('custom')
depends=('glibc')
options=('!libtool')
provides=('wavpack=4.70.0')
conflicts=('wavpack')
source=('http://www.wavpack.com/wavpack-4.70.0-beta.tar.bz2')
md5sums=('5405ff4fd021059059b334962e218fb7')
build() {
cd ${srcdir}/${pkgname/-beta/}-${pkgver}
# export CFLAGS="${CFLAGS/-O1/-O3}"
# export CFLAGS="${CFLAGS/-O2/-O3}"
# export CXXFLAGS="$CFLAGS"
./configure --prefix=/usr --enable-mmx --disable-static
make
}
package() {
cd ${srcdir}/${pkgname/-beta/}-${pkgver}
make DESTDIR=${pkgdir} install
# the current archive does not contain a license file
}
OK. A couple of insignificant nitpickings before the final *nix tarball... (of whom you are probably already aware)
- Remember to put back a license.txt and/or COPYING so the distros and vendors don't get uneasy...
- Update the ChangeLog
- Update the README
I could spot VS 2005 -> 2008. Maybe mention --enable-man for *nix.
Maybe also mention dependencies to build on *nix in there? Is it something like this...?
Dependencies to run:
libiconv
Dependencies to build:
bzip2 (to extract)
pkg-config
libtool
Dependencies to build manpages (is it this....?)
xsltproc
docbook-xml
docbook-xsl
- Add yourself to AUTHORS...?
OK. A couple of insignificant nitpickings before the final *nix tarball... (of whom you are probably already aware)
Thanks for these! I knew to update the changelog of course (I always do that last), but I had forgotten about manually putting the license in there, and I should update the README.
edit: faulty keyboard!
Any news of a final release of version 4.70?
4.70.0 beta for Windows hangs if the output file is NUL.
Any news of a final release of version 4.70?
I'm still working on it, but I've gotten a little busy with other things. Shouldn't be long now...
4.70.0 beta for Windows hangs if the output file is NUL.
Thanks for reporting; I have reproduced.
In the meantime a workaround is to pipe to stdout and redirect to NUL:
wavpack Track01.wav - > NUL
Any news of a final release of version 4.70?
I'm still working on it, but I've gotten a little busy with other things. Shouldn't be long now...
Awesome, Looking forward to the update
Any news on the final stable release?
- experimental, undocumented option to store float16 and float24 audio data as integers (--store-floats-as-ints)
Since it's not officially documented, I'll share my findings about such files here:
Code to determine the real wave format tag of from a WavPack context - presuming context to have been opened with OPEN_WRAPPER:
static uint32_t WavpackGetFormatTagFromWrapper(WavpackContext * wpc ) {
uint32_t bytes = WavpackGetWrapperBytes( wpc );
uint8_t * ptr = WavpackGetWrapperData( wpc ) ;
uint32_t fmtOffset = 8 + 12;
if (bytes < fmtOffset + 2) return 0;
if (memcmp(ptr, "RIFF", 4) != 0) return 0;
if (memcmp(ptr + 8, "WAVEfmt ", 8) != 0) return 0;
return (uint16_t) ptr[fmtOffset] + ((uint16_t) ptr[fmtOffset+1] << 8);
}
static uint32_t WavpackGetFormatTag(WavpackContext * wpc ) {
uint32_t v = WavpackGetFormatTagFromWrapper( wpc );
if (v == 0) {
if ( WavpackGetMode( wpc ) & MODE_FLOAT ) {
v = 3;
} else {
v = 1;
}
}
return v;
}Please correct me if the above is wrong.
Code to determine the real wave format tag of from a WavPack context - presuming context to have been opened with OPEN_WRAPPER:
There are two error cases I can see. The first is if the “fmt” chunk does not come first. I don't know if that ever happens, and is not that big a deal because this code will ignore it then.
However, if an extensible header is used and the wFormatTag is 0xFFFE, then this code will fail. I would suggest changing the condition for using the WavpackGetMode() result to:
if (v == 0 || v == 0xFFFE)
Or you could change WavpackGetFormatTagFromWrapper() to return 0 for 0xFFFE. Either way, this will make sure that the only failure cases are with unsupported files.
Any news on the final stable release?
Sorry for the delay on this...I've been putting out fires at my "day gig" and have been coming up to speed on Git because the WavPack repo is moving to GitHub soon.
But it's still on the radar!
Found out about the new release just now, simply awesome, thanks a bunch David.
bryant, pardon me I am pushing again, any news on the stable release?
Thanks.
Sorry for the delay, but I am now getting ready to finalize this release (been swamped with paying work that is now complete).
The first step was migrating the sources to GitHub, which is complete: repository is here (https://github.com/dbry/WavPack).
Thanks for hanging in there!