RE: old burned cd file in wav

All of this discussion assumes that a music source provides a valid music file, without errors.  As I understand it, EAC can provide this security by using AccurateRip in the Ripping process.  Is there a way to test a CD for its integrity without going through the ripping process?  In other word is there a way to put in a CD into a drive and run some kind of scan to see if there are scratches or other issues that will impact the playing/ripping of the disc?

 

Mike

 

 

 

From: [email protected] [mailto:[email protected]] 
Sent: Thursday, October 01, 2020 6:20 PM
To: [email protected]
Subject: Re: [EAC] old burned cd file in wav

 

  

 





On Oct 1, 2020, at 3:32 PM, Jeff [email protected] [EAC] <[email protected]> wrote:

 

 

On 10/1/20 9:46 AM, Fred Maxwell  <mailto:[email protected]> [email protected] [EAC] wrote:

> {I’m assuming that you have at least two copies of your music
> collection and that you have diff}

Three local (U.S.) and two offsite (France, Norway). I assume I have diff (I run both Linux and W*nd*ws) but in my head a backed up corrupt file would still test OK with the diff method. That is, the two files could be the same as each other but still wrong.

I don’t know that it would be backed up because bit flips don’t change any file creation, modification, or even access times.  How would your backup software/script/etc. know the file had been changed?

 

Linux, BSD (including Mac) have diff.  There are implementations of diff for Windows and I’m betting that you’re familiar with Cygwin.

 

There is the very good suggestion from Jerry Baker of using md5sum to generate md5 hashes for all of your music.  I replied (again, you probably saw it) with a tweaked version of his suggestion using shasum to generate sha256 hashes and operating on all files in the directory tree, so that catches any format of audio file (some are, sadly, unavailable lossless), separate cover art, and so on.

> How many bit flips within FLAC files has your code detected?

I have found a total of two since, I think, 2006 in my own library that had somehow been corrupted. What I don't know is if they always were and I never noticed or if something happened. In both cases, the issues were clearly audible once I knew to listen for trouble. I'm pretty sure that one of the problems was caused by the then-ancient NAS I was using, the other one is a complete mystery. Fortunately I was able to easily replace both files. I have to plug HDTracks: One of the bad files was one I'd purchased from them and they made a replacement available.

But just last week I downloaded an album and did flac -t before going any further and found that four of the tracks wouldn't validate.

That’s a very good use of the internal CRC. I trust what I rip.  Not so much for what I receive from others.

> If you’re seeing bit flips in files, whether FLAC, executable,
> OS, or anything else, you have issues with your storage subsystem
> that need to be addressed.

My primary music drive is now a FreeNAS server using zfs, so I don't anticipate any more surprises going forward. When I run a FLAC check (which takes days!) I usually run against one of the backups rather than the primary. I'd rather find a problem at the end of the chain and work my way back up, if that makes any sense. It's probably not rational, but it certainly isn't hurting anything.

That makes complete sense and is extremely logical — so long as you always have a known-good copy from which to revert.  You’re kind of hosed if it corrupts on your primary, backs up to all of the mirrors, and then you find the problem days later.

 

I can see the appeal of things like whole-directory MD5sums and the like, but I'm unlikely to remember to properly recalculate those files after making tag changes. While I don't make changes every day, I do it often enough that something like that wouldn't work for me. Having something like FLAC's checksum that only tests the actual audio is perfect for me.

If I were doing that, I’d make it part of the script I run to rsync the music.  That’s a manual operation for me because I do it after I make changes, like tagging changes, to propagate the changed files from local storage to the NAS and, from there, throughout the network..

> My music (primarily in ALAC) is stored on a eight drive RAID-6
> NAS that performs regular scrubbing (parity checking). I have
> confidence in the data integrity of all files stored on that NAS,
> including the music files. Of course, that is not my only copy of
> my music (or any other files).

I don't think either of us has a whole lot to worry about. But my inner obsessive nerd just really likes being able to do a real-time corruption test even though in the real world it's probably very nearly pointless.

I totally get it; my inner obsessive nerd requires that my primary workstation always have ECC RAM and that my NAS have RAID-6 or better.. It’s why my workstation does backups to a NAS and to a local USB hard drive — even hour backups to one, odd hour backups to the other.

 

Good discussion.

 

Regards,

  Fred Maxwell

  Moderator, Exact Audio Copy Yahoogroup