Diskussion:RIFF WAVE

message: In dem ganzen Beitrag steht kein Wort davon, daß WAVE den anderen Audioformaten bei vielschichtigem Sound ganz klar überlegen ist. Ich habe gerade anhand von Michelles Album "Nenn es Liebe oder Wahnsinn", das einen anspruchsvollen Synthi-Keyboard-Sound mit Dutzenden von Spuren hat, einen Vergleich angestellt: als AAC-Datei von iTunes klingen die Titel recht blechern, etwas besser ist die WMA-Lossless-Verschlüsselung. Mit ATRAC3plus klingt das Album sehr hart, mit WAVE dagegen habe ich einen breiten, süffigen, vielschichtigen Sound. Jede Soundspur setzt sich hier akustisch klar von der anderen ab. 
: WAV ist üblicherweise unkomprimiert, die anderen verlustbehaftet komprimiert .. --Ribo 19:41, 28. Jun 2006 (CEST)
thread_title:  Vergleich von WAVE mit AAC,ATRAC3plus und WMA 

message: Ich habe eine .wav Datei in der die Länge des 'fmt' headers = 18 ist. Damit sind die offsets im 'data chunk' nicht mehr wie beschrieben.
Gruß Ulrich 
:Ja, das musste ich auch feststellen. Das Problem ist wohl, dass der Artikel nicht deutlich genug hervorhebt, dass es sich hierbei nur um ein Beispiel handelt. So fügt z.B. schon soundrec32.exe von Windows XP (zusätzlich zum mit 18 Byte überlangen 'fmt'-Chunk) noch einen 'fact'-Chunk hinzu, womit dann zusätzlich Verwirrung gestiftet wäre. Um was es sich bei den zusätzlichen 2 Byte handelt, kann ich im Moment aber nicht sagen. -- 92.193.28.140 16:53, 31. Aug. 2009 (CEST)
thread_title:  spezielle Dateistruktur 

message: "8-Bit-Daten sind als unsigned char definiert (Wertebereich 0 bis 255), 16-Bit-Daten als signed short (Wertebereich -32768 bis 32767). Diese Inkonsistenz zwischen signed und unsigned ist ein Nachteil des WAV-Formats."
Das ist totaler Unsinn. Es würde bedeuten, dass bei 8-Bit Dateien keine negative Amplitudenwerte erlaubt sind (?!?!). 
Die Amplitudenwerte kommen in der Datei als eine Bitfolge vor, ob jetzt 10011111 als 159 oder als -97 INTERPRETIERT wird, ist kein Problem oder Nachteil des WAVE Formats, sondern der konkreten Anwendung. Es ist in dieser Hinsicht klar, dass die Bitfolgen, die für die Ampliudenwerte stehen, immer als SIGNED INTERPRETIERT werden sollen. - Nikolay Petkov, 7c0[at]mail.com
: das war in der Tat Unsinn.. gelöscht --Ribo 00:29, 9. Mai 2007 (CEST)
replies: text:  Dieser Unsinn steht in der RIFF-Spec von MS. Als 8-Bit-Auflösungen (und weniger!) aktuell waren, hatten die DA-Wandler eben typischerweise einen unipolaren Ausgang, z.B. 0-5V. Da für Audio-Anwendungen eh ein Koppelkondensator folgt, ist ein bei 2.5 V liegendes Ruhe(!)potenzial kein Problem. Wenn nun das eine Programm die leisen Werte 0 und -1 als signed char schreibt (0x00,  0xFF), das andere Programm jedoch korrekt unsigned liest, kommen 0 und 255 heraus, Vollaussteuerung! Auf dem entgegengesetzten Weg würde aus dem Ruhepegel (0x80) der extreme Wert -128. Du solltest den Unsinn also wieder einsetzen, bevor teure HW abraucht ;-) --Rainald62 19:05, 9. Nov. 2008 (CET)
thread_title:  8- und 16-Bit Dateien 

message: Im Artikel steht "Das WAV-Format verwendet die Little-Endian-Anordnung als Standard, wo das niedrigstwertigste Bit (LSB) an der ersten Stelle steht." Allerdings ist "Little-Endian" doch eher die Byte-Reihenfolge. Es müsste also das niedrigstwertige Byte an erster Stelle stehen.
Wenn es keine Gegenreden gibt, änder ich das einfach! 
------------
Gast: Und für alle, die des Englischen mächtig sind UND die noch etwas mehr allgemeinverständliches Lesen möchten, schauen bitte den entsprechenden englischen wki-Artikel an: http://en.wikipedia.org/wiki/WAV
Ich wollte wissen, was passiert beim Umwandeln von Audio Cd Daten in Wav Daten => da fand ich es. Gruß! also keine Qualitätseinbuße, was mir wichtig ist, da ich meine Audios in Wav umwandele, um sie auf DVD-Ram sicher langzeit zu lagern.
: du bist herzlich willkommen, fehlende infos einzufügen --Ribo 22:58, 14. Apr. 2008 (CEST)
thread_title:  Bit-Reihenfolge - Byte-Reihenfolge 

message: dwSamplesPerSec steht für die Anzahl der Samples pro Sekunde, also der Abtastrate in Hertz (Hz). dwAvgBytesPerSec bezeichnet die durchschnittliche Anzahl von Datenbytes pro Sekunde. Sie entspricht dem Produkt aus Abtastrate und Framegröße:
Wenn gilt: dwAvgBytesPerSec = dwSamplesPerSec * wBlockAlign
Müsste dann dwSamplesPerSec nicht eher die Anzahl der Frames pro Sekunde stehen und nicht der Samples? (bei Mono identisch, aber ansonsten ein Unterschied)
Die Anzahl der Kanäle ist ja in wBlockAlign bereits enthalten und demnach wäre diese ja so zweimal eingerechnet.
Gruß Cyf
: genau, dwSamplesPerSec ist die Abtastrate in Hz, geändert. Im Artikel steht Sample (jetzt) durchgängig für den Wert eines Kanals, für den Autor des zitierten Codes dagegen wohl für die Gesamtheit der Werte zu einem Abtastzeitpunkt, durch aus vertretbar (ein Sample ist dann eben ein Vektor). --Rainald62 18:12, 9. Nov. 2008 (CET)
thread_title:  dwSamplesPerSec 

message: Der Text (linksbündig) war korrekt, die Nummerierung der Bits (0-3, 4-15) auch, bloß das Bild hatte die Bits 0-3 vorne statt hinten, entfernt.
(Quelle: http://www.piclist.com/techref/io/serial/midi/wave.html, die Datei kommt vielfach im Web vor, wer weiß den Autor?). --Rainald62 18:12, 9. Nov. 2008 (CET)
thread_title:  Zero Padding ist hinter dem LSBit vorgesehen! 

message: Außerdem ist int ohne unsigned-Zusatz vorzeichenbehaftet, was die maximale Länge der Datei auf 2 statt 4 GB begrenzen würde (vgl. en.-Version). Habs an diversen Stellen durch unsigned long ersetzt. --Rainald62 18:12, 9. Nov. 2008 (CET)
replies: text: auch das ist Schnee von vorgestern. Entweder int32_t oder int16_t, alles andere ist mehr oder weniger Murks. (nicht signierter Beitrag von 2.207.139.101 (Diskussion) 22:01, 13. Mär. 2014 (CET)
thread_title:  sizeof(int) ist maschinenabhängig 

message: Ist leider weit verbreitet, dieser unglückliche Begriff, vgl. dagegen Bitfehlerrate, Geburtenrate usw.
Kommt zum Glück im Artikel Quantisierung nicht vor, Bit-Tiefe passt besser. In der Einleitung stehen gelassen, sonst ersetzt. --Rainald62 18:12, 9. Nov. 2008 (CET)
thread_title:  Quantisierungs''rate'' 

message: Die Angabe, dass zusätzliche Parameter hinter wFormatTag eingeschoben werden, war mir beim ersten Lesen gleich spanisch vorgekommen, habe ich aber mangels besseren Wissens nicht gleich korrigieren können. Inzwischen habe ich nicht bloß Forumsbeiträge über die Spezifikation gefunden, sondern deren Wortlaut selber, unter http://www.saettler.com/RIFFMCI/riffmci.html, und den Abschnitt entsprechend geändert. Andere Änderungen:
* ceil ist zwar mathematisch korrekt, klappt aber nicht als Code, wenn das Argument durch die Integer-Division schon abgerundet ist,
* Formeln also sinnvollerweise im code- statt math-Format,
* Chunks sind nicht linear aneinander gereiht, sondern geschachtelt
* diverse Kleinigkeiten
--Rainald62 16:05, 12. Nov. 2008 (CET)
thread_title:  Dateistruktur, speziell Beschreibung des Format-Chunks 

message: Erstens hat die IP ihren Edit nicht belegt. Zweitens passen Format-ID (0xFFE) und -Bezeichner ("extension header") nicht zu den bestehenden IDs (aufsteigend durchnummeriert) und Bezeichnern (in Großbuchstaben). Sieht so aus hätte ein Vendor die Anmeldeprozedur von MS umgangen. 3. Die einzige Quelle, die ich zu dieser ID gefunden habe (: "The MMA will maintain a registry of supported wFormatTags") zeigt, dass es nicht bloß um ein weiteres, spezielles Format geht, sondern um die generelle Umgehung des offiziellen Weges.
Natürlich kann jeder sein eigenes Format definieren, aber wenn es sich RIFF WAVE nennt, sollte es den Regeln entsprechen. – Rainald62 10:20, 29. Jan. 2009 (CET)
thread_title:  Revert von [http://de.wikipedia.org/w/index.php?title=RIFF_WAVE&diff=55956514&oldid=55414928 diff] 

message: Ich habe hier noch weitere Datenformat-Werte gefunden. Ich frage mich, worin sich z.B. die Typen 6 und 7 (Microsoft A-law/µ-law) von den Typen 101 und 102 (IBM µ-law/A-law) unterscheiden. Welches entspricht dem Format nach G.711? Oder kocht da wieder jeder sein eignes Süppchen und benennt es dann nur nach einem bekannten Standard, obwohl es nicht diesem entspricht? --RokerHRO 09:51, 1. Mär. 2010 (CET)
thread_title:  Weitere Datenformate -> Verwirrung. 

message: Der Einzelnachweis Thomas Höss und Tobias Rieck: WAV-Audio-Format, fmt-chunk  auf it.fht-esslingen.de ist auf dem Webserver nicht mehr vorhanden und es erscheint eine 404-Meldung! Soll der Link entfernt werden? 17:34, 20. Mai 2014 (CEST)
thread_title:  Toter Link 

message: – GiftBot (Diskussion) 22:45, 22. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekte Weblinks 

message: Ich versuche mich gerade in ein Spracherkennungsprogramm einzuarbeiten, das .wav-Dateien als einziges Eingangsformat akzeptiert. Eine der Anforderungen an die Dateien ist ferner, dass sie "little-endian" sein sollen. Ich habe ein wenig herumgesucht und herausgefunden, dass es sich dabei um die Byte-Reihenfolge handelt, in der die Daten gespeichert werden und habe bei meiner Suche den Eindruck bekommen, dass Little-Endianness eine inhärente Eigenschaft von .wav-Dateien sei -- nur traue ich mich noch nicht ganz diesen Schluss zu ziehen, da es dann ja keinen Sinn machte, dass die Spracherkennungssoftware ausdrücklich Little-Endianness forderte. ---->
Sind .wav-Dateien per se little-endian codiert?--Nix schlecht (Diskussion) 09:53, 30. Aug. 2017 (CEST)
replies: text: EDIT: Thema auch schon weiter oben, im Abschnitt Bit-Reihenfolge -- Byte Reihenfolge angeschnitten.--Nix schlecht (Diskussion) 09:57, 30. Aug. 2017 (CEST)
replies: text: Ich kenne mit mit wav im speziellen nicht so aus, kann aber sagen, dass quasi alle standardisierten, binären Datenaustauschformate entweder eine festgelegte Byte-Reihenfolge haben, oder diese am Anfang irgendwie codiert ist. Ansonsten wäre es ja z.B. nicht möglich, eine am PC erstellte wav-Datei mit dem Smartphone wiederzugeben.--Trockennasenaffe (Diskussion) 10:39, 30. Aug. 2017 (CEST)
thread_title:  little-endian