Comment 10 for bug 911743

>A crucial question in this topic is: What is the main task of Mixxx?
>For my feeling Mixxx focuses clearly the live situations.

Definitely agree here. Mixx should handle the least possible metadata about tracks - and the metadata it handles should be Mixx-specific (play counts, cue points, etc.). There is already a standard mechanism for handling track-specific metadata: id3 tags.

Of the 5 use-cases in the original post:
-User defined tags - what kind of tags? Anything track-specific can be handled by id3 tags (as comments, if nothing else).
-Advanced mp3 tags - can be handled by id3. Mixxx should be able to read useful non-standard tags, such as the musicbrainz tags that Picard inserts.
-Mass tagging - leave this to mass taggers (picard, kid3, etc).
-Filename rename based on tags and viceversa. - see below
-Scripting - I don't see how this is related to metadata. Is it?

The biggest problem related to leaving tagging to an external app is that if a track file is renamed, all of the Mixxx data is lost. The best way to deal with this would be to ID tracks based on a hash of the actual sound data, instead of the file name.

Picard already adds an "AcoustID" to mp3 files, so perhaps this could be used? (AcoustID doesn't appear to be added to all file formats, unfortunately, but "Musicbrainz recording ID" does seem to...).

If this isn't feasible, then simply storing the md5sum of the audio data in the track as the track ID in the Mixxx database shouldn't be too resource hungry.