WavPack 4.0 Beta Release 2, including sources Options

[robUx4]

The latest sources are now uploaded on the CVS of CoreCodec. I haven't uploaded the foobar sources yet because I would like to merge them with the sources I have.

This post has been edited by robUx4: May 14 2004, 14:11

[glauco]

WOW!!!

Linux version, foobar plugin, sources in CVS... Good news keep comming.

Nice work everyone.

[bryant]

After processing the program remains in the memory.

I had several instances of wavpack in the memory after encoding. Processor load stayed at 100%. I had to shutdown the tasks of wavpack manually using the taskmanager.

I have created and uploaded an experimental wavpack+wvunpack package to hopefully address the termination problem (which I cannot reproduce, but which I think is related to a bug in Cygwin). Please let me know if this does not fix the problem (or if you are not using Cygwin). If this works we'll put it in the next release. Thanks again.

experimental version

Thanks for the foobar component. It works fine (so far...). Just one suggestion: maybe there should be a warning/error report in the console when a decoding error occurs (with a corrupt Wavpack file).
I like it very much that Wavpack 4 can keep decoding when errors occur. But could you make it so that the sound is muted when playing the corrupt samples? The noise I hear now is bad for my ears and my speakers 

Yes, one of my next projects is to make playback and decoding more robust, and part of this is to mute (and report) errors. I am also considering making a utility that could do in-place "repair" of WavPack files. This would allow time to do a more thorough repair, including a crossfading of material before and after the error.

[Pamel]

Yes, one of my next projects is to make playback and decoding more robust, and part of this is to mute (and report) errors.

Matroska already has support for adding CRC32 data to Blocks it contains. Using this may be a little easier...

[HansHeijden]

For those interested, just updated the compression/speed webpage (see www button below) with some more WavPack -x levels. Although, the slowest ones will have to wait until some future PC...

[SometimesWarrior]

For those interested, just updated the compression/speed webpage (see www button below) with some more WavPack -x levels. Although, the slowest ones will have to wait until some future PC...

Thanks for the update, HansHeijden!

[den]

@FireStarter

Sorry I didn't answer you before, but yes you can use other tools to transcode to and from Wavpack4. If you stick to the 3.97 options, you can use any of the other multifrontends/transcoders without changing anything apart from copying over the latest wavpack encoder and decoder files.

If you want to use the new modes though, you need to either modify the scripts that usually sit behind these tools to make them work, or simply add what you need in the custom command section.

eg, I used Unifront 1.1 Beta today to transcode to and from Wavpack 4. If I used the old modes, I didn't have to change anything apart from copy the new files in. I wanted to encode into -hb320x3 though so I simply chose Wavpack encoder, and then turned off the built in options, and entered -hb320x3 into the "Add additional options" box. Worked a treat.

Hope this helps.

Den.

[robUx4]

For those interrested, I've tuned the Wavpack beta2 code to compile and run on OS X.

The modified sources can be found here. The same source compile for Win32, Linux and OS X.

[rjamorim]

Elite! Thanks

[MyAdviceIha]

It has been a while since any updates have been to Wavpack 4.0, so I was just seeing how development was coming along. I am very excited this release and plan to archive all my CDs using Wavpack 4.0 once it is final. Thanks for any info anyone can give.

[robUx4]

I guess it's quite stable.
Unfortunately CoreCodec is down so we can't really work in team.
Last I heard of David, he was working on a library version of his code.

[bryant]

It has been a while since any updates have been to Wavpack 4.0, so I was just seeing how development was coming along. I am very excited this release and plan to archive all my CDs using Wavpack 4.0 once it is final. Thanks for any info anyone can give.

Thanks for the interest. The third (and probably last) beta is almost ready and should be posted next week. Like robUx4 said, this version will include a library interface to the encoding routines and an updated Cool Edit / Audition filter (which will now support its native 32-bit floats). I have also made the decoding more robust to errors and added error reporting to the foobar plugin. Despite the lack of CVS, I have incorporated all of robUx4's linux/apple mods, so hopefully it will compile elsewhere with a minimum number of tweaks. Oh, I also improved the noise shaping in the hybrid mode.

[Tec9SD]

Nice to hear, thank you all for your time and effort.

Has MD5 support been created already?

Thanks, tec

[bryant]

Has MD5 support been created already?

MD5 has not been available in any release up to now, but it will be included in the new beta.

[dzy]

is the md5 going to be the md5 of decoded raw data or md5 of compressed data like monkey's audio?

[bryant]

is the md5 going to be the md5 of decoded raw data or md5 of compressed data like monkey's audio?

I chose to calculate the MD5 signature on the raw original uncompressed audio (not including headers). This seems to be the most logical to me for the purpose of verifying the integrity (and version) of the original audio track. This seems to also be the method used by Shnutil and OptimFROG (and I verified my values against those programs).

The disadvantage is that these will not be useful in checking hybrid lossy WavPack files, but WavPack's regular error checking will detect any errors in those. However, the user can still identify the original source by the stored signature even if they didn't create (or download) the correction file.

Please let me know if I made the correct decision (it's not too late to change my mind)...

[guruboolez]

Does it mean that files need to be decoded in order to check md5 validity?
I like Monkey's Audio md5 hashing, because I could check the integrity of my library very, very quickly. It's really nice, especially for slow computer like mine.

I good compromise might be two MD5 signature. Is it possible?

[bryant]

Does it mean that files need to be decoded in order to check md5 validity?
I like Monkey's Audio md5 hashing, because I could check the integrity of my library very, very quickly. It's really nice, especially for slow computer like mine.

I good compromise might be two MD5 signature. Is it possible?

Hmm, that's a good point. Of course, WavPack files verify a lot faster than some others (especially if you avoid using "high" mode), but I'll look into the diffculty of storing a compressed sum as well.

Aren't there stand-alone programs that provide that kind of functionality (with arbitrary file types)? They would certainly be faster and more efficient than anything I could provide for just checking the integrity of the compressed files.

[guruboolez]

Aren't there stand-alone programs that provide that kind of functionality (with arbitrary file types)? They would certainly be faster and more efficient than anything I could provide for just checking the integrity of the compressed files.

Changing tags -> modified md5.
Monkey's MD5 checking is not affected by any tag modification.

[bryant]

Changing tags -> modified md5.
Monkey's MD5 checking is not affected by any tag modification.

Hmm, good point #2...

[robUx4]

IMO it's good to compute it on the encoded data.
#1) there are less data to compute
#2) in normal mode the data are purely equivalent
#3) MD5 also applies to hybrid mode

Also does the MD5 applies to the whole file or just parts ? (and therefore many MD5s)