Mp3tag als 64 bit version

Bei mir zeigt das Eigenschaftsfenster des Ordners exakt die gleiche Anzahl Dateien an wie MP3Tag in seiner Fortschrittsanzeige.

Hast Du die db3-Datenbank mit einem SQLite-Viewer durchleuchtet oder wie hast Du die DB-Anzahl festgestellt?

Was ich nicht weiß ist was Mp3Tag in seiner Datenbank mit Dupes oder Symlinks macht.
Mp3Tag war nie in der Lage mit Symlinks umzugehen, indem es sie als solche betrachtet sondern sieht immer nur das physische Ziel des Links.

Ich habe hier nicht den direkten Vergleich und habe es auch nicht überprüft, indem ich nacheinander zwischen verschiedene Versionen einen Zeitvergleich gemacht habe.
Mir fällt gefühlt halt kein störendes langsames Verhalten auf.
Der Unterschied wird wohl darin liegen, dass die Informationen nicht mehr komplett im RAM liegen sondern teilweise von der Festplatte kommen.
Ich vermute, dass hier meine SSD, auf der ja meine Datenbank liegt, das Verhalten so entscheidend beschleunigt, dass ich keine störende Verlangsamung feststellen kann.

Es ist wohl generell empfehlenswert, die Datenbank auf einer SSD zu haben.

Gratis-Tool ohne Installation: SQLiteSpy
https://www.yunqa.de/delphi/products/sqlitespy/index

Anzahl Dateien:
Entweder in SQLiteSpy auf die Tabelle mtfile doppelklicken oder
SELECT COUNT(id) FROM mtfile
ins rechte, obere SQL-Kommandofenster copy & pasten und F9 drücken.

@poster: Du hattest Recht mit der Datenbank auf SSD! Danke für den Hinweis!
Wenn ich die "mp3tag.db3" auf eine SSD speichere, dann ist der Wechsel von einer Zeile/Datei zur nächsten wieder gleich schnell wie in früheren Versionen. Anscheinend sind die einzelnen DB-Zugriffe auf einer herkömmlichen HDD deutlich langsamer.

Ich bitte @Florian deshalb, den Datenbank-Speicherort in den Optionen einstellbar zu machen. Z.B. unterhalb vom bereits wählbaren Pfad für Cover-Dateien im Eintrag "Verzeichnisse".

Sicherheitshalber die Frage an @Florian:
Ich nehme an, dass Mp3tag diese DB nicht für jede Datei erst öffnet, dann liest/schreibt und danach wieder schliesst?

In der aktuellen Version v2.85h ist die Datenbank jetzt unter "Optionen > Bibliothek" optional aktivierbar.

Wenn die Bibliothek aktiviert ist werden die Informationen in eine interne Datenbank geschrieben, die im Mp3tag Konfigurationsverzeichnis abgelegt ist. Den Speicherort werde ich nicht konfigurierbar machen. Falls Mp3tag auf einer anderen Festplatte speichern soll, kann es einfach mit der Portablen Installation dort installiert werden.

Beim ersten Einlesen werden die Metadaten aus den Dateien gelesen und in der Bibliothek abgelegt. Beim nächsten Einlesen werden die Metadaten dann aus der Bibliothek gelesen und ggf. aktualisiert, falls sich das Änderungsdatum der Datei verändert hat. Zusätzlich dazu, werden Album-Cover und andere Binärdaten ausschließlich in der Bibliothek gespeichert, was sich positiv auf den Speicherverbrauch auswirken kann.

Zusätzlich kann unter "Optionen > Bibliothek" die Verwendung der Datenbank auf einzelne Verzeichnisse eingeschränkt werden. Metadaten von Dateien die außerhalb dieser Verzeichnisse liegen, werden nicht permanent in der Bibliothek gespeichert.

Viele Grüße
— Florian

Es drängen sich mir noch die folgenden Fragen auf:
Löscht MP3tag die Einträge aus der Datenbank, wenn die Dateien nicht mehr da sind oder wächst und wächst die Datenbank?
Gibt es eine Art Hintergrund-Prozess, der die bestehenden Dateien aus dem zu "überwachenden" Ordner mit dem Inhalt der Datenbank abgleicht? Denn es ist ja durchaus möglich, dass in dem Ordner, der MP3tag genannt wird, Dateien hinzukommen oder entfernt werden.

Dies würde speziell für Sammlungen von z.B. Podcasts gelten, wo in regelmäßigen Abständen einzelne neue Dateien hinzukommen, die dann aber, weil zumindest die öffentlich-rechtlichen Erzeuger es nicht schaffen, eine einheitliche Benennung hinzukriegen, nachbearbeitet werden und in eigenen, anderen Ordnern landen. Nicht alle Schritte müssten unter der Kontrolle von MP3tag ablaufen.

Werden alle Dateien aufgenommen, die jemals mit MP3tag gelesen wurden? Also auch z.B. Bilddateien oder Cue-Files - egal, ob die dann der Tag-Bearbeitung unterliegen?

Kurz und gut: wie kann ich die Datenbank pflegen?

Ich werde sie alle paar Monate mal löschen. Sie wird ja dann wieder komplett neu aufgebaut.

Damit wäre dann der gewonnene Geschwindigkeitsvorteil wieder hinüber.
Oder ich beschränke mich dann doch auf die dynamischsten Verzeichnisse und lasse die Option mit der Datenbank für den Alltagsbetrieb ausgeschaltet.
Ob das allerdings aus Entwicklungssicht die ganzen Mühen mit zusätzlicher (Datenbank-) Schnittstelle (und damit Fehlerquelle) wert ist?

Ich habe 3 Gattungsordner in denen meine Dateien nach etlichen Bearbeitungsstufen landen. Und genau nur die sind in MP3Tag für die Datenbank konfiguriert.
Für die alltägliche Tagarbeit von neuem Material benötige ich keine Datenbank, weil die Anzahl der Dateien so gut wie nie die Zahl von 1000 überschreitet.

Um ab und an die große Sammlung zu bearbeiten und vor allem per Export auszuwerten ist es schon von Vorteil, dass die dann schnell eingelesen wird. Vor allem aber ist die Auslagerung der Cover nützlich, um mehr Platz im RAM zu haben. Und ein erneutes langsames Einlesen hat mich in der Vergangenheit besonders dann genervt, wenn MP3Tag z.B. wegen RAM-Mangels abgestürzt war.

Ab und an kann man wie ich schrieb auch die ganze Datenbank löschen und durch Einlesen frisch neu aufbauen lassen. Dass dafür der PC mal 1 Stunde braucht stört mich nicht wirklich, denn sowas macht man halt in einer ruhigen Stunde beim Kaffeetrinken nebenbei, wenn man ohnehin nicht arbeiten will.

Sie wächst dynamisch, ich plane jedoch eine Funktion zum Bereinigen der Datenbank im Optionen-Dialog einzubauen. Damit können dann bei Bedarf verwaiste Dateien aus der Bibliothek entfernt werden.

Für hinzugekommene Dateien passiert automatisch beim Einlesen des Verzeichnisses. Für außerhalb von Mp3tag entfernte Dateien kommt die Bereinigungsfunktion zum Einsatz.

Noch fehlen die Erfahrungswerte und ich glaube, dass das schon unter Fein-Tuning fällt. Die Verzeichnisse die eine hohe Fluktuation haben, können ja in den Bibliotheksoptionen nicht eingeschlossen werden.

Momentan ja, aber das kann sich noch ändern.

Im Idealfall musst Du sie nicht pflegen. Falls doch, kommt die Bereinigungsfunktion (oder die von poster vorgeschlagene Variante) zum Einsatz.

Viele Grüße
— Florian

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.

Ich habe nach längerer Zeit mal wieder meinen kompletten Datenbestand einlesen müssen und stellte fest, dass dies sehr lange dauerte.

Zuletzt hatte ich hier in diesem Thread über die enormen Geschwindigkeitssteigerungen bei Benutzung des neuen Datenbankfeature berichtet:

Also habe ich nochmals meine Tests wiederholt. Inzwischen ist der getagte Bestand gewachsen und die MP3Tag-Datenbank ist auf 2,653 GB angewachsen (bereinigte Datenbank). Beim letzen Test waren es noch 2,293 GB.

Das Einlesen ohne Datenbank dauerte diesmal ca. 85 Minuten.
Mit bestückter und aktivierter Datenbank dauerte es genauso lange, was mich verblüfft und ratlos zurücklässt, denn beim letzten Test waren es ja nur 5:20 Minuten nach Neustart.

Meine Hardware ist unverändert. Die MP3s liegen nach wie vor auf einer klassischen internen SATA-Festplatte, Windows und das Profil mit dem APPPDATA-Ordner befinden sich auf einer SSD.

Mein Windows 10 ist inzwischen 2 Upgrades weiter: 1809 (Build 17763.168).

Wie sieht es bei anderen aus?
Was könnte diese radikale Veränderung bewirkt haben, denn anscheinend hat die Nutzung der MP3Tag-Datenbank bei mir überhaupt keine Auswirkung?

Ich habe die Tests auch wiederholt, nachdem ich die angelegte Datenbank gelöscht hatte. Es wurde eine neue angelegt - bei der Geschwindigkeit änderte sich nichts.
Veränderungen bei der Einlesegeschwindigkeit treten nur auf, wenn kein Neustart vorgenommen wird, also wohl Cache-Vorgänge Einfluss nehmen.

Das Einlesen ohne Datenbank dauerte diesmal ca. 85 Minuten .
Mit bestückter und aktivierter Datenbank dauerte es genauso lange

Wirklich keiner hier, der das gleiche Problem hat oder nach Test es ausdrücklich nicht hat?

Das Vorhandensein bzw. Aktivieren der Datenbank, das ja so eindrucksvoll das Laden großer Bestände gefördert hat, zeigt inzwischen keine Auswirkungen mehr bei mir. Es dauert ohne Datenbank genauso lang wie mit aktivierter Datenbank. Im Prozessexplorer kann ich jedoch sehen, dass MP3Tag auf die Datenbank zugreift.

Du erwartest jetzt nicht von jedem Forumsleser ein:
Nein, keine Veränderung :wink::innocent:, oder?

Bist Du sicher, dass das Windows-September-Update Dein %appdata% nicht wieder auf die langsame interne SATA verschoben oder geändert hat? Zeigt der Prozessexplorer als Pfadangabe wirklich auf Deine schnelle SSD?

Eine Verlängerung um den Faktor 10 kann ich nicht feststellen.
Vielleicht hilft dann eher eine Liste der möglichen Eigenschaften.
Neue Daten einlesen dauert länger als schon bestehende Daten verwenden. (Ob da neue Daten gelesen werden kann man im Library-Verzeichnis an der Journal-Datei erkennen, die dient als Zwischenspeicher).
Datenbank komplett löschen führt dazu, dass alle Daten neu sind - das dauert am längsten.
Datenbank auf bestimmte Ordner beschränken, dann aber Dateien aus anderen Ordnern lesen ist wie lesen ohne Datenbank.
Datenbank nicht aufgeräumt zu haben - eher eine lässliche Sünde, die zwar Speicherplatz kostet, aber kaum einen spürbaren Einfluss auf die Einlesegeschwindigkeit hat.

Das habe ich mit einem W10 mit M.2-SSD und SATA-HDD geprüft. Die Datenbankdatei ist gut 3,5GB groß, das EInlesen der Tag-Informationen dauert etwas mehr als 5 Minuten.

Dieselbe Sammlung wird auch ab und zu auf einer externen per USB3 angeschlossenen HDD verwaltet. Dort dauert das Einlesen mit Datenbank eine gute Stunde, das EInlesen ohne Datenbank ca. 7 Stunden (cum grano salis).

Also: wenn Daten das erste Mal gelesen werden, gibt es keinen Vorteil, ob die Datenbank verwendet wird oder nicht - nur hinsichtlich der Menge auf einmal zu lesender Daten hat die Datenbank dann die Nase vorn.
Beim wiederholten EInlesen von Daten ist die Datenbank auch für die Geschwindigkeit von Vorteil - die maximale Geschwindigkeit wird etwas unterschritten, wenn einige neue Dateien hinzukommen.

1 Like

Klar doch.
Die SSD als Laufwerk C: ist und war ja schon immer das System-Laufwerk meiner Windows-Installation.
Das verschiebt ein Windows-Upgrade nicht mal eben auf Laufwerk D:, höchstens anders herum.

So waren ungefähr ja auch meine bisherigen Erfahrungen bis ich jetzt auf einmal damit konfrontiert wurde, dass eigentlich auf einmal kein Unterschied mehr besteht, ob ich die Datenbank aktiviert und deaktiviert habe und die Werte liegen in einem Bereich, der für ein MP3Tag ohne Datenbank spricht.

Also woran kanns liegen?
Starten von MP3Tag aus einem anderen Nutzerprofil ändert nichts.
Ein Benchmark von Platte und SSD zeigt Werte im üblichen Rahmen.
Von meinen 16 GB RAM ist auch nichts ausgefallen.
Windows neu installieren möchte ich erst mal nicht angehen.

Das ist aus der Ferne wieder sehr schwer zu beurteilen.
Hast du vielleicht ein Verzeichnis zur Überwachung für die DB festgelegt, liest aber immer die Daten aus einem anderen, so dass kene Einträge in die DB übernommen werden und die Daten immer wieder wie "neu" eingelesen werden müssen?
Ändern andere Programme die Daten in den Dateien?
Wird das Änderungsdatum angefasst, so dass die Dateien für MP3tag "neu" wirken?
Setzen andere Programme Merkmale in den Dateien, wenn sie Dateien abspielen?

Aus der Nähe war es auch nicht so einfach.:wink:

Problem gelöst, das Einlesen klappt wieder innerhalb von 6 Minuten.

Ich habe mal in Richtung Virenscanner überlegt und dann festgestellt, dass sich der Windows Defender in den Vordergrund gespielt hatte. Mein installierter Virenscanner ist von Avast und war mit dem Schutzmodul deaktiviert und der Defender war aktiv.

Das habe ich rückgängig gemacht und MP3Tag sprintet wieder beim Einlesen.

Nachvollziehen kann ich es allerdings nicht wirklich. Der neue Ordnerschutz vom Defender war nicht aktiviert,

2 Likes