WavPack 4.3 released Options

[bryant]

Just for the record, I still recommend using the -x option by itself, with no numeric parameter. In the past there was some logic to using -x1 because it would detect low-resolution files, but now this is handled by default, so there's no reason for that anymore. Please refer to this post:

http://www.hydrogenaudio.org/forums/index....ndpost&p=286569

There's nothing wrong with using the numeric parameter, but using -x by itself assures that you're probably getting the best "bang for the buck" for all the extra time you're using. The only exception to this is -hx6 if you absolutely must have the maximum compression and truly don't care how long it takes (like Kazuma).

[VCSkier]

The only exception to this is -hx6 if you absolutely must have the maximum compression and truly don't care how long it takes (like Kazuma). 

or me.

[skamp]

...or me, for high res audio.

[Borisz]

-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.

Well, I have time to spare for encoding...

[askoff]

-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.

Have you tryed plain -hx ? I have no HiRes audio to test with.

[skamp]

I have no HiRes audio to test with.

24 bit, 96 kHz stereo sample

[beto]

Hi, I can't seem to find a way to export the MD5 hashes created by wavpack to a text file.

Is this possible? How do I do it?

thanks.

[.halverhahn]

-hx6 took about 14 hours to encode but the bitrate went from 4671 to 4526 here.

Have you tryed plain -hx ? I have no HiRes audio to test with.

I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.

24bit/96kHz - 156 MB
WavPack -h - 95,5 MB
WavPack -hx - 78,8 MB

not bad for -hx ... but it took a long time on my P3-700

.halverhahn

[smz]

I have no HiRes audio to test with.

24 bit, 96 kHz stereo sample

Apparently this sample isn't available any more...

[smz]

I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.

Do you think this is representetive of true 24/96 material in terms of samples distribution?

Sergio

[landy]

maybe i was searching for the wrong thing as i only found a few results but if you want some hi res stuff you could try this link

[beto]

Hi, I can't seem to find a way to export the MD5 hashes created by wavpack to a text file.

Is this possible? How do I do it?

thanks.

just figured it out

wvunpack -s "wavpack file path and/or name here" > "text file path and/or name here"

[TCM]

  added: command-line option (-r) to generate a fresh RIFF header

i've been using flac mainly so i have a question about this option.

wouldn't it be better to have an option to not store any particular riff headers in the first place? and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?

to me this is a slight distinction between a compressed file (wavpack) vs. a compressed audio format (flac, ...).

[rjamorim]

and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?

Can't you store headers of whatever format you support - be it WAV, AIFF or MKA - and still offer format independency?

Or are you buying into Coalson's arguments not to offer RIFF storage support?

[TCM]

and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?

Can't you store headers of whatever format you support - be it WAV, AIFF or MKA - and still offer format independency?

Or are you buying into Coalson's arguments not to offer RIFF storage support?

personally, i haven't encountered any riff header information that i'd want to keep. that's because i mainly deal with lossless as a format for cd backups.

of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.

edit: additionally, i think that metadata should be transferred to the format's own metadata format instead of storing the original file as-is.

This post has been edited by TCM: Nov 9 2005, 10:20

[rjamorim]

personally, i haven't encountered any riff header information that i'd want to keep. that's because i mainly deal with lossless as a format for cd backups.

Many people have use for the extended RIFF info, mostly people dealing with audio editing and mastering.

of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.

What's the difference for end user? IMO, WavPack just caters to a wider audience with native header storage support. For the usual CD ripping guy, using either format leads to the same experience.

edit: additionally, i think that metadata should be transferred to the format's own metadata format instead of storing the original file as-is.

And indeed, it is stored in special locations inside the WavPack file, and if appropriate - E.G, in the lite decoder - the unnecessary data is ignored. That's how I understand it, at least.

This post has been edited by rjamorim: Nov 9 2005, 10:40

[TCM]

of course there's the argument of treating files vs. treating pure audio data and i have to agree i like flac's approach.

What's the difference for end user? IMO, WavPack just caters to a wider audience with native header storage support. For the usual CD ripping guy, using either format leads to the same experience.

that's true if you are not one of those people (i.e. me) that don't like storing redundant or unnecessary data.

one could argue that using a compressor that gives larger files is against that doctrine, but i think that's another issue.

anyway, my question was not to promote flac's approach. i just think that an option to either store or not store riff headers at encode time would be a better approach than an option to remove them upon decoding. that is assuming the option only works on decoding.

This post has been edited by TCM: Nov 9 2005, 10:53

[[JAZ]]

anyway, my question was not to promote flac's approach. i just think that an option to either store or not store riff headers at encode time would be a better approach than an option to remove them upon decoding. that is assuming the option only works on decoding.

Check it again under which program this option is listed.

[TCM]

Check it again under which program this option is listed.

*blush* so that means wavpack throws away any existing riff headers, generates a new one and stores that instead of just storing nothing and generating a fresh one upon decompressing?

[rjamorim]

*blush* so that means wavpack throws away any existing riff headers, generates a new one and stores that instead of just storing nothing and generating a fresh one upon decompressing?

Yes

I too plan to start using the new switch on my encodes from now on, as I too have no use for extra header data.

This post has been edited by rjamorim: Nov 9 2005, 12:36

[.halverhahn]

I've tested -h vs. -hx with a upsampled CD track to 24bit/96kHz.

Do you think this is representetive of true 24/96 material in terms of samples distribution?

Sergio

Not realy but the upsampled CD-Track contains nothing above 22050hz. You see how good WavPack perform with bandlimited HD-Source material.

[bryant]

This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.

I have dedicated two metadata field ids for storing images of the RIFF data so that a wav file can be perfectly recreated (one is for RIFF data that comes after the audio). But these fields are not required to interpret the audio information, are ignored by plugins (except Audition which uses them), and do not restrict the format in any way. A similar mechanism could be added to FLAC so that it too could, if desired, make perfect copies of wav files. Certainly this would not hobble the format or detract in any way; it would simply be an additional feature. (I am, of course, not suggesting this be added to FLAC. Given the enormous popularity of FLAC, I need every niche I can find! )

It would have been nice if I had set up wvunpack to create a basic wav header if there wasn't one in the WavPack file, but I didn't. So now all WavPack files must contain at least a 44 byte wav header because I think it would be silly to break old wvunpack versions to save 44 bytes, and the encoding library now transparently generates this if the application does not supply it.

While it is correct that in a perfect world I would interpret all the RIFF subchunks and convert them into some internal representation, this is simply not tenable. First, there are simply too many different ones to handle, new subchunk types are constantly being added, and some people have simply defined their own. Also, in some cases, converting back to RIFF might not be lossless because there is some flexibility in writing the subchunks (for example, the order or whether or not items are collected into a LIST chunk).

Obviously nobody would complain if an MP3 encoder discarded RIFF data. However, because archiving is one of their primary uses, I believe that lossless audio compressors are different. That extra RIFF information is part of the archive, and the fact that FLAC discards those unknown subchunks simply makes it unusable for some (albeit rare) applications. The fact that WavPack saves them does not similarly make it unusable for any current or future application (except maybe for the guy that specifically wanted them discarded, for whom I have now provided an option).

[Borisz]

This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.

Just a quick question: does the encoder support WV input? To recompress from one compression ratio to a higher one without decoding to wav first.

[bryant]

This idea that WavPack and FLAC are fundamentally different because one compresses files and the other compresses audio is no longer true. The current native WavPack format is not tied to a particular audio file format. It is the case that the command-line compressor only accepts wav files and the unpacker only generates wav files (or raw audio data), but this is because not a single person has ever asked for any other format. I could easily add other formats without breaking anything.

Just a quick question: does the encoder support WV input? To recompress from one compression ratio to a higher one without decoding to wav first.

No, sorry, wavpack.exe does not accept WavPack files right now.

There are a couple ways around this. You can use pipes so that no intermediate wav file is created but you'll need to do one file at a time and you'll have to copy tags using another app.

A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.

[rjamorim]

A lot of people use foobar (or other transcoding tools) to accomplish this, and in some cases these programs use pipes so that no wav file is stored.

Another elegant solution would be dbpoweramp.