Die Vision eines intelligenten Mediaplayers...

[Assarbad]

Zitat:

Zitat von Mithrandir (Beitrag 1055403)

Assarbad, meine Tabellenstruktur war recht einfach:

SQL-Code:

CREATE TABLE IF NOT EXISTS edges ( id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, FirstSong INTEGER NOT NULL, LastSong INTEGER NOT NULL, stLikeIndex DOUBLE NOT NULL, stTimestamp DATETIME);

Hmm, also nur eine Tabelle. Und das Datum ist das Dateidatum oder Datum der letzten Aktualisierung des Vertex oder Datum der Erstellung des Vertex?

Ich habe nur zwei Probleme damit: 1.) du reduzierst alles auf eine Dimension (kann gehen, kann aber auch danebengehen) und 2.) bleibt das eigentliche Problem unangetastet. Ich denke du solltest SQL benutzen um die Relationen zu ermitteln, nicht nur um sie zu speichern, wenn du verstehst was ich meine.

Ein Index auf einen numerischen Wert ist lächerlich klein. Laß mich dir ein Beispiel geben, weil ich daran erst letztens gearbeitet habe. Wir haben eine Engine die auf 16 verschiedenen Plattformen läuft. Zu den Plattformen kommt dann noch die "Pseudo-Plattform" "alte Engine" (auf einer beliebigen Architektur/OS). Nun haben wir eine bestimmte vordefinierte Menge an Dateien die gutartig, bösartig, in der Grauzone oder unklassifiziert sind. Zwischen den Engine-Versionen sollen selbstverständlich Fehler behoben werden, aber keine Detections verlorengehen. Also muß man die Ergebnisse unseres Kommandozeilenscanners erstmal herunterbrechen. Das geschieht damit, daß ein Perlskript alle Ergebnisse in Einzelteile (Tokens) zerlegt. Diese Einzelteile werden in eine Datenbank eingepflegt (auch SQLite) in der bereits eine Tabelle mit Dateien und eine mit Verzeichnissen existiert. Jedes Verzeichnis hat einen Namen und eine eindeutige Zahl. Grob gesagt hat jede Datei einen Namen und ein Verzeichnis (referenziert die Zahl in der Verzeichnistabelle) sowie eine eindeutige Zahl. Bei mehreren Hunderttausend Dateien in mehreren Zehntausend Verzeichnissen bringt das eine erste Speicherplatzersparnis. Außerdem gestaltet es den Lookup sehr einfach, denn bis zu dem Zeitpunkt wo ich bspw. den Namen der Datei für einen Benutzer anzeigen muß, kann alles über die eindeutigen Zahlen abgewickelt werden. Diese Entscheidung zieht sich denn auch durch alle Tabellen. Dateien können bspw. Objekte enthalten (bspw. gepackte Dateien) und die Namen dieser Objekte sind dann ebenfalls über eine eindeutige Zahl erreichbar. Wann immer ein Ergebnis eine Datei oder ein Objekt innerhalb der Datei usw. referenziert, wird nur eine Zahl gespeichert. Das ist auch bei riesigen Datenmengen sauschnell. Wenn pro Tabelle dann der Index strategisch gewählt wird, was insbesondere bei Indezes über mehrere Spalten wichtig ist, kann dies eine Abfrage deutlich verschnellern. Der nächste Trick ist alles in SQL zu machen (ich kann dir dabei gern helfen), statt in der einbettenden Programmiersprache.

Damit haben wir im Normalfall 17x17 Vergleiche über (zuletzt) eine Tabelle mit 22 Millionen Ergebniseinträgen. Die gesamte Datenbank inklusive der Strings ist zu diesem Zeitpunkt inklusive mehrere Indezes etwa 1 GiB groß. Wenn man die Textform nimmt, läppert es sich schon zu 18 GiB. Nur damit du die Relationen mal siehst. Ich meine, daß es sooo schlimm bei dir nicht werden kann, selbst wenn es eben mal 100,000 Lieder sind ...

(BTW: Die Vergleiche finden auch gegen sich selbst statt um Logikfehler im Programm zu finden und sie finden in beide Richtungen statt, weil sich zwar die Zahl der Dateien nicht unterscheiden sollte, die Zahl der Ergebnisse durch die gefundenen oder nicht gefundenen Objekte hingegen schon.)

[Mithrandir]

Zitat:

Zitat von Assarbad (Beitrag 1055431)

Und das Datum ist das Dateidatum oder Datum der letzten Aktualisierung des Vertex oder Datum der Erstellung des Vertex?

Die Aktualisierung des Vertex :)

Zitat:

Zitat von Assarbad (Beitrag 1055431)

Ich habe nur zwei Probleme damit: 1.) du reduzierst alles auf eine Dimension (kann gehen, kann aber auch danebengehen) und 2.) bleibt das eigentliche Problem unangetastet. Ich denke du solltest SQL benutzen um die Relationen zu ermitteln, nicht nur um sie zu speichern, wenn du verstehst was ich meine.

Ehrlich gesagt bin ich in Sachen Datenbanken noch nicht so fit. Grundbegriffe wie Indizes, PK, FK, SP sind bekannt. Aber wie würde ich solche Relationen abbilden bzw. SQL zu meinem Zweck nutzen? Wie "programmiere" ich mit SQLite?

[Mithrandir]

Ich habe mich mittlerweile ein bisschen weiter mit der Frage beschäftigt, wie ich möglichst viele Informationen über meine Lieder bekomme. Dabei bin ich auf MARSYAS gestoßen. Was soll ich sagen? Ich bekomms nicht kompilliert... :wall:

Ich bin momentan auch noch am Suchen, ob ich weitere Literatur finde zu dem Thema. Imho siehts aber ein bisschen dürftig aus. Was mich ehrlich gesagt ein wenig wundert... :gruebel:

[Assarbad]

Zitat:

Zitat von Mithrandir (Beitrag 1055604)

Ehrlich gesagt bin ich in Sachen Datenbanken noch nicht so fit. Grundbegriffe wie Indizes, PK, FK, SP sind bekannt. Aber wie würde ich solche Relationen abbilden bzw. SQL zu meinem Zweck nutzen? Wie "programmiere" ich mit SQLite?

Also in Sachen SQL kann ich absolut das Buch "The Definitive Guide to SQLite" von Mike Owens empfehlen. Ich hatte schon vorher genügend mit MySQL und auch teils mit PostgreSQL zu tun, aber detailliert verstanden habe ich die Zusammenhänge hinter SQL erst nach der Lektüre dieses Buches. Übrigens ist die Besprechung von SQL im Buch nicht auf SQLite beschränkt sondern es geht mehr um das Grundlagenwissen. Und mit Grundlagenwissen will ich keinesfalls kleinreden wie detailliert die Beschreibung ist - vielmehr wird dort auch auf die mathematischen Grundlagen hinter dem was heute SQL ist eingegangen. Es handelt sich in diesem Sinne also nicht um eine bloße Einführung in das Thema.

"Using SQLite" (erschienen bei O'Reilly, und ich habe es auch noch nicht durchgelesen sondern "drübergeblättert") scheint mehr auf die Anwendung von SQLite fokussiert zu sein - gerade wie der Titel es suggeriert ;)

Okay, nun zu dem was ich meinte. Die Frage ist, ob dies mit einer machinenerstellbaren Metrik (BPM, Metatag auslesen) funktionieren könnte. Meines Erachtens nach werden subjektive Daten des Benutzers wie "Stimmung" eher von Relevanz sein, was dann durch ein Zusammenführen auf einem Server zu ungleich besseren Ergebnissen führen würde. Aber: statt eindimensional einen Vertex abzuspeichern (übrigens macht m.M.n. allein die Eindimensionalität ein späteres Ausbalancieren oder andere Modifikationen am Gesamtgraphen schwer bis unmöglich) stellen wir uns einmal vor wie es aussähe, würden wir "Queen" in Einheiten von "Pink Floyd" abbilden (diese Beziehung wäre automatisch gegenseitig). Ähnlich würde Chopin in Mozarts abgebildet oder Beethoven in Vivaldis. Wenn man einen nicht-NULL-Wert hat, gibt es sozusagen einen Vertex der zwei Titel von "Queen" und "Pink Floyd" verbinden könnte. Eine clevere Datenbank wird entgegen der Aussagen einiger Vorredner eben nicht alle Daten allozieren. Selbst bei Dateisystemen sind "sparse files" seit Jahren Usus. Entsprechend würden nur jene Beziehungen Platz beanspruchen die existieren (plus ein wenig Overhead). Jede Tabelle wäre dabei nur die ID des Liedes und der eigentliche Wert für den Parameter.

Beim Sammeln der Daten könnte man dann die Mastertabelle nach dem Namen aller Tabellen befragen die eine Beziehung zwischen Künstlern abbilden. Ein entsprechendes Schema könnte auch für Melodien und "Stimmung" angewendet werden, wobei man gewisse Parameter (melancholisch vs. lustig usw.) vordefinieren müßte. Zuerst müßte man dann vom aktuellen Lied einige Kennwerte ermitteln (inklusive derer die der Benutzer angibt). Daraufhin kann man dann Lieder ermitteln deren Kennwerte sich gleichen. Zuerst indem man überhaupt Lieder ermittelt die den gleichen oder mindestens x Kennwerte mit dem aktuellen Lied teilt und dann weiter eingrenzend solche innerhalb eines (vermutlich konfigurierbaren) Bereichs.

Zusammenfassend:

die Namen der Tabellen müssen nicht zwangsläufig in deinem Programm vordefiniert sein. Es gibt Metatabellen in SQLite die es erlauben sowas dynamisch zu ermitteln. Habe ich schon gemacht und funktioniert wunderbar. Und solcherlei Dinge kann man ad infinitum schachteln um die Effizienz von SQLite bei dem Verarbeiten der Daten (mithilfe von SQL) zu nutzen anstatt Beziehungen die in SQL leicht und gut darstellbar sind in der Hostsprache nachzumodellieren.

[Mithrandir]

Ok, ich denke, so langsam hab ich verstanden, was du meinst. :gruebel: Das Buch werde ich mir definitiv noch ansehen.

Momentan bin ich dabei, mich ein wenig mit Audioanalyse auseinander zu setzen. Das Thema ist hochkomplex (ach!), aber prinzipiell ist alles lösbar. Es soll auch kein perfektes System werden, den Anspruch habe ich nicht. Je mehr man aber über das Thema liest, umso mehr ist man beeindruckt von dem, was unser Gehirn leistet. ;)

[Mithrandir]

Ich habe das Thema der Audioanalyse mal hierhin ausgelagert.

[DIET3RIX]

Die Idee habe ich schon seit Jahren. Leider habe ich keine Zeit diese in die Tat umzusetzen....

Wäre das nichts für dich?
http://www.mufin.com/de/software/mufinplayer

[Mithrandir]

Ich hab mir das Ding angesehen. Eine Speicherauslastung von fast 300 MB nach einer Stunde hören und die Tatsache, dass offensichtlich nicht rekursiv indiziert werden kann, sprechen dagegen. Außerdem merkt sich das Programm nicht, in welcher Reihenfolge ich meine Songs höre. Desweiteren passt das grad, weil ich mich in C# und WPF einarbeiten muss. :mrgreen:

[DIET3RIX]

Ich hatte den Player auch mal installiert gehabt, aber irgendwie hat der mich in keinster Weise überzeugt. Langsam ist der dazu auch noch.

Ich hätte dann auch mal 'ne Frage an dich.
Nehmen wir mal an, dass die Musiksammlung in der Datenbank gelagert wird. Zudem wirst du mit Sicherheit eine weitere Tabelle anlegen, in der die Playlisten (o.ä.) gespeichert werden (Die Abspielreihenfolge).

Wie willst du die beiden Tabellen referenzieren?
Du könntest das mit einer ID machen, aber was ist wenn sich die IDs ändern (durch neues einlesen, DB Crash, Änderung der Verzeichnisstruktur [wodurch neu eingelesen werden muss], usw.)? Dadurch werden deine Playlisten unbrauchbar.

Oder verstehe ich dein Projekt nicht richtig?

(Eigtl. habe ich auch vor, mich in C# einzuarbeiten...)

[Mithrandir]

Über das Datenbanklayout habe ich mir momentan noch keine weiteren Gedanken gemacht, da ich mich gerade mit der Audioanalyse beschäftige. ;)

Es gibt einige Dinge, die man abfangen kann, andere nicht, stimmt. Die Abspielreihenfolge wird über die IDs der Songs gelöst, alles andere wäre ineffektiv. Die Frage ist allerdings, welche ID man nimmt. Man könnte bspw. nicht die ID des Datenbankeintrages nehmen (die ja uniqe sein sollte), sondern sich eine ID aus Titel,Künstler generieren. Damit wäre man auch vor einem erneuten einlesen sicher. Die Frage ist: Ist der Aufwand gerechtfertigt? Das sind Dinge, über die ich mir noch Gedanken machen muss. Aber ein sehr guter Punkt. :thumb:

Mal ne Gegenfrage: Was genau hat dir an Mufin nicht gefallen?