AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Die Vision eines intelligenten Mediaplayers...
Thema durchsuchen
Ansicht
Themen-Optionen

Die Vision eines intelligenten Mediaplayers...

Ein Thema von Mithrandir · begonnen am 10. Okt 2010 · letzter Beitrag vom 4. Feb 2011
Antwort Antwort
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#1

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 12. Okt 2010, 19:23
Hui, da lässt man euch einmal alleine diskutieren...

Ich habe mir Folgendes überlegt:

Die Gewichtung einer Kante hat die Größe eines Byte, ich habe also 256 Werte. Das ermöglicht in meinen Augen eine recht feine Abstimmung.

Gehen wir davon aus, dass der User eine Sammlung von 100 Liedern hat. Meine Idee ist, die Lieder zu Beginn in einzelne Gruppen (nennt es meinetwegen Teilgraphen) zu organisieren. Hier bin ich noch am Überlegen, welche Gemeinsamkeit geschickt wären. Selber Künstler? Gleiches Album? Ähnliche Beats per Minute?

Angenommen, ich habe jetzt eine Vorauswahl treffen können. Ich gruppiere alle Lieder aus demselben BPM-Bereich. Jetzt verknüpfe ich alle Lieder untereinander, die in derselben Gruppe sind. Die Songs werden dabei so verknüpft, dass das Gewicht auf 0 gesetzt wird (Oder -127, wenn man annimmt, dass das Byte vorzeichenbehaftet ist). Es sind also alle Verbindungen gleichberechtigt. Die Richtung spielt keine Rolle. Das ist der Ausgangspunkt für alle Kanten. Zwischen einzelnen BPM-Gruppen wird noch keine Verbindung erstellt. Jetzt könnte man nach Gemeinsamkeiten im BPM-Block gucken. Bspw. Lieder, die denselben Interpreten haben, oder vom selben Album sind. Hier könnte man das Kantengewicht entsprechend erhöhen.

Jetzt kommt der User ins Spiel. Er hört Song A aus dem BPM-Block 100. Als nächstes käme Song B, dieser wird aber bewusst übersprungen, und es wird C ausgewählt. Jetzt müsste das Programm das Gewicht der Kante A-C erhöhen, denn der User empfindet eine gewisse Bindung zwischen A u. C. Umgekehrt sollte die Bindung zwischen A-B verringert werden, denn dies hat der User übersprungen.

Der Graph ist richtungslos, denn ob ich nun A nach C spiele, oder umgekehrt, sollte im Regelfall eigentlich kein Problem sein. Jetzt ist der User aber ein merkwürdiges Wesen, und findet bspw, dass das Lied aus dem BPM-Block 140 gut nach Lied C kommen könnte. Das führt dazu, dass zwischen dem Block 140 BPM und 100 BPM eine Bindung entsteht, welche in Zukunft als Übergang von 100 nach 140 genutzt werden kann. Da der User diese Bindung selbst erstellt hat, bekommt sie eine höhere Wertung als programmatisch erstellte Bindungen.

Ziel ist also, dass der User den größten Einfluss auf das hat, was das Programm an Zusammenhängen ermittelt. Natürlich kann man überlegen, ob man nicht guckt, wie man die Daten des Users nutzen kann. Denkbar wäre auch eine Liste alà "Vielleicht möchten Sie als nächstes XYZ hören?". Darüber könnte man nachdenken.

Auch müsste zu jedem Knoten ein Timestamp gespeichert werden. So könnte man bspw auch Knoten mal wieder hervorholen, bei denen die letzte Wiedergabe schon länger als X her ist. Oder man verringert die Gewichtung nach einem bestimmten Zeitraum, damit man nicht immer nur denselben Kram hört.

Die Größe der Indexdatei ist in meinen Augen schon ein wichtiger Faktor. Ich meine, wir haben mittlerweile Festplatten im 1 - 2 Terabyte Bereich. Lasst aber mal n Programm mehr Platz als 50 Megabyte belegen. Dann wird Sodom und Gomorrha gebrüllt. Insofern ist der Faktor nicht unwesentlich, auch wenn ich zugeben muss, dass 5000 Lieder schon viel sind. Aber eben nicht unwahrscheinlich.

Assarbad, meine Tabellenstruktur war recht einfach:

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);
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 12. Okt 2010, 19:43
Die Platten sind durchaus größer geworden und der Speicherplatz damit quasi vernachlässigter, aber was ist mit dem Zugriff auf diese Daten?

Da ist kleiner halt schneller
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#3

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 12. Okt 2010, 20:10
Man könnte am Anfang der Daten eine Art Index einfügen - was aber wieder mehr Speicherplatz bräuchte.
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#4

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 12. Okt 2010, 21:41
Assarbad, meine Tabellenstruktur war recht einfach:

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.)
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#5

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 13. Okt 2010, 15:14
Und das Datum ist das Dateidatum oder Datum der letzten Aktualisierung des Vertex oder Datum der Erstellung des Vertex?
Die Aktualisierung 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.
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?
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#6

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 14. Okt 2010, 21:22
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...

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...
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#7

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 15. Okt 2010, 22:34
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.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#8

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 16. Okt 2010, 08:51
Ok, ich denke, so langsam hab ich verstanden, was du meinst. 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.
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#9

AW: Die Vision eines intelligenten Mediaplayers...

  Alt 25. Okt 2010, 12:10
Ich habe das Thema der Audioanalyse mal hierhin ausgelagert.
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell

Geändert von Mithrandir (25. Okt 2010 um 21:21 Uhr)
  Mit Zitat antworten Zitat
Alt 25. Okt 2010, 12:12     Erstellt von Mithrandir
Dieser Beitrag wurde von Mithrandir gelöscht.
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:57 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz