16 Bit- vs. 24 Bit-Sample Sets

1. offizieller Beitrag
    • Offizieller Beitrag

    Ist sehr interessant. Ich habe einmal eine Schaltung im Audiosystem mit OP741 erstellt und das Argument bzgl. des Rauschens mit dem Hinweis , besser einen rauschärmeren OP zu verwenden, erhalten

    Der Hang geht immer zur Perfektionierung.

    Das OP Rauschen liegt weit unter dem minimalen Pegel (ohne Windgeräusche der Orgelwiedergabe). Schaltet man den Motor dazu ist vom IC erst Recht nichts zu vernehmen. Das Rauschen liegt jenseits von gut und böse.

    Ähnliches kann man nach deiner Beschreibung wohl auch feststellen.

    16 versus 24 Bit

    Digitale Signale müssen in analoge Wiedergabe umgewandelt werden.

    Dabei werden Werte einzelner digitaler Informationen interpoliert und ausgeglichen.

    Offensichtlich gibt es einen unteren Grenzwert an Bits wo Unterschiede hörbar werden .

    Darüber wird es ab bestimmter Werte nur theoretisch besser.

    Es nützt nicht viel, die Auflösung in immer höhere Bereiche zu treiben, wenn der DA-Wandler nicht schnell genug oder zu ungenau ist oder die Auflösung unseres Gehörs nicht mehr mitspielt.

    Hat man genügend Speicherplatz kann man ja locker 24 Bits nutzen.

    Übrigens, Der Unterschied von CD zu MP3 wurde auch viel diskutiert.

    MP3 ist für viele Wiedergaben durchaus akzeptabel.

    Deine Idee, eine Wiedergabe zu invertieren und mit der anderen zu summieren um Differenzen zu erhalten ist clever.

    Was machst du beruflich?

    Ich finde die Spektralanalysen hier ganz überzeugend...

    http://www.sonusparadisi.cz/en/blog/do-not-load-in-16-bit/

    Aber, was meine Augen sagen spielt eigentlich keine Rolle...

    Und was ich selbst machen muss, weiß ich noch immer nicht. Billerbeck in 24 Bit geht nicht in 64 GB. Sonus Paradisi sagt 20 Bit, aber leider hilft das fast nichts. Weiß nicht warum... Problem mit GrandOrgue?

    Also, ein Teil muss in 16 Bit geladen werden. Zuerst die Tremulanten - benutze ich bis jetzt nie. Aber dann? Alle "Direct" oder alle "Diffuse" Samples?

    • Offizieller Beitrag

    Eine CD hat 16 Bit Auflösung und einen Dynamik Bereich, der vom leisesten Pianissimo bis zum Fortissimo reicht. Das Ganze mit HiFi (Hohe Wiedergabetreue) bezeichnet.

    Abgespielt mit dreifach Oversampling oder mehr und integrierten Korrekturrechnern.

    Nachgeschaltet sind dann Verstärker und Lautsprecher, die die Wiedergabequalität - dazu in oft unzureichenden Räumen - nicht annähernd adäquat abbilden können.

    Die Frequenz von 20.000 Hz wird bei ca 44KHz getaktet, d.h. ca zweimal je Wellenlänge.

    Das ist in diesem Bereich eckig und wird mit DA-Wandler abgerundet. Insgesamt genügt der Klangeindruck höchsten Ansprüchen.

    D.h. man muß nicht alles um der Technik Willen übertreiben.

    Zitat von emsig

    Ich habe einen Vorschlag für GrandOrgue (falls das nicht sowieso schon so gemacht wird): Beim Laden in 16 Bit die Daten jedes Frames einer WAV-Datei soweit nach links shiften (sagen wir k-mal), daß beim Frame mit maximalem Wert das oberste Bit gesetzt ist, und zum Ausgleich beim Addieren des Samples zum Gesamtklang mit dem passenden Faktor 2^(-k) multiplizieren. Das Ergebnis wäre dann über den gesamten Dynamikbereich der Register so gut, daß man auf den 24-Bit-Modus eigentlich ganz verzichten und damit den speicherknappen Anwender von der Last der Entscheidung, welche Register er mit 16 und welche mit 24 Bit laden soll, befreien könnte. So werden zwar immer noch unnötig große Datenmengen vom Hersteller zum Anwender transportiert und auf der Platte gelagert, aber Leuten mit wenig RAM ist geholfen.

    Man würde hoffen das die Sampleset-hersteller das schon so machen. Es gibt in GO Parameter für individuelle Verstärkungsfaktoren für jede Pfeife.

    Ich glaube aber dass das Grösste Problem nicht mit Leisen oder Lauten Registern zu tun hat, sonder mit Hall. Hat man soeben eine Vielzahl von laute Noten gespielt werden nach zB 10 Sekunden viele Leise "Release" Samples zusammenaddiert.

    Vpo-organist schrieb "Direct ist trocken und verbraucht weniger Speicher". Ja, so sollte es sein, aber in der Praxis is dies stark abhängig vom Sampleset-hersteller. Bei Sonus Paradisi Billerbeck ist es jedenfalls NICHT so. Direct, Diffuse, Rear braucht in GrandOrgue genau so viel speicher.

    Ich werde mal selbst experimentieren, mit Kopfhörer...

    Wenn das Problem nur im Release ist, könnte man doch "einfach" eine Lösung machen in dem man Signalhüllkurve ("Envelope" - heisst das Signalhüllkurve auf Deutsch?) und Signal separat Speichert. Also, z.B. speichern das man für Sample 0-100 eine Verstärkung von 1 benutzt, von 101-500 16, von 501-2000 64, von 2001-Ende 256. Ein Par extra Parameter (hier zB [0 100 500 2000] und [1 16 64 256]) und schon kann man von 24 auf 16 Bit gehen.

    Also, nach links schieben wie emsig schon schrieb, aber nicht mit konstanten k.

    Wie immer, wenn man weiß wie ein Signal aussieht, kan man eine bessere Kompression machen als wenn man nichts weiß.

    Ich nehme an, in algorithmen wie mp3 gibt es auch solche Lösungen - vielleicht könnte man doch etwas benutzen ohne etwas neues zu erfinden. Und in GrandOrgue (glaube ich) ist das Problem nicht Prozessorkraft sondern Speicherplatz. Mein 12-Jahr-alten Rechner mit 64 GB ist schnell genug...

    emsig - es würde mich sehr freuen wenn du anfängst GrandOrgue zu verbessern! Es geschieht viel zu wenig...

    Selbst bin ich kein Softwareentwickler von Beruf, mit C++ habe ich nie gearbeitet - aber Signalbearbeitung (z.B. mit Matlab oder Signalprozessoren) gehört schon zu meiner Arbeit. Jetzt wo Billerback ODF (ein grosses PHP Projekt) so ungefär fertig ist werde ich mit GrandOrgue anfangen - zuerst im Bereich der Benutzeroberfläche, aber später vielleicht auch mehr.

    Wenn man etwas verbessern kann im Speicherbedarf wäre es wirklich gut... wenn 64 GB nicht mehr reichen, und es auch Minuten dauert bis ein Orgel geladen ist, wäre es schon nützlich.

    Ja, du hast recht!

    Da ich gesehen habe das die Einstellung von GrandOrgue (mit Billerbeck) auf 20 statt 24 Bit fast kein Speicher spahrt, vermute ich a) das nicht viel mehr als 20 Bit Info da ist und b) das GO schon etwas intelligentes tut.

    Ich habe schon einige aufgaben für mich:

    - selbst hören...

    - einige Samples analysieren (Ton und Hall)

    - GrandOrgue Programmkod untersuchen

    Ich melde mich wieder!

    • Offizieller Beitrag

    Stimmt und ist ein gutes Beispiel:

    Im "High End"-Audio gibt es Unsinn zur genüge.

    Verstärker werden nach Klirrfaktor nahe Null gekauft, und die ins Gewicht fallende Intermodulation, sowie der Klirrfaktor der Lautsprecher werden nicht berücksichtigt.

    Lautsprecherqualität steigt ca linear mit dem Preis bis zu einer Grenze, wo nur noch der Preis steigt.

    Sie erzeugen mit gleichem Verstärker im gleichen Raum unterschiedliches Hörerlebnis und unterschiedlichen Klang.

    Alles unter der Bezeichnung "HiFi" (Hohe Wiedergabetreue)

    Membranen wurden für Hoch- Mittel- und Tieftöner in unterschiedlichen Ebenen mit dem Hinweis angeordnet, dass dies für die exakte Phasenlage wichtig sei (die Phasenlage spielt für den Klang keine Rolle, man spiele einen Ton mit Sägezahn: starker Anstieg, schwacher Abstieg und umgekehrt. Der Klang bleibt gleich)

    Usw.

    Viele Männer brauchen eben immer das Beste.

    Aus langer Berufserfahrung in der Entwicklung elektronischer Messgeräte kann ich überspitzt sagen:

    Immer höher entwickelte Technik ließe sich bis auf wenige Ausnahmen ohne den Spieltrieb usw der Manner auf dem Markt nicht absetzen.

    Man musste z.B. unbedingt einen neuen Taschenrechner besitzen, der auch die Funktion "Sinushyperbolikus" berechnen kann ohne zu wissen was das ist und überhaupt im Privatbereich jemals eine solche Aufgabe lösen zu müssen und auch zu können.

    Bezogen auf Samplesets.

    Nüchterne Bewertung der Auflösung im Bezug auf RAM-Bedarf und Klangerlebnis gibt ein Optimum. Das liegt aus meiner Betrachtung bei 16 Bit (siehe CD)

    Gruß Rainer

    Wo ich bemerke, dass der große Speicherunterschied von 20-Bit auf 16-Bit zurückfällt - insbesondere, wenn Billerbeck und Friesach gleichzeitig in meinen 32-GB-Computer geladen sind. Ich muss Billerbeck mit 16 laden, wenn Friesach mit 20 geladen ist. Ich habe das Gegenteil noch nicht getestet.

    Bis jetzt habe ich (und ich glaube nicht nur ich) geglaubt das die Samples als Festkommazahlen gespeichert sind. Weil das im Cache und/oder im Speicher so sein kann, habe ich soeben festgestellt dass dies im .wav Dateien nicht immer der Fall sei. Das Beispiel dass ich jetzt vor mir habe speichert die Samples als Fließkommazahl - ich weiß noch nicht ob das jetzt 32 oder sogar 64 Bit/Sample sind.

    Aber, in diese Samples die ich jetzt vor mich sehe ist es deutlich das im Originalaufnahme (selbstverständlich) Festkommazahlen waren - dann aber irgendeine Bearbeitung durchgeführt ist (Filtrieren, nehme ich an) und das Resultat als Fließkommazahl gespeichert ist.

    Frage ist jetzt wie es aussieht wenn man dieses Signal diskretisiert, d.h. wieder zu Festkommazahl macht.

    Im Bild hier ein Release Sample und ein *extremer* Zoom am Ende.

    pasted-from-clipboard.pngpasted-from-clipboard.png

    Übrigens, nicht alle Sethersteller machen es so. Andere speichern im .wav als 24-Bit Festkommazahlen, wie man erwarten würde.

    Zitat von Sjoerd

    Da ich gesehen habe das die Einstellung von GrandOrgue (mit Billerbeck) auf 20 statt 24 Bit fast kein Speicher spahrt, vermute ich a) das nicht viel mehr als 20 Bit Info da ist und b) das GO schon etwas intelligentes tut.

    Diese Erfahrung habe Ich auch. In meinem Orgelcomputer (Intel NUC8i5) sehe ich nicht einmal einen Unterschied in der RAM-Zuweisung zwischen dem unkomprimiertse Laden mit 20 Bit oder 24 Bit, nicht nur mit Billerbeck, sondern auch mit anderen Sample-Sets. Das Laden mit 24 Bit oder mit 20 Bit nimmt 1,5 mal so viel RAM wie das Laden mit 16 Bit. Ich denke, das liegt an eine Speicherverwaltung, die mit Bytes stattfindet. 16 Bit ist 2 Bytes. 24 Bits ist 3 Bytes, aber 20 Bits nimmt auch 3 Bytes.

    Zitat von BasKb

    Diese Erfahrung habe Ich auch. In meinem Orgelcomputer (Intel NUC8i5) sehe ich nicht einmal einen Unterschied in der RAM-Zuweisung zwischen dem unkomprimiertse Laden mit 20 Bit oder 24 Bit, nicht nur mit Billerbeck, sondern auch mit anderen Sample-Sets. Das Laden mit 24 Bit oder mit 20 Bit nimmt 1,5 mal so viel RAM wie das Laden mit 16 Bit. Ich denke, das liegt an eine Speicherverwaltung, die mit Bytes stattfindet. 16 Bit ist 2 Bytes. 24 Bits ist 3 Bytes, aber 20 Bits nimmt auch 3 Bytes.

    Wenn dаs stimmt, verstehe ich nicht warum es überhaupt eine 20-Bit einstellung gibt...

    Ich glaube, wir müssen im Sourcecode hinein...

    Zitat von Sjoerd

    Wenn dаs stimmt, verstehe ich nicht warum es überhaupt eine 20-Bit einstellung gibt...

    Ich glaube, wir müssen im Sourcecode hinein...

    Mit komprimiertes Laden gibts bei mir doch ein wenig unterschied und vielleicht gibt es auch Systeme, bei denen es einen größeren Unterschied gibt. Ich stimme Ihnen zu, dass 20 Bit so wenig Sinn macht. Es versteht sich von selbst, dass 24 Bit 1,5 mal so viel Raum wie 16 Bit benötigd, aber 20 Bit sollte eigentlich nicht mehr als 1,25 mal den Raum von 16 Bit fragen.

    Ich bin gespannt, was Sie im Sourcecode finden.

    Ein interessantes Thema ist dies.

    Hier sind einige Ergebnisse einer kleinen Studie, die ich durchgeführt habe, um zu bewerten, wie ich die RAM-Nutzung mit dem Billerbeck-Sampleset am besten optimieren kann, da viel RAM erforderlich ist. Dafür habe ich ein Register der Semi-Dry-Version verwendet.

    Es fällt auf, dass die Samples des Dauertons nur etwa 1/3 des benötigten Speicherplatzes einnehmen. Ca. 2/3 wird von den Release-Samples angefordert. Der größte Gewinn scheint mit den Release-Samples erzielt zu werden, aber dort besteht auch die beste Chance auf einen hörbaren Effekt. Ich habe mir daher zuerst die Releases angesehen.

    Die Release-Samples

    Effekt der Konvertierung in 16 Bit:

    Bild 1 zeigt ein Spektogramm einer 24-Bit-Version aus dem Ordner rel99999. Bild. 2 zeigt die gleiche Release-Sample nach der Konvertierung in 16 Bit. Das 24-Bit-Sample hat eine Größe von 1,19 MB. Die Konvertierung in 16 Bit reduziert dies auf 815 kB. Dies geht jedoch zu Lasten des Signals, das nach 1,7 Sekunden abfällt, während es in Fig. 1 ungefähr 2,7 Sekunden dauert. So geht etwa 1 Sekunde Signal verloren. Beachten Sie, dass der Abschnitt nach 1,7 Sekunden zwar keine nützlichen Informationen mehr enthält, jedoch immer noch Speicherplatz belegt, als ob das 16-Bit-Signal bis zum Ende des Samples (4,3 Sekunden) fortgesetzt wird.

    Auswirkung der Verkürzung der Releases:

    Um wirklich von der Reduzierung auf 16 Bit zu profitieren, könnten wir das Sample nach 1,7 Sekunden kürzen. Das funktioniert in der Tat, weil dadurch der RAM-Bedarf auf 324 KB reduziert wird.

    Auch für die 24-Bit-Version enthalten ca. 1,5 Sekunden des Samples keine Funktionsinformationen und können daher übersehen werden. Durch Verkürzen der Sample auf 2,8 Sekunden (Abb. 3) wird die Samplegröße auf 783 kB reduziert, ohne das Signal zu beschädigen.

    Verlustfreie Konvertierung anwenden:

    Sowohl Hauptwerk als auch Grandorgue bieten die Möglichkeit, Samples beim Laden verlustfrei zu komprimieren. Um den Effekt zu sehen, habe ich auf FLAC konvertiert, da ich die dafür von HW und GO verwendeten Algorithmen nicht kenne. Ich gehe davon aus, dass sie vergleichbar sind.

    Zuerst habe ich die 24-Bit-Dateien konvertiert. Resultat: Die Samplegröße wurde auf nur 182 kB reduziert. Es gabe keinen Größeunterschied zwischen der verkürzten Version und der Originalversion. (Das Unterschied ist also weniger als 1kB) . Das Vorkürzen der Releases hat daher keinen Mehrwert, wenn verlustfreie Komprimierung verwendet wird.

    Zur Kontrolle habe ich die FLAC-Dateien wieder in WAV-Dateien konvertiert. Resultat: Sie haben die Originalgröße und die gleichen Spektogramme wie die Original-WAV-Dateien.

    Um mich dann davon zu überzeugen, dass es wirklich richtig war, wurde ein zuvor von Markus beschriebener Test durchgeführt, um konvertierte Dateien (von WAV über FLAC zu WAV) mit die Originalsamples zu vergleichen, indem sie invertiert wurden, um die invertierten Dateien mit den Originaldateien zu summieren. Das Ergebnis war: absolut 0. So verlustfrei ist in der Tat verlustfrei (und ich hatte die Konvertierung gut gemacht).

    Es versteht sich von selbst, dass die verlustfreie Komprimierung auch auf die 16-Bit-Version angewendet werden kann. Dann wird es zu einer Datei mit 155 kB.

    Zusammenfassung: Die verlustfreie Komprimierung der 24-Bit-Version des Releases führt somit zu einer Reduzierung von 1,19 MB auf 182 KB. Das Laden mit 16 Bit (nicht verlustfrei) und danach verlustfreier Komprimierung führt zu einer Reduzierung von 1,19 MB auf 155 KB.

    Die Tonsamples

    Schauen wir uns jetzt auch die Tonsamples an:

    Die Konvertierung in 16 Bit führt zu einer Reduzierung des von mir ausgewählten Samples um 1,95 MB auf 1,3 MB.

    Durch Anwenden einer verlustfreien Komprimierung auf das 24-Bit-Sample wird eine größere Reduzierung erzielt, nämlich auf: 946 kB.

    Die Kombination aus (nicht verlustfreier) Umwandlung in 16 Bit und anschließender verlustfreier Komprimierung ergibt die größte Reduzierung, nämlich: Bis zu 390 kB.

    Der Unterschied zwischen den letzten beiden Zahlen ist meiner Meinung nach ein Hinweis auf den Informationsverlust bei der Konvertierung in 16 Bit.

    Ich habe auch den Vorschlag gelesen, die Lautstärke des 24-Bit-Signals vor dem Laden in 16-Bit zu erhöhen, wonach das verstärkte 16-Bit-Signal in GO wieder gedämpft werden könnte, alles um den Informationsverlust zu begrenzen.

    Ich dachte, das wäre ein kreativer Gedanke. Um zu sehen, ob dies effektiv sein könnte, habe ich das 24-Bit-Sample (auf maximale Ausgabe) normalisiert und es dann in 16-Bit konvertiert. Das ergab wieder eine Datei von 1,3 MB.

    Ich habe diese Datei dann verlustfrei in FLAC konvertiert. Dann stellte sich heraus, dass es eine Datei mit 892 KB gab, was fast der Größe der direkten Konvertierung in FLAC entspricht. Dann wäre eine direkte Umstellung auf Flac meine Präferenz

    Die Ram-Anforderung der Tonsample kann auch durch Entfernen der nicht verwendeten Teile des Samples reduziert werden. Dies betrifft den Teil nach die letzte Loop oder zwischen den letzten Loop und dem Cuepoint.

    In das vorliegenden Sample handelt es sich um eine Einsparung von ca. 10%. Das mit allen Samples zu tun scheint viel Arbeit zu sein, aber mit dem Programm "Loop Auditioneer" von Lars Palo ist es möglich, dies automatisch im Batch pro Ordner zu tun.

    Ich habe die folgende Schlussfolgerung fur mich gezogen:

    1. Das Laden mit 16 Bit bietet nicht mehr Reduzierung als verlustfreie Konvertierung.

    2. Die verlustfreie Konvertierung ist dem Laden mit 16 Bit vorzuziehen

    3. Wenn eine weitere Reduzierung erforderlich ist, ist das Laden mit 16 Bit in Kombination mit einer verlustfreien Konvertierung sinnvoll


    Ich hoffe es hilft dir auch,

    Bas

    Frage ist jetzt wie wir GO verbessern können.

    Verkürzen der Releases irgendwie automatisch machen?

    Kompression funktioniert (wenn ich es richtig verstanden habe) nicht mit Interpolation zusammen. Ist wahrscheinlich sowohl eine Prozessorkraft- als auch Speicherplatzfrage.

    Zitat von Sjoerd

    Frage ist jetzt wie wir GO verbessern können.

    Verkürzen der Releases irgendwie automatisch machen?

    HW hat die Möglichkeit, Release-Samples beim Laden zu verkürzen, berücksichtigt jedoch nicht den Inhalt der Samples und den ungenutzten Speicherplatz, der zwischen den Samples stark variiert.

    Wenn Sie die Komprimierungsfunktion verwenden, hat das Kürzen der Releases in Bezug auf den Speicherplatz keinen Mehrwert.

    Zitat

    Kompression funktioniert (wenn ich es richtig verstanden habe) nicht mit Interpolation zusammen. Ist wahrscheinlich sowohl eine Prozessorkraft- als auch Speicherplatzfrage.

    Es wird in der Tat einige "Trade-of "zwischen Prozessorkraft und Speicherplatzfrage darüber geben, ob mit Kompression geladen wird oder nicht. Deshalb ist es wichtig ob Sie genügend Prozessorkraft zur Verfügung haben.

    Ich habe auch mal im Handbuch von HW 5 und der Hilfe von GO nachgesehen.

    Das Hauptwerk V-Handbuch besagt dass das Aktivieren der Komprimierung die Standardeinstellung ist (enabled by default for all ranks) und ausdrücklich empfohlen wird. Es scheint keinen Konflikt mit der Interpolation zu geben.

    (N.B. Ohne Komprimierung speichert HW5 die 24-Bit- und 20-Bit-Samples als 32-Bit und benötigt daher erheblich mehr Speicher als GO !)

    In Grandorgue existiert die Komprimierung gleichzeitig der linearen Interpolation sondern nicht * mit der Mehrphaseninterpolation. Mehrphaseninterpolation erfordert mehr Rechenleistung, ist aber nicht unbedingt immer besser.

    Interpolation wird übrigens nur verwendet, wenn Samples nicht auf der ursprünglichen Tonhöhe gespielt werden.

    * "Not yet" sagt die GO Hilfedatei. Verbesserungsmöglichkeit?

    Zitat von emsig

    Wenn ich GO-Entwickler wäre, würde ich bei 24-Bit-Dateien das Einlesen mit skalierten 16 Bit zum Standard machen. RAM-Bedarf um 1/3 verkleinert, einfach zu implementieren, schnell zu rechnen, Qualitätsverlust nicht wahrnehmbar.

    So einfach ist es Leider nicht. In dem Beispiel, das ich aus der Billerbeck Semi-Dry Demo verwendet habe, konnte ich das Volumen der Sample um 39 dB erhöhen. Im selben Sample-Set befindet sich jedoch auch eine Posaune im Pedal, deren “Headroom” nur ca. 3 dB beträgt. Sie können also nicht alle Samples mit demselben Faktor "skalieren" und dann laden. Wenn Sie diesen Sampleset für 16 Bit optimieren möchten, sollten Sie für jedes Register eine geeignete Skalierung verwenden, die Sie dann im ODF korrigieren müssen. Mir scheint das daher eher eine Herausforderung Für den Sample-Set-Hersteller als für die GO-Entwickler.

    Martin Dyde (Hauptwerk) hat in der Tat jemals empfohlen, dass die Hersteller von Samplesets jedes Register mit maximaler Stärke aufzeichnen. Diese Empfehlung stammt aus der 16-Bit-Ära. Ich weiß nicht, ob es Hersteller von Samplesets gibt, die das jetzt noch tun.

    Da wir 24 Bit haben, ist es nicht mehr notwendig und es ist für Hersteller von Samplesets viel einfacher, alle Register mit denselben Einstellungen mit guten Ergebnissen aufzuzeichnen (und zu filtern).

    Bei großen Orgeln kann es sein das wir fast den gesamten Dynamikbereich von 24 Bit nutzen. Das ist nicht so seltsam, wenn man bedenkt, dass wir ein Lautstärkepedal haben und sowohl das volle Werk als auch ein einzelnes leise Register bei Raumstärke hören möchten. Bei kleinen Orgel wie Kalvträsk ist es deshalb auch weniger kritisch.

    Zitat von emsig

    Ich meinte keine globale und auch keine registerweise, sondern eine dateiweise Skalierung, um den Dynamikumfang der 16 Bit bei jeder WAV-Datei voll ausnutzen zu können, egal ob Posaune oder Flöte. Es ging mir nur um das Einladen von 24-Bit-Dateien im 16-Bit-Modus, um 1/3 des RAMs zu sparen.

    Vielleicht verstehe ich dich nicht sehr gut. Globale Skalierung wird automatisch angewendet, wenn es von 24 Bit auf 16 Bit konvertiert wird. Die Registerweise Skalierung kann ich verstehen. Dann werden die leisere Register vor der Umwandlung in 16 Bit um einen Faktor verstärkt. Derselbe Faktor wird erneut über einen ODF-Befehl verwendet, um das ursprüngliche Volumenverhältnis zwischen den Registern beim Entladen aus dem Speicher wiederherzustellen. Das scheint mir bei Dateigeweise Skalierung Problematisch. Ich sehe noch nicht, wie ich mir diesen Prozess bei der dateibasierten Skalierung vorstellen soll. Ich denke, dass man in diesem Fall auch den Faktor verfolgen sollte, um den jede Datei skaliert wird, um die ursprünglichen Proportionen wiederherstellen zu können.

    Ich bin aber kein GO-entwickler und eben kein Sofware Entwickler und möchte es gerne ihnen überlassen..

    Ich glaube nicht das ich in diesem Bereich etwas Nützliches beitragen kann.

    Für mich selbst bevorzuge ich die verlustfreie Komprimierung die schon in GO implementiert ist.

    Zitat von emsig

    Man müßte an der ODF überhaupt nichts ändern. Man müßte nur beim Reinladen jeder 24-Bit-WAV-Datei nach dem betragsmäßig größten Wert schauen und beim Umwandeln nach 16 Bit alle Werte um den gleichen, maximal möglichen Versatz nach links schieben. Die Anzahl k der Bits, um die man verschoben hat, merkt man sich und skaliert beim Spielen der Datei um 2^(-x).

    Vielen Dank für die Klarstellung Markus. Jetzt verstehe ich ein wenig mehr darüber. Scheint mir auch wirklich eine Frage der Software-Entwickler. Könnte es sein, dass das Funktionsprinzip der verlustfreien Kompression mehr oder weniger ähnlich ist?

    Grüße,

    Bas