Plea for WAV support

(Sorry not to attach this to the original thread - for some reason forum search WAV doesn't find it).

May I ask again for WAV support to be considered? With storage so cheap, WAV is becoming my format of choice for many projects because it is by far the fastest in editor open and save. My only problem with WAV is lack of Mp3tag support.

Perhaps if there other like-minded users who would contribute to the development cost? I'll start it off with a pledge of 50euro.

I would also pay 50 euro too of course.

Until today I'm using Tag & Rename - and still have to - because it supports ID3 tags in WAV files - but it isn't as good as mp3tag ...

I would be very happy if I could tag 99 % of my collection :wink: (no joke).


ID3 tags in WAV files

I need interop with MediaMonkey and GoldWave WAV tagging, but a binary view of a smaple WAV does not show anything like ID3 tags...

Ok, I don't have the software above installed but I'm sure you mean the WAV / fmt tags as described here:
(exif tool - not tested):
or here

I've installed Sony Sound Forge 9.0e last night and noticed that it allows a lot of .wav tags (open a wav file, select file / properties / summary / extended) described in the link above - incl. some T* tags. I didn't have time to take a deeper look into it (hexdump),

but I've noticed during the opening of a .wav incl. ID3 tags (from Tag & Rename 3.5 Beta 5) an error that the embedded information is bad. If Sound Forge has a bug or the .wav file with the ID3 tags edited with Tag & Rename must be analyzed (but I think T&R has a bug because Serato Scratch Live also cries about a bad file ... that's why I would love if mp3tag could handle that :slight_smile: ).

Of course - mp3tag should support:

  • the original tags of the fmt block
  • an additional id3 block with the id3 tags ...

and MediaMonkey and GoldWave should support id3 tags from .wav files :wink:


PS: I don't want but I'll install iTunes for testing the id3 tags in wav files.

I'm sure you mean the WAV / fmt tags as described here:

I meant only what I said :wink: but yes indeed the tags I see look like the I* tags of Thanks for posting that.

Of course - mp3tag should support:

  • the original tags of the fmt block
  • an additional id3 block with the id3 tags ...

Where's the need for non-standard tags such as ID3 to go in a separate block?

ID3 is a standard (ok - it could be much better but ...).

Technically it's possible to have 2 or more tag families in WAV files (WAV Info Tags & the ID3v2 Tags) - as in MP3 files (ID3v2 & ID3v1) - and who knows - sooner or later we might have a new formatting system e.g. ID4 or whatever.

Every tag familiy is a "string" like (very basic):

"ARTIST=abc|TITLE=xyz" or "<art>abc</art><tit>xyz</tit>"

So it is not important in which file format it is stored - it only should have a place / the main file format must support this kind of logic to store "blocks" (which e.g. WAV or RIFF is doing that perfectly).

It's also important that other software which can not display a tag family should save the whole "string" and write it back (when it writes back the whole file). It MUST do it with every block - it doesn't matter if it is a ID3 tag block or other internal information block from e.g. a Sound Forge 9 or Wavelab or MusicMaker etc.

So why shouldn't ID3 tags not stored as a block in WAV files too?

Note: ID3 supports more tags as the original INFO block - that's why an ID3 block would be much better.

More info soon in this forum.


PS: So the only one thing: write an email to all software developers if their product doesn't support ID3 in WAV files. I'll do that soon with Soundforge 9, RealPlayer, etc. the more software support this kind of block in a WAV file, the better it is.

PS: The other great advantage of ID3 would be Unicode - as far as I know the other tag families don't support Unicode.

I don't see how using ID3 tag frame names in WAV INFO chunks has any bearing on the Unicode issue.

Though it would be certainly nice to find a solution to the requirement. And one better than e.g. MediaMonkey - it just puts Unicode in the regular ASCII chunks, breaking compatibility.

Technically it's possible to have 2 or more tag families in WAV files
(WAV Info Tags & the ID3v2 Tags)

Not compliant with the WAV spec.

So why shouldn't ID3 tags not stored as a block in WAV files too?

Because such non-compliance would break compatibility.

The WAV standard provides for custom INFO chunks. That's where ID3-style tags should go.

No no no - that's not true:

e.g. please read:
go to the bottom - read the notes - 4th line:

There may be additional subchunks in a Wave data stream. If so, each will have a char[4] SubChunkID, and unsigned long SubChunkSize, and SubChunkSize amount of data.

There also exist other subchunks like "PAD " (which is a filler to hold place which could save time when you re-write the previous chunks without re-writing the whole (great) wav file!

Also the subchunk "bext", Sound Forge uses this after the subchunk LIST which contains additional data: (page 7).

or the newer tagging subchunk "CART" or

No No No - e.g. non-compliance happens because bad programmed applications (read: go to the bottom and read "Format Variations" ...

So when an application like mp3tag can write LIST or/and ID3 it would be good. It depends on other application settings by the user which tags should be used or e.g. menu functions like "copy LIST tags to ID3 tags" or vice versa.

Other subchunks must be respected by other software - so there is no compatibility break - only bad programmed software!

So - test it:

I've just imported a track with Wavelab5 and added some info for Artist / Title, etc.

After a hexdump I could found these subchunks: "fmt ", "PAD ", "data", "LIST" ("INFO"), "bext".

After that I've started Tag & Rename 3.5 beta 5 (which does not support the "LIST" tags and e.g. autofill the ID3 tags when they are not there ...) and added some info for Arist / Title, etc.

After a hexdump I could found these subchunks: "fmt", "LIST" ("INFO"), "bext", "PAD ", "data", "id3 "

=> so the info about artist / title is stored twice in this case and the "same logical" tags could have different data. (so mp3tag may support a function like "copy LIST tags to ID3 tags" and/or "delete LIST tags when writing ID3 tags", etc. (same as for ID3v1/ID3v2).

  1. When you try to re-open the file with Wavelab 5 it would crash because it is bad programmed. Wavelab 6 (after a specific subversion - I think 6.06) it works correctly and they have fixed this bug reading correct RIFF files.

  2. Open the wav file with Soundforge 9.0 (here it works correctly) ... change the (LIST) tags - save the file - make a hexdump --- all is still there - also the id3 tags.

=> So it depends on how good software is programmed. If they respect the standard then every subchunk works. Maybe I define my own subchunk "SEXY", add it into the wav file with some content. Soundforge 9 won't destroy it ...


The djing software Rane Serato Scratch Live supports the LIST & ID3 tags and show the same logical info in one column.

And the programmer of Rane Serato Scratch Live has told me that iTunes is also storing the id3 tags into the wav files (didn't test it).

So it's nothing special - no standard is broken.

So - after this long discussion - I hope also Florian will read this - and he will support ID3 tags in WAV files soon (maybe LIST too). :slight_smile:

May I ask you a stupid question? Why don't you just use some lossless audio format instead of WAV?

Most lossless formats support tags nicely, the applications that support them also support tags, they do not lower the quality of your music files, they take less place on disk...
I really don't see any advantage of storing music as WAV. After all, nobody uses BMP to store digital images neither. :wink:


pueblo funky wrote:

There may be additional subchunks in a Wave data stream.

I stand corrected - thanks!

But even though ID3 in WAV is not non-compliant, is it standardised anywhere? E.g. is there a written specification to defined things like how the ID3 version is coded, and the character encoding?

nickless wrote:

May I ask you a stupid question? Why don't you just use some
lossless audio format instead of WAV?

WAV is a lossless audio format.

I really don't see any advantage of storing music as WAV.

Of lossless audio formats, WAV is the fastest to load for editing, fastest to save (encode), and the most widely supported by digital audio players.

In fact for many DAPs it is the only one supported.

It's the same as for MP3.

The ID3 format starts with the id "ID3" and the defined data (tags & values) follows as the specification says.

In a WAV file the "ID3" data is a subchunk - there is an extra id "id3 " around + the length of the "ID3" data.

  1. Subchunk-id (4 bytes): "id3 " (+ space) (identifier of the subchunk for a wav)
  2. Size of the subchunk (4 bytes): number of bytes (length of the whole "ID3" data stream as specified in 3 below. So you know where the next subchunks starts (4).
  3. Here starts the ID3 data (with the ID3 tag id "ID3" itself).
  4. Here is the next subchunk-id ...

I'll post a screen shot later.

iTunes is using it - so we can say it's a de-facto standard, or isn't it? :sunglasses:
Various djing software is using it (e.g. Rane Serato Scratch Live
Tag & Rename supports it.

I'll also ask Sony Soundforge to implement it - as I asked here for MP3tag (or should we say "Anytag"? :wink: )

The character encoding doesn't matter - it's specified in the ID3 data stream itself (the character encoding could be defined for every tag!).

Of course - the ID3 specification currently says nothing about them to store it into a WAV file. But how often are there updates on this site? The only one thing for them is to write down what I've posted in the previous reply. :wink: ... That's it.

and any software which supports the RIFF/WAV logic must write back (if there was any change in one subchunk) all other subchunks - if it supports the subchunk or not (it has only to write back the subchunk id, the length + the binary data). The only one problem is that there is a lot of software & players around which are not reading the WAV files correctly (e.g. Wavelab 5)!

Here is the original reply from Josh from Rane Serato:

As chrisji said:

and WAV is supported from all music software (beside reading the whole RIFF / WAV format 100 % correctly)

and I import the files from cd with Wavelab - which writes WAV.

and I'm using Rane Serato Scratch Live which only supports MP3 & WAV & AIFF (also OGG).

and as dj I want to avoid the overhead of "unzipping" data during the live performance :sunglasses:

Currently I have no problem with the big files. Only the backup takes longer - but it's running over the night so ...


I want to explain the RIFF / WAV format with some screen shots!

The following WAV file has been imported by Wavelab 5, ID3 tagged with Tag & Rename + "WAV" tagged with Sony Soundforge 9.0e.

General overview:

A chunk (e.g. "WAVE") contains multiple subchunks (e.g. "fmt ", "data", "LIST", "bext", "id3 ", etc.). After the chunk id (4 bytes) follows the first subchunk id (4 bytes), followed by the size of the subchunk data (4 bytes) and then the subchunk data itself and then the next subchunk id and so on.

When you open this WAV file with a hexdump tool you would find the following:

  1. Screen Shot:

At first you can see the id "RIFF" (red) and after that the size (green) of the following complete data ($000D7B8C - backwards!). When you add the next address $00000008 and the size of $000D7B8C you will have as result $000D7B94 which is the end of the file (see last screen shot).

As next starts the "WAVE" chunk (blue). This chunk contains a lot of subchunks:

Normally the first subchunk is "fmt " (orange) followed by the size of this subchunk (violet). This subchunk contains data like audio format, bits per sample, sample rate, number of channels, etc. When you add the next address $00000014 + the size of the subchunk $00000010 you land ...

at $00000024, where the subchunk "data" starts (yellow), followed by the size and the sound samples itself. Adding again the next address (after the size) $0000002C + the length of the subchunk $000D770C is $000D7738.

Let's look at $000D7738:

The subchunk "LIST" + the size $00000092. This subchunk specifies the blocks "INFO" and "exif" (see here). After "INFO" you can find the first tag "INAM" followed by the length $00000012 of the following text "You're The First" (incl. 2 zero bytes) and then the next tag and so on.

Following the logic, $000D7740 + length $00000092 = $000D77D2 - here starts the subchunk "bext" - specified anywhere. Following the logic, $000D77DA + length $0000025A = $000D7A34 ...

which lets us begin with the next subchunk - which is "id3 " :smiley: - see screen shot:

It starts with the subchunk id "id3 " + size and after that the ID3 specification ( begins - which you can find in typical MP3's.

$000D7A3C + $00000158 = $000D7B94 - which is the end of the file (the same as on the top).

So as you can see, the logic of subchunk + length of a subchunk makes it possible to add various subchunks.

If a program can not understand a specific subchunk - it must store it with the whole length and when the (changed) file will be saved again it writes the subchunk away as it has read it.

That's the specification but a lot of programs are not able to read the correct chunk & sub chunk logic.

I hope this helps.

Maybe fyi:

In, chapter 3, read the first paragraph:

so but may work with other types of encoded audio means - not only MP3.

There is also one little RIFF chunk subchunk issue - but only for Florian who should program that :smiley:

taken from a WAV expert here (File Structure - 2nd paragraph).

(the size of the subchunk id must be even - so a zero byte has to be added after the last tag - if not even - that's all).

PS: Also AIFF files could be ID3 tagged ... it's the same as WAV. Here is an useful link: ... to find at the bottom ... read from

RIFF = FORM = RIFX (with small differences).

I have been using MP3Tag for quite a while and had to switch to Tag & Rename when I started moving to using WAV files.

Whilst Tag & Rename is an OK tool I do prefer MP3Tag and would happily put €50 into the pot for development costs.

I really miss being able to use the scripts from MP3Tag and have to do most of the changes I used to automate by hand now.

I don't know what format of tags are used in Tag & Rename, but they seem to work well and are read by almost every application I have used that supports reading WAV tags. So if MP3Tag could support the same it would be great.

I am also more than happy to do some testing on beta code if it helps.

The same for me. :slight_smile:


Tag & Rename 3.5 RC 1 has a bug - some software (e.g. Sony Sound Forge 9.0e) are reporting a bug on some WAV files with an ID3 tag when you try to open it. That is because T&R writes the id3 sub chunk sometimes with an odd number of bytes. It should be written with an even number of bytes (e.g. adding a zero byte).

Wavelab 5 isn't able to open WAV files with unknown subchunks (which didn't exist during the programming of the software - that's not a correct programming of the standard - Versino 6.06 (?) should be able to read/write them). For Wavelab 5 you have to remove the id3 tag (subchunk).