BUG in Information Block of .wav file

[DougA]

In the "Information Block" portion of the .wav file 5 of the possible fields are being stored with an extra byte (hex 00) not reflected in that field's length value. Note, however, that the total block length does count these extra bytes.

Here is a hex dump of a test file with all information fields containing a value,
the fields with the error are: IART-Artist, ITRK-Track, ISRC-ISRC, IAAR-Album Artist, ICRD-Date
the other fields are correct

4C495354 B0000000 494E464F 49505244 LIST°...INFOIPRD
06000000 416C6275 6D004941 52540700 ....Album.IART..
00004172 74697374 00004943 4F500A00 ..Artist..ICOP..
0000436F 70797269 67687400 49434D54 ..Copyright.ICMT
0C000000 44657363 72697074 696F6E00 ....Description.
49435244 05000000 44617465 00004947 ICRD....Date..IG
4E520600 00004765 6E726500 494E414D NR....Genre.INAM
06000000 5469746C 65006975 726C0400 ....Title.iurl..
00007572 6C006974 726B0600 00007472 ..url.itrk....tr
61636B00 69737263 05000000 49535243 ack.isrc....ISRC
00006961 61720D00 0000416C 62756D20 ..iaar....Album
61727469 73740000 artist..

For example: See the Artist field, starting with 'IART' near the end of line two.
6D004941 52540700 00004172 74697374 00004943
49415254 --- IART
07000000 --- length (=7)
41727479737400 --- 7 bytes: "Artist." (with valid trailing x'00')
00 --- THE EXTRA X'00' ( byte 8 )

The following field should start with "ICOP" but if you index by length of the IART field (7) you get an extra x'00' byte first, putting everything out of sync.
Only the five fields mentioned do this (you can see it in the dump), the others do not.

I found this while using version 5.58, and after upgrading to 5.67, I got the same results.

[Gord]

I was able to confirm this issue by creating a new WAV file in GoldWave.

[GoldWave Inc.]

That is part of the RIFF WAVE specification. All blocks must begin on an EVEN boundary and the block size MUST NOT include the padding byte, if required. Please refer to the RIFF Wave specification for details. Most other blocks, such as 'fmt' and 'data' usually contain an even amount of bytes, so padding isn't required.

Just to clarify, this is NOT a bug in GoldWave. GoldWave is following the RIFF WAVE specification. Any program that does not even-pad a block is violating the standard.

Chris

[DougA]

Ah-ha ! Thanks for the correction Chris.