Drop a WAV file. Any size.
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 & FAQEvery WAV tool can tell you a file is 48 kHz, 24-bit, stereo. None of that tells you whether the take has mains hum in it, whether the “lossless” file you were sent is really an MP3 someone decoded back to PCM (the giveaway is a hard shelf where the encoder threw the top octave away), or where the clipping is. That is a picture, and OmniViewer’s SPECTRUM tab draws it: a spectrogram of the whole file, computed here, from the file’s own samples, by an FFT written for this page — no upload, no plugin, and not the browser’s own analyser, which can only look at audio while it plays. Choose the transform size and window, read a frequency and a musical note off any point, drag sideways to zoom into a moment, and save the picture as a PNG.
A WAV is the one audio format with no frames, no index and no entropy coding: the
data chunk is raw samples, one after another, and a sample frame is
always channels × bytes per sample long. So the byte at any moment is
a multiplication rather than a search — and a spectrogram column five hours
into a recording costs the same single small read as one five seconds in. Reading
the file’s structure never touches the audio at all: the chunk walk steps
over the data chunk using the length in its header, so a
multi-gigabyte session file opens in two reads. Read
why a WAV file can’t be bigger than 4 GB — and what everyone does about it.
RIFF keeps its metadata in a LIST/INFO chunk — the
INAM/IART/ICRD fields Windows Explorer shows
as Title, Artist and Date. The METADATA tab edits them and
downloads a re-tagged copy by rebuilding only the few hundred bytes in front of
data; every sample is copied byte-for-byte, so the audio is never
re-encoded and the download is instant at any size. Beside them it decodes the
Broadcast Wave (bext) record every field recorder and
DAW stamps on a take — originator, origination date and time, the timecode
time reference, the EBU R128 loudness measurements and the coding
history — and the cue markers from the cue
and LIST/adtl chunks, with the labels whoever edited the file gave
them. Every row points at its own bytes in the hex pane beside it.
Every size field in a RIFF file is 32 bits, so a WAV cannot honestly describe
itself past 4 GiB — and a day of 24-bit 96 kHz stereo is fifty. The
industry answered three incompatible ways, and OmniViewer reads all of them:
RF64/BW64 (EBU 3306, which moves the real sizes into a
ds64 chunk), Sony’s Wave64 (16-byte GUIDs and
64-bit lengths), and the commonest case of all — an ordinary
RIFF whose data size is zero, 0xFFFFFFFF, or
simply wrapped. Where the header is wrong, the CHUNKS tab says so
in as many words and reads the audio to the end of the file, which is what every
real decoder quietly does. Detection is by the file’s own magic bytes, never
the extension. Powered by the same engine as
fastjsonviewer.com and
hugecsv.com; OmniViewer opens
every file format.
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.