Look inside the RIFF container.
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
Every WAV is a chain of chunks: a four-character id, a 32-bit length, that many
bytes. The CHUNKS tab prints all of them in file order with the
exact byte offset and size of each, and a line saying what it is actually for
— fmt and data, of course, but also the
bext broadcast record, the LIST/INFO tags, the
cue markers and their LIST/adtl labels, the
fact sample count, the JUNK padding a writer left so a
later edit would not have to move the audio, and the private chunks Pro Tools,
Logic and ACID quietly leave behind.
RIFF sizes are 32-bit, so a WAV past 4 GiB cannot describe itself. The tab
flags a chunk whose declared length runs past the end of the file and says which
rule it fell back on — an RF64 ds64 chunk carrying the real
64-bit sizes, a 0xFFFFFFFF or zero length meaning “read to the
end”, or a size that has simply wrapped. Wave64 files, with their 16-byte
GUID headers, are walked the same way.
The walk uses the length in the data header to step over the
audio and land on whatever a writer appended after it, so listing the chunks of a
20 GB session file costs two small reads rather than 20 GB of them.
It’s one lens on OmniViewer’s WAV Viewer — Spectrogram & Tags: drop a file and every tab is one click away. OmniViewer opens every file format, entirely in your browser — no upload, no server.
No. OmniViewer is a static page with no server-side processing: your WAV is read directly by your browser and never leaves your computer. The spectrogram is computed locally, and even the re-tagged download is assembled from byte slices of your original file.
Drop the file and open the SPECTRUM tab. OmniViewer reads the PCM samples and runs its own FFT over them to draw the picture — nothing is uploaded, and it works on a file of any length. You can choose the transform size (512 to 8192 samples), the window function, which channel to analyse, how far down the dynamic range goes and the colour ramp; hovering reads out the time, frequency, nearest musical note and level under the cursor; dragging sideways zooms into a time range; and "Save PNG" downloads the picture.
A chain of chunks. Each is a four-character id, a 32-bit length and that many bytes. The whole file is one RIFF chunk whose body starts with the form type WAVE; inside it, the "fmt " chunk says how the samples are encoded and the "data" chunk holds them. Everything else — LIST/INFO tags, a bext broadcast record, cue markers, padding, private chunks a DAW wrote — is description hung off the side, and the CHUNKS tab lists all of it with offsets, sizes and an explanation of what each one is for.
Because every size field in RIFF is 32 bits, which stops at 4 GiB. Three answers exist and OmniViewer reads them all: RF64/BW64 puts the real 64-bit sizes in a ds64 chunk; Sony Wave64 uses 16-byte GUIDs and 64-bit lengths; and many writers simply emit a plain RIFF whose data size is zero, 0xFFFFFFFF or has wrapped, leaving the reader to work out that the audio runs to the end of the file. When that happens OmniViewer says so rather than truncating the file at whatever the header claimed.
Open the METADATA tab. It lists the LIST/INFO tags as editable rows — Title (INAM), Artist (IART), Date (ICRD), Comment (ICMT), Engineer (IENG) and any other four-character id — and you can change, add or remove them and click "Download re-tagged copy". Only the bytes in front of the data chunk are rebuilt; every sample is copied byte-for-byte, so the audio is not re-encoded and loses nothing.
It is the Broadcast Wave extension, EBU Tech 3285 — the record a field recorder, DAW or broadcast system stamps on a take. It carries a free-text description, the originator and an originator reference, the origination date and time, a time reference in samples (the timecode position the recording starts at), optionally a SMPTE UMID, the EBU R128 loudness measurements, and a coding history describing what was done to the audio. OmniViewer decodes all of it and points each field at its own bytes; it is shown read-only, because the fields people actually change live in the LIST/INFO tags above it.
Effectively unlimited. Reading the structure never touches the audio: the chunk walk uses the length in the data header to step over it, so opening a file, reading its tags and listing its chunks costs two small reads whatever the size. The spectrogram is bounded the same way — above 64 MB of audio each column is one small read at its own computed byte offset, so the whole picture costs a few megabytes of reading on a 20 GB file.
Browsers only decode a subset of what a WAV can legally contain — in practice 8- and 16-bit PCM. A 24-bit or 32-bit float file, or one using A-law or µ-law, may be refused by the audio element even though the file is perfectly valid. OmniViewer says so plainly when that happens, and it changes nothing else: the SPECTRUM, METADATA, CHUNKS, STATS and HEX tabs decode the samples and read the container themselves, so they all still work.
Almost always, yes: the usual contents are uncompressed PCM samples, so nothing has been thrown away. But "WAV" is a container, not a codec — the fmt chunk can legally declare IMA or Microsoft ADPCM, GSM 06.10, A-law, µ-law or even an MP3 stream in a WAV wrapper, all of which are lossy. OmniViewer names the actual codec from the format tag rather than assuming, so you can tell a genuinely lossless file from one that is only shaped like one.