1.
$num(,4) ergibt die Zeichenkette '0000'
$num(,3) ergibt die Zeichenkette '000'
$num(,2) ergibt die Zeichenkette '00'
$num(,1) ergibt die Zeichenkette '0'

$num(,0) ergibt die Zeichenkette '0'
$num(,-1) ergibt die Zeichenkette '0'
$num(,) ergibt die Zeichenkette '0'

Die Ergebnisse der drei zuletzt genannten Ausdrücke sind meiner Meinung nach falsch.


2.
Richtig wäre es, wenn ...

$num(,0) ergibt die Zeichenkette <leer>
$num(,-1) ergibt die Zeichenkette <leer>
$num(,) ergibt die Zeichenkette <leer>

und zwar ebenso wie:
$num() ergibt die leere Zeichenkette <leer>.

(Weil die Mp3tag Skriptsprache die schriftliche Darstellung der leeren Zeichenkette nicht kennt, habe ich "<leer>" geschrieben.)

Weiterhin gilt:
$num(123,0) ergibt die Zeichenkette '123'. (Weil der zweite Parameter gleich null ist, ist das Padding ausgeschaltet.)
$num(123,1) ergibt die Zeichenkette '123'. (Weil der zweite Parameter gleich eins ist und die Zahl mehr als eine Ziffer hat.)
$num(123,2) ergibt die Zeichenkette '123'. (Weil der zweite Parameter gleich zwei ist und die Zahl mehr als zwei Ziffern hat.)
$num(123,3) ergibt die Zeichenkette '123'. (Weil der zweite Parameter gleich drei ist und die Zahl drei Ziffern hat.)
$num(123,4) ergibt die Zeichenkette '0123'. (Weil der zweite Parameter größer ist als die Anzahl der Ziffern der Zahl.)
usw.

$num(123,-1) ergibt die Zeichenkette '123'. (Negative Werte für den zweiten Parameter können zwar eingegeben werden, werden aber als Wert Null gewertet.)


3.
Warum erscheint die Funktion $num(x,y) inkonsistent?

Die Funktion ist im Mp3tag Manual so beschrieben:
"Pad decimal number with leading zeros."
Was so viel bedeutet wie "Auspolstern einer dezimalen Zahl mit führenden Nullen".

Wie man oben im Beispiel sieht ist als erster Parameter nicht nur eine "dezimale Zahl" erlaubt (die aber eine "ganze Zahl" ist), sondern sogar ein leerer Wert (eine leere Zeichenkette).

Dass als erster Parameter nicht nur eine Zahl, sondern auch eine Zeichenkette erlaubt ist, das zeigt das folgende Beispiel:
Das Tagfeld TRACK enthält die Zeichenkette "8/15".
Der Ausdruck "$num(%TRACK%,2)" erzeugt die Zeichenkette "08".

Die Funktion $num(x,y) wertet jede Zeichenstelle des ersten Parameters von links gesehen aus. Sobald ein Zeichen entdeckt wird, das keine Ziffer ist, wird die Auswertung beendet und die bis dahin entdeckte Ziffernfolge ausgegeben, dabei entsprechend dem Wert des zweiten Parameters links mit führenden Nullen ausgepolstert.

Warum eine leere Zeichenkette, die nicht ausgepolstert werden soll, z. B. "$num(,0)", trotzdem das Ergebnis "0" ergibt, das ist nicht logisch und ich meine sogar, das ist auch nicht sinnvoll.

Auch darf "$num('A',0)" nicht "0" sein, weil es sonst dasselbe wäre wie "$num(0,0)".
Der Buchstabe 'A' ist nicht dasselbe wie die Zahl 0.


4.
Weiterhin tritt besondere Verwirrung bei der Verwendung des Filters auf:

Weil der Ausdruck ...
$num($left(%_FILENAME%,1),1)
... immer das Ergebnis "0" liefert, kann nicht unterschieden werden, ob das übergebene Zeichen eine Ziffer oder ein Buchstabe ist.
Der Ausdruck liefert für alle Inhalte von _FILENAME dasselbe Ergebnis "0".

Dadurch wird der Filterausdruck ...
$num(%_FILENAME%,1) IS 0
... sinnlos, weil der Filter die Unterscheidung zwischen den Dateinamen, die mit einer Ziffer oder einem Buchstaben beginnen, nicht treffen kann.

Ebenso ist der Filterausdruck ...
$num(%_FILENAME%,0) IS ""
... nicht zu gebrauchen, weil $num() in der vorliegenden Version niemals eine leere Zeichenkette liefert.


DD.20100411.1124.CEST
Edit.20101209.0922.CET

4. Beim Filter musst du wenn links vom Operator % oder $ verwendet wird alles in " Zeichen setzen:
z.B.
"$num(%_FILENAME%,1)" IS 0

Somit kann ich deine Beobachtungen beim teilweise Filter auch nicht bestätigen:
"$num(%_FILENAME%,1)" IS 0
zeigt nur Dateien die mit einem Buchstaben oder Null beginnen.

Ja ja ... das Thema mit der Syntax beim Filter und wann werden wo doppelte Anführungszeichen gesetzt, das habe ich ja schon einmal angesprochen.
Die Systematik beim Filter ist mir noch nicht so geläufig.
Es ist an vielen Stellen in Mp3tag so leicht, Fehler zu machen, auch beim Filter.

Wie du bestätigt hast oder doch nicht bestätigt hast (???) ...

"$num(%_FILENAME%,1)" IS 0

... reagiert dieser Filterausdruck auf jedes nicht numerische Zeichen genauso wie auf die Ziffer Null, und das ist eben ein falsches Verhalten, wie man es von einer $num(x,y) Funktion normalerweise nicht erwarten würde.

DD.20100411.1542.CEST

Ich finde die Diskussion hier nicht sonderlich zielführend. Die Funktion interpretiert den ersten Parameter als Dezimalzahl und diese Interpretation bzgl. der leeren Zeichenkette ergibt in Mp3tag eben 0 - und bei 08/15 eben 8.

Mir ist auch nicht ganz klar, warum der Fall in dem als zweiter Parameter 0 verwendet wird als so wichtig und beachtenswert angenommen wird. Gerade bei einer Funktion die laut Beschreibung die übergebene Dezimalzahl mit der angegebenen Anzahl an Nullen auffüllt, erschließt mich genau dieser Anwendungsfall nicht direkt (-1 ist in dem Kontext noch besser).

Also, alles in allem eine ausführliche Analyse des Verhaltens von $num wenn semantisch nicht sinnvolle Werte übergeben werden, aber auf jeden Fall kein Bug in Mp3tag.