Die Vision eines intelligenten Mediaplayers...

[Sir Rufo]

Ja, wie beim Aufbau der Matrix muss man die Ähnlichkeit zu jedem Lied ermitteln und dann in die Koordinaten umrechnen.

Mögliche Auswertungskriterien wären (mal gebrainstormt)
- frequenzspektrum (von n Frequenzbereichen die prozentualen Werte ermitteln)
- Dynamikänderungen (laut-leise Wechsel)
- USW.

[Assarbad]

Zitat von Mithrandir:

Ich hab mal einen kleinen Test gemacht, und ich glaube, ich weiß, warum dieses Feature noch kein Player implementiert hat.

Gehen wir davon aus, dass wir 5000 Lieder auf der Festplatte haben (jahrzehntelange Sammelwut). Baut man für die Initialisierung einen Graphen auf, bei dem jedes Lied mit jedem eine Verknüpfung hat, so kommt man auf die niedliche Datenmenge von insgesamt 25.000.000 Verbindungen. Das bedeutet, dass ich, halte ich diese Menge im Speicher vor, einen Speicherverbrauch von über eine Gigabyte habe. Serialisiere ich meine Liste in eine XML-Datei, ist diese 2,8 Gigabyte groß. Das Hauptproblem ist also weniger die Rechenleistung, sondern eher die riesigen Datenmengen, die anfallen.

Poste mal das aktuelle DB-Schema. Und nebenbei: riesige Datenmengen implizieren meist auch mehr erforderliche Rechenleistung. Man kann das minimieren, aber generell besteht da schon eine Beziehung.

Und laß ab von diesem XML-Fanatismus. XML hat seine Anwendungsbereiche, aber bei der Datenspeicherung sehe ich die absolut nicht. Denn im Gegensatz zu bspw. SQLite ist deine XML-Datei am A.... wenn sich zwischendrin das Programm verabschiedet. Dann validiert die XML nicht mehr weil diverse Tags nicht geschlossen wurden ... naja

Zu den bisherigen Antworten fällt mir auf, daß sie alle den Spaß etwas zu stark vereinfachen. Denn der Abstand für "Genre" mag X betragen, kann aber für "Stimmung" schon wieder Y sein. Bsp.: Oper und Requiem. Und um eine sinnvolle Wertung vorzunehmen muß mehr als ein Merkmal gewichtet werden.

Ergänzung:

Zitat von Sir Rufo:

Ja, wie beim Aufbau der Matrix muss man die Ähnlichkeit zu jedem Lied ermitteln und dann in die Koordinaten umrechnen.

Mögliche Auswertungskriterien wären (mal gebrainstormt)
- frequenzspektrum (von n Frequenzbereichen die prozentualen Werte ermitteln)
- Dynamikänderungen (laut-leise Wechsel)
- USW.

Bin mir nicht sicher, daß Beethovens 9te da so anders abschneiden würde als manch "moderne" Musik. Abgesehen davon wäre das ein schutzwürdiger Aufwand, denn sobald sowas gelöst ist (ich entsinne mich einer Meldung auf Heise über ein Programm welches vorgespielte Lieder in Noten übersetzt), kann man auch eine Musiksuchmaschine bauen bei der der Suchende ins Mikrofon pfeift und dann ähnliche Titel angeboten bekommt die er dann kaufen darf. Und nun ratet mal warum iTunes usw. das noch nicht haben

[mkinzler]

Zitat:

Und nebenbei: riesige Datenmengen implizieren meist auch mehr erforderliche Rechenleistung.

Das sollte für ein gescheites DBMS nicht gelten

@Bug: Eine Aufwandsanalyse ist imho wichtig. Sieht man am Anfang schon ein Problem, welches die Realisierung beeinträchtigen/verhindern könnte, wäre es fahrlässig dieses einfach auszublenden

[BUG]

Zitat von mkinzler:

@Bug: Eine Aufwandsanalyse ist imho wichtig. Sieht man am Anfang schon ein Problem, welches die Realisierung beeinträchtigen/verhindern könnte, wäre es fahrlässig dieses einfach auszublenden

Natürlich ist es wichtig, das man sich im Klarem darüber ist, dass der Index eventuell sehr groß wird.
Allerdings ist es sinnlos, jetzt darüber zu diskutieren ob der Index bei 5000 Liedern bei 20kB, 2MB oder 200 MB liegt.

Man könnte sich zum Beispiel überlegen, dass, wenn man am Anfang alle Lieder mit gleichem BPM verknüpft, man bereits am Anfang sehr viele Kanten hat.
Damit könnte es tatsächlich klug sein, gleich eine Matrix zu nehmen. Allerdings muss man dann in Kauf nehmen, dass bei Hinzufügen eines Liedes der Speicherbedarf quadratisch mit der Anzahl der Knoten steigt.
Wenn die Kanten nach und nach hinzugefügt werden, wäre es dann eventuell besser, eine andere Darstellung zu wählen und das Organisieren der Daten zB. SQLite zu überlassen.

Letztlich gewinnt man bei dieser Überlegung nicht viel, wenn sie am Anfang steht. Wenn die Kantenwerte genau so groß sind wie die Knotenbezeichner (und das wäre dann vermutlich wenig), dann kostet die Speicherung aller möglichen Kanten in einem Graphen als Matrix nur ca. 1/3.
Das ist doch kein so großartiger Faktor, zumal wir noch nicht wissen, wie die Anzahl der Kanten von der Anzahl der Knoten abhängt.

Allein um jedes Lied nach jedem anderem zu anzuspielen (und nach 3 Sekunden weiterzuskippen, ohne Pause) bräuchte man ca. 2,4 Jahre.
Das heißt wenn man die Anzahl der anfänglichen Kanten nicht so hoch setzt, wird sehr lange dauern, bis alle Kanten gesetzt sind.

[Teekeks]

Zitat von BUG:

Allein um jedes Lied nach jedem anderem zu anzuspielen (und nach 3 Sekunden weiterzuskippen, ohne Pause) bräuchte man ca. 2,4 Jahre.
Das heißt wenn man die Anzahl der anfänglichen Kanten nicht so hoch setzt, wird sehr lange dauern, bis alle Kanten gesetzt sind.

OT:
Falsch:
5000 Lieder * 3sekunden= 15000s

15000s/60s=250m
250m/60m=4,17h

Also ein bisschen über 4 Stunden und nicht 2,4 Jahre...

Aber BTT...

[Sir Rufo]

Er meint alle liedkombinationen

[Assarbad]

Zitat von mkinzler:

Das sollte für ein gescheites DBMS nicht gelten

Mir scheint du verwechselst DBMS und Implementation. Selbst das DB-Schema spielt eine sehr wichtige Rolle bei der Effizienz der Datenbank. Im Grunde sollten sich ansonsten DBMS nicht großartig unterscheiden.

Hingegen ein richtig oder falsch gesetzter Index kann deutliche Einbußen der Performance hervorrufen.

Das Schema haben wir bisher allerdings nichtmal auszugsweise gesehen

[Mithrandir]

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);

[Sir Rufo]

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

[Mithrandir]

Man könnte am Anfang der Daten eine Art Index einfügen - was aber wieder mehr Speicherplatz bräuchte.