Print

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

[Matt]

Media 28.0.9 and newer add an "Audio CRC" checksum field that will be filled by the audio analysis.

This value is calculated for 16-bit and 24-bit stereo files.  The files will often need to be lossless (since a lossy format like MP3 is 64-bit).

The value we calculate matches common rippers like EAC (and saved in the *.log files of EAC).

I needed a way to check some files to see if they matched the rip, so thought adding this to MC made sense.

[BigCat]

Great news, Matt!

[benjy]

Media 28.0.9 and newer add an "Audio CRC" checksum field that will be filled by the audio analysis.

Will there be a way to scan your library to check for corruption or changes? For example, if disk blocks went bad or if a file was somehow modified since the CRC was calculated?

In the event that one intentionally edits an audio file after the original CRC is calculated, will there be a way to update the checksum so that the file is not flagged during any library corruption check.

If one runs audio analysis on a file and the CRC changes from the last value, how will it be handled? Since filesystem / disk corruption occasionally happens, I hope that a new analysis flags the discrepancy for further action by the user instead of just silently updating the original value.

Having the ability to detect corruption and changes is very cool. Thanks!

[Matt]

Maybe there should be another database field "CRC Changed" that is normally just false.

If something causes a CRC change, it could set it to true.

Then if you searched your library for any true values, you would find changes?

I'm the paranoid guy that invented a verify feature for Monkey's Audio so I routinely check my whole collection!

[Vocalpoint]

Maybe there should be another database field "CRC Changed" that is normally just false.

If something causes a CRC change, it could set it to true.

Then if you searched your library for any true values, you would find changes?

I'm the paranoid guy that invented a verify feature for Monkey's Audio so I routinely check my whole collection!

+1 I like this a lot!

But I think any CRC record check (or potentially a couple fields) should record date logic - especially a Modified Date so we can see exactly when a CRC was changed for troubleshooting purposes. Having the system simply state that the CRC has changed does not really help me determine when something has changed.

And while relying on the Windows Modified date should be good enough but quite frequently - but in many cases - it's not.

VP

[Hendrik]

MC is not going to continously monitor your files, it would only compute this during audio analysis - at which point it could notify you that something changed. Not sure a date field helps (or even the "CRC changed" field), since its not doing checks unless you ask it to check, and can immediately let you know then and there.

All that said, I view the CRC more generally useful to check rips or conversions, if you are worried about file corruption, the file system or the OS would probably be better equipped to monitor that on a regular basis, since verifying a file changed is faster if you don't also parse and decode the audio. My file server checks a portion of my files every night for integrity, and it gets through all files every few weeks that way.

[Matt]

MC is not going to continously monitor your files, it would only compute this during audio analysis - at which point it could notify you that something changed. Not sure a date field helps (or even the "CRC changed" field), since its not doing checks unless you ask it to check, and can immediately let you know then and there.

All that said, I view the CRC more generally useful to check rips or conversions, if you are worried about file corruption, the file system or the OS would probably be better equipped to monitor that on a regular basis, since verifying a file changed is faster if you don't also parse and decode the audio.

If you choose a format like APE, you'll get CRC checking built in.  It takes around 6 seconds to check a CD, and the detection is bullet proof.

[Hendrik]

If you choose a format like APE, you'll get CRC checking built in.  It takes around 6 seconds to check a CD, and the detection is bullet proof.

And yet you don't want MC continously running checks on every music file in your library. So when does it verify it? In audio analysis.

[Matt]

And yet you don't want MC continously running checks on every music file in your library. So when does it verify it? In audio analysis.

To Verify with Monkey's Audio you need to run the program.

It's one of the modes.

The check in Media Center is a lot heavier since it needs to decode all the data.

[Vocalpoint]

MC is not going to continously monitor your files, it would only compute this during audio analysis - at which point it could notify you that something changed. Not sure a date field helps (or even the "CRC changed" field), since its not doing checks unless you ask it to check, and can immediately let you know then and there.

Makes sense - and yes - if this is all manual in nature (like I need to run Audio Analysis to check the CRC) I probably would not bother with this at - with 100,000+ tracks - I would never have the time or patience to run Audio Anaylsis on the whole library.

And - I would never rerun Audio Analysis on a previously analyzed file. I do replace things with better copies from time to time but that would be a new incoming file.

Not exactly sure how this could work for large existing libraries. It would take me probably 24 hours to reanalyze everything AND I would be very annoyed if the file modified dates were altered due to a rescan as it would instantly cause my backups to need to take new copies of 100,000+ files.

Just as long as it's an option (and not automatically "On") ...

VP

[dtc]

Makes sense - and yes - if this is all manual in nature (like I need to run Audio Analysis to check the CRC)

Not exactly sure how this could work for large existing libraries. It would take me probably 24 hours to reanalyze everything AND I would be very annoyed if the file modified dates were altered due to a rescan as it would instantly cause my backups to need to take new copies of 100,000+ files.

If CRC were a separate option and did not require all the other Audio Analyze functions to run, then you could set it to not update tags and run it as needed. Having to rerun R128, HDCD, waveform just to do a CRC check seems unnecessary.  It really would be nice to be able to run these functions separately.  It seems that AA has taken on a bit of a bloat factor.

[EnglishTiger]

Does this mean that MC's own Ripper will also be able to calculate a CRC and store it in the ripped file?

[Matt]

Does this mean that MC's own Ripper will also be able to calculate a CRC and store it in the ripped file?

It's part of any audio analysis of a lossless file which ripping does perform.

[RD James]

And yet you don't want MC continously running checks on every music file in your library. So when does it verify it? In audio analysis.

Perhaps there could be an option to check a file (or the album?) on playback, and notify the user/flag a file if there's a change.

[newsposter]

so, can this be used for my request from a few days ago for a "clean rip" library field or flag?

[EnglishTiger]

so, can this be used for my request from a few days ago for a "clean rip" library field or flag?

Probably not because MC would have to store the CRC for every every track for every album to be able to compare your rips with those of others to tell if it was a "clean rip" or not.

[flac.rules]

This sounds excellent, I already use external software to CRC-check the audio on my files (regular CRCs doesn't work due to tag-changes). I really like a CRC-check-function. I forgot about the early upgrade this time around, but a CRC-checking function is worth it alone for me.

[benjy]

Perhaps there could be an option to check a file (or the album?) on playback, and notify the user/flag a file if there's a change.

Agreed! CRC change notification at playback would be exceptionally useful to avoid embarrassing fails while DJing. I have personally experienced a situation where a known good song silently became corrupt, got queued during a gig, and gave a nasty surprise to the room part-way into the song.

In light of that, I'd rather receive the notification when a song gets added to any zone's play queue. That way, I'd most likely get the notification when either adding it to my preview zone or Playing Now, and have enough time to find a replacement without messing up the flow of the set. 

[joelha]

Just to be clear, MC28 has a feature in which all the files which haven't been ripped on MC28 can still have their checksums tabulated in MC28?

Thanks.

Joel

[AJSchmidt]

Hello,
On 11/8/2021 I received an email from <mediacenter@listserver.jriver.com> with Subject: "A JRiver Offer For Black Friday".
An interesting paragraph appeared near the bottom of the page:

"Verify Your Audio Files"
"MC28 can write a CRC checksum to each audio file and use it to verify the integrity of your file each time it's played.  You can be certain that it's the same file, just as originally written."

That's the first I've read that MC has implemented the file integrity auto-verify feature, and it's a great idea! 
Unfortunately, the email didn't provide a link to find further details and instructions; and multiple searches turned up nothing. 

Please provide details for how to enable and configure this new CRC auto-check feature.

Thank you!

[antenna]

Media 28.0.9 and newer add an "Audio CRC" checksum field that will be filled by the audio analysis....

Might this CRC also be used to help reduce duplicate uploads for Cloudplay?

Use case:  I've uploaded a playlist with, say, 20 tunes.   A couple three weeks later, I want to re-upload one of the tunes because, e.g.,  I found better cover art.   Unfortunately, instead of just the one tune being uploaded anew, many (sometimes most) of the tunes on the playlist are re-uploaded, even though they have not been changed (at least changed in a manner that may be significant to Cloudplay).

 

[JimH]

Might this CRC also be used to help reduce duplicate uploads for Cloudplay?

Use case:  I've uploaded a playlist with, say, 20 tunes.   A couple three weeks later, I want to re-upload one of the tunes because, e.g.,  I found better cover art.   Unfortunately, instead of just the one tune being uploaded anew, many (sometimes most) of the tunes on the playlist are re-uploaded, even though they have not been changed (at least changed in a manner that may be significant to Cloudplay).

If the name of the playist doesn't change, only the changed file should be uploaded.

[antenna]

If the name of the playist doesn't change, only the changed file should be uploaded.

Of course, that depends upon how "changed file" is defined.

But, let's say, if I use a tune in multiple playlists, and it is uploaded both times, the duplicate does not seem to be weeded out.

Bottom line, I don't have an issue one way or another.  I just wanted to bring your attention to a symptom I see.  If you're OK with it, I'll go away quietly. 

I just thought that Cloudplay may be having more storage requirements than needed because of the multiple uploads.  I'm trying to help, not criticize. 

[HTPC Videophile]

Is there a way to check the integrity of the video file. For example corrupt disks and bad sectors sometimes "eat away" chunks of file. How to keep a check on that if the stored video  file still maintains its integrity ?

[Dawgincontrol]

If the name of the playist doesn't change, only the changed file should be uploaded.

If you play the file, the metadata will change when Media Center updates the stats (i.e. Last Played).  Thus, it changes the file in the way Cloudplay sees it.  In other words, in Cloudplay's vision, the file has been changed just by playing it. 

You may not make any physical change, but Media Center will.  That's why you get so many reuploads (is that a word?) to Cloudplay.  It recognizes any metadata as a change.

[ferrarabrainpan]

This value is calculated for 16-bit and 24-bit stereo files.  The files will often need to be lossless (since a lossy format like MP3 is 64-bit).

I have a handful of MP3 files in my 99% lossless library and when I view the details in MC28 the bit depth column shows them as 16-bit...?

[username2013]

Audio CRC is nice to calculate and compare it meets the original file but why don't you add par files to an album and if corruption occurs you will have the parity information to actually fix it back to the original bit for bit.  Using QuickPar is an awesome tool to check for integrity and if it's corrupt it will fix the files with the parity information back to it's original exactly.   http://www.quickpar.org.uk/
Check it out! This would be so cool to integrate into MC.  What do you think?

Steve