Diskussion:RIFF WAVE

Überarbeitung nötig

"Was ist eine Audiodatei" gehört nicht in diesen Artikel, genausowenig Erläuterungen über das Prinzip von PCM - dazu gibt es einen eigenen Artikel (Puls-Code-Modulation). --Speck-Made 20:39, 24. Sep 2005 (CEST)

........ zudem sollte mal die deutsche grammatik (besonders in den ersten sätzen) überarbeitet werden! (nicht signierter Beitrag von 62.104.115.250 (Diskussion) 18:48, 4. Okt. 2005 (CEST))

Jap. Ausserdem find ich den ganzen Artikel für einen Laien zu kompliziert. Also ich kenn mich ein bisschen aus mit Computern, wenn ich das aber lese hab ich keine Ahnung von was dahier gesprochen wird. (nicht signierter Beitrag von 83.65.25.235 (Diskussion) 17:14, 21. Nov. 2005 (CET))

Nicht meckern - verbessern :) --Afogel 01:24, 31. Dez 2005 (CET)

Was erwartest du dir denn? Wenn du Fragen hast, bitte poste sie doch hier. Dann können wir die offenen Punkte in den Artikel einbauen. --Ribo 18:53, 2. Jan 2006 (CET)

Der kurze Artikel liefert alle wesentlichen Informationen, die ich lange suchte, eine Wav-Datei zu verstehen. Prima! (RoSo 2.Jan.06) (nicht signierter Beitrag von 172.180.243.136 (Diskussion) 18:38, 2. Jan. 2006 (CET))

Also ich finde den Artikel gelungen. Ich glaube kaum, dass sich Leute über die Herkunft dieses Formats gedanken machen wenn es sie nicht wirklich interessiert. Für mich ist der Informatik Anteil zwar recht hart, aber alles Allgemeine wurde ja vorher gesagt. Nur eine Frage, zu den sich neu eröffneten, blieb unangesprochen. Was ist der Unterschied zwischen RIFF-Wave und Broadcast-Wave? Mir begegnen diese Beide öffter in Audioprogrammen und ich weiß nicht ob sie in ihrer Kompartibilität oder Qualitat unterschiedlich sind. (marco) (nicht signierter Beitrag von 84.59.13.209 (Diskussion) 19:54, 17. Jan. 2006 (CET))

Finde auch, das der Artikel vieles hat, was so manchen Büchern fehlt: Er bringt die Tatsachen gut verständlich auf den Punkt (genaue Spezifikation des Fromats) ohne groß drumrumzureden. Dabei wird alles kurz und knapp, jedoch verständlich erklärt; auch weil Begriffe wie PCM gleich mit erklärt werden und der Laie sich nicht erst durch andere Artikel wühlen muss, um diesen zu verstehen. Programmiere selbst und fand diesen Artikel damals einfach nur genial, weil keine Fragen aufgekommen sind. (nicht signierter Beitrag von 84.56.112.74 (Diskussion) 19:24, 15. Sep. 2006 (CEST))

Noch was zu Broadcast-Wave: Das sind einfach die Daten ohne den RIFF-Header. Der Player muss also das Format der Daten kennen um diese richtig abspielen zu können. Wenn die Daten unkomprimiert sind, gibt es AFAIK keinen Qualitätsunterschied. (nicht signierter Beitrag von 84.56.112.74 (Diskussion) 19:26, 15. Sep. 2006 (CEST))

na das nenn ich doch ein schönes comment zum WAV Kapitel in meiner Diplomarbeit ;) --Ribo 17:21, 16. Sep 2006 (CEST)

also ich kenne broadcast-wave als wave datei, die einen timestamp enthält, d.h., ein in einer DAW aufgenommenes file kann mittels SPOTfunktion an den zeitpunkt seiner aufnahme geschickt werden. das konnten früher nur die sd2-files von protools unter macOS, die aber nicht mit anderen DAWs kompatibel, geschweige denn plattformübergreifend waren. broadcast wav war da eine große entspannung. ich hab aber keine ahnung, wie das unter der haube aussieht, darum schreib ich das nicht in den artikel. wäre toll, wenn das jemand täte, der davon wirklich ahnung hat. --Punne (Diskussion) 00:11, 23. Apr. 2012 (CEST)

wBlockAlign = wChannels * (WBitsPerSample mod 8) ?

Kann das sein? Dann wäre ja WBlockAlign=0, falls WBitsPerSample = n*8 ist. Muss da nicht eher sowas wie

wBlockAlign = wChannels * ceil(WBitsPerSample / 8) stehen? --80.137.55.107 14:44, 6. Apr 2006 (CEST)

Die Geschichte des BlockAligns ist eine Geschichte voller Missverständnisse. Der Blockalign ist die Framegröße, nicht die Anzahl der ungenutzten Bit pro Frame. Daher ist deine Anmerkung vollkommen richtig. Innerhalb der letzten vier Jahren muss das auch schon jemand korrigiert haben. Weiter unten im "Beispiel" steht aber:

<channels> * (<bits/sample> / 8) (Division ohne Rest)

Das ist natürlich nur dann richtig, wenn die Bit/Sample durch 8 teilbar sind. Nebenbei wird aber dort noch bemerkt, dass die Bit/Sample nur genau 8, 16 oder 24 sein können. Was ist denn nun richtig? --84.60.99.77 19:20, 23. Mai 2010 (CEST)

Unterschied zwischen mp3 und wav

Wo ist der Unterschied zwischen .mp3- und .wav-Formaten am PC? 80.171.69.152 15:15, 9. Jun 2006 (CEST)- und wie kommt's, dass ich nicht mit meienm Namen unterschreibe sondern mit dem von dem einen Benutzer?

MP3 wurde vom Frauenhofer Institut für integrierte Schaltungen (IIS) in Erlangen (bei Nürnberg) entwickelt, mit dem Ziel einer möglichst starken Datenreduktion ohne höhrbare qualitative verluste. -> Wikipedia Artikel "mp3" (nicht signierter Beitrag von 84.56.112.74 (Diskussion) 19:17, 15. Sep. 2006 (CEST))

Und WAV kann sogar MP3 enthalten. Wenn ich bloß wüsste, wie ich den WAV-Container entferne :o – 20:59, 5. Nov. 2006 (CET)

Vergleich von WAVE mit AAC,ATRAC3plus und WMA

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. (nicht signierter Beitrag von 85.178.10.88 (Diskussion) 00:51, 28. Jun. 2006 (CEST))

WAV ist üblicherweise unkomprimiert, die anderen verlustbehaftet komprimiert .. --Ribo 19:41, 28. Jun 2006 (CEST)

Dublette "CONTROL RES VQLPC"

In der Tabelle "Sample Datenformate (Format Tag)" ist der Wert "CONTROL RES VQLPC" als Duplikat sowohl dem Code "0x0034" wie auch "0x0035" zugeordnet. Laut http://hul.harvard.edu/jhove/wave-hul.html muss der Wert für "0x0035" "Digireal" heißen.

Grüße, Jürgen

(nicht signierter Beitrag von 141.3.49.176 (Diskussion) 01:52, 17. Jul. 2006 (CEST))

spezielle Dateistruktur

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 (nicht signierter Beitrag von 62.226.207.71 (Diskussion) 18:12, 9. Dez. 2006 (CET))

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)

8- und 16-Bit Dateien

"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

(nicht signierter Beitrag von 84.238.200.132 (Diskussion) 23:24, 8. Mai 2007 (CEST))

das war in der Tat Unsinn.. gelöscht --Ribo 00:29, 9. Mai 2007 (CEST)

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)

WAV oder Wav?

Schreibt man abgekürzt eigentlich eher WAV oder Wav? Momentan wird im Artikel WAV verwendet. Ein echtes Akronym ist WAV ja eigentlich nicht... (nicht signierter Beitrag von 84.176.104.198 (Diskussion) 19:37, 25. Mai 2007 (CEST))

Länge der Sample-Data

<bits/sample>/8? Ist das nicht ein bisschen wenig? Bei 8 bits/sample sind das gerade mal 1 Byte für die Sample-Daten. Oder irre ich mich? (nicht signierter Beitrag von 84.160.37.128 (Diskussion) 22:53, 28. Dez. 2007 (CET))

wie kann ich Wav Datein auf meinem Computer testen?

ich hab hier im Wiki nichts darüber gefunden wie ich Wav Datein auf meinem PC darauf testen kann ob die wirklich Verlustfrei sind oder doch Mp3 Herkunft sind. kann mir da wer weiterhelfen? vielleicht mit Programm und Anleitung? auCDtect funktioniert nicht bei mir. hab jetzt schon stundenlang versucht das hinzubekommen. mfg Sven (nicht signierter Beitrag von 91.64.33.120 (Diskussion) 09:55, 12. Jan. 2008 (CET))

Bit-Reihenfolge - Byte-Reihenfolge

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! (nicht signierter Beitrag von Delilahblue (Diskussion | Beiträge) 08:35, 14. Jan. 2008 (CET))

---

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.

(nicht signierter Beitrag von 134.76.41.213 (Diskussion) 16:49, 14. Apr. 2008 (CEST))

du bist herzlich willkommen, fehlende infos einzufügen --Ribo 22:58, 14. Apr. 2008 (CEST)

dwSamplesPerSec

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

(nicht signierter Beitrag von 93.129.17.252 (Diskussion) 21:17, 10. Okt. 2008 (CEST))

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)

Zero Padding ist hinter dem LSBit vorgesehen!

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)

sizeof(int) ist maschinenabhängig

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)

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))

Quantisierungsrate

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)

Dateistruktur, speziell Beschreibung des Format-Chunks

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)

Revert von diff

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 ([1]: "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)

Weitere Datenformate -> Verwirrung.

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)

ID3?

RIFF WAVE "sollte" keine ID3-Daten enthalten können, das ist korrekt. Aber warum sollte das bei AIFF möglich sein? AIFF hat eine eigene Art und Weise, Metadaten zu speichern, und die hat WAVE ebenfalls. Es ist sehr wohl möglich, Daten wie Autor, Veröffentlichungsdatum, Titel, etc... in einer WAVE-Datei abzuspeichern! (nicht signierter Beitrag von 95.88.54.133 (Diskussion) 23:17, 31. Mär. 2014 (CEST))

Gute Frage: Wie geht das mit den Meta-Daten? Der vorhin eingesetzte Link scheint zu helfen, in dieser Richtung etwas herauszufinden, aber ich habe gerade die Muße dafür nicht. Hier der Link:

In Audacity unterstützte Metadaten-Formate (engl.).

Ich werde ihn gleich aus dem Artikel rausnehmen, weil ich nicht weiß, was er (für den Leser) in diesem Artikel soll. Immerhin ist es ja kein Artikel über Audacity. -- Pemu (Diskussion) 00:06, 26. Dez. 2016 (CET)

Toter Link

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) (ohne Benutzername signierter Beitrag von Danbru1211 (Diskussion | Beiträge))

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
• http://www.it.fht-esslingen.de/~schmidt/vorlesungen/mm/seminar/ss00/HTML/node116.html
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.it.fht-esslingen.de/~schmidt/vorlesungen/mm/seminar/ss00/HTML/node116.html

– GiftBot (Diskussion) 22:45, 22. Nov. 2015 (CET)

little-endian

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)

EDIT: Thema auch schon weiter oben, im Abschnitt Bit-Reihenfolge -- Byte Reihenfolge angeschnitten.--Nix schlecht (Diskussion) 09:57, 30. Aug. 2017 (CEST)

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)