Diskussion:SoundFont

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 3 Jahren von 2003:D4:7F18:6F37:8D53:A306:2071:1C0 in Abschnitt Wavetable Synthese
Zur Navigation springen Zur Suche springen

Wavetable Synthese[Quelltext bearbeiten]

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

hier steht ja shcon wieder dieser unsinn mit der "wavetable synthese" und der "soundblaster" karte, wie er auch unter "wavetablesynthese", "wavetable" und in diversen anderen deutschen artikeln zu finden ist. was soll das immer? soundfont ist ein beschreibungsformat für _sampler_ programme und hat von daher weder mit "synthese" noch mit "wavetables" irgendetwas zu tun. und das format wurde auch nicht von emu und ensoniq sondern von emu und creative labs entwickelt; letztere halten bis heute die namesrechte daran. -bubu, 2020/02 (nicht signierter Beitrag von 2003:D4:7F18:6F37:8D53:A306:2071:1C0 (Diskussion) 23:09, 16. Feb. 2021 (CET))Beantworten

DLS Level 1 von Roland?[Quelltext bearbeiten]

Letzter Kommentar: vor 13 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

Woher kommt eigentlich die Information, daß Roland an der Entwicklung von DLS beteiligt war? Ich habe mich bemüht Quellen zu finden, aber ich habe keine Quellen gefunden, die das belegen. (Ich weiß 18:28, 25. Mär. 2007 (CEST))Beantworten

Stimmt auch gar nicht. Ich bin eben (nur knapp vier Jahre später) über die entsprechende Seite bei der Interactive Audio Special Interest Group gestolpert. Dort steht:
Downloadable Sounds Working Group (DLSWG)
This group delivered a proposal to the MMA for Downloadable Sounds Level 1 in the fall of 1996. The MMA membership ratified a revised proposal in January 1997 and released the specification to the public later that year. Working with DLSWG members, the MMA has continued development of DLS and released a DLS Level 2 specification in 1999.
...muss ich mal bei Gelegenheit im DLS-Artikel ergänzen...
Ich habe daher den fraglichen Satz, der fälschlicherweise den Verweis auf Roland enthielt, entfernt. --Ich weiß 02:53, 13. Feb. 2011 (CET)Beantworten

Einladen des Soundfonts/ RAM Bedarf[Quelltext bearbeiten]

Letzter Kommentar: vor 13 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt

Die Treiber der Soundblaster Audigy und X-FI laden das Soundfont je nach Einstellung nicht komplett ein. Es gibt einmal die Option, das Soundfont dynamisch einzuladen oder statisch. Bei Dynamisch wird das Soundfont nur komplett eingeladen, wenn es im Soundfontbank- Manager hinzugefuegt wird. An Sonsten wird nur bei Bedarf eingeladen. Einzelnde Samples, die bei Abspielen benoetigt werden und noch nicht im RAM liegen, ebenfalls. Nicht benoetigter RAM wird dann wieder freigegeben. (Das Nachladen kann beim Abspielen dann fuer kleine Aussetzer sorgen, dafuer wird nicht staendig der fuer Soundfonts zugewiesene RAM genutzt) Wird das Soundfont statisch eingeladen, wird das Soundfont komplett im RAM gehalten. Je nach Treiberversion laedt er das gesamte Soundfont ein, sobvald der Rechner bootet oder wenn eine Anwendung MIDI-Daten abspielen laesst. Wenn geladen, verbleibt das Soundfont vollstaendig im RAM. (Es kann durchaus sein, das es wieder entladen wird, wenn laengere Zeit nicht benoetigt, das weiss ich jedoch nicht) Bei der statischen Methode treten keine Nachladeaussetzer auf.

Die Reservierung des RAMs fuer Soundfonts ist eigentlich keine. Man legt nur den maximal meoglichen Speicherbereich fest. Das heist nicht, das Dieser auch frei sein muss. Hier ist nur wichtig das man mindestens so viel frei gibt, wie das Soundfont vollstaendig geladen an Platz benoetigt. Anders waere es auch schlecht zu loesen, da der MIDI-Synth/ Treiber der Audigy oder X-FI nicht hellsehen kann, was da jetzt an Samples benoetigt wird. Das klappt nur wenn der MIDI-Player auch den Synth enthaelt. Bei "Dynamisch" wird ein Mittelweg genommen. Deswegen ist dieser Satz hier falsch "Dadurch, dass die Sound Blaster-Treiber anders vorgehen und versuchen, den gesamten SoundFont in den Arbeitsspeicher zu laden, ist klar, dass die Größe des zu ladenden SoundFonts nicht den freien Arbeitsspeicher im Rechner überschreiten darf." Die Reservierung von RAM richtet sich nur nach dem physikalisch vorhandenem RAM. Steht nicht genuegend RAM zur Verfuegung wird Windows Swappen.87.139.55.127 10:39, 7. Feb. 2011 (CET)Beantworten

Ich würde mal gerne wissen, wo Du diese Informationen herhast (aus der Hilfe-Datei entnommen?). Die stimmen nämlich schlichtweg nicht. Du kannst mit einem Speicher- und mit einem Diskmonitor zweifelsfrei selbst feststellen, dass die Caching-Strategie überhaupt keinen Einfluss auf das Treiberverhalten hat (die Option im SoundFont-Bank Manager ist daher seit jeher Veräppelei am Kunden). Die SoundFont-Treiber von Creative Labs verwenden in jedem Fall "Memory-Mapping" als Methode, um den SoundFont zu laden, d.h. der SoundFont wird grundsätzlich komplett in den Speicher geladen. Solche Caching-Strategien, wie Du sie beschreibst, gibt es in hochwertigen Software-Samplern, nicht aber in den Treibern von Creative Labs (leider). Durch das Memory-Mapping überläßt der Creative-Treiber die Speicherverwaltung komplett dem Betriebssystem.
Es gibt allerdings Programme, die ein dynamisches Caching-Verhalten tatsächlich nachrüsten (z.B. MegaFont). --Ich weiß 13:33, 7. Feb. 2011 (CET)Beantworten
Ich weiss es weil ich das Teil benutze. Klickst du "Dynamisch" an laedt er nicht das komplette Soundfont nach dem Booten des PCs, auch wenn du eine Anwendung mit MIDI-Unterstuetzung startest. Ich spiele des Oefteren Descent 1 und da ist das beschriebene Verhalten nachzuvollziehen. (Die ersten paar Minuten laedt er bei "Dynamisch" sehr oft nach) Wenn du den Soundfontbank-Manager benutzt, laedt er das Soundfont kommplett ein. Ebenfalls ist es bei normaler MIDI-Wiedergabe nachzuvollziehen. Bei "Statisch" zieht er beim Abspielen einer MIDI-Datei das Soundfont komplett in den RAM, danach gibts, solange dir der RAM ausgeht, keine Nachladeaussetzer. Die erweiterten Strategieen, das nur benoetigte Samples eingeladen werden, koennen die Treiber gar nicht bewerkstelligen. Wunschtraum! Wie gesagt: Die Treiber koennen nicht hellsehen. Ein Software-Sampler mit integriertem Player weiss im Vorraus, welche Samples benoetigt werden.80.153.6.48 17:36, 7. Feb. 2011 (CET)Beantworten
OK, wir haben irgendwie mehrere Themengebiete gestreift, und deswegen teilweise aneinander vorbeigeredet. Ich habe auch noch mal ein paar Experimente mit sehr großen SoundFonts (1,2GB und 1,6GB, damit ich Ladepausen auf jeden Fall mitbekomme) gemacht, Monitor-Programme zur Hand genommen, und bin erst einmal zu Folgendem gekommen:
  1. Egal, ob statisches oder dynamisches Caching, der SoundFont wird, wenn er geladen wird, immer komplett in den Speicher geladen. Teilweises Laden gibt es nicht.
  2. Wenn man den SoundFont Bank Manager benutzt, dann wird der SoundFont unabhängig von der Caching-Methode immer sofort komplett in den Speicher geladen.
  3. Der Unterschied zwischen dynamischem und statischem Caching besteht lediglich darin, dass bei einem Neustart der SoundFont bei dynamischem Caching erst dann geladen wird, wenn ein Programm erstmals auf einen der beiden SoundFont-Synthesizer zugreift. Aber auch dann wird der SoundFont komplett geladen. D.h. es ist kein dynamisches Laden auf Preset-Ebene, sondern lediglich ein verzögertes Laden der ganzen Bank ab Erstbenutzung.
  4. Sowohl bei statischem als auch bei dynamischem Caching bietet der Treiber von Creative Labs keinerlei eigene Logik oder gar Intelligenz. In beiden Fällen wird das Betriebssystem per Memory-Mapping beauftragt, die SoundFont-Datei als Speicherbereich zur Verfügung zu stellen. Das hat zur Folge, dass bei beiden Caching-Methoden
  1. die Beschränkungen von Windows greifen
  2. damit auch die Unterschiede zwischen 32-Bit und 64-Bit Windows zutage treten
  3. die bekannten Registry-Tricks funktionieren, die in die Speicherverwaltung von Windows eingreifen
Im Prinzip kann ich also Deine sämtlichen Beschreibungen bestätigen, bis auf einen Punkt: Du schreibst, dass beim Spielen von Descent in den ersten paar Minuten sehr oft nachgeladen wird. Das kann ich nicht nachvollziehen. Es müßte beim erstmaligen Zugriff auf das Synthesizer-Gerät einmalig die ganze Bank nachgeladen werden. Ich würde daher behaupten, dass, wenn bei Dir tatsächlich mehrere Aussetzer über mehrere Minuten auftreten, diese dann nicht nur auf das Laden des SoundFonts zurückzuführen sind. Können wir das irgendwie mit einem geeigneten Experiment zeigen oder ausschließen? Ich habe leider Descent für Windows nicht zur Hand. Könntest Du bitte kurz beschreiben, wie Dein System ausgestattet ist (CPU, Speicherausbau, Windows-Version, Creative Labs Karte, Treiberversion, Name und Größe des SoundFonts)?
Du gehst auf einen bestimmten Satz aus dem Artikel ein, von dem Du behauptest, dass er falsch sei. Das kann ich so nicht nachvollziehen. Die Reservierung von Arbeitspeicher richtet sich nicht nach dem physikalischen Speicher, sondern es muss tatsächlich genügend freier Arbeitspeicher im Speicherseitenpool des VMM zur Verfügung stehen. Ich gebe zu, dass man das genauer und korrekter formulieren kann, aber es stimmt im Prinzip so, wie es da steht, und ich würde daher die Frage entgegnen: wieviel technisches Wissen über die Speicherverwaltung von Windows gehört in einen Artikel über SoundFonts? Da kann man doch besser auf geeignetere und ausführlichere Artikel verlinken, oder nicht? --Ich weiß 01:20, 13. Feb. 2011 (CET)Beantworten
Du hast vollkommen Recht. Das Nachladen tritt bei den Creative-Treibern nicht auf. Das restliche von mir beschriebene Verhalten jedoch schon. Ich habe da etwas vermischt, da ich teilweise auch Timidity benutze. Sry ;) 87.139.55.127 12:57, 21. Feb. 2011 (CET)Beantworten


Grenzen des nutzbaren Speichers bei Sound Blaster-Karten[Quelltext bearbeiten]

Bei der Audigy besteht hier jedoch das Problem, das sie nicht über eine 64Bit-Adressierung verfügt und somit Probleme auftauchen können.

Also, diesen Satz habe ich erst mal aus dem Artikel entfernt und hierhin auf die Diskussionsseite verschoben. Der Satz wirft drei Fragen auf:

  1. nur bei der Audigy? Wenn, dann vermutlich nicht nur da, oder?
  2. die Ursache ist die fehlende 64Bit-Adressierung bei der Karte? Das halte ich für zumindest für fragwürdig. Es kann auch der Treiber schuld sein, siehe kxProject
  3. Es ist nur allgemein von irgendwelchen Problemen die Rede, die auftreten können. Geht's etwas genauer?

--Ich weiß 02:42, 13. Feb. 2011 (CET)Beantworten

Die Audigy verfuegt ueber keine 64Bit-Adressierung. Das heist, das die Adressierung und die I/O-Vorgaenge innerhalb des 32-Bit Adressraumes abgewickelt werden muessen. Das fuehrt auf Grund der veralteten Treiber dazu, das der DSP der Audigy nicht korrekt genutzt werden kann. Und auch wenn ein Treiber das beheben kann waere es immer noch nur ein Flickwerk. Neue Treiber gibt es jedoch nicht. Das Problem aeussert sich darin, das unter einem 64Bit-Betriebssystem keine Hardwarebeschleunigung zur Verfuegung steht oder die Soundkarte gar nicht angesprochen werden kann, sobald der RAM auf 4 GByte oder mehr aufgeruestet wurde.87.139.55.127 12:57, 21. Feb. 2011 (CET)Beantworten

Welche praktischenTipps?[Quelltext bearbeiten]

Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Das ist gute Theorie. Für den Laien bitte etwas praktischer: Was sollte ich tun, wenn beim Versuch, eine xyz.mid - Datei abzuspielen die Fehlermeldung kommt: Bitte Soundfont-Datei (.SP2) installieren. (Bsp. bei mir VLC-Media Player)??

Werden die .sp2-Dateien zugeschnittel für einen Player oder für die jeweils installierte Soundkarte benötigt? (nicht signierter Beitrag von 217.234.204.138 (Diskussion) 22:47, 5. Jan. 2013 (CET))Beantworten

Was sollen denn sp2-Dateien sein? Ich denke nicht, dass Fehlermeldungen, die nur ein spezifisches Programm betreffen, hier rein gehören. Eher in einen Artikel zum VLC, und da würde es wahrscheinlich auch wieder rausgelöscht werden. Im Übrigen hat es mich genau zwei Sekunden gekostet, durch Eingabe von "vlc soundfont" in Google folgende Seite zu finden: http://wiki.videolan.org/Midi Ich weiß (Diskussion) 00:46, 6. Jan. 2013 (CET)Beantworten

Defekte Weblinks[Quelltext bearbeiten]

Letzter Kommentar: vor 8 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
  • Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks.
  • Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

– GiftBot (Diskussion) 19:03, 4. Dez. 2015 (CET)Beantworten

Was ist denn SoundFont nun?[Quelltext bearbeiten]

Meine Bedürnisse hat der Artikel in seiner jetzigen Gestalt kein bisschen befriedigt. Ich bin in Zusammenhang mit der Capella Software auf das Thema SoundFont gestoßen, verstehe aber nicht, was das ist. Im Artikel ist viel die Rede von Soundblaster AudioKarten und Speicherbegrenzungen - könnte nicht jemand mal noch eine Erklärung nachschieben, was SoundFont nun ist, welche Vorteile die Technik hat gegenüber ähnlichen Techniken (ist z.B. VSTi vergleichbar?) etc.? Habe ich das richtig verstanden, dass ein SoundFont i.d.R. nicht nur eine Klangfarbe enthält, sondern oft ein komplettes GeneralMIDI als Klangbibliothek abdeckt? Und wie werden die einzelnen Klänge dann angesteuert/ausgewählt? Als Name, als MIDI-Kanal...? Wie gesagt: Ich habe aus dem jetzigen Artikel so gut wie nichts über SoundFont verstanden, kann aber logischerweise auch nichts beitragen außer dieser Anregung!

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:SoundFont&oldid=208896134“