# 'Alarm' bei Normalisierungsfehlern
**URL:** https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910
**Category:** Vorschläge
**Created:** [February 11, 2009, 5:27am UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910 "2009-02-11T05:27:04Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@lux](https://community.mp3tag.de/u/lux)
#### Post date: [February 11, 2009, 5:27am UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/1 "2009-02-11T05:27:04Z")
Ok, der Titel ist vielleicht nicht besonders aussagekräftig, aber ich versuch mal meinen Vorschlag zu beschreiben.
Vorweg: Ich liebe dieses Programm, ich kann gar nicht sagen, viele 1000 Stunden Tipparbeit mir in den letzten Jahren dadurch erspart wurden.
Also, ich brüte grad mal wieder über einer größeren Liste (ca. 2000) un- bzw falsch getaggter Songs. Zum Glück sind die Dateinamen halbwegs brauchbar, sodass ich den Dateinamen -\> Tag Konverter verwenden kann. Natürlich ist das nicht perfekt, denn jede kleine Abweichnung von Dateinamensmuster bringt die Konverter durcheinander. Besonders häufig tritt das auf, wenn das Zeichen, das eigentlich den Separator darstellt (meistens das '-' Zeichen) z. B. auch Teil des Interpreten ist, also z. B.
A-Teens - Track# - Titel
Das hat denn zur Folge, dass ein Teil das Interpreten in das nächste Feld geschrieben wird. So kommt es häufig vor, dass das Interpretenfeld nur mit einem Buchstaben gefüllt wird, und der Rest dann z. B. in der Tracknummer landet.
Das ist soweit auch ok und kann man sicher nicht so leicht ändern, allerdings könnte ich eine Funktion gut gebrauchen, womit man solche Fehler beim Durchschauen leichter ausmachen könnte.
Ich hab mal überlegt und mir sind da zwei Ansätze in den Sinn gekommen:
a) Man kann für die verschiedenen Felder bestimmte Bedingungen festlegen, die erfüllt werden sollen, wenn das nicht der Fall ist, wird die entsprechende Zeile farblich hervorgehoben. Also, man legt z. B. fest, das die Tracknummer keine Buchstenben enthalten darf, wenn doch, gibts nen 'Alarm'.
🕶 Man baut die Funktion in den Filter mit ein. Bei den Scriptbefehlen gibts ja schon so Dinge wie $len(x) oder isdigit(x). Wenn man solche Ausdrücke auch im Filter verwendet könnte, könnte man evtl. Tag-Fehler schnell lokalisieren.
mfg
LUX
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 11, 2009, 2:38pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/2 "2009-02-11T14:38:17Z")
Spontan sehe ich in deinem Beispiel kein Problem!
**A-Teens - Track# - Titel**
lässt sich mit Formatstring
**%artist% - %track%# - %title%**
fehlerfrei zerlegen.
"A-Teens - Track# - Titel.mp3" -\>
artist: A-Teens
track: Track
title: Titel
Wenn dich die Bindestriche bei folgenden Schritten irritieren, dann könntest du im ersten Schritt die Zeichensequenzen ' - ' durch ein spezielles Zeichen ersetzen z. B. '~' (mit $replace oder $regexp), und später dann wieder umändern, wenn nötig.
DD.20090211.1637.CET
---
### Author:  [@lux](https://community.mp3tag.de/u/lux)
#### Post date: [February 12, 2009, 11:12am UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/3 "2009-02-12T11:12:28Z")
Jo, wenn alle Dateinamen EXAKT nach dem selben Muster aufgebaut sind gibt es natürlich keine Probleme, aber schon bei kleinen Abweichungen, wie z.B. 'A - Teens' statt 'A-Teens' paßt das Erkennungsmuster nicht mehr. Um bei dem Beispiel zu bleiben:
%artist% - %track%# - %title%
"A-Teens - Track# - Titel.mp3" -\>
artist: A-Teens
track: Track
title: Titel -\> KORREKT
"A - Teens - Track# - Titel.mp3" -\>
artist: A
track: Teens
title: 01 - Titel -\> FALSCH
Das mit den Zeichenersetzen werd ich mal ausprobieren, aber steh ich da nicht wieder vor dem Problem, dass das Programm entscheiden muß, welcher der Bindestriche denn nun tatsächlich einen Seperator darstellt und welcher eigentlich Teil eines Feldes werden soll? Aus den o.g. Beispiel könnte man ja noch eine ganze Reihe weiterer Variationen bilden, also
"A-Teens-Track#-Titel.mp3"
"A - Teens-Track#-Titel.mp3"
usw...
Evtl. könnte man das alles mit regulären Ausdrücken berücksichtigen, aber regex sind für mich bisher schwarze Magie 🙂
Deshalb wäre für mich so eine Filterfunktion sehr interessant, mit der man einfach verdächtige Zeilen aufspüren könnte. Denn bei aller Automation muß/sollte man das Ergebnis i.d.R. ohnehin noch einmal manuell überprüfen.
---
### Author:  [@ci3nt](https://community.mp3tag.de/u/ci3nt)
#### Post date: [February 12, 2009, 2:50pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/4 "2009-02-12T14:50:43Z")
Hallo,
mir fallen jetzt zwei Möglichkeiten ein, du kannst entweder A - Teens immer durch A-Teens ersetzen lassen, was ja dann auch richtig ist oder zu deinem Filter:
Suche doch einfach nach Bindestrichen im Track oder Titel, weil er beim Formatstring "%artist%-%track%-%title% ja den vierten Bindestrich in den Titel schreibt.
mfG
gnor
---
### Author:  [@lux](https://community.mp3tag.de/u/lux)
#### Post date: [February 13, 2009, 8:27am UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/5 "2009-02-13T08:27:01Z")
Danke für die ganzen Hinweise.
Bei den Songs dir ich vor mir hatte (bin jetzt fertig) handelte es sich um eine Sampler-Reihe, also viele verschiedenen Interpreten in allen möglichen Kombinationen was den Bindestrich beim Interpreten angeht. Da ja meistens via freedb getaggt wird, kommt es halt immer darauf an, wie es dort gespeichert ist.
Das A-Teens-Beispiel war da vielleicht etwas zu einfach gewählt, es gibt natürlich noch viele andere Interpreten mit Strich, also H - Blocks, N-Sync, aber auch Künstler-Combos wie 'A-Interpret feat B - Interpret' etc...
Bei der nächsten größeren Liste werd ich es mal mit der Vorbereitung via Ersetzen ausprobieren, aber vielleicht kann der Entwickler ja doch mal über die Filterfunktion nachdenken. Ist nicht überlebenswichtig, das Programm leistet auch so sehr gute Dienste, könnte aber ich manchen Situationen recht hilfreich sein.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [February 13, 2009, 8:55am UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/6 "2009-02-13T08:55:59Z")
> [@lux](#):
>
> ...
> %artist% - %track%# - %title%
> ...
> "A - Teens - Track# - Titel.mp3" -\>
> artist: A
> track: Teens
> title: 01 - Titel -\> FALSCH
Bei "A - Teens - 01 - Titel.mp3"
kannst du z. B. den Formatstring verwenden:
%artist% - %artist% - %track% - %title%
Ergebnis:
artist: A Teens
track: 01
title: Titel
Musst du nur schauen wie du den Bindestrich bei artist wieder hineinbringst.
DD.20090213.1055.CET
---
### Author:  [@anon40879270](https://community.mp3tag.de/u/anon40879270)
#### Post date: [February 13, 2009, 5:58pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/7 "2009-02-13T17:58:24Z")
> [@lux](#):
>
> ich brüte grad mal wieder über einer größeren Liste
... und suche nach der Möglichkeit einer 'Syntax-Prüfung' zwischen zwei Feldern.
Feststellung: Das Erscheinungsjahr der Tracks eines Albums ist das Erscheinungsjahr des Albums.
Anders ausgedrückt: Die Tracks eines Albums haben alle das gleiche Erscheinungsjahr.
Wie kann ich diesen Zusammenhang zwischen %year% und %album% automatisch auf Richtigkeit überprüfen?
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [February 15, 2009, 5:26pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/8 "2009-02-15T17:26:11Z")
Meine Variante zur ursprünglichen Frage:
1. Erst-Bereinigung und Hinzufügen wichtiger Informationen (Ersterscheinungsjahr, Kommentar, etc.): Mp3tag.
2. Zuordnung und Einbinden weiterer (für mich) wichtiger Informationen, Abspeichern in der endgültigen Ordner-Struktur: [MusicBrainz Picard](http://musicbrainz.org/doc/PicardDownload).
3. Nacharbeit: Mp3tag.
Damit gibt es nie wieder Unklarheiten über die Schreibweise eines Interpreten, die Albenzuordnung ist eindeutig, Titel-Schreibweise definiert usw. 😃 (Und ganz nebenher löst es mbaa3s Problem gleich mit.)
Hin und wieder muss man natürlich ein (selteneres) Album zuerst selbst bei MusicBrainz in der Datenbank anlegen, aber das kommt ja _allen_ zugute. Zudem ist es meiner Meinung nach die derzeit bestgepflegte Datenbank weltweit, weil von _Menschen_ gehandhabt (und ausdiskutiert!). Selbst mit EAC benutze ich nicht mehr _freedb_ oder _Gracenote_, sondern ausschließlich die MusicBrainz cddb-Schnittstelle. (Link: [http://freedb.musicbrainz.org/~cddb/cddb.cgi](http://freedb.musicbrainz.org/~cddb/cddb.cgi))
---
### Author:  [@anon40879270](https://community.mp3tag.de/u/anon40879270)
#### Post date: [February 15, 2009, 6:21pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/9 "2009-02-15T18:21:01Z")
> [@Moonbase](#):
>
> 😃 (Und ganz nebenher löst es mbaa3s Problem gleich mit.)
Wie das???
Ich gehe davon aus, das folgendes gemeint war: Die Tracks eines Albums haben untereinander alle das gleiche Erscheinungsjahr. Wie läßt sich diese Zusammenhang zwischen %year% und %album% automatisch auf Richtigkeit überprüfen?
---
### Author:  [@lux](https://community.mp3tag.de/u/lux)
#### Post date: [February 16, 2009, 12:50pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/10 "2009-02-16T12:50:51Z")
Wie 'sauber' geht dieser MB-Tagger denn mit den ID-Tags um?
Ich hab bis vor einigen Jahren immer mal wieder verschiedenen Tag-Programme (Helium, Tag&Rename, Godfather, div. Medienplayer) auf meine Sammlung losgelassen und dabei feststellen müsssen, dass diese dabei häufig Dateien 'vermurksen' (Header defekt etc.) oder aber in Tag-Felder schreiben, die der Standard nicht vorsieht oder sonst kein anderes Programm verwendet. Einige dieser Auswirkungen merkt ich selbst heute noch ab und zu. Deshalb benutzt jetzt nur noch einen Tagger, eben MP3Tag, das hat mir bisher noch keinen Dateien 'verhauen'.
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [February 17, 2009, 1:48am UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/11 "2009-02-17T01:48:23Z")
> [@mbaa3](#):
>
> Wie das???
Einfach, indem Picard ja das Erscheinungsjahr in das YEAR-Tag schreibt, damit also nie »Unrichtigkeiten« auftauchen _können_ 😉 (Natürlich keine Lösung für _schon existente_ Daten, klar.)
> [@lux](#):
>
> Wie 'sauber' geht dieser MB-Tagger denn mit den ID-Tags um?
Recht ordentlich, man kann zudem noch einiges über sog. »Tagger Scripts« beeinflussen. Die geschriebenen Tags sind ordentlich [dokumentiert](http://wiki.musicbrainz.org/PicardTagMapping?highlight=(tag)|(mapping)), bisher bei über 25.000 Files (MP3, FLAC, OGG, WMA) null Fehler, keine »Verwurstelungen« entdeckt bei ID3v2.3/ISO-8859-1, ID3v2.3/UTF-16, ID3v2.4/UTF-8. Bestehende und unbekannte Tags werden belassen, außer natürlich denen, die er überschreiben _muss_. (Und selbst die kann man abschalten.)
Einzige Unschönheit (die ich sogar vor Zeiten mal angeregt habe _hüstel_): Picard schreibt den Interpreten-Sortiernamen in ID3v2.3 als »XSOP« (eXperimental Sort Order Performer), da »TSOP« erst ab ID3v2.4 definiert ist. Und _dieses_ Tag Frame will Florian partout nicht unterstützen, daher ist es in Mp3tag nicht zu sehen 😉 Also müsste man entweder Lukáš überreden, TSOP auch in ID3v2.3 zu schreiben, oder Florian, XSOP zu unterstützen…
Aber für »richtig gutes Taggen« ist natürlich Mp3tag _zusätzlich_ sehr hilfreich – erst _zusammen_ werden die beiden ein unschlagbares Team! 🙂
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [July 30, 2009, 8:29pm UTC](https://community.mp3tag.de/t/alarm-bei-normalisierungsfehlern/7910/12 "2009-07-30T20:29:46Z")
> [@lux](#):
>
> Jo, wenn alle Dateinamen EXAKT nach dem selben Muster aufgebaut sind gibt es natürlich keine Probleme, aber schon bei kleinen Abweichungen, wie z.B. 'A - Teens' statt 'A-Teens' paßt das Erkennungsmuster nicht mehr. Um bei dem Beispiel zu bleiben: ...
> "A - Teens - Track# - Titel.mp3" -\>
> artist: A
> track: Teens
> title: 01 - Titel -\> FALSCH ...
Ich habe nochmal darüber nachgedacht ...
Wenn das 'grobe Muster' im Dateinamen immer gleich ist, also z. B. 'ARTIST - TITLE - TRACK' und nur im ersten Bereich ARTIST zusätzliche Bindestriche eingestreut sind, dann kann es helfen, den Standort zu wechseln, also den Dateinamen von der anderen Seite aus zu betrachten, also den Dateinamen umzudrehen, und dann den Dateiname-Tag Konverter wie gewohnt anzuwenden.
Das Umdrehen muss nach der Zerlegung in jedem erzeugten Tagfeld wieder rückgängig gemacht werden, das versteht sich von selbst.
Bild 1:
Bild 2:
Bild 3:
Ich habe den Vorgang in einer Aktionengruppe zusammengefasst (d. h. was man mit den Konverterdialogen manuell machen kann nun als Aktionen formuliert).
Der Dateiname selbst wird dabei nicht geändert.
Anfang Aktionengruppe **lux\_reverse**
Aktion #1
_Aktionstyp 7:_ **Tagfelder importieren**
_Quellformat:_ **$reverse(%\_FILENAME%)**
_Formatstring:_ **%TITLE%÷-÷%TRACK%÷-÷%ARTIST%**
Aktion #2
_Aktionstyp 5:_ **Tagfeld formatieren**
_Feld:_ **TITLE**
_Formatstring:_ **$reverse(%TITLE%)**
Aktion #3
_Aktionstyp 5:_ **Tagfeld formatieren**
_Feld:_ **TRACK**
_Formatstring:_ **$reverse(%TRACK%)**
Aktion #4
_Aktionstyp 5:_ **Tagfeld formatieren**
_Feld:_ **ARTIST**
_Formatstring:_ **$reverse(%ARTIST%)**
_Hinweis: Ein Sonderzeichen ÷ durch ein Leerzeichen ersetzen._
Ende Aktionengruppe **lux\_reverse** (6 Aktionen)
DD.20090731.0030.CEST
Edit. Aktionengruppe auf das Nötigste reduziert.
DD.20090731.1555.CEST
