'Alarm' bei Normalisierungsfehlern

lux · February 11, 2009, 5:27am

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

DetlevD · February 11, 2009, 2:38pm

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

lux · February 12, 2009, 11:12am

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.

ci3nt · February 12, 2009, 2:50pm

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

lux · February 13, 2009, 8:27am

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.

DetlevD · February 13, 2009, 8:55am

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

anon40879270 · February 13, 2009, 5:58pm

... 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?

Moonbase · February 15, 2009, 5:26pm

Meine Variante zur ursprünglichen Frage:

Erst-Bereinigung und Hinzufügen wichtiger Informationen (Ersterscheinungsjahr, Kommentar, etc.): Mp3tag.
Zuordnung und Einbinden weiterer (für mich) wichtiger Informationen, Abspeichern in der endgültigen Ordner-Struktur: MusicBrainz Picard.
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)

anon40879270 · February 15, 2009, 6:21pm

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?

lux · February 16, 2009, 12:50pm

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'.

Moonbase · February 17, 2009, 1:48am

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.)

Recht ordentlich, man kann zudem noch einiges über sog. »Tagger Scripts« beeinflussen. Die geschriebenen Tags sind ordentlich dokumentiert, 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!

DetlevD · July 30, 2009, 8:29pm

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