Free utility to check all Wavpack files in a Directory., New Software Announcement Options

[gl.tter]

Updated - latest version: 1.0 (now with shell extension)

I've released a little standalone Windows utility that will check single Wavpack files, or all .wv files contained in a directory tree or drive for errors:
http://wavpack.gl.tter.org

Easy two-click operation. It writes the full paths of any bad files found to a text file for further processing. Useful when eg. like me you ripped 1500+ files with an overheating CPU, and had to track down the few corrupted ones.

Bug reports welcome (here or email).

This post has been edited by gl.tter: Dec 31 2006, 21:38

[Maglor]

Hi all! I've been reading a lot of posts lately about bad blocks or crc errors on wavpack files, and I can't find the solution to my problem, which is: recently I've bought a new external drive where I've passed all my rips still on folders, not rar's, and many of them have now been corrupted when they weren't before that.
So now what I want is to recover those files, because many of those CD's that I've ripped aren't with me anymore. So is there a little something like this that could recover those wavpack files?
I appreciate very much all the help!

[photographer]

Unfortunately I'm having a little difficulty. When I run CheckWavpackFiles_1.0 I get an error stating "# Couldn't read MD5 hash.". I use Easy CD DA to rip my audio to my hard drive. I've tried it with files that were ripped using both the latest and the previous WavPack .dll's.

[gl.tter]

Unfortunately I'm having a little difficulty. When I run CheckWavpackFiles_1.0 I get an error stating "# Couldn't read MD5 hash.". I use Easy CD DA to rip my audio to my hard drive. I've tried it with files that were ripped using both the latest and the previous WavPack .dll's.

Never had that error on any of my files. It could be a bug in the way Easy CD encodes Wavpack files. I don't use EasyCD, anybody else able to test it?

Try ripping to .wav and encoding with the Wavpack utilities. If that works, send an email to the EasyCD guys.

EDIT: also try verifying a bad file with the Wavpack utils (switch -v IIRC).

This post has been edited by gl.tter: Apr 2 2007, 21:49

[photographer]

Unfortunately I'm having a little difficulty. When I run CheckWavpackFiles_1.0 I get an error stating "# Couldn't read MD5 hash.". I use Easy CD DA to rip my audio to my hard drive. I've tried it with files that were ripped using both the latest and the previous WavPack .dll's.

Never had that error on any of my files. It could be a bug in the way Easy CD encodes Wavpack files. I don't use EasyCD, anybody else able to test it?

Try ripping to .wav and encoding with the Wavpack utilities. If that works, send an email to the EasyCD guys.

EDIT: also try verifying a bad file with the Wavpack utils (switch -v IIRC).

Thanks for the prompt reply. I just installed WavPack 4.40 and Foobar 2000. Had it rip a single CD to a new directory and your utility verifies that all files are OK. I'll submit a bug report to the author of Easy CD-DA.

Thanks again. Good tool to have.

[gl.tter]

Thanks for the prompt reply. I just installed WavPack 4.40 and Foobar 2000. Had it rip a single CD to a new directory and your utility verifies that all files are OK. I'll submit a bug report to the author of Easy CD-DA.

Cool, he's probably just writing the MD5 hash in slightly the wrong place (or maybe he's forgetting to write it altogether?).

It should be:

<pack all samples>
call WavpackStoreMD5Sum(...)
call WavpackFlushSamples()


(why do my new replies keep getting attached to my last reply??)

Hi all! I've been reading a lot of posts lately about bad blocks or crc errors on wavpack files, and I can't find the solution to my problem, which is: recently I've bought a new external drive where I've passed all my rips still on folders, not rar's, and many of them have now been corrupted when they weren't before that.
So now what I want is to recover those files, because many of those CD's that I've ripped aren't with me anymore. So is there a little something like this that could recover those wavpack files?
I appreciate very much all the help!

Maglor, it depends why the files are coming back corrupt. If there's a problem with the external drive's interface (USB?), then the files might actually be OK on the disc. If not, then the data really is corrupt and there's no getting it back.

Try connecting the external HD another way, or on another PC.

This post has been edited by gl.tter: Apr 2 2007, 23:34

[bryant]

Cool, he's probably just writing the MD5 hash in slightly the wrong place (or maybe he's forgetting to write it altogether?).

It should be:

<pack all samples>
call WavpackStoreMD5Sum(...)
call WavpackFlushSamples()

That will work fine but my documentation says:

CODE

  1. get a context and set block output function with WavpackOpenFileOutput()
  2. set the data format and specify modes with WavpackSetConfiguration()
  3. optionally write a RIFF header with WavpackAddWrapper()
  4. allocate buffers and prepare for packing with WavpackPackInit()
  5. actually compress audio and write blocks with WavpackPackSamples()
  6. flush final samples into blocks with WavpackFlushSamples()
  7. optionally write MD5 sum with WavpackStoreMD5Sum()
  8. optionally write RIFF trailer with WavpackAddWrapper()
  9. optionally append metadata tag with functions in next section
  10. optionally update number of samples with WavpackUpdateNumSamples()
  11. close the context with WavpackCloseFile()

which is actually wrong because the MD5 sum will not get written! There should be an additional step at 8.5 to call WavpackFlushSamples() again. Doh!

Maybe a registered user should show this post to the author of Easy CD Extractor...

David

(why do my new replies keep getting attached to my last reply??)

It's a feature so you can easily do this.

[gl.tter]

That will work fine but my documentation says:
<snip>

The function name is confusing - people might easily assume that it's only required after packing the samples.

How about requiring the call only once (as you said it works anyway), and calling it 'FlushStream' or 'FlushData' instead?

It's a feature so you can easily do this.

Is that sarcasm or true? If it's a feature, how do I turn it off?

[bryant]

That will work fine but my documentation says:
<snip>

The function name is confusing - people might easily assume that it's only required after packing the samples.

How about requiring the call only once (as you said it works anyway), and calling it 'FlushStream' or 'FlushData' instead?

Well, there actually is an odd case where the call would be required twice. If the audio only consumes a single WavPack block then the additional flush is required to make sure that the RIFF header and trailer are not in the same block. Not very likely, but possible...

And, of course, you know I'm not going to rename the function, B! But I will update the docs.

[

It's a feature so you can easily do this.

Is that sarcasm or true? If it's a feature, how do I turn it off?

I am never sarcastic!

I haven't tried to turn it off (because I like it), but I think that the button labelled "+ QUOTE" with the tooltip "Toggle multiquote addition" might do it.

The author of the software has made the corrections that you noted and has published a link to the updated .dll's in the thread at : http://www.poikosoft.com/forum/viewtopic.php?p=2573#2573 . Thanks very much for your help and your great softwares.

Wow, that was fast!

Thanks for the link, but unfortunately only registered users can access that page. Does it seem to fix the problem?

Thanks,
David