[F] $meta() und [] bleibt leer in Konverter>Tag-Dateiname

Man nehme eine Datei mit einem multi-value Feld und versuche den Inhalt der Felder per $meta() auszugeben - sofern denn Daten da sind:
%artist% - %title%[ $meta_sep(mixartist,; )]

Der Ausdruck in den eckigen Klammern wird anscheinend nie gefüllt.
Bug oder Feature?

Die "Eckige-Klammer-Funktion" ist so definiert:
[...] Text zwischen eckigen Klammern wird nur ausgegeben, wenn mindestens ein innerhalb der Klammern verwendeter Platzhalter gefunden wurde.

Weil im Beispielausdruck ... [ $meta_sep(mixartist,; )] ...
sichtbar ein Feld-Platzhalter sich nicht befindet, sondern nur ein Feld-Name, ...
so kann auch nichts ausgegeben werden.
Somit ist das Ergebnis per definitionem nachvollziehbar.

Aber wenn so etwas speziell für die Funktion $meta_sep doch möglich gemacht werden könnte, dann wäre das vielleicht sogar ganz brauchbar.

In der Zwischenzeit kann man es so machen ...
(ohne die Funktion der eckigen Klammern):

$if(%MIXARTIST%,$meta_sep(MIXARTIST,'; '),)
... oder so ...
$iflonger($meta(MIXARTIST,1),0,$meta_sep(MIXARTIST,'; '),)

DD.20170102.1327.CET

Nun gut ... das mit dem Feld-Platzhalter ist aber schon gewöhnungsbedürftig, denn
%albumartist% _ %album% _ [$num(%track%,3)] _ %title%
funktioniert und gibt nur dann eine 3-stellige Nummer aus, wenn in TRACK auch was drin steht.
Dass nun ausgerechnet die fehlenden %-Zeichen dafür verantwortlich sein sollen, dass nichts ausgegeben wird, $meta() aber ansonsten einen String produziert und auch das Feld mit Daten gefüllt ist, führt(e) zumindest mich aufs Glatteis.

Ach ja: %albumartist% _ %album% _ [$iflonger($meta(MIXARTIST,1),0,$meta_sep(MIXARTIST,'; '),) _ ]%title%
(also mit eckigen Klammern) gibt nichts vom MIXARTIST aus,
%albumartist% _ %album% _ [$if(%MIXARTIST%,$meta_sep(MIXARTIST,'; '),)] _ %title%
gibt es aus, da hier %MIXARTIST% vorkommt.
Beide Ausdrücke sind übrigens syntaktisch richtig und zeigen keinen Fehler.
Das ist und bleibt für mich spitzfindig (und damit nicht überraschungsfrei und damit ein Bug, auch wenn es mit viel Kenntnis eine Umgehungsmöglichkeit gibt).

Ja so ist es; es funktioniert, wenn %TRACK% als Tagfeldinhalt-Platzhalter bzw. als Inhaltsoperator (content operator) einen Wert liefert, der im Feld TRACK enthalten ist.

Ja, genau erkannt, denn innerhalb der Funktion mit den eckigen Klammern ist kein Tagfeldinhalt-Platzhalter zu sehen, sondern nur Tagfeldnamen, womit wir wieder bei der Anfangssituation sind.
Außerdem ist hier die "Eckige-Klammer-Funktion" falsch angewendet und überflüssig, weil der Formatstring die Sonderfunktion der eckigen Klammern bereits simuliert.
Nur ohne die eckigen Klammern wird die passende Ausgabe erzeugt.

In diesem Fall sind die eckigen Klammern überflüssig, denn sie tun nichts dazu und ändern auch nichts am Ergebnis des Formatstrings.

Interessant ist aber, dass der eine Tagfeldinhalt-Platzhalter %MIXARTIST% dafür sorgt, dass die technische Funktion der eckigen Klammern wirksam wird.

Deshalb funktioniert auch das ...

[$if(%_FILENAME%,$meta_sep(MIXARTIST,'; '),)]

... was dasselbe Ergebnis liefert wie ...
$if(%_FILENAME%,$meta_sep(MIXARTIST,'; '),)
... oder auch ...
$if($not(),$meta_sep(MIXARTIST,'; '),)
... oder vielleicht ganz einfach so ...
$meta_sep(MIXARTIST,'; ')

DD.20170102.1808.CET

$meta_sep() liefert doch auch einen Wert aus den multi-value-Feldern, also ist der Ausdruck eigentlich auch nicht leer, müsste also nach der Logik der eckigen Klammern nun auch als "gefüllt" bewertet werden und damit ebenfalls zur Anzeige führen.

Ich hatte das Beispiel gebracht, um einen über weite Strecken gleichen Ausdruck zu zeigen, dessen einziges Merkmal ist, dass er MIXARTIST und nicht %MIXARTIST% enthält, obwohl ja die Auswertung, ob denn Daten erscheinen oder nicht schon im $if() erledigt wird. Da aber kein %-zeichen im Ausdruck vorkommt, wird die eckige Klammer als "leer" interpretiert.

Und dies war als Beweis für die These mit den %-zeichen gedacht: hier sind %-zeichen enthalten und - Bumsfallera - gibt es auch durch die Auswertung der eckigen Klammern eine Ausgabe, obwohl auch hier die Stringerzeugung durch die $ifgreater()-Anweisung längst abgeschlossen ist.

Ja. Und genau das ist der Stein, über den ich gestolpert bin.
Es erschließt sich mir nicht, warum ich bei den meisten $()-Anweisungen auf den Tagfeldinhalt referenziere, bei $meta() aber auf den Feldnamen...

Damit aber wurde in der Sachfrage mehr Verwirrung erzeugt.

Was sich nicht erschließt, das muss gelernt werden, weil es eben so implementiert ist.

DD.20170103.0507.CET

Natürlich hast du im Prinzip Recht: das kann man (als Ausnahme von der sonstigen Regel) lernen.
Habe ich ja jetzt auch gemacht.

Trotzdem gibt es in der SW-Entwicklung so etwas wie "Erwartungskonformität" als Qualitätskriterium (siehe auch https://de.wikipedia.org/wiki/Erwartungskonformit%C3%A4t)
und spätestens hier sind zumindest meine Erwartungen nicht mit der Implementierung konform gewesen.
Naja, nun haben wir den Fall dokumentiert, ob das Verhalten geändert wird, wird die Zeit zeigen.

Hmm, in einem Datenfeld, welches den Namen FELDNAME hat, referenziert und liefert die Syntax %FELDNAME% immer genau einen Wert - soweit die Erwartung.

Wenn man diese Syntax und Erwartung auf ein Mehrwerte-Feld anwendet, dann dürfte bzw. müsste eigentlich nur der erste eine Wert ausgegeben werden, doch das würde nur Verwirrung stiften, ebenso wie die Ausgabe aller Einzelwerte auf einmal.

Was ist mit den anderen Werten im Mehrwerte-Feld?
Und wie kann man gezielt z. B. nur den zweiten Wert auslesen?
Dafür gibt es die Sonderfunktion: $meta(FELDNAME,Indexposition).

Der normale Inhaltsoperator %FELDNAME% kann das nicht ausgeben.

Man sollte akzeptieren, dass ein Mehrwerte-Feld, welches eine Liste oder Tabelle von Einzelwerten ist, technisch etwas anderes ist als ein Einzelwert-Feld.

Mp3tag bietet für die Behandlung dieser besonderen Mehrwerte-Felder die dazugehörigen besonderen Funktionswerkzeuge an.
Und das funktioniert doch, oder?

DD.20170116.1952.CET

Vielleicht habe ich ja auch nur einen Knoten im Hirn.
Auslöser war ja nicht die $meta()-Funktion an sich, sondern die fehlende Ausgabe bei den eckigen Klammern.
Und hier haben wir schon festgestellt: obwohl die $meta()-Funktion einen Wert zurückliefert, weigert sich MP3tag den Ausdruck in den eckigen Klammern als "gefüllt" zu betrachten. Dieser Auslöser scheint das %-Zeichen zu sein.
(Denn, zugegeben, wenn man eine Textkonstante in die eckigen Klammern schreibt, wird auch nichts ausgegeben).
Festzuhalten: (Beispiel) $meta(artist,2) liefert den Inhalt eines Feldes, adressiert über einen Index zurück.
Das tut ein %artist% auch. Von außen betrachtet ist das Ergebnis sehr vergleichbar: es werden Tag-Felder ausgefracht.
Nur bei [$meta(artist,2)] gibt es keine Ausgabe,
bei [%artist%] gibt es eine.
Das ist für mich unerwartet.

Wir haben uns dann den Ausflug gegönnt, zu fabulieren, ob vielleicht ein $meta(%artist%,2) besser wäre (nein, ist es nicht für die Adressierung) nur theoretisch würde ein $meta(%artist%,2) zu einer Ausgabe führen, da nun das %-Zeichen um die Feldreferenz tanzt.

Ich würde ja sofort Ruhe geben, wenn man mit $meta() in eckigen Klammern genauso eine Ausgabe erzeugen könnte wie mit [$num(%track%,2)]

Du meinst also, dass die drei $meta Funktionen ...
$meta(x), $meta(x,n), $meta_sep(x,sep)
... auch wirken sollen innerhalb der "Eckige Klammern Funktion [...]".

Hmm, das müsste doch machbar sein?
Zur weiteren Vervollständigung der Mp3tag Skriptsprache würde es aber schon dienen.

DD.20170117.0724.CET

Das funktioniert jetzt im aktuellen Development Build Mp3tag v2.81c. Danke für eure detaillierte Analyse :slight_smile:

Viele Grüße
– Florian

Stimmt. Super. :smiley: