Behandlung von Nicht-Sound-Dateien

Deutsch / German Vorschläge
#1

Angeregt durch diesen Thread, der zwar ein anderes Thema betrifft, sich aber auch mit der Behandlung von Nicht-Sound-Dateien in MP3Tag beschäftigt, greife ich mal ein Thema auf, das mich seit geraumer Zeit in MP3Tag etwas nervt oder sagen wir mal dessen Behandlung ich mir optimaler vorstellen könnte.

Ich habe in den Optionen von Mp3Tag diverse Nicht-Sound-Dateien-Suffixes definiert (JPG, PNG, PDF, TXT). Hintergrund ist dabei, dass ich in meinen Albumordnern nur das Frontcover in einer Auflösung von 800x800 in die Musikldateien einbette, um diese nicht zu sehr aufzublähen, ich andererseits im Albumordner aber durchaus Cover-Dateien in höherer Auflösung ablege (Front, Back, CD, Booklets) und auch manchmal Textdateien bzw. PDFs zu dem betreffenden Album sammele, und es als praktisch empfinde, auch diese Dateien im Blickfeld zu haben ohne auf ein weiteres Fenster im Dateimanager zurückgreifen zu müssen.

Dieser Umstand führt allerdings auch zu dem Zwang, dass ich bei allgemeinen Aktionen und Konverter-Aufrufen bewusst nur die Sounddateien markiere oder durch Filterung die Ansicht vorweg vor dem Markieren auf diese beschränken muss, da ansonsten durch MP3Tag eine Anwendung auch auf die Nicht-Sound-Dateien erfolgt, was zu Problemen und Fehlermeldungen führt.
Ein einfaches CTRL+A ist halt ohne vorherige Filterung so nicht angebracht.

Während gezielte Dateibenennungsaktionen speziell für diese Nicht-Sound-Dateien teilweise durchaus Sinn machen, weil ich dabei z.B. auf Pseudotags wie _DIRECTORY oder _PARENT_Directory zurückgreife, führen allgemeine Tag-Schreib-Aktionen natürlich zu unterbrechenden Fehlermeldungen.

Ich empfände es daher als eine gute Verbesserung, wenn MP3Tag solche Aktionen abfangen würde, damit der Benutzer selbst mit etwas weniger Akribie bei der Arbeit bei der Auswahl der Dateien vorgehen könnte:

  1. MP3Tag sollte nur versuchen "echte" Tags in Dateien zu schreiben, die es als solche unterstützt.

  2. MP3Tag sollte bei Dateiumbenennungen oder beim Anlegen von Ordnerstrukturen anhand von Tags aus Dateien sich auf solche beschränken, bei denen die Tags dort tatsächlich vorhanden sind bzw., die es generell unterstützt und demgemäß lesen kann.

  3. Dateibenennungen von Nicht-Sound-Dateien anhand von Pseudo-Tags sollten weiterhin möglich bleiben.

Punkt 1 wäre mir persönlich der Wichtigste und nach meiner laienhaften Vorstellung am leichtesten zu implementieren (Brücksichtigung der Dateiendung vor dem Versuch einer Tag-Schreib-Aktion), da es mich vor allem nervt, dass ich mal wieder versehentlich auch Nicht-Sound-Dateien markiert habe und dann mit unterbrechenden Fehlermeldungen bombadiert werde.
Eine Filterung durch den Benutzer ist im übrigen keine so praktische optimale Lösung, da ohnehin öfters anderweitig gefiltert wird und in diesen Fällen Filterkombinationen zum Tragen kommen müssen.

#2

Ja, Dauerfeuer auf den OK-Knopf abzugeben, ist lästig.
Hier ein paar gefundene Alternativen:
Der W10-Explorer spart sich die Problemfälle mittlerweile bis zum Schluss auf und fragt dann nach.
In MS Access, womit man ja auch größere Datenbanken manipulieren kann, werden Problemfälle in einer flugs angelegten Datenbanktabelle gesammelt, so dass man die noch mal nachvollziehen kann.
Vielleicht wäre für MP3tag so eine Sammlung von Dateinamen in einer Playlist eine (schnell zu implementierende?) Möglichkeit und der Meldung am Ende "Es hat Fehler gegeben, sollen die erstellte Playlist jetzt geöffnet werden?"
Das würde einem natürlich die gerade geladene Liste versauen, aber man könnte ja auch "Nein" klicken und erst mal weiter machen...

Was ich mir schwieriger vorstelle: für jede Datei erst mal zu prüfen, ob das eine ist, für die eine Aktion anwendbar ist und sie dann ggf. zu überspringen. Aber das ist Sache des Programmierers.

#3

Er sollte sich ja eigentlich nur an den Dateiendungen orientieren müssen.

#4

Naja, wie du selbst schreibst

D.h. MP3tag müsste bei jeder Aktion prüfen, um welche Sorte Datei es sich handelt und ob die Aktion Attribute beeinflussen soll, die in dieser Datei nicht vorhanden sind.

#5

Eigentlich müsste MP3Tag nur wissen, bei welchen File-Typen (Suffix) es in der Lage ist, Tags in die Dateien zu schreiben und andere Filetypen von der Behandlung ausschließen.
Damit wären die Unterbrechungen ("kann nicht geöffnet werden") schon mal abgefangen. Deshalb habe ich meine Priorität in der Darstellung ja auch darauf gesetzt.

Etwas anderes sind die Pseudotags, mit denen ich allenfalls Dateibenennungen vornehme. Beispielsweise benenne ich ein PDF, das in einem Albumordner liegt und eventuell den kryptischen Namen 4zghr907tg.pdf beim Download aus dem Internet bekommen hat, mittels format value und dem Formatstring %_parent_directory% - %_directory% indirekt nach dem Schema %albumartist% - %album% um, da in meinem System %_parent_directory% = %albumartist% und %_directory% = %album% ist.
Auf dieses Feature von MP3Tag, das gewissermaßen ein Nebenprodukt ist, möchte ich auch ungern verzichten.

Wiederum etwas anderes ist das Problem, dass MP3Tag auch Aktionen, deren Formatstring auf eingebetteten Tags beruht, "dumm" auch auf Files anwendet, bei denen es überhaupt keine Tags lesen kann und demgemäß als Ergebnis Murks erzeugt.

Und als letztes Problem haben wir, dass versehentlich angewendete Aktionen im Formatstring angegebene Tags mit Null-Inhalt verwenden, obwohl in der Datei der betreffende Tag überhaupt nicht vorhanden ist, was also auch über die Problematik von "Nicht-Sound-Dateien" hinausgeht und etwas die "Narrensicherheit" und Benutzerfreundlichkeit von MP3Tag erhöhen würde.

Ich sehe die Prioriät durchaus in der aufgelisteten Reihenfolge, wobei natürlich alle Probleme auch durch Sorgfalt des Benutzers abgefangen werden können, sei es durch manuelle Markierung oder Filterung oder auch bei den beiden letzten Varianten durch Gestaltung des Formatstrings.

#6

Ich hab das mit Mp3tag v2.90c umgesetzt.

#7

Danke Florian. Funktioniert.

Ergänzend ist mir noch eine Variante aufgefallen, die in die gleiche Richtung geht.

Wenn man filtert, kümmert sich MP3Tag auch m.E. unangebracht hinsichtlich echter eingebetteter Tags um Nicht-Audio-Dateien, bei denen MP3Tag keine Tags unterstützt.

Beispiele für betroffene Filterausdrücke:
%album% MISSING
%year% LESS 1960
NOT %unsyncedlyrics% HAS [Instrumental]

Betroffen sich also immer Ausdrücke, die nach einem Tag bzw. Taginhalt filtern, der nicht vorhanden ist.
In dem Fall werden auch alle Nicht-Audio-Files aufgelistet.

Man muss deshalb also umständlich Filterkombinationen anwenden
%album% MISSING AND %_filename_ext% HAS mp3

Wünschenswert wäre daher nach meiner Ansicht, dass MP3Tag bei auch bei der Filterung Nicht-Audio-Dateien hinsichtlich eingebetteter Tags außen vor lässt.