- RIFF WAVE
-
Waveform Audio File Format (WAVE) Dateiendung: .wavMIME-Type: audio/vnd.wave
audio/wav
audio/wave
audio/x-wavEntwickelt von: Microsoft & IBM Art: Audiodatei Erweitert von: RIFF Das WAVE-Dateiformat ist ein Containerformat zur digitalen Speicherung von Audiodaten, das auf dem von Microsoft für Windows definierten Resource Interchange File Format (RIFF) aufsetzt. Eine WAVE-Datei enthält vor den Audiodaten zumindest Informationen über deren Format.
Enthalten sind meist sogenannte PCM-Rohdaten, also eine zeit- und wertdiskrete Darstellung des zeitlichen Verlaufs eines Signals. Die Qualität des aufgezeichneten Klangs hängt dann von zwei Werten ab, der Abtastrate (Anzahl der Abtastungen pro Zeiteinheit) und der Auflösung (Bit-Tiefe); im Fall von komprimierten Daten auch vom Verfahren, z. B. ADPCM oder MP3.
Inhaltsverzeichnis
Dateistruktur
WAV-Dateistruktur
Das RIFF-Format besteht aus mehreren Abschnitten (engl. chunks)[1], die wie beim IFF aufgebaut sind, bis auf die Byte-Reihenfolge: niederwertiges Byte (LSB) voran. Die WAVE-Spezifikation definiert drei Abschnitte als verpflichtend: Der RIFF-Abschnitt identifiziert die Datei als .wav-Datei und enthält als Container die anderen Abschnitte. Der FORMAT-Abschnitt enthält Parameter wie z. B. die Abtastrate. Der DATA-Abschnitt enthält den Signalverlauf.
Im Laufe der unkoordinierten Entwicklung kam es zu einer unüberschaubaren Anzahl weiterer Abschnittstypen mit teils redundanten Inhalten. Ein Beispiel ist der „Label“-Abschnitt und „Note“-Abschnitt, die beide Cuepoint-Einträge im „Cue“-Abschnitt mit einer Beschriftung versehen. Dabei bezeichnet ein „Label“ den Titel eines Cuepoints, „Note“ einen Kommentar. Sie sind als Unterabschnitte (engl. subchunks) im übergeordneten Associated-Data-List-Abschnitt gespeichert. Des Weiteren gibt es eine Vielzahl von komprimierten Formaten, für die ein „Fact“-Abschnitt mit der dekomprimierten Größe verbindlich ist, die aber ansonsten unterschiedlichste Parameter definieren, was eine vollständige Unterstützung des WAV-Formats für Entwickler noch schwieriger macht.
RIFF-Abschnitt (auch „RIFF-WAVE“-Abschnitt)
Er enthält als Container die anderen Abschnitte, sein Header besteht lediglich aus
chunkID(char[4], "RIFF")ChunkSize(uint32_t, = Dateilänge in Bytes - 8)riffType(char[4], "WAVE")
„Format“-Abschnitt
Er beginnt mit der Kennung "fmt " und muss in der Datei genau einmal enthalten sein – und zwar als erster Unterabschnitt, worauf man sich aber genauso wenig verlassen kann wie darauf, dass der Daten-Chunk der letzte ist. Auf seine
ChunkSizefolgt der Inhalt, der aus einem Satz allgemeiner Parameter und einem nachfolgenden formatspezifischen Teil besteht. Der allgemeine Teil:wFormatTagIdentifizierung für das verwendete Format, z. B steht 0x0001 für PCM, das kanonische, unkomprimierte FormatwChannels(uint16_t)dwSamplesPerSec(uint32_t, Abtastrate in Hz)dwAvgBytesPerSec(uint32_t, nötige Übertragungsbandbreite)wBlockAlign(uint16_t, Größe der Frames in Bytes)
Für PCM-Daten hat der Format-Abschnitt nur noch dieses eine Feld:
wBitsPerSample(uint16_t, Quantisierungsauflösung, identisch für alle Kanäle)
Wird keine Kompression verwendet, ist
dwAvgBytesPerSecdas Produkt aus Abtastrate und Framegröße. Die Framegröße ergibt sich aus der Vorgabe, dass alle Werte im Daten-Abschnitt als Integer zu kodieren sind mit einer gerade ausreichenden Größe in Byte (eventuell nötige Füllbits stehen am niederwertigen Ende mit dem Wert 0). Für das PCM-Format giltwBlockAlign = wChannels * ((wBitsPerSample + 7) / 8)(Integer-Division ohne Rest),
sodass die Framegröße für 12-Bit-Stereo nicht drei sondern vier Byte beträgt.
„Data“-Abschnitt
Er hat die Kennung "data". Seine
chunkSizeenthält (wie bei allen Abschnitten) weder die 8 Bytes von Kennung und Größe noch eventuell ein am Ende zur vorgeschriebenen Ausrichtung auf Wortgrenzen nötiges Null-Byte. Sein Inhalt ist eine Folge von Frames.Im Fall von PCM-Daten enthält jeder Frame ein „Sample“ von Abtastwerten, einen pro Kanal. Bei zwei Kanälen (Stereo) wird erst der linke, dann der rechte Kanal gespeichert. Abtastwerte sind für Bit-Tiefen bis 8 als
unsigned charkodiert, sonstsigned int. Bei Bit-Tiefen, die nicht durch 8 teilbar sind, wird das niederwertigste Byte (LSB) rechts mit Nullen aufgefüllt (Zero-Padding). Das ergibt beispielsweise für den größten positiven 12-Bit-Wert „0x7FF“ die Bytefolge „0xF0 0x7F“.Dieses Format, ohne Header gespeichert, hat üblicherweise die Endung *.raw und setzt bei der Wiedergabe die Kenntnis von Abtastrate, Bittiefe und Byte-Reihenfolge voraus (letztere ist nur unter RIFF festgelegt, nicht für rohes PCM).
Die Größe des „Data“-Abschnitts im Datenformat PCM berechnet sich wie folgt: Pro Sekunde fallen
dwSamplesPerSecFrames zu jewChannelsAbtastwerten zu je ein oder zwei Bytes an. Für CD-Qualität (16 Bit stereo = 4 Bytes pro Sample, 44.100 Hertz) z. B. also etwa 10 Megabyte pro Minute (60 s · 44.100 Hz · 4 byte).Beispiel eines allgemein lesbaren WAVE-PCM-Formats
RIFF-Header:
Offset Länge (in byte) Inhalt 0 (0x00) 4 'RIFF' 4 (0x04) 4 <Dateigröße - 8> 8 (0x08) 4 'WAVE' Der fmt-Abschnitt beschreibt das Format der einzelnen Abtastwerte:
Offset Länge Inhalt Beschreibung 12 (0x0C) 4 'fmt ' Header-Signatur 16 (0x10) 4 <fmt length> Länge des restlichen fmt-Headers (16 byte) 20 (0x14) 2 <format tag> Datenformat der Abtastwerte (siehe separate Tabelle weiter unten) 22 (0x16) 2 <channels> Anzahl der Kanäle: 1 = mono, 2 = stereo; Mittlerweile sind auch mehr als 2 Kanäle (z. B. für Raumklang) möglich. ergänzt von [1] 24 (0x18) 4 <sample rate> Samples pro Sekunde (z. B. 44100) 28 (0x1C) 4 <bytes/second> Abtastrate * Frame-Größe 32 (0x20) 2 <block align> Frame-Größe = <channels> * ((<bits/sample>+7) / 8) (Division ohne Rest) 34 (0x22) 2 <bits/sample> z. B. 12 Der Daten-Abschnitt enthält die Abtastwerte:
Offset Länge Inhalt Beschreibung 36 (0x24) 4 'data' Header-Signatur 40 (0x28) 4 <length> Länge des Datenblocks 44 (0x2C) <block align> der/die erste(n) Abtastwert(e) <block align> der/die zweite(n) Abtastwert(e) … … Datenformate (Format-Tag)
ID Bezeichnung 0x0001 PCM 0x0002 MS ADPCM 0x0003 IEEE FLOAT 0x0005 IBM CVSD 0x0006 ALAW 0x0007 MULAW 0x0010 OKI ADPCM 0x0011 DVI/IMA ADPCM 0x0012 MEDIASPACE ADPCM 0x0013 SIERRA ADPCM 0x0014 G723 ADPCM 0x0015 DIGISTD 0x0016 DIGIFIX 0x0017 DIALOGIC OKI ADPCM 0x0020 YAMAHA ADPCM 0x0021 SONARC 0x0022 DSPGROUP TRUESPEECH 0x0023 ECHOSC1 0x0024 AUDIOFILE AF36 0x0025 APTX 0x0026 AUDIOFILE AF10 0x0030 DOLBY AC2 0x0031 GSM610 0x0033 ANTEX ADPCME 0x0034 CONTROL RES VQLPC 0x0035 CONTROL RES VQLPC 0x0036 DIGIADPCM 0x0037 CONTROL RES CR10 0x0038 NMS VBXADPCM 0x0039 CS IMAADPCM (Roland RDAC) 0x0040 G721 ADPCM 0x0050 MPEG-1 Layer I, II 0x0055 MPEG-1 Layer III (MP3) 0x0069 Xbox ADPCM 0x0200 CREATIVE ADPCM 0x0202 CREATIVE FASTSPEECH8 0x0203 CREATIVE FASTSPEECH10 0x0300 FM TOWNS SND 0x1000 OLIGSM 0x1001 OLIADPCM 0x1002 OLICELP 0x1003 OLISBC 0x1004 OLIOPR Einzelnachweise
- ↑ Resource Interchange File Format Services Spezifikation von Microsoft auf msdn.microsoft.com (engl.)
Literatur
- Born, Günter: Referenzhandbuch Dateiformate. 1990, Addison Wesley Longman, in diversen überarbeiteten Auflagen
- Born, Gunter: File Formats Handbook. 1995, ITP Boston
Weblinks
Wikimedia Foundation.
