Die Vision eines intelligenten Mediaplayers...

[omata]

Habt ihr eigentlich schon mal darüber nachgedacht was ihr das so schreibt?

Bei einem neuronalen Netz ist eine Lernphase nötig. Wann soll diese durchgeführt werden?
Bei einem Backpropagationnetz wird kontrolliertes Lernen angewendet. Ein Kohonennetz lernt zwar selbst aber wie wollt ihr das dann interpretieren?

Was sollen die Eingangs- und was die Ausgangssynapsen sein?

Siehe auch mein Backpropagation-Netz.

Ein Kohonennetz habe ich auch mal realisiert, aber hier nicht veröffentlicht.

Also Graphen mit gerichteten Kanten ist wohl die bessere Variante.

[Hisoka]

Zitat von omata:

Habt ihr eigentlich schon mal darüber nachgedacht was ihr das so schreibt?

Bei einem neuronalen Netz ist eine Lernphase nötig. Wann soll diese durchgeführt werden?
Bei einem Backpropagationnetz wird kontrolliertes Lernen angewendet. Ein Kohonennetz lernt zwar selbst aber wie wollt ihr das dann interpretieren?

Was sollen die Eingangs- und was die Ausgangssynapsen sein?

Siehe auch mein Backpropagation-Netz.

Ein Kohonennetz habe ich auch mal realisiert, aber hier nicht veröffentlicht.

Also Graphen mit gerichteten Kanten ist wohl die bessere Variante.

Daher fällt das ganze ja auch unter die Kategorie "Interessante Idee ohne Plan". Also die Idee ein NN für sowas zu nutzen ist ja recht interessant, nur wie man sowas umsetzt ist etwas anderes.

An sich ist ein Problem ja der Anfang. Man hat keine Vergleichsdaten. Also man muss dem Netz erstmal beibringen was zu einander passt( "Like button", "ähnlich button",...) und mit den Ergebnissen könnte man dann ein Netz füttern und dann auf unbekannte Lieder los lassen. Ob das Ganze aber zufriedenstellend funktioniert ist eine andere Sache. Dazu kommen ja noch Sachen wie das zu viel lernen(auswendig lernen), dadurch kann das Ergebnis vielleicht für eine kurze Zeit sehr gut sein aber dann wenn man neue Musik erwirbt kann es total versagen.

Aus der Praxis heraus würde ich daher doch eher einen fertigen Dienst wie Last.fm einbinden. Aber das wäre dann weniger interessant.

[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.

Freiwillige bitte zuerst melden, die hier einen Lösungsvorschlag hätten.

[Teekeks]

Den Baum nicht im Speicher halten sondern nur dann das passende (aus der DB) laden wenn es gebraucht wird.

[Mithrandir]

Es geht mir auch mehr um die Gesamtdatenmenge. Versuch mal, dem User zu erklären, dass er für seine 5000 Lieder eine Indexdatei mit 3 GB braucht.

Ich teste das gerade mit SQLite durch... Sollte ja mindestens um den Faktor 10 kleiner werden, wenn ich richtig gerechnet habe. Das ginge ja noch... Ggf. könnte man auch sehen, dass man von vornherein nur die Wahrscheinlichsten Verknüpfungen zulässt, und das Programm dann später eigenständig neue Verknüpfungen hinzufügt...

[jfheins]

Du kannst einen Graphen (fast immer) auch als Matrix darstellen.

In diesem Beispiel also eine 5000x5000 Matrix (wenn jedes Element ein Byte hat, ist das nicht mal allzu groß) und ein Wert stellt dann dar "wie doll" die beiden Lieder (Zeile/Spalte) zusammenhängen. Also z.B. -128 = gar nicht 0=neutral, 127 = quasi identisch
Da diese Zuordnung symmetrsich ist, brauchst du auch nur die Hälfte der Einträge. Wären also 12,5 Megabyte

Und wenn du dann das nächste Lied spielen sollst, gehst du einfach alle Lieder durch, ermittelst die "Ähnlichkeitskomponente" und (nur als Beispiel) nimmst diese als Wahrscheinlichkeit und wählst zufällig eins aus. (Ähnliche Lieder werden wahrscheinlicher ausgewählt als fremde)

[Medium]

Da hatter wahr . Find's immer schmerzhaft zu sehen, wenn diese XML/DB-Euphorie so simple schlanke Dinge vom Platz der "ersten Einfälle" verdrängt

[Medium]

Nimm statt XML ein ordentliches, natives Format . Geht man von sortierten Daten aus, brauchst nu nichtmal mehr Strukturinformationen, und kannst die Bindungsstärken einfach so der Reihe nach auf die Platte streamen. Drückt man die einfach mal in Bytes aus, erscheinen 25MB schon garnicht mehr so fies. Koppel das mit einem einigermaßen sinnvollen read-ahead Algo, und du musst das auch nicht am Stück im Speicher halten.

[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