# Java Sound-API stagniert



## Spacerat (19. Aug 2012)

Hallo
Ich hab' jetzt, wie schon anderweitig erwähnt, dass ich nun auch komplett auf Java7 umgestiegen bin und auch schon die ein oder andere Überraschung damit erlebt habe.
Leider blieb auch die ein oder andere Überraschung aus; Eine davon bertifft das Standard Soundsystem "javax.sound.sampled". Irgendwie finde ich (schon seit 2004) darüber nicht die geringste "was ist neu"-Information, deswegen frage ich mich, ob das überhaupt noch weiter entwickelt wird und ob man nun immer auf Non-Standard-Frameworks (maw.: auf Klassen ausserhalb des Ordners JRE) zurückgreifen muss. Mehr als 2 Kanäle gab es ja schon lange bevor Java überhaupt auf dem Markt war, aber von Soundunterstützung in Java kann nach wie vor auch in JRE7 nicht die Rede sein. Okay, evtl. benötigt man nicht wirklich die Samplingraten von SACD (2,8GHz) aber die Unterstüzung von etwa 9.1-Soundsystemen (und zwar ohne JOAL, LWJGL, JavaFX usw.) sollte schon drin sein, findet ihr nicht?
[EDIT]Evtl. ist ja auch irgendwas (ausser irgendwelche Frameworks) an mir vorbei gegangen, was die Weiterentwicklung des SoundAPIs überflüssig macht. Hat evtl. jemand Tipps oder Anregungen (ausgenommen irgendwelche Frameworks)?[/EDIT]


----------



## Marco13 (19. Aug 2012)

Ja, vieles davon wirkt schon sehr antiquiert  Ich stand/stehe auch vor dem Problem, z.B. einen Sound auf den n (4/6/...) Boxen eines Mehr-Boxen-Systems auszugeben. Mit der reinen Java-API geht das zwar theoretisch, aber ... praktisch dann eben doch nur sehr rudimentär (kurze Sounds werden verschluckt, etc...). Aber auch sonst sieht's da irgendwie düster aus. Selbst wenn man sich dann letztenendes dazu überwinden würde, DirectSound zu verwenden: Das ist doch ein Krampf, wer hat sich denn diese :autsch: API ausgedacht? JOAL und LWJGL helfen da auch nur bedingt, weil es zumindest nicht trivial zu sein scheint, einzelne Boxen anzusteuern. Im Moment bin ich bei FMOD / NativeFMOD, was vielleicht die gewünschte Funktionalität bietet, aber auch nicht so vertrauenserwckend aussieht...

Bis zu einem gewissen Grad ist es verständlich: In den "klassischen" Anwendungsbereichen von Java kommt der meiste Sound immernoch vom Lüfter  Und wenn man sich mal ansieht, WIE kompliziert Dinge wie DirectSound und die ganzen Dolbies (?) sind, versteht man, dass der Aufwand, um das Plattformunabhängig (!) abzudecken enorm sein muss. Aber schade ist es schon. 

Konkrete Tipps...? Würde ich auch gern hören...


----------



## twseitex (20. Aug 2012)

Java hat weiterhin den traditionellen Mangel, das, was im Mediabereich
minimal wenigstens möglich ein sollte, z.B. Audio wie midi, mp3, wav,
per einfacher Zusammenstellung von Komponenten des Java-Standards
zu ermöglichen. Also Bausteine anzubieten, die abgestimmt sind.
Denn das würde die GUI-Aufsetzung erleichtern - und die ist nicht
unbedingt trivial.

Das Verwenden von Framworks oder anderen Java-Versionen ist
wegen Support ev. nicht (ganz) zukunftssicher.

Der Boom auf Mobil macht Java eh zu schaffen.

Es wird Meilensteine in Java geben, aber Java für jedermann nie.

Oracle wird die Java-Revision nicht systemisch vollziehen.

Meiner einer weiss, dass ich z.B. die Programmierung eines
dynamischen Audio-Media-Players per Java SE nicht nochmal
angehen würde (siehe audio, flash and java).

Daher ziehe ich immer den Hut vor Abenteuerlustigen, die
aus Java Highlights z.B. wie 9.1-Sound herauskitzeln wollen.

MS DirectX (also DirectMedia) ist mit Java nicht vergleichbar.

MS Silverlight ist auf absteigendem Ast.

Adobe Flash riecht leicht nach Java. Adobe hat noch ne Menge zu tun
und macht dabei sich selbst Äger: Air-Laufzeit-System und HTML5.
Und Flash ist alles andere als preiswert.

Was übrigens HTML-5-Media in Browsern wie Opera betrifft:
Es wird C++ Einzug halten, denn z.B. Google liefert Addon-Code.

Klingt alles nicht so gut für Java.
Dass von Oracle das neuere JavaFX mit verteilt wird, kommt zu spät.

Was wirklich dauerhaft Spass macht, ist z.B. die Eclipse-IDE für Java
etc.. Da mal reinschauen lohnt sich. Wer kann bzw. die Kohle hat,
sollte mal sich das Eclipse-Plugin für Adobe-Flash ansehen (Adobe
Flash Pro muss installiert sein, da von dort u.a. die Hilfe kommt
und die grafischen Elemente erzeugt werden können (keine reine
Compiler-Version wie die Open-Flash-Version von Adobe).


----------



## Guest2 (20. Aug 2012)

Moin,



Marco13 hat gesagt.:


> DirectSound zu verwenden: Das ist doch ein Krampf, wer hat sich denn diese :autsch: API ausgedacht?



wurde DirectSound nicht durch XAudio 2 ersetzt?

(Habe schon mit dem Gedanken gespielt, einen Wrapper dazu zu bauen, da ich ein ähnliches Problem habe.)

Viele Grüße,
Fancy


----------



## tuxedo (20. Aug 2012)

*MalSoInDenRaumWerf*: Was ist denn mit gstreamer? Gibt's da nicht schon mehr als 2.0 Audio? DIe Anbindung an sich stellt ja mit diversen Wrappern keine allzugroße Hürde dar. Und da es GStreamer (mehr oder weniger) für die Windows-Welt gibt, wäre das dann ja Plattformunabhängiges Audio ... 

- Alex


----------



## Marco13 (20. Aug 2012)

Tja, wer weiß das schon... über XAudio bin ich bei meiner Suche auch gestolpert, konnte aber nichts damit anfangen. Die MSDN-Doku ist ein häßlicher, häßlicher Wust von Spezifikationen, die schon beim ersten Lesen aussehen, als hätte man an irgendwelche Krücken noch mit Tesafilm einen Spoiler drangepappt um es fit für die 90er zu machen (das kann täuschen, vielleicht bin ich auch von Java NOCH mehr verwöhnt, als ich schon antizipert habe, aber ... bei dem, was ich glaubte, mir für das Ansprechen einzelner Boxen mit WAV-Daten anlesen zu müssen, nämlich Multiple Channel Audio Data and WAVE Files , rollen sich einem doch die Fußnägel zu einer Beroulli-Spirale hoch :autsch: und von "veraltet" oder "ersetzt durch XAudio" steht dort auch nichts, auch wenn das Datum schon suspekt aussieht). 

@twseitex: Was du als "traditionellen Mangel" beschreibst finde ich (vielleicht nur aus reiner Unwissenheit, also widersprich' mir ggf. ) unangebracht. Eine moderne, klare API wäre was feines, ausgerichtet auf die Konzepte von Dolby (sofern es da "Konzepte" gibt, da bin ich mir nicht so sicher). Aber inwiefern ist das ein "Mangel" von Java? Wenn ich das richtig sehe, _gibt es sowas überhauptnicht_. Es scheint, als würde Dolby nur für überteuerte Fernseher und Stereoanlagen verwendet, und vielleicht von irgendwelchen Tonstudios die Spezialsoftware für x0000€ verwenden. Aber eine einigermaßen vernünftige API dafür (und ich lehne mich mal so weit aus dem Fenster: Egal in welcher Sprache) habe ich bisher noch nicht gesehen. :bahnhof:

EDIT: @tuxedo GStreamer hattest du (oder jemand anderes) in einem anderen Thread schonmal erwähnt, ich bin bisher davon ausgegangen, dass das in erster Linie ein Player ist, und nicht für irgendwelche Low-Level-Sachen (Dolby Boxen ansteuern) - bei einem Blick über die API steht da auch was von "lowlevel", ggf. mal schauen ob man damit sowas machen könnte, und wie "einfach" das zu benutzen ist...


----------



## Spacerat (20. Aug 2012)

@Fancy: Kannst ja bei dem im Anhang mal versuchen, darauf zu kommen, warum die JavaZoom-SPIs nicht funktionieren (Obwohl... das kann ich auch noch selbst). XD
@Marco13: Die oder der Verbrecher des Java Sound APIs (Kara Kytel) wurde anscheinend schon 2004 unehrenhaft entlassen. XD
Das Teil im Anhang ist jedenfalls mein OpenAL-Wrapper für JOAL und LWJGL, welches aber erst mal nur SourceDataLines und Clips unterstützt. So wirklich das Wahre ist das aber auch nicht, weil Framework-Abhängig.
Ferner steht dadurch auch Suns DirectAudioDevice nicht mehr zur Verfügung, da weis ich aber nicht, ob das erst seit Version 7 so ist. Zumindest liefern Mixerabfragen auf die immer noch vorhandenen Mixer.Infos nur noch null, sobald das Jar im Java-Ext-Verzeichnis liegt.
Und wo wir grad' davon Sprechen... Suns DirectAudioDevice hat sich nur in einer winzigen Kleinigkeit verändert. Die Controls einer Line stehen einem erst zur Verfügung, wenn die Line geöffnet wurde. Vorher war's nicht immer so, obwohl es afaik von Anfang an in der API stand.
Ansonsten... was bitte ist XAudio 2? (Okay... gelesen. Das hat aber nichts mit Suns DirectAudioDevice zu tun.)


----------



## Guest2 (20. Aug 2012)

Mein Hinweis auf XAudio 2 bezog sich nur auf Marcos Versuchen zu DirectSound. Aus der Wikipedia (was natürlich nicht stimmen muss):



			
				https://de.wikipedia.org/wiki/DirectX#XAudio_2 hat gesagt.:
			
		

> XAudio 2 basiert auf der Xbox-360-Sound-API und hat DirectSound abgelöst. Die programmierbaren DSP-Programme ermöglichen EAX-ähnliche Effekte auf allen Soundkarten; diese werden allerdings auf dem Hauptprozessor ausgeführt. Dies hat vor allem Kritik seitens des Soundkartenherstellers Creative hervorgerufen, weil auf dessen Karten solche DSP-Programme „in Hardware“ ausgeführt werden könnten, um Spielern somit einen Geschwindigkeitsvorteil zu bieten (durch Entlastung der CPU).



Inwieweit sich damit die Lautsprecher einzeln ansteuern lassen, weiß ich allerdings auch nicht. Die XAudio 2 API ist vermutlich auch nicht schön.


Wenn es um reine Java API geht, dann ist vielleicht ein Blick in den Quellcode des 3D Sound System von Paul Lamb hilfreich (und dem zugehörigen JavaSound library PlugIn). Das wird sehr oft empfohlen. Er selbst schreibt aber auch, dass es mit dem OpenAL PlugIn viel besser klingt als mit dem JavaSound PlugIn.

Und ich schließe mich Marco an, Sound ist immer ein Krampf, egal mit welcher Sprache und egal mit welchem Betriebssystem. 

Viele Grüße,
Fancy


----------



## Marco13 (20. Aug 2012)

Spacerat hat gesagt.:


> @Marco13: Die oder der Verbrecher des Java Sound APIs (Kara Kytel) wurde anscheinend schon 2004 unehrenhaft entlassen. XD



Naja... die Verwendung ist ja für bestimmte Anwendungsbereiche (auch unter Berücksichtigung der Zeit, zu der das entwickelt wurde) etwas mehr als nur "genial":

```
Clip clip = AudioSystem.getClip();
AudioInputStream inputStream = AudioSystem.getAudioInputStream(stream);
clip.open(inputStream);
clip.start();
```
spielt eine WAV-Datei ab. Auf Linux, Windows oder MacOS, egal welches Format die WAV hat, und egal welche Soundkarte im Rechner steckt. DAS ist GUT. (Nochmal die Erinnerung an Multiple Channel Audio Data and WAVE Files : Selbst wenn man das alles und noch viel mehr gelesen und verinnerlicht hat, ist man noch weeeiiit davon weg, auch nur einen Ton aus dem Lautsprecher zu kriegen!)

Der Nachteil ist, wie so oft, dass das eben eine rieeesige Black-Box ist. Wo kann man da jetzt die Lautstärke einstellen? Tjaaaa... schon geht's los. Selbst das ist, grob gesagt, noch "so einfach wie es eben sein kann", aber an bestimmten Stellen stößt man dann eben DOCH an die Grenzen, die durch ein übles Gemisch aus Plattform(un?)abhängigkeit, Hardware"nähe", Codec-Hölle, schnellebigen Standards (Dolby) und, damit verbunden, ja, auch mangelnde Weiterentwicklung Seitens Sun/Oracle gezogen werden. 

Das von Paulscode sieht recht übersichtlich aus, scheint aber zumindest auf den ersten Blick (ähnlich wie GStreamer) auf einer relativ hohen ebene Anzusetzen - ähnlich wie beim Snippet oben scheint es damit leicht zu sein, aus einer Datei einen Sound abzuspielen, auch im 3D-Raum mit OpenAL & Co, aber ... man muss sich wohl mit beidem (und/oder den vielen anderen APIs/Libs die es so gibt) lange beschäftigen, um erstmal rauszufinden, OB man damit so "low-level"-Sachen machen kann, wie einen Sound gezielt auf eine Box zu legen, und wenn ja, wie...


----------



## Spacerat (20. Aug 2012)

Also das gezielte Boxen ansteuern ist ja kein Ding bei 2 Kanälen und in OpenAL ist es auch mit mehreren nicht wirklich das Problem.
Was aber ein Problem darstellt; Bei deinem Snippet fehlt etwas. Ich kenne kein Sound API weder in Java noch sonstwo (ausser anno domini beim Amiga), welches andere Encodings ausser PCM abspielen kann. Ich weis nicht seit wann, aber inzwischen gibt es auch WAVs mit A- bzw. U-LAW Encoding. Java unterstützt diese beiden Encodings zwar auch, sonst wäre der Support von AIF, AIFF und SunAU nicht möglich gewesen. Auch die Javazoom-Codecs müssen in PCM gewandelt werden, so dass man letztendlich stets per Methode dafür sorgen muss, dass eine SourceDataLine ausschliesslich mit PCM gespeisst wird.

```
public static final AudioFormat ensurePCM(AudioFormat af) {
		Encoding enc = af.getEncoding();
		if(!PCM_SIGNED.equals(enc) && !PCM_UNSIGNED.equals(enc)) {
			int ssb = af.getSampleSizeInBits();
			int c = af.getChannels();
			if(ssb < 8) {
				ssb = 8;
			}
			int minFs = c * ssb / 8;
			int fs = af.getFrameSize();
			if(fs < minFs) {
				fs = minFs;
			}
			af = new AudioFormat(
					AudioFormat.Encoding.PCM_SIGNED,
					af.getSampleRate(),
					ssb * 2,
					af.getChannels(),
					fs * 2,
					af.getSampleRate(),
					af.isBigEndian()
				);
		}
		return af;
	}
```
Diese Methode liefert für jede Sounddatei (Javastandards, MP3 und OGG) ein passendes AudioFormat, mit welchem der AudioInputStream gelesen werden kann. Eigentlich gehört dieser Teil direkt in die Abspielmethode der Line, dann müsste man sie nicht andauernd selbst vorwegschalten.
Was in Java und auch vielen anderen Sprachen sehr viel vereinfachen würde, wäre, wenn man grundsätzlich die Vereinbarung trifft, dass ein AudioStream nur PCM-Daten liefern darf und sich die Codecs um eine Wandlung in dieses selbst bemühen dürften oder aber das Device alle Konvertierungen selbst vornimmt, statt mit Exceptions um sich zu schmeissen.
Dann kommen noch so Dinge wie diverse Controls hinzu. Wer ahnt da schon, dass man z.B. bei simplen Volumeneinstellungen teilweise statt prozentuale Lautstärke, DeziBell-Werte übergeben muss. Das ist nicht mal festgelegt :autsch: und von Hardware zu Hardware verschieden.


----------



## Guybrush Threepwood (20. Aug 2012)

Hi,
hast Du schon einmal die neuen Möglichkeiten von JavaFX 2.0 angesehen? Die Medienunterstützung ist erheblich besser: Incorporating Media Assets Into JavaFX Applications: Introduction to JavaFX Media | JavaFX 2 Tutorials and Documentation 


> The formats currently supported are the following:
> 
> Audio: MP3; AIFF containing uncompressed PCM; WAV containing uncompressed PCM; MPEG-4 multimedia container with Advanced Audio Coding (AAC) audio
> 
> Video: FLV containing VP6 video and MP3 audio; MPEG-4 multimedia container with H.264/AVC (Advanced Video Coding) video compression



Man kommt extrem viel leichter an Metadaten heran etc. Vielleicht ist ja dabei, was Du suchst.


----------



## Spacerat (21. Aug 2012)

Guybrush Threepwood hat gesagt.:


> Hi,
> hast Du schon einmal die neuen Möglichkeiten von JavaFX 2.0 angesehen?


Ja, hab' ich.





Guybrush Threepwood hat gesagt.:


> Vielleicht ist ja dabei, was Du suchst.


Nein, ist es nicht...





> ... und zwar ohne LWJGL, JOAL, JavaFX usw.


Diese Problematik ist der Grund dieses Themas.


----------



## maki (21. Aug 2012)

> In den "klassischen" Anwendungsbereichen von Java kommt der meiste Sound immernoch vom Lüfter Und wenn man sich mal ansieht, WIE kompliziert Dinge wie DirectSound und die ganzen Dolbies (?) sind, versteht man, dass der Aufwand, um das Plattformunabhängig (!) abzudecken enorm sein muss.


"Lüfter-Musik" LOL

Die "ganzen Dolbies" sind übrigens nur MP3 (A52), bis auf TrueHD.


----------



## Marco13 (21. Aug 2012)

@maki: Mit den Dolbies meinte ich eben 5.1, 7.1, 9.1 (gibt's auch mal x.0?), mit unterschiedlichen Anzahlen von Boxen, die irgendwie angeordnet sein müssen für irgendeinen tollen Raumklang... bin da nicht so der Experte...



Spacerat hat gesagt.:


> Also das gezielte Boxen ansteuern ist ja kein Ding bei 2 Kanälen und in OpenAL ist es auch mit mehreren nicht wirklich das Problem.



Ein Snippet, das mit OpenAL (LWJGL, OpenAL soft) alle Devices auflistet (bei 'soft'???), und für jedes Device auf jeder verfügbaren Box einen Ton ausgibt, würde ich begrüßen. Habe neulich gesehen, dass es explizit "Multi-Channel-Buffer" gibt, damit könnte das gehen, habe es aber noch nicht gestestet (meintest du das?). Ansonsten kann man nur eine 3D-Position im Raum angeben, und das kommt dann mehr oder weniger aus irgendwelchen Boxen eines Dolby-Systems...

Die Änderung des AudioFormats ist eine Sache. Ähnlich wie man leicht einen Zettel mit der Aufschrift "Zeitmaschine" auf einen Toaster kleben kann. Irgendwelche Daten dann tatsächlich umzuwandeln um sie abspielen zu können ist dann nochmal ein anderes Thema (isConversionSupported und so...). Wobei ich mich mit den ganzen Mechanismen, die es rund um das große Thema "Codecs" herum gibt, nicht auskenne.

Ich fände eine Abstraktion von diesen ganzen Dingen schon praktisch. Und mit "Abstraktion" meine ich nicht, dass man nurnoch eine Methode hat wie "play(file)", und sonst nichts, sondern dass es eine allgemeine, abstrakte Repräsentation von Sounds geben könnte, zum Beispiel(!) ganz naiv(!) als eine Liste von FloatBuffern (für jeden Channel) mit Werten zwischen -1 und 1, und eine abstrakte Repräsentation eines Devices, dem man eine Liste von FloatBuffern geben kann, und die dann abgespielt werden. Damit die Frage, ob es nun irgendwann irgendwo, kurz vor dem Lautsprecher,  2-byte-unsigned-big-endian-PCM-Daten sein müssen, einfach ausgeblendet wird. 
(Ich weiß, dass es nicht so einfach ist, und in der beschrieben Form schon SEHR naiv vereinfacht und praxisfern, aber von der Idee her...)


----------



## Spacerat (21. Aug 2012)

Marco13 hat gesagt.:


> Ein Snippet, das mit OpenAL (LWJGL, OpenAL soft) alle Devices auflistet (bei 'soft'???), und für jedes Device auf jeder verfügbaren Box einen Ton ausgibt, würde ich begrüßen. Habe neulich gesehen, dass es explizit "Multi-Channel-Buffer" gibt, damit könnte das gehen, habe es aber noch nicht gestestet (meintest du das?). Ansonsten kann man nur eine 3D-Position im Raum angeben, und das kommt dann mehr oder weniger aus irgendwelchen Boxen eines Dolby-Systems...


Jep, diese Multichannelbuffer meine ich. Soundpositionierung funktioniert eh' nur mir Mono-Quellen. Ein Snippet dazu würde wenig Sinn machen, wenn man sich mit der Anordnung der Daten im Bytestream des Sounds nicht auskennt, das ganze hatten wir bereits hier und in OpenAL trifft das auch noch zu (112233445566..) nur muss man zusätzlich noch festlegen, welcher Kanal zu welchem Lautsprecher gehört. BTW.: X.Y bedeutet Anzahl der "Sateliten" (X) und Anzahl der "Subwoofer", ja, es gibt noch X.0; 1.0, 2.0, 4.0



Marco13 hat gesagt.:


> Die Änderung des AudioFormats ist eine Sache. Ähnlich wie man leicht einen Zettel mit der Aufschrift "Zeitmaschine" auf einen Toaster kleben kann. Irgendwelche Daten dann tatsächlich umzuwandeln um sie abspielen zu können ist dann nochmal ein anderes Thema (isConversionSupported und so...). Wobei ich mich mit den ganzen Mechanismen, die es rund um das große Thema "Codecs" herum gibt, nicht auskenne.
> 
> Ich fände eine Abstraktion von diesen ganzen Dingen schon praktisch. Und mit "Abstraktion" meine ich nicht, dass man nurnoch eine Methode hat wie "play(file)", und sonst nichts, sondern dass es eine allgemeine, abstrakte Repräsentation von Sounds geben könnte, zum Beispiel(!) ganz naiv(!) als eine Liste von FloatBuffern (für jeden Channel) mit Werten zwischen -1 und 1, und eine abstrakte Repräsentation eines Devices, dem man eine Liste von FloatBuffern geben kann, und die dann abgespielt werden. Damit die Frage, ob es nun irgendwann irgendwo, kurz vor dem Lautsprecher,  2-byte-unsigned-big-endian-PCM-Daten sein müssen, einfach ausgeblendet wird.
> (Ich weiß, dass es nicht so einfach ist, und in der beschrieben Form schon SEHR naiv vereinfacht und praxisfern, aber von der Idee her...)


Meines Erachtens sind die Codecs praxisfern, die bestimmen wollen, mit welchen Encodings die Widergabehardware klar kommen muss und deshalb MP3  in ihr Audioformat schreiben und dann nur Konvertierungen für MP3L3 usw. anbieten (JLayer macht das so). Ein entsprechendes PCM-Format kennt der FormatConversionProvider nicht obwohl der Codec selber mindestens eines unterstützt. Meine "ensurePCM"-Methode gibt es nur genau deswegen wieder. Ich hatte sie schon vorher in etwas abgeänderter Form und habe nur auf A- bzw. U-LAW geprüft, was aber dadurch überflüssig wurde, weil es für diese beiden Encodings entsprechende ConversionProvider gibt. Deine Idee (bis auf die Grenzen der Floatwerte... da ist man mit 0.0 - 1.0 besser bedient) aber ist praxisnah, leider auch anscheinend weltfremd. Ist wohl zu einfach, es so zu handhaben. Ich zumindest mache das so.


----------



## Marco13 (21. Aug 2012)

Hmja, ich hatte kürzlich auch ein bißchen mit Sound rumgespielt, und dabei ein paar Methoden/Klassen gemacht, die (wie wir schon in anderen Threads festgestellt hatten) wohl nicht ganz unähnlich zu deinen sind (und auf deinen Hinweis neulich hin hatte ich auch versucht, von -1...1 auf 0...1 umzustellen  aber ... das zusammen mit einigen weiteren "Generalisierungen" führte dann in einen sehr spziellen Arbeits-Ast...). Vielleicht können wir das ja irgendwann mal zusammenwerfen. Oder gibt's deinen Code schon irgendwo? War das ausschließlich zum Zusammenhang mit deiner IO-Bibliothek, oder als allgemeine Sound-Utilities gedacht?


----------



## Spacerat (21. Aug 2012)

Das gilt für sowohl als auch, ist ja generalisiert. Also ich selbst verwende diese Wandlung in Floats bisher nur noch ein mal bei 8-Bit-Samplen des Protracker2-Formats (frisch hochgeladen ). Da gibt es eine Klasse PT2_Sample und da findest du es in Zeile 126.
Generalisiert in Pseudocode sieht das dann so aus:

```
float sample = 0.0;
switch(bits) {
case 8:
  int sByte = sByte0 & 255;
  if(signed) {
    sample = (sByte + 128.0) / 255.0;
  } else {
    sample = sByte / 255.0;
  }
  break;
case 16:
  byte lo = (bigEndian)? sByte0 : sByte1;
  byte hi = (bigEndian)? sByte1 : sByte0;
  int sShort = (hi << 8 | lo) & 65535;
  if(signed) {
    sample = (sShort + 32768.0) / 65535.0;
  } else {
    sample = sShort / 65535.0;
  }
}
```
Die Rückwandlungen in unsigned Bytes bzw. Shorts sind nun recht trivial (sample * 255.0 bzw. sample * 65535.0). Für signed Bytes bzw. Shorts muss nur noch der Bias abgezogen werden (128.0 bzw. 32768.0). Shorts müssen dann nur noch in der richtigen Reihenfolge in den Stream geschrieben werden.
Wenn du es mal testen willst: hier noch Links zur DT_Lib und jeder Menge Modfiles


----------

