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


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.

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 https://github.com/afarhan/sbitx/issues/16, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFYXOB55MSQUFA73K2FBVDWATRXRANCNFSM6AAAAAAQYI7UWE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

afarhan / sbitx

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