hatte ich um Rat gebeten, weil sich im Track-Feld die Einzelteile "Tracknummer" und "Gesamtzahl" nicht wie zu erwarten greifen lassen (ist dort beschrieben).
Ist das tatsächlich ein unübliches Verhalten? Oder steckt dahinter eine besondere Programmlogik?
Ich habe mal ein bisschen rumgespielt mit Feldern, die Zahlen enthalten, jeweils mit dem Ausdruck:
1: $regexp(%feldname%,(\d*),$1)
und dann auch noch mit
2: $regexp(%feldname%,\d*,$1)
Da jedesmal das Suchen einer Zahl angegeben ist, zeigt das erste Beispiel, was MP3tag denkt, wie die Zahl aussieht und das zweite zeigt, was übrig bleibt.
Für %releasetime% mit den Inhalt "2016-01-20T04:38:00Z"
bleibt für 1 "2016-01-20T04:38:00Z" übrig und für
2: "--T::Z"
Ein vergleichbares Ergebnis kriegt man für den geänderten Inhalt von YEAR mit 2014/11:
1: 2014/11
2: /
also scheint \d+ nicht beim ersten Nicht-Zahl-Zeichen zu stoppen. Tja ... vielleicht wirklich ein Bug.
Könnt ihr mal schauen, wie sich das ganze ändert, wenn ihr davon ausgeht, dass der reguläre Ausdruck den gesamten String matchen muss?
$regexp(%track%,^(\d+).*,$1)
Hier werden erst alle Zahlen am Anfang des String gematched und in der ersten Gruppe hinterlegt. Danach werden alle anderen beliebigen Zeichen gematched.
$regexp(%track%,.*?(\d+)$,$1)
Hier werden erstmal alle beliebigen Zeichen gematched, allerdings auf "nicht-gierige" (non-greedy) Art und Weise, sodass am Ende die letzte zusammenhängende Gruppe von Zahlen gematched wird.
Ja, die Beispiele funktionieren zwar, sind aber anders als das Verhalten z.B. bei _FILENAME.
Die Lösung aus diesem Thread /t/17095/1
Zum Löschen der führenden Zahl funktioniert weiterhin, ohne den String nach der führenden Zahl extra zu nennen.
So wird mit
$regexp(%_Filename%,\d+,)
aus 003 _ Baggi Begovic _ Good God [Baggi Begovic & Soul Conspiracy Remix].mp3
->
" _ Baggi Begovic _ Good God [Baggi Begovic & Soul Conspiracy Remix]"
wie zuvor und auch für TRACK oder YEAR oder RELEASETIME erwartet.
Oder auch ein Feld wie BPM, das z.B. 128.09 enthalten kann, wird mit
$regexp(%bpm%,.[0-9][0-9]$,)
zu 128, ohne den ganzen String zu matchen.
Beide Ergebnisse sind in Ordnung, wenn bzw. weil $1 nicht definiert ist und leer ist.
Was ich nicht nachvollziehen kann, das ist der Fall, der mit ??? gekennzeichnet ist ...
$regexp('abc 123','(\d)$','$1')-> abc 123 ok kein Treffer$regexp('abc 123','.*(\d)','$1')-> 3 ok Treffer$regexp('abc 123','.*?(\d)$','$1')-> 3 ok Treffer$regexp('abc 123','.*?(\d)','$1')-> 123 ???
Nur war das nicht der ganze Testfall:
Der Test 1 für Releasetime liefert nämlich mit
$regexp(%releasetime%,(\d*),$1)
(hier ist $1 definiert)
mit dem Inhalt "2016-02-04T04:41:00Z"
das Ergebnis "2016-02-04T04:41:00Z"
Erwartet hätte ich "2016", weil dann die Zahl aufhört und ein Minus/Bindestrich kommt.
Ja, das ist zu beobachten - nur ist das auch richtig?
Schließlich lieferte ein _FILENAME mit führender Zahl diese Zahl als Treffer, ebenso wie im Feld BPM ...
Der oben gezeigte Link zum Löschen von Zahlen hat ja mal ohne Angabe des Rest-Strings funktioniert.
Vielleicht kann ja jemand meinen Denkfehler auflösen:
$regexp('003 _ Baggi Begovic _ Good God [Baggi Begovic & Soul Conspiracy Remix]',\d+,$1)
erzeugt ja
" _ Baggi Begovic _ Good God [Baggi Begovic & Soul Conspiracy Remix]"
also ohne die führende Nummer.
Allerdings gibt
$regexp('003 _ Baggi Begovic _ Good God [Baggi Begovic & Soul Conspiracy Remix]',(\d+),$1)
jetzt nicht "003"
sondern den vollständigen String - das deutet darauf hin, dass es für \d+ eigentlich keinen Treffer gegeben hat und deshalb der Ausgangsstring ausgegeben wird.
Nur: warum wird dann im Beispiel ohne gefülltes $1 die führende Zahl weggeschnitten?
Und warum passiert das auch für diesen Ausdruck:
$regexp('003 _ Baggi Begovic _ Good God [Baggi Begovic & Soul Conspiracy Remix]',\d+,)
Irgendwie erkennt der Parser doch die Nummer am Anfang.