Dann sagten sie: »Auf, bauen wir uns eine Stadt und einen Turm mit einer Spitze bis zum Himmel, und machen wir uns damit einen Namen, dann werden wir uns nicht über die ganze Erde zerstreuen.« (I. Mos. II,4)
Bei der technischen Umsetzung dieses Ausspruchs wurden die Babylonier bekanntlich von höherer Stelle mit der göttlichen Sprachverwirrung belegt. Für den Fremdsprachenunterricht ist also der Schuldige bereits gefunden! Was haben nun Zuse & Co. verbrochen, auf daß wir erneut mit einer Sprachverwirrung belegt wurden? Oder wie würden Sie das erschreckende Durcheinander an diversen Sampleformaten bezeichnen?
Für den, der nun ebenfalls verwirrt ist und sich immer noch nichts unter dem Thema dieses Artikels vorstellen kann, folgt eine kleine Definition: Sprache, Musik, eigentlich alle Geräusche kann man, entsprechende Hardware vorausgesetzt, zu einer »Kolonne« aus 0 und 1 digitalisieren. Auf gut Neudeutsch ist dieser Vorgang auch als »samplen« bekannt. Das Ergebnis nennt sich daher »Sample«. Dieses Sample kann mit einem Computer weiterverarbeitet, gespielt oder gespeichert werden. Und schon sind wir bei des Pudels Innenleben, dem Lesen von Sampeln in diversen Ablageformaten.
Die momentan auf »erschwinglichen« Rechnern verbreitetste Unterart dieser digitalen Tonkonserven dürften die PCM (Pulse Code Modulation) kodierten 8-Bit-Mono-Samples darstellen. Hierbei wird das Auf und Ab der Schallwellen in eine Folge von einzelnen Bytes zerhackt. Bei einer Samplefrequenz von 12,5 kHz wird die Amplitude 12500mal pro Sekunde abgetastet und das Ergebnis in einer 8 Bit großen Zahl festgehalten. Dabei fallen, nach unserem alten Rechenkünstler Adam R., in einer Sekunde etwa 12 Kilobyte Daten an. An und für sich ein recht simpler Vorgang, aber schon beginnt die Verwirrung: Die einen verwenden Werte von 0 bis 256, betrachten das Byte also ohne Vorzeichen (unsigned). Die anderen betrachten das Byte mit Vorzeichen (signed), nehmen also Werte von -128 bis +127. Der springende Punkt ist in diesem Fall das Bit Nummer 7.
Dank der »Erschwinglichkeit« des Falcon 030, breiten sich derzeit 16-Bit-Samples in der Atariwelt aus. Bei dieser Spezies zerlegt man die Schallwellen nicht mehr in 8-Bit-»Häppchen«, sondern zugunsten der Klangqualität in 16-Bit-»Bröckchen«. Die Amplitude darf sich jetzt innerhalb der Grenzen von 0 bis 65536 bzw. -32768 bis +32767 bewegen.
Für Stereo-Fans existieren sowohl bei 8-Bit- wie auch bei 16-Bit-Sampeln entsprechende Ableger. In der Regel liegen die 8- bzw. 16-Bit-Werte der beiden Kanäle einfach hintereinander.
Für ein Sample von einer Sekunde Dauer und einer Samplefrequenz von 12,5 kHz ergibt sich ungefähr folgender Speicherverbrauch:
8 Bit Mono —> 12 KByte
8 Bit Stereo —> 24 KByte
16 Bit Mono —> 24 KByte
16 Bit Stereo —> 48 KByte
Im Großen und Ganzen haben wir es also mit vier prinzipiellen Sample-Arten, dazu jeweils auch noch signed oder unsigned, also insgesamt acht Abarten zu tun. Beim Speichern der Tondaten in einer Datei, auf Diskette oder Festplatte, müssen wir aber natürlich auch noch andere Informationen wie Samplefrequenz, Stereo oder Mono oder Beschreibung beilegen. Wie sonst wüßte ein Sample-Player, mit welchen Parametern ein Sample aufgenommen wurde.
Um alle relevanten Daten in einer Datei zusammenzufassen, hängt man am sinnvollsten vor das eigentliche Sample einen Kopf mit eben diesen Informationen. Und genau dieser »Header« ist es, der uns die Verwirrung bringt, da man es bis dato nicht geschafft hat, einen wirklich systemübergreifenden Standard hierfür zu schaffen.
So existieren zig Formate, jedes mit seinen spezifischen Vor- und Nachteilen. Am sichersten erkennt man ein bestimmtes Format an den ersten Bytes der Datei, hier sind in der Regel eindeutige Kennungen abgelegt. Die Datei-Endungen (*.AVR, *.SMP usw.) sind leider nicht immer eindeutig. Um wenigstens die verbreitetsten Sounds anhören zu können, finden Sie auf der TOS-Diskette das Programm »SND_PLAY.APP«, ein universeller Sample-Player, lauffähig auf ST, STE, TT und Falcon030. Abgesehen von der Möglichkeit, auch unbekannte Formate laden zu können, versteht SND_PLAY folgende Formate automatisch:
AVR, 8/16 Bit Mono/Stereo, Offset 0, »2BIT«
Wurde ursprünglich von der A.V.R. PRO SERIES Software verwendet und soll sich laut Atari zum Standard entwickeln, doch dazu muß erst noch die Dokumentation endgültig feststehen.
SMP, 4/8 Bit Mono/Stereo, Offset 0,0x7E817E8112
Dieses Format stammt ursprünglich von den Galactic-Samplern. Es gibt hiervon wiederum zig Abkömmlinge!
SAM, 8 Bit Mono/Stereo, Offset 0, »STE.«
Wird hauptsächlich vom Artis-Soundeditor verwendet. Die Endung SND wird allerdings auch häufig von anderen Programmen verwendet.
HSN, 8/18 Bit Mono/Stereo, Offset 0, »HSND1.1
Das Format von CrazySounds. Dieses Format ist momentan das einzige auf dem Atari, in dem auch die Einstellungen für die DMA-Sound-Hardware wie z.B. Lautstärke, Höhen und Tiefen abgelegt sind. Da das HSN-Format auf den Autor dieses Artikels zurückgeht, sind die Header-Informationen in Tabelle 1 aus erster Hand.
IFF-8SVX 8 Bit Mono/Stereo, Offset 0, »FORM«, Offset 8, »8SVX«, Offset 12, »VHDR
Die IFF-Familie stammt eigentlich aus der AMIGA-Welt. Es gibt neben dem Sample-Format auch noch IFF-Formate für Bilder, Texte usw. Das 8SVX-Sound-Format wird allerdings auch von einigen Atari-Programm geschrieben.
»VOC«, 8 Bit Mono, Offset 0, »Creativ Voice File«
Ein komplexes Format aus der MS-DOS-Welt. In diesem Format kann ein Sample in unterschiedliche Blöcke zerlegt sein, SND—PLAY unterstützt davon folgende: 0 - End-Block, 1 - Sound-Block, 2 - Sub-Sound-Block, 3 - Silence-Block. Da es allerdings nur 8 Bit Mono beherrscht, wird es bald der Macht von WAV erliegen.
»WAV«, 8/16 Bit Mono/Stereo, Offset 0, »RIFF«, Offset 8, »WAVE«, Offset 12, »fmt«
Windows-3.1-Anwender kennen dieses Format, es stammt aus der MS-DOS-Welt und wird von Windows verwendet. Eigentlich ist es ein Abkömmling des IFF-Formats.
Unbekannte Formate werden einfach komplett in den Speicher befördert. Die entsprechenden Parameter können dann im Dialog experimentell ermittelt werden.
Offset | Beschreibung |
---|---|
0 | 20 Byte, die Kennung "HSND1.1" gefolgt von einer 0 und 12 weiteren beliebigen Byte |
20 | 4 Byte, die Länge des Samples ab dem Headerende in Byte |
24 | 2 Byte, die Abtastrate in Hz/10 |
26 | 2 Byte, 0„Mono, 1 „Stereo |
28 | 2 Byte, reserviert, bitte ignorieren |
30 | 2 Byte, 0 bis 8 kennzeichnen 8 Bit Samples, 16 kennzeichnet 16 Bit Samples |
32 | 2 Byte, reserviert, bitte ignorieren |
34 | 2 Byte, das DMA-Sound Lautstärkeregister 0-40 |
36 | 2 Byte, das DMA-Sound Register für Links 0-20 |
38 | 2 Byte, das DMA-Sound Register für Rechts 0-20 |
40 | 2 Byte, das DMA-Sound Register für die Höhen 0-12 |
42 | 2 Byte, das DMA-Sound Register für die Tiefen 0-12 |
44 | 4 Byte, reserviert, bitte ignorieren |
48 | 41 Byte, 40 Zeichen Text + 1 Null-Byte |
Tabelle 1. Der Header eines Samples am Beispiel von Crazy Sounds
Da es den Rahmen sprengen würde, ausführlich auf jedes Format einzeln einzugehen, haben wir Ihnen die Arbeit abgenommen. Auf der TOS-Diskette wartet das C-Listing »LOAD_SND.C« auf entsprechende Verwendung.
Die Haupt-Funktion »int load_sound(SOUNDINFO *sin, char *path)« liest die erwähnten Sample-Formate komfortabel ein und füllt im Erfolgsfalle die in »sin« übergebene Struktur mit den entsprechenden Werten und liefert ein positives Ergebnis zurück, das Auskunft über den gefundenen Sample-Typ gibt.
typedef struct
{
char name[20]; // Dateiname des Samples
long laenge; //Die Länge in Bytes
int frequenz; //Die Frequenz/10
int stereo; / / TRUE = Stereo, FALSE = Mono
int bitsps; // Bits pro Sample (8bzw. 16)
char *anfang; //Zeiger auf den Beginn des Samples
}SOUNDINFO;
Soll ein bestimmtes Sample geladen werden, muß sein kompletter Pfadname (etwa »c:\samples\boing.wav«) in »path« stehen. Um die Wahl des Samples dem Anwender zu überlassen, darf path auch NULL sein. In diesem Falle verwendet load_sound() zum Zwecke der Anwenderbefragung die Funktion »fselect()«. Nach Möglichkeit werden die Samples als signed geliefert, da dies das natürliche Format der STE-, TT- und Falcon-Hardware ist. Im Zweifelsfalle wandelt die Funktion »change_vorz()« von signed nach unsigned und zurück.
Natürlich kümmert sich load_sound() um den benötigten Speicher bzw. gibt den bereits allokierten beim Laden eines neuen Samples wieder an das Betriebssystem zurück. Um zu erkennen, ob ein Sample bereits im Speicher steht, beachtet load_sound() »sin-an-fang«. Ist der darin enthaltene Wert gleich NULL, fordert die Funktion nur neuen Speicher an. Bei einem Wert ungleich NULL, wird dieser als Zeiger auf den freizugebenden Speicherblock interpretiert. Um mehrere Samples gleichzeitig im Speicher zu halten, empfiehlt es sich daher, vor jedem erneuten Aufruf von load—soundO die Struktur »sin« zu sichern und wieder mit NULL zu initialisieren.
Bei eventuell auftretenden Fehlern (nicht genug Speicher und ähnliche), sorgt load_sound() zunächst für entsprechende Fehlermeldungen, schließt danach alle Dateien und gibt FALSE zurück.
Wenn Sie Bequemlichkeit schätzen, sollten Sie SND_PLAY.APP in Ihrem Desktop auf die Endungen der entsprechenden Samples anmelden. Ein Doppelklick auf ein Sample genügt dann, um SND—PLAY zu starten.
Im Kasten, direkt unter dem Namen des geladenen Samples, stehen die originalen Werte des Samples. Bei unbekannten Sample-Formaten oder zum Erzeugen von Effekten, kann es unter Umständen nützlich sein, die vorgegebenen Werte durch Anklicken der Felder zu verändern. Eventuell finden Sie die Frequenz des Samples auch gar nicht unter den Werten von »Wiedergabe«, da die STE/TT/Falcon-Hardware nur bestimmte Frequenzen abspielen kann. Keine Panik, der Button »Frequenz« unter »Rechnen« transformiert es auf die gewählte Wiedergabefrequenz.
Sollte ein Sample sehr verrauscht und/oder krächzend klingen, kommt »Format« zum Einsatz. Mit diesem Button wandeln Sie das Sample von signed nach unsigned bzw. umgekehrt. Vor der Verwendung von »Frequenz« sollte das Sample unbedingt im richtigen Format (signed) vorliegen, da sonst die Umrechnung der Frequenz in die Hose geht! Einfach munter ausprobieren.
Bei der Gelegenheit möchte ich noch daran erinnern, daß der Falcon aus technischen Gründen keine 6,25-kHz-Samples abspielen kann. Damit aber wenigstens etwas zu hören ist, verwendet SND_PLAY.APP in diesem Falle 12,5 kHz - lieber zu schnell als gar nicht. Die Buttons im Kasten »Spielen« sollten sich eigentlich von selbst erklären, abgesehen vielleicht von der »ankreuzbaren« Box vor »DMA«. Rechner mit DMA-Sound können darauf verzichten und sich so in die Niederungen des »normalen« ST begeben. In diesem Fall muß der Soundchip als D/A-Wandler herhalten. Da Ihr Rechner auch ohne Verwendung des DMA-Playback weiterläuft, verbraucht dieses Verfahren reichlich Rechenzeit. Bewegen Sie die Maus zu heftig, »verzieht« das Sample, und als Symptom totaler Überlastung kann sich auch Ihre Tastatur verselbständigen. Ein Druck auf irgendeine Taste wirkt allerdings beruhigend. Auch warnt SND_PLAY, wenn es Ihren Rechner für zu langsam hält. Die Geschwindigkeit Ihres Rechners geben Sie im Menü »Optionen« bitte unter »Geschwindigkeit« ein. Als Faustregel, um sich auf der sicheren Seite zu bewegen, gelten erfahrungsgemäß folgende Grenzen:
8 Mhz = 12,5 kHz
16 Mhz = 25,0 kHz
schneller = 50,0 kHz
Die restlichen Funktionen von SND_PLAY bedürfen keiner Erklärung. Viel Spaß beim Ausprobieren. (ah)