I think it has been addressed numerous times:
(e.g. here: http://www.hydrogenaudio.org/forums/index....amp;hl=verifier (http://www.hydrogenaudio.org/forums/index.php?showtopic=88875&hl=verifier) )
the "file integrity verifier" is not optimized for multicore, hence does only start 1 verification process at a time.
therefore it (for me) only uses 13 % (12,5) of the availlable CPU power.
this will only get more serious in the years to come, since multicore is something everyone nowadays has, even cellphones.
in my oppinion it should not be difficult to just start as many verification threads as core are availlable, like foobar converter does.
additionally to that: the resultwindow after completed verification is quite useless.
(http://img26.imageshack.us/img26/6894/screenshotydw.jpg)
some kind of sorting or filtering of the results would be quite helpful.
only way to do actually something good with the results is to export them,
copy the path of the tracks in question from the exported text file,
put them in a text file, make it unicode, save as m3u8 and load it in foobar so you can "fix vbr header" and "rebuild mp3 stream"
this could all be done with a simple sorting, selecting, right click, and "fix + rebuild"
or maybe the resultwindow could directly offer e. g. to "fix vbr header" for all found tracks with "inaccurate length"
does anyone agree with me?
no one cares?
Wait, am I too late? I care! I care!
I have my own question or suggestion, as the case may be. I just tried using File Integrity Verifier to check a boatload of audio files. The verification seemed to be proceeding very slowly -- actually taking longer to verify some files than it would take to play them! If the OP is correct in stating that the Verifier uses only one processor core, that can't help. But is there perhaps some setting that I could adjust to speed things up? It could take days, weeks, months to verify a large collection of files at that rate.
In a related observation, I noticed that the verification was going into audio files contained in rar archives. Presumably those archived audio files had been detected in the initial processing phase, when Foobar2000 was building my playlist. Is there a setting that can prevent that sort of investigation?
Many thanks for any comments.
Personal requests (some a bit far-fetched):
1) Add ability to save logs in source directory using a title formatting pattern (just like the Converter does);
2) Currently there are two trailing newlines in the logs -- there should only be one;
3) Group-by-album (just like ReplayGain scans) when verifying multiple items;
4) AccurateRip v2 and CTDB.
yes, i care too some good points mentioned here.
Threading is a bad idea considering most music libraries are still located on HDDs and NAS. In case of format conversion, multi-threaded makes sense because the encoding speed is usually way below the reading speed of a HDD, so even with some overhead (=more HDD head movements needed) you get better results. Reading files from magnetic storage ASAP as foo_verifier does in one thread is faster than multi-threaded, though, because the overhead shaves off the maximal speed the HDD has. The problem is usually even more noticeable with a NAS.