I am in the process of completing the 4.70 release of WavPack and thought it would be a good time for an alpha (built with SVN 300) while I finish tweaking. 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. 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 an alpha 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).
New features:- detect UTF-16LE encoding for tag text files (mostly a Windows thing)
- use temporary files for safer overwriting
- option to verify WavPack file integrity on creation (-v)
- transcoding from existing WavPack files (with tag copy)
- transition to Visual Studio 2008 (Windows)
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
Windows 32-bit executables (http://www.wavpack.com/wavpack-4.70.0-alpha.zip)
Linux distro (http://www.wavpack.com/wavpack-4.70.0-alpha.tar.bz2)
Thanks in advance for any testing and/or suggestions!
Nice one Bryan!
Been waiting for this feature.
What about native tagging support? (Remember APEv2 1MB limit for art work?)
Are you referring only to artwork? Tagging has been supported for years. From the manual:
-w "Field=Value" = write specified metadata to APEv2 tag
Thank You, bryant!
I will test soon. I have several files of classical music waiting to compress.
I like this release, having jumped the gun and tested at r294 or so.
I believe krafty is referring to the inability to add an image (and possibly other binary files) greater than 1MB to the WavPack tags using the command-line program. for me this is a non-issue because I don't use album art, and foobar2000 supports adding >1MB binary files anyway.
I think a solution to this would be to max out the tag data at 16MB (2^24), either on a per-field basis or with all the fields added together. if people want ridiculously huge files in their tags, why not?
good new,thank u, bryant.
i'll try it
Are you referring only to artwork?
Yes. I think the issue is here:
http://www.hydrogenaudio.org/forums/index....st&p=697522 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=75212&view=findpost&p=697522)
Did a transcoding test of a WavPack file, and I didn't see any problems. The tags transferred over just fine, and both files (original & copy) passed MD5 and bit comparison tests in fb2k. The new verification feature also worked (It adds 1.5 to 2.0 seconds to the encoding process).
I think the pkg-config file is not correct. From wavpack.pc.in:
Libs: -L${libdir} -lwavpack @LIBM@ @ICONV@However, iconv isn’t used in the library at all, only in the command-line tools. This means it should not be a linking requirement for libwavpack. The math library, on the other hand, is used by libwavpack, but its symbols are not part of the libwavpack API. This means it should go into Libs.private only (for static linking; see Guide to pkg-config (http://people.freedesktop.org/~dbn/pkg-config-guide.html)).
In summary, the line should be replaced by these two:
Libs: -L${libdir} -lwavpack
Libs.private: @LIBM@
What about native tagging support? (Remember APEv2 1MB limit for art work?)
No, I haven't forgotten, but I keep going back and forth on this one.
I was thinking of adding a "--allow-huge-tags" option to allow embedding of up to 4 MB of tag data, with no single file over 1 MB. Would that be enough?
In summary, the line should be replaced by these two: Libs: -L${libdir} -lwavpack
Libs.private: @LIBM@
Thanks! I'll get this in...
I was thinking of adding a "--allow-huge-tags" option to allow embedding of up to 4 MB of tag data, with no single file over 1 MB. Would that be enough?
That would still rely on APEv2 tags, right?
What I meant was a native tagging format like FLAC has.
Can VorbisComments be implemented into WavPack?
Sorry to sound pesky, I'm not really pesky about this. Any remedy is ok.
That would still rely on APEv2 tags, right?
What I meant was a native tagging format like FLAC has.
Can VorbisComments be implemented into WavPack?
Well I guess I'm confused then. I thought the problem was the desire to embed more than 1 MB of picture data into a WavPack file.
APEv2 tags are "native" to WavPack just like Vorbis comments are "native" to FLAC. Why would I want to implement Vorbis comments in WavPack? Doing that would break every program and device that supports WavPack files. Do Vorbis comments provide something important that APEv2 tags do not? The 1 MB limitation is something I have came up with to make the files more embedded-device friendly...it's not a APEv2 limitation (which actually specifies 8 KB as a limit).
Sorry Bryant.
It was my misunderstanding.
Well can you just raise this to 2MB then?
It is just for the sake of embedding a large 1000px cover front, some of them are 1.5MB sometimes. Only sometimes.
I don’t mean that you shouldn’t have the ability, but where do requests like this end? Someone might want larger images and/or a different format, and thus want 3 MB, someone else 4… If anything, it seems that it would make more sense to remove the limit altogether than to raise it to another arbitrary threshold on the basis of one particular user and some of their files. This seems fair if a hard limit to size is not known and could be done with a disclaimer that users are responsible for any potential weird behaviour introduced by especially large embedded chunks of data.
Of course, there’s always the argument that files should be left external if full flexibility is desired… [/devilsadvocate]
Since I use mostly for lossless encodings, I think this limit should be removed. Lossless files are huge anyway, 2MB won't make a difference. Let alone images with 400MB, say 10MB of image data wouldn't hurt.
Perhaps maintaining it for lossy is ok.
FWIW, to me, an all or nothing approach seems most logical. If not, someone would probably eventually find a reason to want >1 MB in lossy files, then we’d be back here again. It seems like it would be more work to maintain different limits for the two encoding modes, which doesn’t seem worthwhile.
Of course, I don’t speak for David or his desires for his codec. But given that he already threw out Frank’s unforgiving limit of 8 kB, there’s no specified upper ceiling for the size of embedded chunks, so it seems like less work just to leave it open, and let users do what they want at their own risk, than it would be to decide upon a new limit.
It isn't like the source is closed.
I don’t mean that you shouldn’t have the ability, but where do requests like this end? Someone might want larger images and/or a different format, and thus want 3 MB, someone else 4… If anything, it seems that it would make more sense to remove the limit altogether than to raise it to another arbitrary threshold on the basis of one particular user and some of their files. This seems fair if a hard limit to size is not known and could be done with a disclaimer that users are responsible for any potential weird behaviour introduced by especially large embedded chunks of data.
This makes sense. I'll attempt to read any tag I find. For writing, I'll add an option "--allow-huge-tags" that will raise the limit to some absurd size (like 16 MB) that disavows me of all responsibility.
Thanks, guys!
This makes sense. I'll attempt to read any tag I find. For writing, I'll add an option "--allow-huge-tags" that will raise the limit to some absurd size (like 16 MB) that disavows me of all responsibility.
Why not only use a long-option something more like "--allow-absurdly-huge-tags-solely-on-your-own-responsibility-so-there" ....