Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[imeric]

Reviving this old post:  https://yabb.jriver.com/interact/index.php/topic,120813.msg835292.html#msg835292

I found a bunch of corrupted audio files on one of my hard drives not sure how it happened but I had about 30-50 files out of thousands which couldn't play and were without tags.  Fortunately this was isolated to an external drive out of 4-5 backups I also have on other PCs. It also seems to be specific to audio files as I also had a bunch of other files which all seem ok... 

I thought the external hard drive was bad but SMART Status was fine, Windows Check Disk could not find errors and WD diagnostics reported the drive was working fine.  The only thing I can think of is my son disconnected it without ejecting at one point...

I used MP3 tag to find most of them as they didn't have tags but the tool that was the most helpful was the File Integrity checker component in Foobar.  I scanned my entire library and not only did it find a few more bad files which had a lot of bad frames but I also found a few more files with only a few bad frames that would play just fine but only had one or two very subtle glitches.  Those files were ripped either accurately with dBpoweramp or with MCs SecureRip.  So those glitches were introduced at one point by something...Tag edition? Lyric addition? I don't know)...This part is scary.  Most of these bad files however had a similar Modified Date so whatever did it it seems like it happened on that date.  Those files still import fine in MC and are not considered bad.  So I have 30 or so ALAC files that got corrupted by the external drive plus another 20 or so with minor glitches plus 186 mp3 files  which I don't really care about and were most likely always bad.

I also had thousands of ALAC files reporting the file length was inaccurate. The audio is fine and just reconverting ALAC->ALAC in MC fixed this issue.  I realise JRiver can't have all the bells and whistles but since a lot of us are paranoid about the quality of their audio such a tool to report on file integrity would be great!

I will definitely pay a closer look at my files as I always synchronise my library between hard drives especially for Lyrics updates... Something messed up my files and I hope it won't happen again...Wondering if I shouldn't go back to FLAC which has Error Handling...

Thx

[Matt]

I run Verify on my Monkey's Audio collection often.  It's just an MD5 read so is really fast.

MP3 doesn't have anything like that unfortunately.

[imeric]

I run Verify on my Monkey's Audio collection often.  It's just an MD5 read so is really fast.

MP3 doesn't have anything like that unfortunately.

Can this be done on other Lossless codecs such as FLAC or ideally ALAC?

[zybex]

FLAC has MD5 checksums for the decoded data, not sure about MP3.

Would it be possible to compute and store in a Field the MD5 for the entire file (regardless of format), excluding the Tag blocks? This could then also be used for Video/Picture/Data files.

This would not so much detect if the file is corrupt, but would at least detect if the file was changed...

[wer]

I don't want to sound like I'm opposed to having an integrity checker, it would be nice.  But not as nice as some people might think.

Although md5 is "fast" on a file, a smallish file, it is NOT fast on 10,000 or 50,000 files.

Hashing just the the audio part of the file is good for avoiding the problem caused by tag changes, but it will not make the process of "check all my audio files" appreciably faster.

With even moderately sized libraries, this will not be a fast or lightweight process, even though it might have value.  It will be slow and take a long time to run, which will discourage people from using it.

Computing the checksum when the file is read for playback would be relatively painless, but by that point you probably know anyway if the file has been corrupted.

[imeric]

I don't want to sound like I'm opposed to having an integrity checker, it would be nice.  But not as nice as some people might think.

Although md5 is "fast" on a file, a smallish file, it is NOT fast on 10,000 or 50,000 files.

Hashing just the the audio part of the file is good for avoiding the problem caused by tag changes, but it will not make the process of "check all my audio files" appreciably faster.

With even moderately sized libraries, this will not be a fast or lightweight process, even though it might have value.  It will be slow and take a long time to run, which will discourage people from using it.

Computing the checksum when the file is read for playback would be relatively painless, but by that point you probably know anyway if the file has been corrupted.

I don't really care how long it takes as long as it can validate the audio integrity within the container.  This would be run weekly or monthly just to ensure files are ok.

Looks like how it's done by the foobar checker is sufficient.  It does take about 5-10 hours for close to 50 000 files.  It could be implemented via a check box in the file import option or a right click under the Library tools...   

[Awesome Donkey]

If such a thing is added, hopefully the feature itself along with the storing of the MD5 tag is made optional.

[wer]

If such a thing is added, hopefully the feature itself along with the storing of the MD5 tag is made optional.

Agreed.

[JimH]

It should be possible for a third party program to do this, using MCWS.

[newsposter]

implemented along with a strong caution that the integrity checking can take a very very long time......

[tij]

Thats why i am sitting on FreeNAS  ... checksum is part of the OS ... though if you copy already corrupted file to it, it wont detect it - all it does is prevent bit rot.