Felder/Tags automatisch nach Regeln prüfen

ehrlacher · April 28, 2026, 5:31pm

Gibt es eine Möglichkeit, dass mp3tag "automatisch" Eingaben in Feldern auf "Gültigkeit" nach bestimmten Regeln / Formaten prüft?

Hintergrund:
Obwohl ich (glaube ich) recht sorgfältig tagge, passieren mir immer wieder kleine Fehler und plötzlich steht "202" oder "2062" in der Jahreszahl statt "2026" oder ich hab einen Leerschlag zuviel (am Anfang, am Ende oder einfach nen doppelten) in einem Titel oder Album oder Interpreten...

Bisheriges "Doing":
Ich habe mir dafür rund 20 Filter gebastelt, mit denen ich von Zeit zu Zeit meine gesamte Musiksammlung auf Fehler absuche - nun wäre es doch super, wenn mp3tag direkt beim Speichern "meckert" oder ein "!" anzeigt nach dem Motto "überleg Dir das noch mal..."

Beispiel:
Ich checke die Jahreszahlen mit dem Filter:

(%year% GREATER 2026 OR %year% LESS 1930 OR %year% IS "" OR (NOT %year% MATCHES ^\d{4}$)) AND NOT YEAR IS 0000

Der schmeißt mir alle mp3s raus, die eine unplausible (über 1930 kann man streiten man kann auch 1920 oder 1910 nehmen), in der Zukunft liegende Jahreszahl oder eben keine Jahreszahl haben oder eine falsch formatierte (die Industrie liefert schonmal YYYY-MM-DD an). "0000" ist mein Dummy für CDs, auf denen keine Jahreszahl steht und die auch nirgends in Erfahrung zu bringen ist (meistens Budget-CDs von Anfang/Mitte der 1990er Jahre).

Gibt es da irgendwas, was mir da "weiterhilft" aus Eurer Sicht?
Oder wäre das ein Feature-Vorschlag?

Danke für Euren Input!

ohrenkino · April 28, 2026, 6:20pm

Ich glaube kaum, dass es allgemeingültige Regeln gibt, die als fest eingebranntes Feature umzusetzen wären.

Für die Prüfung:
Ich würde mir eine Aktionsgruppe bauen, die bestimmte Bearbeitungen als Abschluss vornimmt (führende und endständige Leerzeichen entfernen z.B. oder doppelte durch eines ersetzen).
Weitere Aktionen könnten sich an deinen FIltern orientieren und ein benutzerdefiniertes Feld (vielleicht EINGABEFEHLER) füllen - auch da vielleicht nur mit einer "1", wenn irgendein Fehler gefunden wurde oder mit einer Benennung wie "Jahr") erzeugen, so dass anschließend nur noch nach der Präsenz dieses Felds gefiltert werden muss, nicht aber x Abfragen nacheinander ausgeführt werden müssen.

LyricsLover · April 28, 2026, 7:47pm

Es gibt keine Verifikationsmöglichkeit die ein "falsches" Speichern verhindert.
Aber Du kannst Dir beliebig viele Prüf-Spalten einrichten, die was auch immer Du einheitlich haben möchtest ständig prüfen.

Eine meiner Prüf-Spalten zeigt mir z.B. sofort visuell an, ob ein Cover in der Höhe und Breite mehr als 500 Pixel gross ist:
$if($and($grtr(%_cover_height%,500),$grtr(%_cover_width%,500)),✔,)
Damit sehe ich auf einen Blick ob irgendwo eine Covergrössenanpassung vergessen ging:

Nach solchen Spalten kann man auch sortieren, wenn sie mehrere verschiedene Werte enthalten können.

Das erspart die Auswahl und Anwendung von Filtern und ist auch visuell - je nach Wahl der Werte oder Symbole - deutlich.

ehrlacher · April 28, 2026, 10:31pm

Erst mal Danke Euch beiden

@ohrenkino: Ich gebe zu, die doppelten Leerzeichen waren kein gutes Beispiel, da ich die in der Tat inzwischen über eine Aktionsgruppe "abfange" und nur noch die Altlasten rausfiltern muss. Mir geht es vorsichtig um die Felder, bei denen der Nutzer (also ich) eingreifen muss, zum Beispiel wenn im YEAR Tag "202" steht, oder gar nicht und zu entscheiden ist, on das nun 2012, 2020, 2026 oder was auch immer sein sollt.

Meine Idee war auch tatsächlich nicht, dass es da eine einheitlich definierte "Gültig oder ungültig-Regel" gibt, sondern dass der User selbst hinterlegen kann (analog des Filters), wann er einen Ausdruck als "gültig" betrachtet und er dann im Zweifelsfall rot hinterlegt wird - oder in einer separaten Spalte ein Symbol anzeigt.

@LyricsLover Deine Lösung ist schon ziemlich nah an dem (oder fast genau das), was ich mir dachte - jetzt scheiter ich nur an meinen limitierten "Programmier-Kenntnissen".

Ich habe versucht, den oben beschriebenen und funktionierenden Filter in eine Formel zu "übersetzen", scheitere aber...

$ifgreater(%year%,2026,,$ifgreater(1930,%year%,,$if($eql(%year%;""),,))) funktioniert noch tadellos.
(Ich fand das für "Stimmt nicht" passender als den Haken).

Spätestens beim Vergleich mit dem "AND" 0000 Kriterium, verfange ich mich in Schleifen...
(*UPDATE: $regexp "Bug" in meiner Formel hab ich gestern Abend noch gefunden.)

Gibt es da ne einfache Methode, Filter in Funktion zu "übersetzen"? (Die Filter stehen ja alle, habe das Gefühl, mit den Funktionen fange ich von vorne an...) Da stoße ich an meine Grenzen...

Liebe Grüße!

ohrenkino · April 29, 2026, 6:36am

Der Vorteil einer Aktionsgruppe wäre, dass die dynamisch wachsen kann, je nach dem, welche Fehler du sonst noch so findest - es können ja immer noch welche neu hinzukommen.
Ich weiß auch nicht, wie viele Spalten du für einen Fehlercheck hinzufügen möchtest und wie lang der Ausdruck in "Wert" werden soll - das wird schnell unübersichtlich, fürchte ich.

könntest du in der Aktionsgruppe in mehrere Aktionen übersetzen, jeweils vom Typ "Tag-Feld formatieren" für das Feld EINGABEFEHLER der Formatstring:
%eingabefehler%$ifgreater(%year%,2026,:Jahr in Zukunft;,)
%eingabefehler%$if($less(%year%,1930),:Jahr zu früh;,)
``%eingabefehler%$if($equl($num(%year%,1),0),:Jahr fehlt;,)`

Den Check auf die Länge im Track, könntest du ggf. so abfangen:
$if($eql($len($regexp(%track%,(\d+)/(\d+),$1)),$len($regexp(%track%,(\d+)/(\d+),$2))),x,-)

Und am Ende kannst du ggf. nach dem Feld EINGABEFEHLER filtern oder sortieren. Das Feld sollte ja nur dann gefüllt sein, wenn es einen Fehler nach Durchlauf der Aktion gegeben hat.
Und nach der Korrektur sollte es weg sein, weil du es gelöscht hast.

LyricsLover · April 29, 2026, 7:52am

Es führen meistens mehrere Wege nach Rom.

Wenn Du den Inhalt von TRACK darauf prüfen willst, ob vor dem Slash und nach dem Slash immer exakt 2 Zahlen stehen (also z.B. 01/10 OK ist, aber 1/10 nicht OK), dann funktioniert auch dieser Prüfspalten-Wert:

$if($eql($regexp(%track%,^(\d{2})/(\d{2})$,OK),OK),,❌)

Das Vergleichsprinzip bei Mp3tag ist ein wenig speziell.

Der $regexp()-Befehl in Mp3tag gibt immer einen String zurück.
Wenn der reguläre Ausdruck nicht matcht/übereinstimmt, wird einfach der ursprüngliche String unverändert zurückgegeben.

Der $if()-Befehl wertet jeden Ausdruck als "wahr", wenn er nicht leer und nicht 0 ist.
Deshalb funktioniert eine direkte Kombination wie
$if($regexp(...),...) nicht wie erwartet - sie ist praktisch immer wahr.

Die Lösung ist in diesem Fall das Verhalten von $regexp() gezielt auszunutzen:

1.) Bei einem Match wird der gefundene Inhalt durch einen festen Wert (z.B. OK) ersetzt.
2.) Bei keinem Match bleibt der ursprüngliche String bestehen.
3.) Mit $eql() kann dann geprüft werden, ob das Ergebnis genau OK ist.

Beispiel:

$if($eql($regexp(%track%,^(\d{2})/(\d{2})$,OK),OK),,❌)

Erklärung:

Passt der Inhalt von %track% auf das Muster (\d{2})/(\d{2}) (also genau zwei Ziffern vor und nach dem Slash), gibt $regexp() den String OK zurück.
$eql(...,OK) ist dann wahr → es wird nichts angezeigt.
Wenn keine Übereinstimmung/Match vorliegt, bleibt der ursprüngliche String erhalten → der Vergleich schlägt fehl → es wird ❌ angezeigt.

Das würde bei diesen beispielhaften TRACK Inhalten so aussehen:

Nicht das ich wüsste.
Aber Du kannst mit ganz konkreten Beispielen und Filtern gerne hier im Forum nachfragen.

ehrlacher · April 29, 2026, 11:55am

Danke Dir herzlich - ich versuche ja nicht zu oft zu "nerven" und erst mal zu tüfteln, merke aber immer wieder, dass - wenn man sich wie ich nur alle paar Monate mal damit beschäftigt - einige Dinge verloren gehen, die man glaubte zu wissen und wohl auch mal "richtig" wusste... daher Danke für die Einordnung, das hilft ne Menge.

Ich habe es diese Nacht dann mit einem
$if($neql($regexp(%track%,^\d{2}/\d{2}$|^\d{3}/\d{3}$,$1),%track%),,❌)
geschafft, was wohl dasselbe in grün ist (Du siehst, wie verquast ich dann war, dass ich mit $neql gespielt habe, doppelte Verneinung quasi).

Momentan "versuche" ich, alle meine Filter so zu gestalten, dass ich pro Feld nur noch einen habe, den ich dann in eine Formel umwandel.

Beispiel:
Für Titel will ich finden:

die das "&" enthalten (das ich i.d.R. durch "And" oder "und" bzw. "+" ersetze)
die ein Semikolon enthalten (macht beim CSV Export in manchen Programmen-Probleme, wenn sie das Einsetzen in "" nicht richtig interpretieren)
die ein Anführungszeichen enthalten (ähnlicher Grund wie oben)
die mit einem Leerzeichen beginnen
die mit einem Leerzeichen enden
die doppelte Leerzeichen enthalten

funktioniert top mit:
%title% MATCHES (&|;|^\s+|\s+$|\s\\|\\\s|\w+\s\s\w+|\")

Werde mich dann als nächstes an die Umwandlung in Formel(n) machen, kann gut sein, dass ich dann noch mal "nerve"...

Danke auf jeden Fall!

LyricsLover · April 29, 2026, 12:13pm

Mit solchen Fragen nervst Du nicht. Du hast ja jeweils auch schon selber probiert und hast Dir ganz konkrete Überlegungen gemacht.
Nicht vergessen: Es profitieren immer auch einige andere stille Mitleser von solchen Fragen und Antworten. Genau dafür ist ein Forum wie dieses da.

Wenn Du dann idealerweise auch noch Deine gefundenen, funktionierenden Lösungen mit uns teilst, haben wir sogar alle etwas davon.

ehrlacher · April 29, 2026, 12:20pm

Sobald ich die "Filtersammlung" vollständig habe, werde ich sie gerne hier posten - vielleicht kann der ein oder andere Aspekte daraus gebrauchen oder hat noch weitere Checks, an die ich bisher nicht gedacht habe...

LyricsLover · April 29, 2026, 12:26pm

Damit prüfst Du auf 2 x zweistellige oder 2 x dreistellige Zahlen vor/nach dem Slash. Wenn es zwingend auf beiden Seiten gleich viele Stellen sein müssen, dann ist der Ausdruck so wirksam.
Wenn es vor oder nach dem Slash 2 oder 3 Stellen sein dürften, könnte man das direkt mit ^\d{2,3}/\d{2,3}$ erreichen.

Das würde dann 12/100 genauso akzeptieren wie 13/99 oder 123/456.
Aber auch 567/21 oder 18/11.
\d{2,3} bedeutet hier:
\d steht für eine beliebige Zahl
{2,3} ist ein Quantifier und bedeutet: mindestens 2, höchstens 3 Wiederholungen.
Konkret also alle Zahlen von 10 bis 999 würden matchen/übereinstimmen.

LyricsLover · April 29, 2026, 1:51pm

Du kannst es damit probieren:
$if($neql($regexp(%title%,'&|;|^\s+|\s+$|\s\\|\\\s|\w+\s{2,}\w+|\"',''),%title%),❌,)
Das würde alle Treffer mit einem in der Prüfspalte versehen.
Also alle Einträge die irgendwo im Titel eine Deiner Definitionen enthalten.

Man könnte diesen Befehl auch so erklären:
"Wenn sich der Titel verändert, nachdem bestimmte unerwünschte Muster entfernt wurden → zeige "

ehrlacher · April 30, 2026, 10:42am

Yapp, genau aus diesem grund will ich xx/xx oder yyy/yyy haben - das ist (für mich) der Sinn der führenden Null, dass es vorne wie hinten dieselbe Stellenanzahl gibt und "99/123" fände ich genauso "störend" wie "1/12", was ich ja durch diesen Check genau abfangen will.

Funktioniert bei den ersten Tests super und dient mir dann hoffentlich als "Blaupause" oder Motivation für weitere Filter-Formel-Umschreibungen.

Momentan hänge ich aber im selben Kontext an einem anderen Problem... - daher später hier weiter.

ohrenkino · April 30, 2026, 11:20am

Was machst du denn mit der Erkenntnis, dass das Format in TRACK nicht stimmt?
Korrigierst du dann die fehlerhaften Einträge per Hand?

Ich würde ja eine Aktion vom Typ "Tag-Feld formatieren" für TRACK anwenden:
Format String: $num($regexp(%track%,(\d+)\s*/.*,$1),$len($num($regexp(%track%,.*/(\d+),$1),1)))/$regexp(%track%,.*/\s*(\d+),$1)

Bitte beachte, dass der Windows Explorer 3-stellige Zahlen mit führenden Nullen als oktale Werte interpretiert.

ehrlacher · May 1, 2026, 2:01pm

Nein, dann lass ich eine von mir geschriebene Aktionengruppe drüber laufen, die versucht den Fehler zu korrigieren - in 90 % der Fälle schafft sie das. Das "x" brauche ich, um zu wissen, über welche Tracks ich noch mal die "Korrekturgruppe" drüber laufen muss - bei über 1,6 Mio. Tracks mag ich das nicht über alle machen. Bei neu ankommenden Tracks lasse ich die Gruppe eigentlich per se drüber laufen - das "x" ist der Reminder, dass ich es vergesse, die meisten Fehler passieren halt immer noch vor der Tastatur

Es gibt aber auch Einträge, die ich bewusst "per Hand" korrigiere, das sind die restlichen 10 %. Entweder sind da irgendwelche "Sonderzeichen" drin, die ich noch nicht in der Korrekturgruppe abfange und dann ergänze (ich habe gelernt, dass es zweistellige Variationen des Apostrophs und Backticks gibt...) oder eben die, bei denen ich bewusst per Hand entscheiden will. Ein " kann nämlich aus irgendeinem Grund ein Anführungszeichen im Titel sein, das wandel ich dann zum ', es kann aber auch ein Zeichen für 7'' oder 12'' sein, das wandele ich dann eben in ''. Irgendwann werde ich auch dafür nen Replacer schreiben, aber das ist dann Schritt 2 oder 3...

Von daher, die Aktionsgruppe(n) habe ich natürlich seit Jahren - momentan geht es mir darum, die Tracks zu finden, die trotzdem Fehler enthalten (weil ich vergessen habe die Aktionsgruppe zu starten oder sie noch nicht alle "Sonderzeichen" enthielt, sie wächst eben kontinuierlich) und gleichzeitig künftig direkt bei der Eingabe durch ein "x" zu sehen, da ist noch Handlungsbedarf (und wenn es nur bedeutet "Starte Deine Aktionsgruppe!").

ohrenkino · May 1, 2026, 2:09pm

Witzigerweise hat mich das auch schon geärgert - und deshalb habe ich mich von dem Inch-Zeichen völlig verabschiedet und aus 7" Single und aus 12" Maxi gemacht.
Das sind aber eben Aktionen, die für jeden Satz neu hinzukommende Dateien gelten und angewandt werden.
Ich persönlich will nicht noch per Auge die Daten inspizieren. So, wie bei der Eingabe Fehler passieren können, übersehe ich auch mal was.
Von daher würde ich die üblichsten Fehler über einen Satz Bereinigungsaktionen versuchen zu beseitigen.
Und alle anderen Fehler sind Zufallsfunde, für die ich dann eh über Filter überprüfen muss, ob ich sie noch öfter gemacht habe.
Aber da hat jeder seine eigene Vorgehensweise.

LyricsLover · May 1, 2026, 2:17pm

Das ist der Hauptvorteil gegenüber Filtern. Man muss nichts manuell aktivieren oder manuell auswählen, sondern sieht dank der Spalte immer vollautomatisch, ob irgendwo noch ein Zeichen wie das steht. Man kann die Zeichen natürlich auch sprechender gestalten um besser und eindeutiger zu erkennen worum es geht, bzw. was man anwenden soll.

ehrlacher · May 1, 2026, 2:22pm

Genau das mach ich gerade im Wesentlichen:
Beispiel:
Vor einem Jahr habe ich eine Korrekturgruppe geschrieben, die die Sonderzeichen A, B und C filtert (in Wahrheit sind es wie gesagt > 150), vor 10 Monaten habe ich über einen Filter (oder Zufallsfund) Sonderzeichen D und E gefunden und hinzugefügt, vor 6 Monaten Sonderzeichen F und G ... allerdings heißt das, das Sonderzeichen D, E, F und G nur in den Dateien der vergangenen 10 bzw. 6 Monate bereits ausgetauscht sind, in allen Älteren sind sie drin.

Daher dahre ich so ca. 1 Mal im Jahr eine große Bereinigungsaktion und versuche dabei dann auch, so viele "Fehler" wie möglich zu finden, und in Korrektur-/AktionsGruppen aufzunehmen...

ehrlacher · May 1, 2026, 2:23pm

Ja, genau das ist mein Ansatz, durch das zu "lernen" und zu hinterfragen:
Warum steht das da? Kann ich das über ne Aktion künftig abfangen oder muss ich da manuell eingreifen...

ehrlacher · May 1, 2026, 2:32pm

Dann vielleicht ein anderes Beispiel:

Ich habe
Johnny & Mary von Robert Palmer,
Ich & du & dein Hund dazu von Jack White
Toi & moi von Gregoire
Johnny & Mary von Anthony Monn

Bei allen möchte ich das "&" in Sprache übersetzen, weil er auf verschiedenen Samplern und Alben, je nach Label, einmal als "&" und einmal ausgeschrieben steht, so dass ich z.B.

Johnny & Mary
Johnny + Mary
Johnny And Mary

in der Sammlung habe - was aber für die meisten meiner Archivprogramme 3 verschienede Titel sind...

Also vereinheitliche es auf "And", "und", "et" und das kann ich m.E. nur zu Fuß machen - und wie das Beispiel oben zeigt, sollte es dann bei Robert Palmer "Johnny And Mary" werden und bei Anthony Monn "Johnny und Mary".... und da fehlt mir die Fantasie für eine auch nur einigermaßen zuverlässige Formel...

ohrenkino · May 1, 2026, 2:39pm

ich würde ja genau den umgekehrten Weg gehen und das jeweilige, sprachentypische Bindewort durch ein sprachunabhängiges Symbol ersetzen - vielleicht das "&".
Das erleichtert dann auch die Suche in der Sammlung, da man nicht so fremdsprachenkundig sein muss, alle lokalen Varianten des "und" zu kennen.
Für mich wäre also

die beste Version.
Dass bei der Titelfindung oft der Praktikant die Wörter eintippt und es keinerlei EInheitlichkeit gibt, ist dann die Nachlässigkeit der Erzeuger. Aber da habe ich die Freiheiten, die Daten an meine Bedürfnisse anzupassen - es ist nicht mehr ganz das Original, aber sinnentstellend ist die Änderung nicht und auf jeden Fall deutlich leichter zu verwalten.

Ein anderer Dauerbrenner ist das "Featuring", was auch in zig Varianten vorkommt und ggf. in deutschen Titel als "mit" oder "und" ergänzt wird.
Wenn so etwas im Titel steht (und nur da, der Künstler bleibt nur als Hauptname erhalten), dann verwandele ich das in <& Künstler>. Das einleitende Wort ist mir völlig egal. Durch die spitzen Klammern setzt sich die Zeichenfolge dann auch von dem anderen & als "und"-Ersatz ab.