Ich bin verwirrt.
Einerseits erkennst du das Prinzip der Datenbank vollkommen korrekt, andererseits verlangst du der Datenbank etwas ab, was sie so gar nicht leisten kann und dann machst du irgendwo mittendrin einen großen Logikfehler.
Wenn ich dich nicht ganz grundlegend missverstanden habe, kann deine Idee so gar nicht funktionieren.
Gehen wir der Sache mal detailliert auf den Grund.
Du weißt, dass die mAirListDB die Funktion “Ordnerstruktur beibehalten” hat, das schreibst du ja selber. So weit, so schön.
Andererseits aber rippst du deine neuen CDs wild auf einen Haufen und importierst sie in “Unsortiert”.
Bereits hier erkenne ich den ersten logischen Bruch.
Wir finden, man sollte seinen CDs von vornherein auf der Festplatte einen klaren, eindeutigen Platz zuweisen. Über “Ordnerstruktur beibehalten” findet sich in der mAirListDB dann gewissermaßen ein Abbild der Festplattenordnung, was gewisse Suchvorgänge erleichtern kann.
Weiter:
Die Datenbank ist ja nichts anderes als ein Verzeichnis des physischen Speicherortes des jeweiligen Elements. Eine Art Telefonbuch mit Adressverzeichnis.
Du möchtest jetzt, dass mAirList aufgrund deiner Ordnerverschiebung in der mAirListDB zugleich den physischen Speicherort auf der Platte ändert und diesen Eintrag in der Datenbank anpasst. Ein massiver Eingriff mit Folgen - besser nicht.
Warum könnte das scheitern?
Die Ordner in der Datenbank heißen nur deshalb “virtuell”, weil sie real eigentlich gar nicht existieren. Das ermöglicht es, dass ein Element sowohl im Ordner “Deutsch” als auch “Schlager” als auch “1960er Jahre” aufgelistet ist.
Preisfrage: Welcher der drei Ordner ist jetzt der dominante, nach dem sich das physische Verzeichnis ändern soll - und die anderen nicht?
Jeder Start des von dir angedachten Skripts würde alle (!) Ordnerveränderungen, die du im Laufe der Zeit so vorgenommen hast, zu Änderungen auf der Festplatte führen.
Ich möchte eindringlich davor warnen!
Bitte verschiebe deine gerippten CDs zuerst auf der Festplatte an die richtigen Plätze und importiere sie danach in die mAirListDB. Auch wenn du es jetzt vielleicht nicht ganz nachvollziehen magst, aber in ein paar Jahren denkst du an unseren Austausch zurück und wirst mir danken.
Noch so ein Logik-Ding: Was soll damit dann geschehen? Den Titel auch von der Festplatte löschen?
Immerhin: Wenn du einen Titel aus der mAirListDB entfernst, wirst du im Dialog bereits gefragt, ob der Titel nur aus dem Ordner entfernt oder auch physisch gelöscht werden soll. Diese Möglichkeit besteht in der manuellen Bearbeitung also schonmal. Aber automatisiert? Was nicht in der Datenbank drin ist, soll automatisch auch von der Festplatte verschwinden? Gewagt…
Das ist auch so eine Baustelle, die ich am liebsten beseitigt hätte, aber Torben kann oder möchte da - noch! - nicht loslassen, glaube ich.
Die mAirListDB ist nun mal keine ID-Tag-Verwaltung. Es geht sowieso nur mit mp3s, nicht aber mit flac, aac undsoweiter, und auch bei mp3s werden nicht alle Felder zurückgeschrieben. Ich würde also nicht allzu stark auf dieses Pferd setzen.
Nach einiger Überlegung kam ich zu der Überzeugung, wir sollten diesen Zopf “In ID-Tag schreiben” einfach mal komplett abschneiden. Ist aber noch nicht geschehen. Vielleicht kommt es ja mit der v7, wann auch immer sie erscheinen möge. Wie auch immer: Sollte dieses Feature eines Tages weg sein, gebt mir die Schuld.
ID-Tag-Bearbeitung (oder auch Vorbis Comment, siehe flac) gehört in die Hände spezialisierter Programme wie z.B. Mp3tag von Florian Heidenreich. Nicht vom Programmnamen täuschen lassen, das taggt nahezu alles, was nicht bei drei auf dem Baum ist. 
Meine These zur Datenbank, und da sind Torben und ich weitestgehend einer Meinung: Änderungen in und für die Datenbank bleiben auch dort. Alles außerhalb der Datenbank sollte außerhalb erledigt werden und das auch bestenfalls vor der Synchronisation.
Dass man über die Massenbearbeitung Tags neu einlesen kann, bleibt ja bestehen.
