WavPack 4.60 beta available, Windows and Linux versions Options

[bryant]

This is long overdue, but I have finished a beta release of the 4.60 WavPack library and command-line programs:

Windows binaries
Linux distribution

The big changes are binary APEv2 tag support (i.e. cover art), raw PCM support, and the 16-channel limit being removed.

Here's the complete list of changes from 4.50. Note that some of these items were included in the alpha release (in January!)
and some were included in the beta release of the winamp plugin which was done for the Essentials Pack (so there is no new
winamp update).

• added functions to libwavpack for handling binary fields in APE tags (done in a backward compatible way)
• moved tag handling to its own source code module called tags.c (part of a slow cleanup)
• fixed bug where APEv2 tags with footers but no headers would not be detected
• added new option --write-binary-tag “Field=@File.ext” to allow appending binary tags during encoding (for cover art)
• added -x option to wvunpack to allow extracting arbitrary tags (including binary) to stdout
• added -xx option to extract a specified tag (including binary) to a file (optional custom filename with replacement codes %a, %t, and %e)
• added --no-utf8-convert option to wavpack and wvunpack to force skipping of the UTF-8 conversion for APEv2 tag fields
• improved formatting of -ss output and removed dumping of multiline tags (available now with -x option)
• fixed a bug that caused multichannel files using all 8 streams to refuse to decode (related to Ambisonics)
• increased number of available channels from about 16 to 4096 (although currently limited to just 256)
• new option --raw-pcm to allow encoding raw pcm data (allows specification of sampling rate, bit-depth, and number of channels)
• added ability to specify “unassigned” channels with --channel-order option
• added new option --pair-unassigned-chans (this was the previous behavior, but now unassigned channels go to mono streams)
• fixed bugs that could cause decoding of a valid WavPack correction file to report errors where none exist (although decoding was still accurate) or could cause seeking in correction files to fail
• add "lossless" and "category" to metadata keywords that we handle in winamp plugin
• add internationalization support to winamp plugin (many thanks to winamp folks!)
• add GPL license to xmms plugin and fix xmms build on some systems
• add -n option to wvgain for processing new files only (those without ReplayGain info)
• increase maximum possible gain value generated by wvgain from +24 to +64 dB

Note that the -ww option in the alpha for adding binary tags has been changed to --write-binary-tag because I
realized that using -ww would not report any error with a previous version, but would store the file as text (oops!)

Thanks everyone for your support and, as always, I appreciate any testing or comments on the betas!

[esa372]

Excellent news, bryant - Thank you!

It's great to see new WavPack developement. I'll be cheking out the new beta tomorrow.

Keep up the good work, and thanks again!



~esa

[Liisachan]

Thank you
I tested the --raw-pcm option, and --raw-pcm=48000,16,2 worked for me.
When wvunpack'ed, the result is (of course) bit-identical to the original data (except the newly decoded file has 'cue '... at the end).

[shadowking]

Thanks David.

[Synthetic Soul]

Excellent news David, thanks you.

I am particularly interested in binary tagging, and the ability to dump tags to stdout or to file.

[Xenion]

excellent

[sPeziFisH]

Thank you.

If you want to hear a complete album in only some minutes, you could put each track into its own channel.. and downmix Yeah I know, your human brains are not capable of things like that..

edit: stuff

This post has been edited by sPeziFisH: Sep 16 2009, 21:45

[BoraBora]

Great news, thanks a lot for your work, Bryant!

It may be worth noting that Catraxx now supports WavPack:

8.30 - August 31, 2009

* Audio: Added full support for WavPack files.

[ssjkakaroto]

Thanks for the update David!

[randal1013]

i'm a little confused about the binary tag for adding cover art. is there a specific field i should use for the art? and the picture must be in the same folder as the source file, right?

[bryant]

i'm a little confused about the binary tag for adding cover art. is there a specific field i should use for the art? and the picture must be in the same folder as the source file, right?

The field name for cover art has been decided to be "Cover Art (Front)". A complete list of WavPack accepted fields is near the end of this document (although anything is allowed, obviously, if you don't need any other application to recognize it).

I think the source file folder is looked in first, but if it's not found there then it will look in any other directories specified on the command line. Also, on Windows, the filename can be a wildcard (but there must be only one match).

[randal1013]

when i use --write-binary-tag "Cover Art (Front)=Folder.jpg", foobar's art viewer says it's an unsupported format or corrupt file. when i load the converted file into mp3tag it doesn't recognize any cover art. what am i doing wrong?

if i convert to wavpack without the binary tag, i can add cover art with mp3tag and it shows up in foobar.

[bryant]

when i use --write-binary-tag "Cover Art (Front)=Folder.jpg", foobar's art viewer says it's an unsupported format or corrupt file. when i load the converted file into mp3tag it doesn't recognize any cover art. what am i doing wrong?

Unless you just typed it wrong for this post, you need a '@' before the filename to indicate it's a file. Otherwise it's just making a binary tag with those 10 characters (and that's how it should show up when you do a -ss on it with wvunpack):

CODE

Cover Art (Front): 10-byte binary item

instead of this:

CODE

Cover Art (Front): 60288-byte binary item (jpg)

edit: I think that this is a pretty easy error to make, and I can't think of any reason to create a binary tag directly from the command-line (as opposed to from a file), so I think maybe I'll make it an error instead. Thanks for catching this!

This post has been edited by bryant: Sep 24 2009, 05:46

[randal1013]

i've tried the "@" symbol and when i click convert i get an error message.

1 out of 1 tracks converted with major problems.

Source: "D:\[MUSIC]\[TEMP]\Black Sabbath\1970-1\01.Black Sabbath.wv"
An error occurred while writing to file (The encoder has terminated prematurely with code 1; please re-check parameters) : "D:\TEMP\[MUSIC]\01.Black Sabbath.wv"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "D:\APPS\FOOBAR\0.COMMON\encoding\wavpack-460beta.exe" -i --write-binary-tag "Cover Art (Front)=@Folder.jpg" - "01.Black Sabbath.wv"
Working folder: D:\TEMP\[MUSIC]\

Conversion failed: The encoder has terminated prematurely with code 1; please re-check parameters

if i remove the "@", the conversion works, but then obviously the artwork doesn't show.

[bryant]

Ah, okay, I remember this problem (although I'm not exactly sure of a solution, depending on how you are doing things). The original thread was here.

The problem is that wavpack.exe does not know where to find "Folder.jpg" (which is why it's failing). It tries the current folder and any paths mentioned on the command line, but that's about all it can do. Taking out the '@' fixes the failure, but of course it's still not really finding the art.

What I gather from the poster is that if the artwork is put in the target folder then wavpack.exe can find it, but it can't find it if it's in the source folder. You might try that (if possible) or maybe putting in the full path to the artwork (probably not easy). Other than that, I don't have a solution, sorry...

I did fix the bug reported in that thread of the crashing, but I don't think that will help here.

[randal1013]

ok, i can confirm that it works if the picture is already in the destination folder, and also works if you put the full path in the command line. the good news is, you can use %FIELD% in the path.

for example, i used "@D:\[MUSIC]\[TEMP]\%ARTIST%\%DATE%\Folder.jpg" and it worked.

i also confirmed that by specifying the file path, the picture can be located anywhere on the hard drive. so if you have a folder with all your cover art, you can point to it in the command line. for example: "@D:\[MUSIC]\[COVER ART]\%ARTIST% - %ALBUM%.jpg" works as well.


so in conclusion, the binary tag actually has more functionality than originally implied.



good work and thank you for your help



EDIT: i feel i should point out, that $blah() operations don't work. so you can't use $REPLACE(%PATH%,%FILENAME_EXT%,Folder.jpg)

This post has been edited by randal1013: Sep 24 2009, 17:13

[tedgo]

for example, i used "@D:\[MUSIC]\[TEMP]\%ARTIST%\%DATE%\Folder.jpg" and it worked.

Thanks for this hint

EDIT: i feel i should point out, that $blah() operations don't work. so you can't use $REPLACE(%PATH%,%FILENAME_EXT%,Folder.jpg)

That's sad...
Would be great if foobar could support full title formating strings in converter.

@bryant
Thanks for making my preferred lossless codec even better and better

[bryant]

This is really good information...thanks for all your help (and thanks to everyone for trying out the new versions)!