Aktion 'Tag-Feld formatieren' mit _ALL

Ich bereinige im Rahmen einer Aktion die Felder TITLE, ARTIST, ALBUMARTIST, COMPOSER, LYRICIST um Zeichen, die nicht dem deutschen Standardsatz entsprechen,

Beispiel:
Tag-Feld formatieren
$replace(%TITLE%,ā,a,ī,i,ķ,k,ļ,l,ņ,n,ų,u,ğ,g,ş,s,İ,I,ė,e,ă,a,ț,t,â,a,ū,u,ə,a,å,a,Ş,S,Ā,A,ę,e,ł,l,ą,a,ı,i,ı,i,î,i)

$replace(%COMPOSER%,ā,a,ī,i,ķ,k,ļ,l,ņ,n,ų,u,ğ,g,ş,s,İ,I,ė,e,ă,a,ț,t,â,a,ū,u,ə,a,å,a,Ş,S,Ā,A,ę,e,ł,l,ą,a,ı,i,ı,i,î,i)

usw…

Damit sind wir auch schon bei meinem “Problem” - wenn ich ein neues Sonderzeichen “finde”, das ich bereinigen will (meistens dann, wenn es in den Dateinamen %ARTIST% - %TITLE%.mp3 geschrieben wird und Windows die Datei dann nicht mehr erkennt) muss ich dies in mindestens 5 Aktionen machen.

Kann man das vereinfachen?

Versuche mit $replace(_ALL…) (oder $replace(%_ALL%…)

sind genau so gescheitert, wie es über die Aktion “Ersetzen” zu lösen - da kann ich zwar _ALL eingeben, aber dann immer nur ein Muster/Buchstabe bei “Original” und bei “Ersetzen durch”, so dass ich hier dann für jedes Zeichen eine eigene Aktion schreiben muss.

Habt Ihr eine andere Idee - oder etwas, was ich noch nicht kenen?

DANKE!

Guck mal, ob du hier Inspiration findest:

Es ginge um die Aktion "Tag-Felder importieren"

Von der Verwendung von _ALL rate ich persönlich grundsätzlich ab.
Weil Du damit wirklich sämtliche Felder korrigierst, inkl. z.B. die Liedtexte in UNSYNCEDLYRICS. Das führt dann im schlimmsten Fall zu "falschen" Wortbedeutungen.

Deutsche Beispiele sind

schon
schön

oder

Bar
Bär

Das gilt sinngemäss auch für Wörter in anderen Sprachen.

@LyricsLover , Danke für den Hinweis, aber ich bin da Pedant:

Entweder ich pflege ein Feld konsequent und in allen Files - oder es kommt über eine Aktion “Tag-Felder entfernen außer” weg.

Die von mir gepflegten Felder sind:

ALBUM;ALBUMARTIST;ARTIST;COMPILATION;COMPOSER;GENRE;LYRICIST;MEDIATYPE;PICTURE;RELEASETYPE;TITLE;TOTALTIME;TOTALTRACKS;TRACK;YEAR

… da hier nur

ALBUM;ALBUMARTIST;ARTIST;COMPOSER;GENRE;LYRICIST;MEDIATYPE;RELEASETYPE;TITLE

Textfelder sind und ich GENRE, MEDIATYPE und RELEASETYPE regelmäßigen Qualitätschecks sind (auch da habe ich vordefinierte Werte, die das Feld haben darf - oder “nix”) besteht hier keine Gefahr.

Danke @ohrenkino ,

ich glaube, jetzt habe ich es gebastelt

Falls es jemand nachbauen muss/will:

Quellformat:

$replace($meta_sep(artist,\\) - %TITLE% - $meta_sep(composer,\\) - $meta_sep(lyricist,\\) - $meta_sep(albumartist,\\),ā,a,ī,i,ķ,k,ļ,l,ņ,n,ų,u,ğ,g,ş,s,İ,I,ė,e,ă,a,ț,t,â,a,ū,u,ə,a,å,a,ä,ä,ö,ö,Ş,S,Ā,A,ę,e,ł,l,ą,a,ı,i,ı,i,î,i)

Formatstring:

%ARTIST% - %TITLE% - %COMPOSER% - %LYRICIST% - %ALBUMARTIST%

Bonusfrage:

Ich habe festgestellt, dass $replace scheinbar nicht “unendlich” viele Parameter/Paare verarbeitet. Ich habe, daher für jedes Feld mehrere $replace in einer Aktionsgruppe.

Weißt Du, wie viele “gehen”?

Die Doc sagt nur “multiple”:

returns the string x with all occurrences of string y replaced by string z. Supports multiple parameter pairs y and z.

Mit hoher Wahrscheinlichkeit sind es immer noch 31 Paare:

Da habe ich eine Verständnisfrage, inwieweit diese Zeichen dafür sorgen, dass Windows die Datei nicht erkennen sollte. Das sind doch alles für Dateinamen erlaubte Zeichen.

Für dienigen, die sich fragen welchen Sinn es macht ein ä mit einem ä oder ein ö mit einem ö zu ersetzen:
Die ä und ö sehen zwar gleich aus, sind aber nicht identisch:


Die kleinen deutschen Umlaute ä und ö die man direkt über die Buchstaben-Tastatur eintippt, nennt man auch:

U+00E4 : LATIN SMALL LETTER A WITH DIAERESIS
U+00F6 : LATIN SMALL LETTER O WITH DIAERESIS

Ich will da nicht unnötig darauf rumreiten. Für zukünftige Leser möchte ich aber doch darauf hinweisen, dass die Reduzierung von Sonderzeichen in Künstler- und Komponistennamen auch zu Verwechslungen führen kann.
Die beispielhaften Künstlerinnen

Sia
Sîa
Sià
Siâ
Siå

sind alles verschiedene Personen und würden durch die Ersetzung zur identischen
Sia
Wenn man keine zusätzliche eindeutige Künstler-ID speichert, kann das unter Umständen zu Verwirrung und Verwechslung führen.

@LyricsLover,

das ist mir komplett bewusst, aber ich finde es “gefährlicher", Künstler nach Sonderzeichen zu unterscheiden, die es nicht in allen Zeichensätzen gibt. (äöüß sind bei mir die einzigen Ausnahmen).

Also wäre es bei mir Sia (02) oder Sia (03) und dass muss ich eh "zu Fuß regeln, genau wie die Industrie mal “Gilbert Becaud" und mal “Gilbert Bécaud" anliefert - das muss ich auch alles zu Fuß machen bzw. schaffe mir mir obigen Ersetzungen Hilfen…

@poster - ich formuliere es konkreter (ich bin da auch kein Windows Experte): Wenn ich beispielsweise einen Titel mit einem Ogonek drin habe (den übersieht man leicht) und den in den Dateinamen übernehme, erkennt mein (Windows)Playlist-Editor diese Datei nicht und importiert sie nicht. Wo jetzt genau das Problem liegt (Windows der 3rd Party Software) kann ich nicht rekonstruieren, aber seitdem bin ich auf der sicheren Seite und nehme nur Standard Zeichen (ä, ö, ü… lasse ich zwar in den Tagfeldern (weil es sonst doch sehr legasthenisch aussieht) stehen, konvertiere aber separat den Dateinamen in “ae”, “oe” oder “ue”)

Vermutlich müssten solche Namen in UTF-8-Playlisten abgelegt werden. In MP3tag passiert das über die Erweiterung m3u8. Wenn das nicht von deinem Playlisten-Generator unterstützt wird ... wäre vielleicht ein anderer besser.
Wenn m3u8 Playlisten nicht von deinem Abspieler unterstützt werden, bleibt für mich trotzdem die Frage, warum die Ersetzungen in den Tags stattfinden müssen und nicht nur bei der Erzeugung der Dateinamen angewandt werden. Denn im Abspieler dürften all diese Zeichen gar keine Probleme bereiten.

@poster - ich kann es Dir nicht definitv sagen, ich habe aber immer das Problem, wenn ich

… mein mp3-Verwaltungsprogramm unterstützt es aber auch nicht und - sry - ich nehme das Programm, das mir am besten taugt und nicht das, dass dann auch noch mit litauischen und aserbaidschanischen Sonderzeichen umgehen kann…

Niemand sagt, dass es “muss” - es geht um Standards. Die Industrie liefert Dateien sehr unterschiedlich getaggt an - ich habe oben schon das Beispiel gegeben, manchmal bekomme ich “Gilbert Becaud” manchmal “Gilbert Bécaud”. Noch anstrengender wird es mit Dateien aus Polen oder anderen “östlichen” Ländern (die haben eben den Ogonek und einige andere Besonderheiten). Meistens ist es so, wenn ich einen Download direkt aus Polen bekomme, ist der Ogonek meistens gesetzt, bekomme ich sie vom deutschen Vertrieb, ist er schon eliminiert, da deren System auch oft nur “Standard”-Zeichen kann.

Es gibt 3 Möglichkeiten, um das zu vereinheitlichen:

  1. Ich ändere alle é zu e oder ę zu e - was natürlich Unfug ist, dann habe ich auch Unhéilig, oder eben Unhęilig - so rum geht es nicht, da es eben rund 20 verschiedene Varianten des "e" in unterschiedlichen Sprachen gibt. Also: Unpraktikabel.

  2. Ich schaue jeden Titel, jeden Interpreten, jeden Komponisten, jeden Texter nach, wie er sich in Landessprache schreibt - theoretisch möglich, aber beim Umfang meiner Sammlung faktisch - ca. 1,6 Mio. Datensätze - nicht machtbar. Zumal ich wette, spätestens wenn wir in die ostdeutschen, slawischen, russischen, griechischen Schriftzeiten kommen, wird es schon schwer von hier aus festzustellen, was richtig ist. Also ebenfalls: Unpraktikabel.

  3. Bleibt die 3. Variante, alle Buchstaben / Schriftzeichen auf die deutsche Entsprechung zu standardisieren. Natürlich ist das nicht perfekt und je nach Transliterationsprogramm bleiben immer noch Unschärfen zwischen "Jevgenij" und "Yevgeni" - aber von den 3 Möglichkeiten die praktikabelste.

... und auch die ist nur gangbar, wenn ich es automatisiere. Ich muss also sicherstellen, dass er aus jedem - ich nehme das einfachste Beispiel - "Gilbert Bécaud" einen "Gilbert Becaud" macht, damit ich nachher nur einen "Gilbert Becaud" in der Datenbank habe.

Aber die Frage war auch gar nicht, warum mache ich das (glaube mir, da habe ich in den vergangenen 20+ Jahren jedes Detail mehrfach hinterfragt), sondern WIE mache ich es. Und da hast Du mir sehr auf die Sprünge geholfen. Danke nochmal!