On Mon, Sep 04, 2023 at 11:52:46AM +0100, Will Godfrey wrote:
(duplicate lines removed)
00000000 52 49 46 46 3c b7 1f 04 57 41 56 45 66 6d
74 20 |RIFF<...WAVEfmt |
00000010 10 00 00 00 01 00 02 00 80 bb 00 00 00 65 04 00 |.............e..|
00000020 06 00 18 00 64 61 74 61 cc b5 1f 04 00 00 00 ff |....data........|
00000030 ff ff 00 00 00 ff ff ff 00 00 00 ff ff ff 00 00 |................|
Apart from the 'fmt' chunk (which all WAV files have), there is no
metadata in this file. The only other 'data' chunk (starting at 0x0024)
contains the actual samples up to the end of the file.
00000010 10 00 00 00
These four bytes are the size of the 'fmt' chunk, in this case
16 bytes.
I actually simplified things a bit in my previous post. There
are four possible sizes for the 'fmt' chunk:
size M$ name
------------------------------
14 WAVEFORMAT
16 PCMWAVEFORMAT
18 WAVEFORMATEX
40 WAVEFORMATEXTENSIBLE
The first two are officially obsolete. So this file should be
considered as non-standard. But e.g. libsndfile still writes
this format - it should use at least WAVEFORMATEX (18 bytes),
and the 40-byte version for more than 2 chan or 16 bits.
All software I know of will accept the 16 byte format for
reading, even if doing the right thing and use the 18 or 40
byte format when creating a new file.
I have lots of files with a similar 'fmt' chunk and Picard
does accept them. So it's not really clear what should be
the problem.
The one thing that is suspect is that the total file size
(0x041fb73c) is longer than the 'data' chunk plus its offset.
So is there something special at the end (look at the last
1024 bytes) ? If any real metadata is stored there, I'm not
sure if that is OK. I'd expect the 'data' chunk to be the
last one.
Ciao,
--
FA