.wav file, produced by sBitx REC button, is invalid.

[wb2osz]

The .wav file produced by the sBitx REC button can't be read by other applications.
One application reported that the data length was -1 which would not be possible.
Let's take a look at it in detail.


$ od -t x1   sbitx/audio/20220929-0138-12.wav  | more

0000000 52 49 46 46 23 00 00 00 57 41 56 45 66 6d 74 20
        ----------- ----------- ----------- -----------
First 4 bytes "RIFF" - OK.
Next 4 bytes should be file length - 8.  
(remaining length of file after these first 8 bytes.)
Instead we find 19 which is not puzzling.  <--- *** ERROR ***
Next "WAVE" - OK
Next "fmt " - OK


0000020 10 00 00 00 01 00 01 00 e0 2e 00 00 c0 5d 00 00
        ----------- ----- ----- ----------- -----------
4 bytes for the format 16 - OK
2 bytes.  1=PCM. - OK
2 bytes.  1 channel (mono). - OK
4 bytes - 12000 samples per second - I was expecting 96000
4 bytes - 24000  block align * samples per second.

0000040 02 00 10 00 64 61 74 61 ff ff ff ff 81 fe c4 fe
        ----- ----- ----------- -----------.
2 bytes.  2 = block align - bits per sample / 8 * number of channels - OK
2 bytes. 16 bits per sample. - OK
4 bytes. "data" - OK
4 bytes.  Should be number of bytes following.
Instead we find -1.     <---  *** ERROR ***

0000060 44 fe 25 ff 9b 00 1b 01 f3 00 1c 01 35 01 6b 00



The problem is that the two length fields are not filled in.
When recording is finished, the application must seek to:
 * offset 4 from beginning and fill in file length - 8.
 * offset 40 from beginning and fill in file length - 44.

[afarhan]

Thanks, I will add that. Many apps like aplay don't mind leaving them unfilled but the office memo is that they must be filled.

…

On Thu, Sep 29, 2022, 6:21 AM wb2osz ***@***.***> wrote: The .wav file produced by the sBitx REC button can't be read by other applications. One application reported that the data length was -1 which would not be possible. Let's take a look at it in detail. $ od -t x1 sbitx/audio/20220929-0138-12.wav | more 0000000 52 49 46 46 23 00 00 00 57 41 56 45 66 6d 74 20 ----------- ----------- ----------- ----------- First 4 bytes "RIFF" - OK. Next 4 bytes should be file length - 8. (remaining length of file after these first 8 bytes.) Instead we find 19 which is not puzzling. <--- *** ERROR *** Next "WAVE" - OK Next "fmt " - OK 0000020 10 00 00 00 01 00 01 00 e0 2e 00 00 c0 5d 00 00 ----------- ----- ----- ----------- ----------- 4 bytes for the format 16 - OK 2 bytes. 1=PCM. - OK 2 bytes. 1 channel (mono). - OK 4 bytes - 12000 samples per second - I was expecting 96000 4 bytes - 24000 block align * samples per second. 0000040 02 00 10 00 64 61 74 61 ff ff ff ff 81 fe c4 fe ----- ----- ----------- -----------. 2 bytes. 2 = block align - bits per sample / 8 * number of channels - OK 2 bytes. 16 bits per sample. - OK 4 bytes. "data" - OK 4 bytes. Should be number of bytes following. Instead we find -1. <--- *** ERROR *** 0000060 44 fe 25 ff 9b 00 1b 01 f3 00 1c 01 35 01 6b 00 The problem is that the two length fields are not filled in. When recording is finished, the application must seek to: * offset 4 from beginning and fill in file length - 8. * offset 40 from beginning and fill in file length - 44. — Reply to this email directly, view it on GitHub <#16>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFYXOB55MSQUFA73K2FBVDWATRXRANCNFSM6AAAAAAQYI7UWE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>