Help - Search - Members - Calendar
Full Version: Mp3Tag - Datenbank Anbindung
Mp3tag Forums > Mp3tag - Deutsch > Vorschläge
Sarus
Hi,

ich habe zwar den Tread im englischen Teil des Forums gelesen, da ich nicht mit meinen Englischkenntnissen quälen will...

Ich würde Mp3Tag auch gerne mit einer Datenbank im Hintergrund haben. Sogar so gerne dass ich bereit wäre die nötige DB zu entwickeln.
Deswegen die Frage an euch - würdet ihr mir hierfür eine Schnittstelle schaffen?

Als erster Schritt nur einfach mal Daten mit Mp3Tag synchronisieren.

Besteht Interesse? Konzept als Diskussionsgrundlage wäre vorhanden ;-)

//Sarus
gnor
Du kannst eventuell den umständlichen Weg gehen und über Tools ein Programm einbinden, was diverse Playlisten bereitstellt, die es aus einer eigenen Datenbank entnimmt.
Eine Schnittstelle ist natürlich komfortabler.

Generell finde ich die Idee auch gut.

mfG
gnor
DetlevD
QUOTE (Sarus @ Feb 18 2010, 13:55) *
... würdet ihr mir hierfür eine Schnittstelle schaffen? Als erster Schritt nur einfach mal Daten mit Mp3Tag synchronisieren. ...

So wie ich Mp3tag kenne gibt es bereits eine, beser gesagt, zwei Schnittstellen für den Daten Export (Export Textdatei) und Import (Textdatei - Tag). Wenn man weiß wie man mit diesen Funktionen umzugehen hat, dann kann man eine Vielzahl von Export-Import-Anforderungen damit lösen. Vollständiger 1:1 Export ist noch nicht möglich (z. B. bei Bilddaten und evtl. bei Lyricsdaten sowie evtl. bei Tags (hier gibt es den Weg über die Mp3tag Zwischenablage)).

Was du allerdings mit "synchronisieren" meinst zwischen externer DB und geladenem Track in Mp3tag, das vermag ich mir nicht vorzustellen, das solltest du dann doch genauer beschreiben.

DD.20100218.1713.CET
Sarus
ok ok - ich seh schon werde wohl mehr ins Detail gehen müssen... ;-)

also als ersten Schritt würde ich mir 2 Knöpfe im Frontend vorstellen.
- Der Eine der die komplette eingelesene Liste von Tags in eine Tabelle einer Datenbank schreibt. Zusätzlich sollte jede Datei/Zeile einen eindeutigen Identifier haben (GUID)
- Der Andere der die komplette Liste wieder aus der Datenbank einliest. Der Join der Daten erfolgt über die GUID. Zusätzlich liefert die Datenbank eine weitere Spalte in dieser Tabelle, die Mp3Tag mitteilt, dass diese Zeile/Datei neu geschrieben werden muss (Modify-Flag)

Diese Anpassung sollte ohne größere Anpassungen erfolgen können, so dass die generelle Weiterentwicklung von Mp3Tag nicht behindert wird.
Ich würde daraufhin aus den Daten eine Datenbank mit den ersten Basicfeatures entwickeln und als Diskussionsobjekt übergeben.
Das würde beiden Seiten die Möglichkeit geben zu beurteilen, ob eine weitere Zusammenarbeit sinnvoll ist ;-) und auch ob sich weiterer Aufwand lohnt.

So jetzt mir bitte verzeihen das ich als Newbee ohne Kenntnisse des inneren Aufbaus mich in diesen einmische... ich könnte mir als Weiterentwicklung vorstellen, das die Datenhaltung über ein dll-Plugin erfolgt. D.H. die Datenverwaltung von Mp3Tag ist in eine dll ausgelagert und alle Änderungen an den Daten im Speicher erfolgen über Methoden. Dadurch könnte man einfach weitere Arten der Datenverwaltung einsetzen - eben auch eine Datenbank. Ein weiterer Vorteil wäre hierdurch könnten beliebig verschiedene Datenbankengines (MSSQL, Oracle, MySQL) eingebunden werden. Neue dll schreiben und fertig. Was mir sehr entgegenkommt, da ich MySQL nicht als Datenbank erachte und mir so Diskussionen erspare warum ich diese nicht verwende.
gnor
ZITAT(Sarus @ Feb 19 2010, 13:53) *
... als Newbee ohne Kenntnisse des inneren Aufbaus ...

Das geht zumindest mir ebenso. Der Quelltext ist ja nicht frei verfügbar.

mfG
gnor
DetlevD
QUOTE (Sarus @ Feb 19 2010, 13:53) *
... also als ersten Schritt würde ich mir 2 Knöpfe im Frontend vorstellen.
- Der Eine der die komplette eingelesene Liste von Tags in eine Tabelle einer Datenbank schreibt. Zusätzlich sollte jede Datei/Zeile einen eindeutigen Identifier haben (GUID)
- Der Andere der die komplette Liste wieder aus der Datenbank einliest. Der Join der Daten erfolgt über die GUID. Zusätzlich liefert die Datenbank eine weitere Spalte in dieser Tabelle, die Mp3Tag mitteilt, dass diese Zeile/Datei neu geschrieben werden muss (Modify-Flag)
...

Wie gesagt, das kannst du mit Mp3tag jetzt schon machen, nur irgendwie etwas huddelig. Eigentlich fehlen nur die zwei Knöpfe dafür an einer naheliegenden Stelle im "Frontend", also auf der obersten Ebene im GUI.

Die Aufgabe des/der GUID übernimmt derzeit %_PATH%, das funktioniert auch fehlerfrei, weil Eindeutigkeit gegeben ist. Eine GUID braucht dagegen vergleichsweise weniger Platz, ist aber nur schwer menschenlesbar, und sollte deshalb garnicht zur Ansicht gelangen.

Was macht man mit einer Datei in Mp3tag, die zufällig ihre GUID gerade eben durch Tag ausschneiden oder so verloren hat, oder wenn der Zwischenablageinhalt mitsamt GUID gerade in eine andere Datei eingefügt worden ist?

Eine Frage ist auch, wie das Umbenennen von Dateien zu handhaben wäre, ob in diesem Fall eine neue GUID zu erzeugen ist oder ob die derzeitige GUID für immer und ewig am Track kleben bleibt und wo gespeichert ist.

Ein Modify Flag ist nicht unbedingt nötig, weil durch den Import-/Einlesevorgang definiert ist, dass die derzeit in der Trackliste befindlichen Dateien bearbeitet werden sollen, soweit sie mit den Dateipfadnamen in der Importmenge übereinstimmen.

Eine doppelte Datenhaltung in Mp3tag, also parallel Altbestand und neuer Modify Bestand ist unsinnig und würde bestimmt zu Verständnis und Bedienproblemen führen. Mp3tag ist kein Datenbankverwaltungsprogramm, sondern ein Datenver- oder bearbeitungsprogramm und darauf ausgerichtet, sowohl einzelne Dateien, als auch eine größere Anzahl von einzelnen Dateien jeweils separat zu bearbeiten.

Die Frage ist, ob das bisherige Mp3tag Datenbanksystem, das durch das für alle unterschiedlichen Objekte offene und geeignete hierarchische Ordner/Dateisystem der Festplatte bereits gegeben ist, durch ein angeflanschtes externes Datenbank-Archivsystem an Brauchbarkeit gewinnt oder nicht

Es gibt doch schon genug Katalogsysteme auf dem Markt, warum also noch eins dazu erfinden?

Ich habe vor kurzer Zeit in einem Thread demonstriert wie man eine SQLite Datenbank aus Mp3tag heraus erzeugen kann. Also irgendwie ist doch schon das alles möglich, was du dir vorstellst, vielleicht nicht ganz so offensichtlich oder benutzerfreundlich wie man es lieber hätte.

Du könntest dich damit beschäftigen, einen oder zwei grafische Benutzerdialoge zu entwickeln, die das Zuordnen von Tagfeldnamen für den Export bzw. für den Import durch Ziehen mit der Maus oder Drag und Drop oder andere Mapping Methoden erledigt werden kann (z. B. vergleiche Importdialog von CSV Dateien in Excel).

DD.20100219.2013.CET
Sarus
@DetlevD:
ich seh schon du willst's mir net leicht machen ;-)
Du beschäftigst dich schon zu sehr mit den Details - lass uns doch erst mal versuchen beim groben Überblick vom selben reden.

Aus folgende Punkten würde ich eine Datenbank als vorteilhaft sehen (Endausbau)
- die Verwaltung der Daten im Speicher stößt irgendwann an ihre Grenzen
- das Einlesen bereits bekannter Dateien ist unnötig und langsam
- es gibt Funktionen, die sind mit Aktionen nur schwer und umständlich umzusetzen
- Weiterverwendbarkeit der erfassten Daten als MediaLib
- Schnellere und umfassendere Suchen
- durch die Normalisierung der Daten muss ich Daten nur an einer Stelle ändern
- mehrere Versionen einer Datei (um z.B. später kaputte Dateien ersetzten zu können)
- Archivierung / Snapshots
- die Übernahme neuer Sammlungen kann stark automatisiert werden
- Zusammenarbeit bei der Pflege mehrerer Personen an einer Sammlung

dies ist aber nur möglich wenn eine direkte Kommunikation besteht
=> und das beste, verwendet man die Standard-DLL ist alles wie früher


und nun noch zu den Details (obwohl das ja nur eine Option wäre)
- die GUID ist nötig um die Datei vollständig ändern zu können (auch den Pfad und Dateinamen)
- die GUID wird nur zur Kommunikation zwischen Mp3Tag und DB verwendet und ist für den Endanwender unsichtbar
- die GUID wird für aus dem Filesystem eingelesene Dateinen immer neu vergeben
- Daten die aus der DB gelesen werden besitzen eine GUID (Match mit Filesystem erfolgt über den Path)
- die Daten werden erst auf Anforderung in der DB gespeichert (Medialib)
- d.h. benennst du eine Datei im MediaLib außerhalb Mp3Tag um wird sie schlimmstenfalls als neue Datei erkannt
- ModifyFlag ist nötig, damit Mp3Tag weiß welche Sätze zu bearbeiten sind (auch dieses Flag ist für den User unsichtbar - auch ist es nur für den Bruchteil einer Sekunde gesetzt)
- keine doppelte Datenhaltung geplant (diese ist nur während der Machbarkeitsstudie zur einfachen Einbindung in das bestehende System nötig)
- die Dateien selbst werden grundsätzlich immer im Dateisystem gespeichert.


Deine Frage zur Brauchbarkeit soll ja diese Machbarkeitsstudie (Schritt 1) klären.
Katalogsystem von Wert kosten alle Geld und keine kann mit den umfassenden Funktionen vom Mp3Tag mithalten.

So für alles weitere warte ich jetzt erst mal auf eine Äußerung von Florian - schließlich ist Mp3Tag ja sein Baby.

//Sarus
DetlevD
Oh ... eine Fehlermeldung des Forums:
THE FOLLOWING ERROR(S) WERE FOUND
You have posted more than the allowed number of quoted blocks of text
Das ist eine Nachricht mit Flair aus der EDV-Steinzeit.
Jetzt müsste man nur noch wissen was mehr als erlaubt ist.

Also lasse ich die Teil-Quotes 'mal versuchweise weg und hoffe trotzdem auf Verständlichkeit.
Ich beziehe mich im Folgenden auf ...
QUOTE (Sarus @ Feb 19 2010, 22:26) *
...


... - die Verwaltung der Daten im Speicher stößt irgendwann an ihre Grenzen ...
Von welchen Daten redest du?
Die Daten sind doch in den getaggten Dateien gespeichert.

... - das Einlesen bereits bekannter Dateien ist unnötig und langsam ...
Weil die Welt offen ist, gibt es zu keiner Zeit die Garantie, ob eine Datei nicht durch ein anderes Programm geändert worden ist oder nicht.

... - es gibt Funktionen, die sind mit Aktionen nur schwer und umständlich umzusetzen ...
Von welchen Funktionen redest du?

... - Weiterverwendbarkeit der erfassten Daten als MediaLib ...
Also doch noch ein Katalogsystem, das die Welt nicht braucht.

...- Schnellere und umfassendere Suchen ...
Behauptung und/oder Wunschtraum. Was willst du in deiner Datenbank suchen, was Mp3tag nicht suchen kann, und was soll Mp3tag dann mit dem Ergebnis der Suche in der Datenbank wie anfangen?

...- durch die Normalisierung der Daten muss ich Daten nur an einer Stelle ändern ...
Huh, was wird denn "normalisiert"?

... - mehrere Versionen einer Datei (um z.B. später kaputte Dateien ersetzten zu können) ...
Festplattenplatz kiostet nichts, und hat ja auch jeder genug davon.
Hmm, wann gehen Dateien denn später kaputt?

... - Archivierung / Snapshots ...
Schlagworte ohne Sinn.

...- die Übernahme neuer Sammlungen kann stark automatisiert werden ...
Nicht stärker als jetzt. Und wohin soll etwas woher übernommen werden?
Machen wir doch jetzt schon mit "Kopieren" von einem Dateisystemordner in den anderen.

... - Zusammenarbeit bei der Pflege mehrerer Personen an einer Sammlung ...
Was hat das mit Mp3tag zu tun?

... dies ist aber nur möglich wenn eine direkte Kommunikation besteht => und das beste, verwendet man die Standard-DLL ist alles wie früher ...
Am Besten lässt du alles so wie es ist, dann ist es wie früher.

... und nun noch zu den Details (obwohl das ja nur eine Option wäre)
- die GUID ist nötig um die Datei vollständig ändern zu können (auch den Pfad und Dateinamen)
- die GUID wird nur zur Kommunikation zwischen Mp3Tag und DB verwendet und ist für den Endanwender unsichtbar ...

Wo ist denn die unsichtbare GUID gespeichert?

...
- die GUID wird für aus dem Filesystem eingelesene Dateinen immer neu vergeben
- Daten die aus der DB gelesen werden besitzen eine GUID (Match mit Filesystem erfolgt über den Path) ...

Eine GUID lässt sich nicht matchen mit einem Dateipfad, sondern nur mit einer anderen GUID.
Ein Dateipfad lässt sich nicht matchen mit einer GUID, sondern nur mit einem anderen Dateipfad.

... - die Daten werden erst auf Anforderung in der DB gespeichert (Medialib)
- d.h. benennst du eine Datei im MediaLib außerhalb Mp3Tag um wird sie schlimmstenfalls als neue Datei erkannt ...

Das können dann schon 'mal so auch 10.000 oder mehr Dateien sein.

... - ModifyFlag ist nötig, damit Mp3Tag weiß welche Sätze zu bearbeiten sind (auch dieses Flag ist für den User unsichtbar - auch ist es nur für den Bruchteil einer Sekunde gesetzt) ...
Mp3tag weiß auch so welche Dateien zu bearbeiten sind, nämlich die, die gerade in der aktuellen Ansicht zur Verfügung stehen, und die über den Dateipfad passend zueinander gehören.

... - keine doppelte Datenhaltung geplant (diese ist nur während der Machbarkeitsstudie zur einfachen Einbindung in das bestehende System nötig) ...
Wofür dann eine externe Datenbank???

... - die Dateien selbst werden grundsätzlich immer im Dateisystem gespeichert. ...
Also eigentlich alles so wie gehabt ...
... mit Ausnahme der von dir erwähnten Sicherungskopien, wenn 'mal 'was in deiner Datenbank kaputt geht.

...Deine Frage zur Brauchbarkeit soll ja diese Machbarkeitsstudie (Schritt 1) klären. ...
Ich würde sagen ... mach mal hinne, dann schaun wir mal, ob's zu gebrauchen ist.

... Katalogsystem von Wert kosten alle Geld und keine kann mit den umfassenden Funktionen vom Mp3Tag mithalten. ...
Werden hier nicht Äpfel mit Birnen verglichen?
Der Windows Media Player oder Real Media oder WinAmp oder vielleicht auch iTunes bieten Katalogsysteme, die für die meisten Menschen brauchbar funktionieren.

...So für alles weitere warte ich jetzt erst mal auf eine Äußerung von Florian - schließlich ist Mp3Tag ja sein Baby.
Baby?

DD.20100219.2313.CET
Sarus
@DetlevD:
hat dir schon mal jemand erklärt, dass es die höchste Form von Unhöflichkeit ist während einer Diskussion einen Teilnehmer persönlich anzugreifen. Was du mehrfach getan hast.

Auch bin ich nicht daran interessiert eine Diskussion nur des diskutierens wegen mit dir zu führen - du hast nicht auch nur im geringsten darüber nachgedacht was ich meinen könnte. Du lebst in deiner kleinen Welt und wehe dem der sie verändern will.
Bei all den Dingen die ich geschrieben habe beschäftigst du dich immer nur mit den Details - du hast kein einziges mal versucht zu verstehen was ich vorschlage.

Da es sinnlos ist mit Menschen zu diskutierten, die nur ihre eigene Welt begreifen wollen, werde ich die Kommentare von dir ab sofort ignorieren. Solltest du tatsächlich zuhören wollen können wir es gerne nochmal versuchen.

@Florian: solltest du interessiert sein mein Angebot steht.

@ALL: Sorry für die unnötige Belästigung

//Sarus
DetlevD
QUOTE (Sarus @ Feb 20 2010, 12:13) *
...@DetlevD:
hat dir schon mal jemand erklärt, dass es die höchste Form von Unhöflichkeit ist während einer Diskussion einen Teilnehmer persönlich anzugreifen. Was du mehrfach getan hast. ...

Das habe ich ganz sicher nicht beabsichtigt und auch nicht getan.
Hast du denn schon 'mal was gehört von Kritik- und Konfliktfähigkeit?

QUOTE (Sarus @ Feb 20 2010, 12:13) *
... Auch bin ich nicht daran interessiert eine Diskussion nur des diskutierens wegen mit dir zu führen - du hast nicht auch nur im geringsten darüber nachgedacht was ich meinen könnte. Du lebst in deiner kleinen Welt und wehe dem der sie verändern will.
Bei all den Dingen die ich geschrieben habe beschäftigst du dich immer nur mit den Details - du hast kein einziges mal versucht zu verstehen was ich vorschlage....

Was schlägst du denn vor?
Wie es scheint habe ich deine Botschaft und dein Arbeitsangebot wohl noch nicht richtig verstanden?

Lieber Sarus, wenn du meine Beiträge zu deinem Vorhaben (ist doch dein Baby oder?) richtig liest und versuchst zu verstehen und insbesondere die Kritikpunkte nachvollziehen würdest/könntest, dann hättest du bestimmt eine andere Meinung über meine Mitwirkung erworben als die, die du vorstehend kund getan hast.

Ich habe dich nicht persönlich angegriffen, das liegt mir total fern. Aber ich habe mich intensiv mit deiner Idee beschäftigt, teilweise Satz für Satz.
Nicht eine einzige konkrete detaillierte Antwort habe ich von dir erhalten auf meine diesbezüglichen Fragen.

Du machst es einem wirklich nicht leicht, aus dem von dir bisher vorgetragenen Schlagwortkatalog insgesamt eine Glücksbringerbotschaft aus praktischer und technischer Sicht nachzuvollziehen.

Was willst du konkret Neues hinzufügen oder anders oder besser machen, als das was jetzt in Mp3tag zum Taggen von Musikdateien vorhanden ist?

Wie sieht dein versprochener Mehrwert konkret aus?

Was gewinnt die Mp3tag community durch deine Mitarbeit?

DD.20100220.1557.CET
pueblo funky
Hi,

ich glaube was Sarus meint (nicht nur) - und auch ich gerne möchte - mir bei jedem Start von zB. mp3tag oder auch Tag & Rename, die Daten von den Files einlesen zu müssen zu ersparen.

Vorab möchte ich noch sagen, daß ich mp3tag "nicht" kenne, weil es keine WAV Files unterstützt, ich aber trotzdem ab und zu im Forum nachsehe, ob sich diesbezüglich etwas tut. ;-)

Bei mir sind die Files auf mehrere externe Festplatten verteilt. Ideal ist die Lösung, wie es Serato Scratch Live angeht: Im Root jeder Festplatte liegt ein Verzeichnis (_ScratchLIVE_) mit einer "Datenbank" (mit den "Files" dieser Festplatte) und beim Start von Serato liest es einfach alle externen Datenbanken "zusammen" - und zwar superschnell!

Leider bietet Serato (noch) keinenfalls die Funktionsmöglichkeiten von mp3tag oder Tag & Rename und teilweise ist es auch "buggy" und die Neuseeländer haben ihre eigenen "Ansichten". zB. wird beim "Rescan" nicht erkannt, ob ein Feld entfernt wurde und trotzdem der Inhalt der Datenbank angezeigt. Gut -> dass habe ich eingemeldet und wird frühestens ab Version 2.1 funktionieren.

Weiters unterstützt es leider (noch) nicht ID3v2.4 und auch nicht einmal von ID3v2.3 nicht alle Tags. Abgesehen davon halte ich ID3 als eines der schlimmsten Dateiformate.

Kurzum:
- Eine "Datenbank" pro Festplatte
- Eine "Datenbank" mit einem "gscheitem" DB-Design (dh. mehreren Tabellen).
- Eine künstliche ID (lokal pro Festplatte) kann in ein "privates" ID3 Feld geschrieben werden, um Dateien wieder zu finden bzw. wird eine Festplatte (Files) "importiert", bekommen die neuen Files automatische eine neue ID.
- Import und Export - in die Original-Felder von ID3v2.3/4 UND am besten gleich mit "gscheiten" Feldern in ein "privates" ID3 Feld als eine Art XML oder ähnlich. Der Export in normale ID3 Felder eben nur für externe Programme (Player, DJ-Software - nur zum Anzeigen!).

Ich verwende zB ausschliesslich Tag & Rename zum Schreiben der Tags (und da auch nur bestimmte). Alle Files sind bei mir READ-ONLY (Tag & Rename bietet auch die Option READ-ONLY Files zu ändern - sehr praktisch in diesem Fall) ... weil so "entziehe" ich allen anderen Programmen - wie Serato - die Schreibrechte (ok - ginge auch anders aber machen wirs mal einfach - so kommen nirgendwo Fehlermeldungen). ;-)

Und bevor ich als DJ wo auflege, importiere ich in Serato (notwendigerweise) einfach alle Files noch einmal - also an die 6.000 WAV Files auf einer Platte sind in ein paar Minuten via USB 2.0 eingelesen.

Serato hat im Prinzip den richtigen Ansatz - nur ...

LG
Sarus
hi,

QUOTE (pueblo funky @ Feb 27 2010, 07:01) *
ich glaube was Sarus meint (nicht nur) - und auch ich gerne möchte - mir bei jedem Start von zB. mp3tag oder auch Tag & Rename, die Daten von den Files einlesen zu müssen zu ersparen.

das wäre eine meiner Ideen hierzu. Wäre aber erst als späteres Feature möglich (aufwendig zu integrieren)

QUOTE (pueblo funky @ Feb 27 2010, 07:01) *
Kurzum:
- Eine "Datenbank" pro Festplatte
- Eine "Datenbank" mit einem "gscheitem" DB-Design (dh. mehreren Tabellen).
- Eine künstliche ID (lokal pro Festplatte) kann in ein "privates" ID3 Feld geschrieben werden, um Dateien wieder zu finden bzw. wird eine Festplatte (Files) "importiert", bekommen die neuen Files automatische eine neue ID.

pro Festplatte - interessante Idee. Ich hätte bisher nur einen gemeinsamen Speicherort berücksichtigt. Selbstverständlich mit "gescheitem" :-) DB-Desing und mit eindeutigen IDs, die man sicherheitshalber auch in die Tags schreibt - ja so ungefähr.

QUOTE (pueblo funky @ Feb 27 2010, 07:01) *
- Import und Export - in die Original-Felder...

genau das Hauptproblem, denn ich sehe bisher keine Möglichkeit wie ich geänderte Tags aus der Datenbank 100%tig sicher wieder mit den ursprünglichen Dateien verknüpfen kann.

=> Lösungsvorschläge zu diesem Problem gerne willkommen...

//Sarus
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.