Read a WAV byte by byte.
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
The HEX tab is a virtualised byte window over the file: it opens a
multi-gigabyte recording as fast as a small one because it only ever reads the part
you are looking at. Useful when a WAV will not open anywhere and you need to see
whether the RIFF magic, the WAVE form type or the
fmt chunk is where it should be.
The first twelve bytes are RIFF, a 32-bit length and WAVE.
The fmt chunk follows almost immediately: format tag, channel
count, sample rate, byte rate, block align and bit depth, all little-endian. The
CHUNKS tab gives you the offset of every other chunk, and the
METADATA tab highlights the bytes behind each individual tag,
so you rarely have to count.
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.