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: Free utility to check all Wavpack files in a Directory. (Read 66282 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Free utility to check all Wavpack files in a Directory.

Reply #25
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.
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #26

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

Free utility to check all Wavpack files in a Directory.

Reply #27
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.
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #28
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).
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

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

Free utility to check all Wavpack files in a Directory.

Reply #30
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?
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #31
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?
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #32
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?..

Free utility to check all Wavpack files in a Directory.

Reply #33
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.
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #34
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")
Allegari nihil et allegatum non probare, paria sunt.

Free utility to check all Wavpack files in a Directory.

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

Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #36
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
Allegari nihil et allegatum non probare, paria sunt.

Free utility to check all Wavpack files in a Directory.

Reply #37
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.
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #38

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.

Free utility to check all Wavpack files in a Directory.

Reply #39
Very very usefull program, thanks alot
And if you believe theres not a chance to die...

Free utility to check all Wavpack files in a Directory.

Reply #40
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!

Free utility to check all Wavpack files in a Directory.

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

Free utility to check all Wavpack files in a Directory.

Reply #42
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).
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #43

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.

Free utility to check all Wavpack files in a Directory.

Reply #44
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.
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

Reply #45
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: [Select]
  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. 

Free utility to check all Wavpack files in a Directory.

Reply #46
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?

Quote
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?
Author of -Wavpack4Wavelab- and -CheckWavpackFiles-

Free utility to check all Wavpack files in a Directory.

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

Free utility to check all Wavpack files in a Directory.

Reply #48

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.


[
Quote

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

 

Free utility to check all Wavpack files in a Directory.

Reply #49
hello, i am curious about one thing. it is written in the 'readme' file:
Quote
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)
Quote
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.