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

[gl.tter]

is Win98 SE supported by CheckWavpack?
Because it's not working on my side.

No, I didn't think anybody was still using it (NT-based apps use Unicode strings, hence the garbage paths you were getting).

Try this version and let me know if it works.

[disintegrated]

is Win98 SE supported by CheckWavpack?
Because it's not working on my side.

No, I didn't think anybody was still using it (NT-based apps use Unicode strings, hence the garbage paths you were getting).

Try this version and let me know if it works.

Thank You very, very much! Seems to work fine
Overnight wv-checking is planned
Only thing I noticed was wrong colourcodes here and there:


Regards,
disintegrated

[gl.tter]

Only thing I noticed was wrong colourcodes here and there:

Strange, I'm not seeing that here (on XP). Might be some bugs in 9x consoles.

Try this one, it tidies up a couple of 9x things.

[gl.tter]

New version uploaded (see 1st post).

The files now work on 9x too, and also auto-delete the 'BadFiles.txt' file when no bad files were found (it was supposed to do that before but didn't).

This post has been edited by gl.tter: Dec 13 2006, 21:48

[disintegrated]

Only thing I noticed was wrong colourcodes here and there:

Strange, I'm not seeing that here (on XP). Might be some bugs in 9x consoles.
Try this one, it tidies up a couple of 9x things.

Tried 0.95b.. still wrong colours.. just the same as in 0.94b_9x..
New screeny, this time with a selfmade corrupt file:



Everything else seems to just works fine..


Regards,
Disintegrated

[gl.tter]

Tried 0.95b.. still wrong colours.. just the same as in 0.94b_9x..

Thanks for the reports - is anybody else seeing this, on what platform?

[gl.tter]

0.97b RC1 released. Now includes the new Wavpack 4.40 code.

Only thing holding back a 1.0 release is the colour issue. Please report if you get this problem with details. If it's just down to Win98 bugs it won't be fixed.

Also Bryant pointed out that it likely doesn't work on Win95 - anybody want to try?

[satorippoi]

Hey, gl.tter, just wanted to let you know that you program is really awesome...thanks, mate!!!

btw, i can't find SSE2 edition at your site...could point where i can get it?..

yet, are you planning to make it support dual cores checking two simulteneously?..

[gl.tter]

Hey, gl.tter, just wanted to let you know that you program is really awesome...thanks, mate!!!

Cheers.

btw, i can't find SSE2 edition at your site...could point where i can get it?..

I've removed it because it wasn't actually faster. It was just compiler-generated SSE2, to really speed things up requires hands-on code.

yet, are you planning to make it support dual cores checking two simulteneously?..

I've thought about it, but it makes the display complicated, and you would also get some disk trashing, which may or may not be a problem depending on your setup.

Another way to support dual-cores would be to change the Wavpack code to unpack the stereo channels on seperate processors.

BTW, I added a couple more features and it's now at 0.99b RC2. This version creates an Explorer shell extension so that you can also scan folders by right-clicking them. Everyone, give this one a quick try so I can bump it to 1.0.

[ssjkakaroto]

Hi gl.tter, can you add non-ascii support to your app?
Checkwavpack can't check files with japanese characters (eg. "03. サンキュー!!.wv"), the error I get is couldn't open! ("can't open file")

[gl.tter]

Hi gl.tter, can you add non-ascii support to your app?
Checkwavpack can't check files with japanese characters (eg. "03. サンキュー!!.wv"), the error I get is couldn't open! ("can't open file")

I just took a look at this, turns out there's no easy solution. Almost none of my apps (including Wavelab and even the Wavpack utils themselves) can open this filename on my English XP - so far only Notepad has managed it (good old Notepad).

The problem is that the filename contains characters from a different language than what the OS is set to, which is particularly problematic with the ANSI (Win9x compatible) version. A workaround might be to temporarily change your OS language to Japanese - let me know if that works.

It does work with an all-Unicode version (with a couple of Wavpack code changes), but the problem is that the Jap characters cannot be displayed correctly on the console, nor are they listed correctly in BadFiles.txt. I don't know how much use that is, but try it.



This post has been edited by gl.tter: Dec 26 2006, 04:11

[ssjkakaroto]

Thanks a lot gl.tter, that'll work for me since the directories are using ascii characters, so I'll know which song is which by the track number.

EDIT: It's working fine

This post has been edited by ssjkakaroto: Dec 27 2006, 16:41

[gl.tter]

Managed to squeeze 1.0 in the last few hours of '06.

The default one is now the Unicode version, Win98 compatible is a seperate download if you need it.

Enjoy and keep reporting problems.

[collector]

is Win98 SE supported by CheckWavpack?
Because it's not working on my side.

No, I didn't think anybody was still using it (NT-based apps use Unicode strings, hence the garbage paths you were getting).

I do. Not even SE . Win98 is sufficient enough to run my MMM (multi media machine). It's only for fooling around with music and downloads. I am a newbie at Wavpack. So, I can't try your checker yet.

[xequence]

Very very usefull program, thanks alot

[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?

[photographer]

Gentlemen,

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.

JD

[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

[sn0wman]

hello, i am curious about one thing. it is written in the 'readme' file:

Each Wavpack block is tested for CRC errors, stored sample totals
are compared to the actual number of samples in the file, and MD5 fingerprints
(if present) are compared to the audio data.

on my computer, verifing with your app a set of files having stored fingerpring takes about 56 secs. when i use speek's wavpack frontend to verify these files (no switch), it takes almost the same time. little longer but still almost a minute takes to verify files with -m switch, which implies decoding and then hashing the stream with md5 algorithm. so, doing both verifing the integrity (blocks' crcs) and fingerprint should take about 2 minutes.
how you do it in a one ?
- i missunderstand something, or
- it is not written correctly in the readme that you do both things, or
- you really do it in some magic speedy way

//edit
well, another thing suprises my but its somehow OT here, but btw, as far as i understand, in context of wavpack, veryfing means checking all blocks CRCs, and veryfing with -m switch is about decoding and checking md5 (is it correct?). if it is, then how is it possible to do both things within almost the same time ? decoded file is more than twice bigger, and md5 is little slower than crc algorithm. i am not questioning anything here, just wonder if i can do some things better in my own code.

//edit2
these may be the answer:
(from format specs)

uint32_t crc; // crc for actual decoded data

it means, that it is not crc for a block itself, but for block decoded ?


best regards, sn0wman.

This post has been edited by sn0wman: Apr 5 2007, 18:56