Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WavPack 4.3 released (Read 48075 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

WavPack 4.3 released

Reply #25
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). 

WavPack 4.3 released

Reply #26
Quote
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). 
[a href="index.php?act=findpost&pid=340350"][{POST_SNAPBACK}][/a]

or me. 
a windows-free, linux user since 1/31/06.

WavPack 4.3 released

Reply #27
...or me, for high res audio.

WavPack 4.3 released

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

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

WavPack 4.3 released

Reply #29
Quote
-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.

WavPack 4.3 released

Reply #30
Quote
I have no HiRes audio to test with.
[{POST_SNAPBACK}][/a]


[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=35624&pid=318436&st=0&#entry318436]24 bit, 96 kHz stereo sample[/url]

WavPack 4.3 released

Reply #31
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.

WavPack 4.3 released

Reply #32
Quote
Quote
-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.
[a href="index.php?act=findpost&pid=340484"][{POST_SNAPBACK}][/a]

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
.halverhahn

 

WavPack 4.3 released

Reply #33
Quote
Quote
I have no HiRes audio to test with.
[{POST_SNAPBACK}][/a]


[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=35624&pid=318436&st=0&#entry318436]24 bit, 96 kHz stereo sample[/url]
[a href="index.php?act=findpost&pid=340487"][{POST_SNAPBACK}][/a]


Apparently this sample isn't available any more...
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

WavPack 4.3 released

Reply #34
Quote
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
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

WavPack 4.3 released

Reply #35
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

WavPack 4.3 released

Reply #36
Quote
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.
[a href="index.php?act=findpost&pid=340570"][{POST_SNAPBACK}][/a]



just figured it out 

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

WavPack 4.3 released

Reply #37
Quote
  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, ...).

WavPack 4.3 released

Reply #38
Quote
and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?[a href="index.php?act=findpost&pid=340639"][{POST_SNAPBACK}][/a]


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?

WavPack 4.3 released

Reply #39
Quote
Quote
and in that case, wouldn't it be better to make a lossless compressor independent of any particular file format?[a href="index.php?act=findpost&pid=340639"][{POST_SNAPBACK}][/a]


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?
[a href="index.php?act=findpost&pid=340672"][{POST_SNAPBACK}][/a]
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.

WavPack 4.3 released

Reply #40
Quote
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.

Quote
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.

Quote
edit: additionally, i think that metadata should be transferred to the format's own metadata format instead of storing the original file as-is.[a href="index.php?act=findpost&pid=340677"][{POST_SNAPBACK}][/a]


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.

WavPack 4.3 released

Reply #41
Quote
Quote
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.

WavPack 4.3 released

Reply #42
Quote
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.
[a href="index.php?act=findpost&pid=340682"][{POST_SNAPBACK}][/a]


Check it again under which program this option is listed.

WavPack 4.3 released

Reply #43
Quote
Check it again under which program this option is listed.
[a href="index.php?act=findpost&pid=340689"][{POST_SNAPBACK}][/a]
*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?

WavPack 4.3 released

Reply #44
Quote
*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?[a href="index.php?act=findpost&pid=340691"][{POST_SNAPBACK}][/a]


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.

WavPack 4.3 released

Reply #45
Quote
Quote
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
[a href="index.php?act=findpost&pid=340582"][{POST_SNAPBACK}][/a]

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

WavPack 4.3 released

Reply #46
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).

WavPack 4.3 released

Reply #47
Quote
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.[a href="index.php?act=findpost&pid=340767"][{POST_SNAPBACK}][/a]

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.

WavPack 4.3 released

Reply #48
Quote
Quote
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.[a href="index.php?act=findpost&pid=340767"][{POST_SNAPBACK}][/a]

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.
[a href="index.php?act=findpost&pid=340793"][{POST_SNAPBACK}][/a]

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.

WavPack 4.3 released

Reply #49
Quote
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.[a href="index.php?act=findpost&pid=340796"][{POST_SNAPBACK}][/a]


Another elegant solution would be dbpoweramp.