Das Thema "Unicode" ist ziemlich komplex, das ich hier aber kurz anreißen muss, um ein Feature von Nemp zu erläutern. Die Grundproblem ist in diesem Bild schön zusammengefasst.

In den ID3-Tags stehen letztendlich viele, viele Bytes. Das sind Zahlen zwischen 0 und 255. Wenn in einer Datei ein Text steht, dann werden diese Zahlenwerte als Buchstaben interpretiert und entsprechend angezeigt. Bei den "normalen" Buchstaben A-Z und a-z gibt es in der Regel keine Probleme. Bei deutschen Umlauten geht es schon los. Und wenn man dann das Alphabet wechselt, z.B. ins kyrillische, griechische oder hebräische, wird es langsam schwierig.

Alle Zeichen, die es gibt, erhalten über Unicode eine eigene, eindeutige Nummer. Die meisten davon haben (offensichtlich) eine Nummer jenseits der 255. Wenn in ein Byte aber nur maximal der Wert 255 passt, dann muss man sich etwas mehr überlegen, wie man diese Zeichen korrekt codiert.

Die sinnvollste Methode dafür sind die Codierungen UTF-8 oder UTF-16. Damit lassen sich praktisch alle Zeichen codieren. Wenn ein Programm aber kein UTF-8 versteht, erhält man Effekte wie in dem Bild.

Eine andere Methode sind die ISO-8859-Normen. Dabei einigt man sich auf einen bestimmten Bereich des Unicode-Zahlenraumes und interpretiert dann die Werte zwischen 0-255 entsprechend anders. Je nach Interpretation wird dann ein kyrillischer Buchstabe angezeigt, ein griechischer, hebräischer, thailändischer, oder sonst was. Das funktioniert aber nur, wenn man Dateien nur mit Leuten austauscht, die sich auf die gleiche ISO-8859-Norm geeinigt haben.

Zeichenkodierung in ID3v1-Tags

Und jetzt kommen wir zurück zu den ID3-Tags. In dem sehr einfach aufgebauten ID3v1-Tag ist keine Information über die verwendete Zeichenkodierung vorgesehen. Das kann dazu führen, dass Informationen nicht korrekt ausgelesen werden können. Weit verbreitet sind meiner Erfahrung nach die verschiedenen ISO-8859-Normen, und in letzter Zeit auch vermehrt UTF-8. Nemp kann versuchen, die verwendete Zeichenkodierung in ID3v1-Tags zu bestimmen. Das funktioniert manchmal, vielleicht auch oft, aber sicherlich nicht immer. 

Zunächst versucht Nemp, die Informationen als UTF-8 zu interpretieren. Wenn das nicht funktioniert, wird eine Vermutung aufgrund des Dateinamens vorgenommen. Wenn der Dateiname viele kyrillische oder griechische Zeichen enthält, dann dürften die Metadaten auch diese Zeichen enthalten. Nemp wählt dann eine der ISO-8859-Normen aus, die für den jeweiligen Zeichenbereich gültig sind.

Zeichenkodierung in anderen Formaten

Andere Metadaten-Formate (inklusive ID3v2-Tags) haben dieses Problem nicht. Hier ist in der Regel UTF-8 oder UTF-16 vorgeschrieben, oder die verwendete Kodierung kann (oder muss) explizit in den Metadaten mit angegeben werden.