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 _______________________________________________ Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
