Edit the tags in a WAV file.
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
RIFF keeps its metadata in a LIST/INFO chunk: four-character ids
like INAM, IART and ICRD, which Windows
Explorer displays as Title, Artist and Date. OmniViewer lists every one as an
editable row with its plain-English name beside it, and lets you change, add or
remove them.
Clicking Download re-tagged copy rebuilds only the few hundred
bytes that sit in front of the data chunk and copies every sample
byte-for-byte after them. The audio is never decoded, never re-encoded and loses
nothing — which is also why it is instant on a file of any size.
Underneath the tags OmniViewer decodes the Broadcast Wave
(bext) record every field recorder and DAW stamps on a take:
description, originator, origination date and time, the timecode
time reference in samples, the SMPTE UMID, the EBU R128 loudness
figures and the coding history. Below that come the cue markers,
with the labels whoever edited the file gave them. Every row highlights its own
bytes in the hex pane beside it, so you can see exactly where each value lives.
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.