Danke für die Klarstellungen.
Und schon ergibt sich die nächste Frage: wirkt die Angabe eines Ordners für die Datenbank dann wirklich nur auf genau den Ordner oder auch auf die Unterverzeichnisse?
Bzw.: wenn ich einen, sagen wir mal, "Sammelordner" habe, in dem ich die neuen Dateien sammele und aus dem sie dann nach Abschluss der ersten Bearbeitung verschoben werden, dann sollte der außerhalb des für die Datenbank angegebenen Dateibaums liegen, damit wegen der häufigen Änderungen die Datenbank nicht unnötig anschwillt?
Warum frage ich so skeptisch nach?
Ich habe Lösungen für Audio-Dateien in Form von itunes, foobar, kodi und wmp und Media Center gesehen, Lösungen für Bilddateien z.B. in Form von AcdSee und Adobe Produkten.
Ich verwende das Synctoy um größere Dateibäume (mit hunderttausenden von Dateien) zu synchronisieren - und immer dauert der Abgleich und produziert auch gerne mal größere CPU-Lasten und HDD-Auslastung sowieso.
Und bei allen ist die Bestandsaufnahme immer eine langwierige Angelegenheit, die eigentliche Pflege am Ende meist nur eine kurze Aktion. Aber ohne Pflege hat man binnen kurzem nur noch Datenschrott.
Der Nutzen ist allerdings ebenso unbestreitbar.
Die Anbindung einer Datenbank könnte meiner Ansicht nach noch ganz andere Optionen:
Verschiebung der Daten aus der mp3tag.cfg in die Datenbank und damit vielleicht Umsetzung die oft gewünschte leichtere Bearbeitung der Historienlisten für Filter und Konvertermasken.
Oder die Definitionen für Spalten mit unterschiedlichen Mengen von eingeblendeten Spalten als mehrere Konfigurationsinstanzen in der Datenbank, zwischen denen dann leicht hin- und hergeschaltet werden kann.
Und zu guter Letzt: die Duplikat-Suche. z.B. nach einem Export der Tag-Daten gibt es z.B. in Access ein vorgefertigtes Beispiel für eine (SQL-)Abfrage, die nach Duplikaten in den Access-Daten sucht. Wenn so eine Abfrage auch auf die Daten der MP3tag-Datenbank losgelassen werden könnte ...
Und für so eine Fortentwicklung sind starke Datenbankfunktionen ein solides Fundament.