Plea for WAV support Options

[pueblo funky]

Ok,

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 " - see screen shot:


It starts with the subchunk id "id3 " + size and after that the ID3 specification (id3.org) 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.

This post has been edited by pueblo funky: Oct 19 2008, 09:56

[pueblo funky]

Maybe fyi:

In http://www.id3.org/id3v2.4.0-structure, chapter 3, read the first paragraph:

ID3v2 is a general tagging format for audio, which makes it possible to store meta data about the audio inside the audio file itself. The ID3 tag described in this document is mainly targeted at files encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III and MPEG-2.5, but may work with other types of encoded audio or as a stand alone format for audio meta data.

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

One tricky thing about RIFF file chunks is that they must be word aligned. This means that their total size must be a multiple of 2 bytes (ie. 2, 4, 6, 8, and so on). If a chunk contains an odd number of data bytes, causing it not to be word aligned, an extra padding byte with a value of zero must follow the last data byte. This extra padding byte is not counted in the chunk size, therefor a program must always word align a chunk headers size value in order to calculate the offset of the following chunk.

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).

[pueblo funky]

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

Microsoft decided that IFF was a good idea ...

RIFF = FORM = RIFX (with small differences).

[BatterseaBob]

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.

[pueblo funky]

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. :-)

Note:

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).