# \[F\] $meta() und \[\] bleibt leer in Konverter\>Tag-Dateiname
**URL:** https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578
**Category:** Fehlermeldungen
**Created:** [January 2, 2017, 7:55am UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578 "2017-01-02T07:55:21Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 2, 2017, 7:55am UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/1 "2017-01-02T07:55:21Z")
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?
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [January 2, 2017, 11:00am UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/2 "2017-01-02T11:00:18Z")
> [@ohrenkino](#):
>
> ... 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
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 2, 2017, 1:29pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/3 "2017-01-02T13:29:25Z")
> [@DetlevD](#):
>
> 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.
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).
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [January 2, 2017, 3:30pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/4 "2017-01-02T15:30:18Z")
> [@ohrenkino](#):
>
> ... [$num(%track%,3)] ... funktioniert und gibt nur dann eine 3-stellige Nummer aus, wenn in TRACK auch was drin steht. ...
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.
> [@ohrenkino](#):
>
> ... Ach ja: ...
> **[**$iflonger($meta(MIXARTIST,1),0,$meta\_sep(MIXARTIST,'; '),) \_ **]**...
> (also mit eckigen Klammern) gibt nichts vom MIXARTIST aus ...
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.
> [@ohrenkino](#):
>
> ... [$if(%MIXARTIST%,$meta\_sep(MIXARTIST,'; '),)]
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
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 2, 2017, 7:38pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/5 "2017-01-02T19:38:19Z")
> [@DetlevD](#):
>
> 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.
$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.
> [@](#):
>
> ...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.
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.
> [@](#):
>
> In diesem Fall sind die eckigen Klammern überflüssig, denn sie tun nichts dazu und ändern auch nichts am Ergebnis des Formatstrings.
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.
> [@](#):
>
> Interessant ist aber, dass der eine Tagfeldinhalt-Platzhalter %MIXARTIST% dafür sorgt, dass die technische Funktion der eckigen Klammern wirksam wird.
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...
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [January 3, 2017, 3:07am UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/6 "2017-01-03T03:07:41Z")
> [@ohrenkino](#):
>
> ... Ich hatte das Beispiel gebracht, um einen über weite Strecken gleichen Ausdruck zu zeigen ...
Damit aber wurde in der Sachfrage mehr Verwirrung erzeugt.
> [@ohrenkino](#):
>
> ... Es erschließt sich mir nicht, warum ich bei den meisten $()-Anweisungen auf den Tagfeldinhalt referenziere, bei $meta() aber auf den Feldnamen...
Was sich nicht erschließt, das muss gelernt werden, weil es eben so implementiert ist.
DD.20170103.0507.CET
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 3, 2017, 12:06pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/7 "2017-01-03T12:06:27Z")
> [@DetlevD](#):
>
> ...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)](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.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [January 16, 2017, 5:52pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/8 "2017-01-16T17:52:42Z")
> [@ohrenkino](#):
>
> ... Trotzdem gibt es in der SW-Entwicklung so etwas wie "Erwartungskonformität" als Qualitätskriterium ...
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
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 16, 2017, 6:07pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/9 "2017-01-16T18:07:57Z")
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)]
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [January 17, 2017, 5:24am UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/10 "2017-01-17T05:24:23Z")
> [@ohrenkino](#):
>
> Vielleicht habe ich ja auch nur einen Knoten im Hirn. ... Das ist für mich unerwartet. ... 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
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 21, 2017, 4:59pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/11 "2017-04-21T16:59:13Z")
Das funktioniert jetzt im aktuellen Development Build [Mp3tag v2.81c](http://developer.mp3tag.de). Danke für eure detaillierte Analyse 🙂
Viele Grüße
– Florian
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 21, 2017, 6:00pm UTC](https://community.mp3tag.de/t/f-meta-und-bleibt-leer-in-konverter-tag-dateiname/18578/12 "2017-04-21T18:00:22Z")
Stimmt. Super. 😃