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.
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.
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...
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.
Has MD5 support been created already?
is the md5 going to be the md5 of decoded raw data or md5 of compressed data like monkey's audio?
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?
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.