Datenübernahme bei Datenbankabfragen sollten flexibler werden

Deutsch / German Vorschläge
1

Hallo Florian,

erstmal möchte ich Danke sagen für Dein Spitzen-Programm. Es gibt keinen besseren Tagger. Ich nutze das Programm schon seit über 10 Jahren. Aber nun zu meinem Vorschlag:

Bei DB-Abfragen habe ich desöfteren das Problem, dass ich nur einen Teil der Daten übernehmen möchte. Deswegen wäre es schön, wenn vor jedem Wert eine Checkbox wäre (deren letzter Status für den nächsten Aufruf gespeichert werden sollte), die ermöglicht, gewisse Werte nicht zu übernehmen.

Außerdem wäre eine Überschrift über den beiden Titellisten sinnvoll, weil sich auf den ersten Blick nicht erschließt, was lokal ist und was aus dem Netz kommt.

Bei den Titellisten fallen mir gleich eine größere Anzahl an Vorschlägen ein, die ich nicht auf dem angehängten Screenshot erwähnt habe:

  1. Checkbox, um die Titelliste überhaupt nicht zu übernehmen.
  2. Checkbox, um nur die Tracknummern nicht zu übernehmen (beim beiliegenden Beispiel handelt es sich um ein 3-CD-Box-Set, bei mir jede CD beginnend bei 1, bei der DB-Abfrage von 1 - 63 durchnumeriert). Das will ich nicht übernehmen.
  3. Eine Checkbox vor jedem Songitel.
  4. Synchronisation der Scrollbalken. Wenn man den Scrollbalken der einen Liste bewegt, bewegen sich beide Listen synchron.
  5. Darstellung, bei welchen Songtiteln Unterschiede bestehen (z. B. grün hinterlegt für identisch, rot für unterschiedlich).
  6. Die Möglichkeit schaffen, die Tags für alle Titel zu übernehmen. Es kommt häufig vor, dass die DB-Abfrage z. B. 12 Titel ergibt, ich aber 13 oder 14 Titel in einem Ordner habe, weil da noch irgendwelche Bonus-Tracks drin liegen (Japan etc.). Bei den letzen Tracks fehlen dann gewisse Angaben, wie z. B. Jahr. Soweit diese Tags im Tag-Panel vorhanden sind, kann die über das DropDown diese zwar recht schnell auf die anderen Tracks übernehmen, aber bei den erweiterten Tags geht das nicht (außer Du baust dort je Tag-Feld ein DropDown ein).

Jetzt noch ein ganz anderer Vorschlag, vielleicht für eine Version 3.0:
Bisher habe ich MP3Tag hauptsächlich genutzt, um einzelne Alben oder ganze Interpreten zu taggen. Dafür ist es einfach nur genial. Aber jetzt habe ich seit kurzem ein NAS und darauf einen UPnP-Server installiert (MinimServer, sehr zu empfehlen). Wenn man dann durch seine Musiksammlung browst, wird einem erst klar, wie viele Tags falsch sind. Z. B. wenn man nach Genre browst sieht man erst, wie viele unterschiedliche Schreibweisen für das gleiche existieren. Die einzige Möglichkeit, diese Fehler, die sich über das ganze Archiv verteilen, zu bereinigen, besteht darin, die ganze Sammlung in MP3Tag einzulesen, was bei meinem Archiv von fast 50.000 Tracks ca. 35 Minuten dauert.

Mein Vorschlag lautet daher - optional zuschaltbar - die Tags in eine DB (z. B. SQL lite) zu schreiben. Die DB würde ich dabei in erster Linie als eine Art Cache betrachten. MP3Tag soll auf jeden Fall so schlank und schnell bleiben, wie es ist.

Viele Grüße

Edit: Ich sehe gerade, die Übernahme des Covers kann man bereits über das Kontextmenü deaktivieren.

Verbesserungsvorschlag_DB_Abfrage.png939×589 105 KB

2

Ich sehe ein Problem mit der Datenbank:
Wenn ich mit einer Datenbank im Hintergrund Dateien in MP3tag lade - sehe ich dann den Inhalt der Tags (das wäre so wie jetzt) oder den der Datenbank? Wie gleicht Mp3tag dann ab, welche Daten die wahren sind? Wenn sowieso jede Datei angefasst werden muss, ist der zusätzliche Vergleich mit der Datenbank eher ein Zeitfresser als ein Zeitsparer, da zum Einlesen der Dateidaten auch noch der Vergleich mit der Datenbank kommt.
Wenn dann sowieso nur die Daten aus den Dateien genommen werden sollen, kann man sich die Datenbank eigentlich sparen.
Ach ja: und wie wird die Datenbank gepflegt, wer entscheidet, welche Dateien neu eingetragen werden und welche gelöscht werden?

Ich glaube, dass für diese Unterhaltungsfunktionen die 35 Minuten nicht mehr ausreichen.
Ach ja: die Funktion, ganze Sammlungen in einer Datenbank abzulegen liefert z.B. iTunes mit. Und es ist möglich, die Einträge aus iTunes in MP3tag zu übertragen per Drag&drop. Damit müsste die Plausibilitätsprüfung eigentlich zu machen sein, ohne dass Mp3tag die gesamte Sammlung lädt, da nur die gezogenen Dateien von Mp3tag geladen werden.

Anhand von iTunes kann man dann auch schön sehen, wie lange es dauert, eine Datenbank auf dem aktuellen Stand zu halten...

3

Tipp:
Zum reinen Begutachten, Filtern und anschließend Auswählen aus einer sehr großen MP3-Sammlung empfiehlt sich die Benutzung des Windows-Explorers.
Der Vorteil ist, dass man nicht erst die Dateien zeitaufwändig einlesen muss und man sie gleich filtern und auswählen kann.
Voraussetzung ist natürlich, dass die entsprechende Ordnerstruktur im Windows-Explorer für Musikdateien optimiert ist (rechte Maustaste -> Eigenschaften -> Anpassen) und der Ordner auch in der Liste der zu indizierenden Ordnern enthalten ist (Systemsteuerung -> Indizierungsoptionen).

Praktisches Beispiel:
Du wählst im Explorer den Oberordner in dessen Unterordnern alle Deine MP3s enthalten sind.
Dann filterst Du im Suchfeld oben rechts alle Dateien, bei denen im Genre-Tag "Heavy Metal" steht, indem Du eingibst:
genre:heavy metal
Die gelisteten Dateien kannst Du dann zur eventuellen Weiterbearbeitung in Mp3Tag markieren und per Kontexmenü an Mp3Tag übergeben.

4

Der Vorschlag mit dem Windows Explorer ist gut, jedoch für mich im Moment unbrauchbar, da ich mich entschlossen habe, auf ID3 2.4 umzusteigen, welches vom Explorer unter Windows 7 nicht unterstützt wird (was an sich schon ein Witz ist, dass Windows 7 von 2009 einen Standard aus 2000 nicht unterstützt). Aber ich behalte das im Hinterkopf, wenn ich auf Windows 10 umsteige. Ich gehe davon aus, Windows 10 unterstützt 2.4.

iTunes habe ich bisher noch nicht genutzt. Kann ich mir mal angucken.

Aber zu der DB-Problematik:
Sollte Florian das wirklich in Erwägung ziehen, muss man sich natürlich noch um die Details Gedanken machen, das habe ich im Eingangsposting bewusst noch nicht gemacht. Ich könnte mir das ganze folgendermaßen vorstellen:

Die ganze DB-Sache ist standardmäßig deaktiviert. Einmal aktiviert, wird der User z. B. darauf hingewiesen, dass, falls er noch andere Tagging-Tools benutzt, diese den Timestamp auch aktualisieren müssen, damit MP3Tag eine Änderung erkennen kann.
Sobald MP3Tag für irgendeinen Ordner aufgerufen wird, werden die Daten in der DB abgelegt, sei es für einen Ordner oder die ganze Struktur. Sollte ein Eintrag bereits vorhanden sein, wird er aktualisiert. Dateien, die in einem Ordner nicht mehr vorhanden sind, werden in der DB gelöscht.

Nehmen wir an, ich habe meine ganze Sammlung bereits in der DB, mache jetzt aber nur einen Ordner in MP3Tag auf, so muss ja nur die Timestamp abgeglichen werden und die DB bei Bedarf aktualisiert.

MP3Tag müsste dann schon einen DB-Browser bekommen, wo z. B. links alle vorkommenden Tags angezeigt werden. Klickt man auf einen Tag, werden rechts sämtliche Files, die diesen Tag haben, angezeigt. Die rechte Seite wäre dann quasi die ganz normale Spaltenansicht, mit dem Unterschied, dass die Daten aus der DB kommen. Dann könnte ich z. B. Sortieren und Filtern, markiere die Files, die ich ändern will, trage im Tag Panel meine Änderung ein (z. B. mache ich aus "rock" "Rock") und dann Strg+S. Im Hintergrund geht MP3Tag in einer Schleife sämtliche markierten Tracks durch und versucht, die Tags zu speichern. Dabei müssen natürlich Prüfungen laufen wie z. B. ob die Datei noch existiert und vor allem, ob der Timestamp der Datei mit dem Timestamp in der DB übereinstimmt. Wenn der nicht übereinstimmt, darf diese Datei nicht aktualisiert werden und es muss eine Fehlermeldung kommen.

Das wäre natürlich keine Funktion für Leute, die in erster Linie andere Tagger als MP3Tag benutzen. Ich (und bestimmt die meisten hier im Forum) benutze ausschließlich MP3Tag, daher wären meine Daten in der DB immer aktuell.

Ich stelle mir das auch gar nicht so aufwändig vor. Im Endeffekt muss nur das, was im Erweiterten Tag-Panel (Alt+T) angezeigt wird, in die DB geschrieben werden. Die DB braucht nur eine Tabelle und jeder Tag wäre eine eigene Spalte. Dann noch ein zweites Panel, was die Spalten untereinander alphabetisch anzeigt. Sobald man dieses Panel anzeigen lässt, wird auf die DB geswitcht.

Auf jeden Fall soll MP3Tag schlank und schnell bleiben, wie es ist. Es soll kein Monster wie iTunes oder MM draus werden.