Validation lifecycle in beets

[GoogleCodeExporter]

It would be nice if beets managed the media file validation lifecycle. The goal 
is twofold:

1. Prevent obviously broken files from being added to the media repository.
2. Detect damage from other apps or partial failures of the underlying storage.

For each file, use (if provided) or create appropriate checksums:
. Use an external md5 file and http://mp3val.sourceforge.net/ or similar for MP3
. Use internal checksums and FFP for FLAC
. I'm not sure what the appropriate tools are for other file formats, but md5 
should be a fallback

Integrate validation with CLI and other beets functionality:
. Allow validation as an action in the CLI. 
. Optionally validate on file open

Detail:
. Some checksum methods cannot ignore the tag segment in media files. If file 
covered by this type of checksum has its tags modified, verify, modify tags and 
re-checksum 

Original issue reported on code.google.com by telejes...@gmail.com on 15 Feb 2012 at 11:55

[GoogleCodeExporter]

Great idea. As you mentioned, there are two components here:

1. A generic mechanism for detecting "broken" files of any type. (Currently, 
anything we can read the tags from is considered OK.)
2. Checksums on the files stored in the database to detect out-of-band 
modification. That is, a new Item property would be created called "sha256sum" 
or whatever that keeps track of the file's last known state.

Thanks for the link to mp3val. It should be pretty straightforward to put 
together a plugin that does at least the basic stuff here -- although plugins 
can't yet add a new database columns.

Original comment by adrian.sampson on 16 Feb 2012 at 12:56

• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Medium, Milestone-1.1, Component-Plugins

[GoogleCodeExporter]

Original comment by adrian.sampson on 19 Feb 2012 at 10:46

• Removed labels: Milestone-1.1

[GoogleCodeExporter]

I think it might be important to make a difference between "changed checksum" 
due to some other app modifying the file and "broken CRC" aka "file corruption".

I'm also using other applications (such as my mediaplayer Bangarang) to edit 
metadata of files, so I'd only need the "broken CRC" feature which means it 
should be configurable, which feature to use.

For FLAC files, the flac encoder itself can be used to check using the 'test' 
param -t, e.g.
flac -t /tmp/Testfile.flac

Original comment by elias.pr...@gmail.com on 20 Mar 2012 at 1:01

[GoogleCodeExporter]

Another tool for checking for bad frames and whatnot is Checkmate MP3 Checker, 
available here: http://checkmate.gissen.nl/download.php

There is a CLI version for linux, and it's GPL. I haven't used mp3val, just 
wanted to mention an alternative.

Original comment by mikemacl...@gmail.com on 19 Jun 2012 at 6:06

[GoogleCodeExporter]

This also ought to apply to attachments (gcode 109, github 111).

Original comment by telejes...@gmail.com on 10 May 2013 at 9:20