Bug in RIFF-Wav-Header

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in RIFF-Wav-Header

Thomas Foerster
Hi,

I think there is a bug in writing wav-headers (i.e. 24 Bit). I've done
this with a "normal" 16/44,1 kHz wav-file :

sox input.wav -b 24 output24.wav

input.wav has a filesize of 27.579.596 bytes (without wav-header
27.579.552 bytes). Doing the command above, you should get
27.579.552 * 3 / 2 bytes plus 44 bytes (= 41.369.372 bytes)

Sox calculates 41.369.408 bytes. The Header has a size of 80 bytes...
The same with 32 Bit. The way back the same. Audacity i.e. calculates it
right.

Regards
Thomas






------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Jan Stary
On Sep 18 02:00:14, TJF wrote:
> I think there is a bug in writing wav-headers (i.e. 24 Bit). I've done
> this with a "normal" 16/44,1 kHz wav-file :
>
> sox input.wav -b 24 output24.wav
>
> input.wav has a filesize of 27.579.596 bytes (without wav-header
> 27.579.552 bytes). Doing the command above, you should get
> 27.579.552 * 3 / 2 bytes plus 44 bytes (= 41.369.372 bytes)

Why should you? The size of the WAV header is not fixed.
Typically, the WAV headr contains just the "fmt " chunk
and is 44 bytes long.  For sample sizes bigger than 16bit
(as in 24 bit), there is also the "fact" chunk.

See e.g. http://www.sonicspot.com/guide/wavefiles.html
for a good description of the WAV format.

Look at your files with the wavmeta tool to see the header:
http://stare.cz/~hans/.tmp/wavmeta.tar

> The same with 32 Bit. The way back the same.

32 is bigger than 16, too.

        Jan


------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Thomas Foerster
Hi Jan,

I get this with your tool:

----------------------------------------------------------
CHUNK: fmt  (40 bytes)
extensible, 2 channels, 44100 Hz, 24 bits
22 bytes of format extension
valid bits: 24
speaker map: 3
subformat: 1
CHUNK: fact (4 bytes)
6894888 samples
CHUNK: data (41369328 bytes)
This is the audio data chunk
----------------------------------------------------------
or here:

Length        : 41369408
RIFF          : 41369400
WAVE
fmt           : 40
Format        : 0xFFFE => WAVE_FORMAT_EXTENSIBLE
Channels      : 2
Sample Rate   : 44100
Block Align   : 6
Bit Width     : 24
Bytes/sec     : 264600
Valid Bits    : 24
Channel Mask  : 0x3 (L, R)
Subformat
esf_field1    : 0x1
esf_field2    : 0x0
esf_field3    : 0x10
esf_field4    : 0x80 0x0 0x0 0xAA 0x0 0x38 0x9B 0x71
format        : pcm
fact          : 4
frames        : 6894888
data          : 41369328

Sample Rate   : 44100
Frames        : 6894888
Channels      : 2
Format        : 0x00130003
Sections      : 1
Seekable      : TRUE
Duration      : 00:02:36.347
Signal Max    : 8.03712e+006 (-0.37 dB)

----------------------------------------------------------

Here the file before (16 Bit):

----------------------------------------------------------
CHUNK: fmt  (16 bytes)
linear PCM, 2 channels, 44100 Hz, 16 bits
CHUNK: data (27579552 bytes)
This is the audio data chunk
----------------------------------------------------------

Sox makes from a linear PCM file (uncompressed WAVE_FORMAT_PCM) another
format: WAVE_FORMAT_EXTENSIBLE with chunk "fact", what is used in case
of compressed files (s. your link).

This is still a correct 32 Bit  WAVE_FORMAT_PCM (with 44 byte header):

CHUNK: fmt  (16 bytes)
linear PCM, 2 channels, 44100 Hz, 32 bits
CHUNK: data (55159104 bytes)
This is the audio data chunk

Header size is undependant of BitWidth because it is added and not
multiplicated by x (in case of increasing BitWidth).

Regards
Thomas




Am 18.09.2011 15:42, schrieb Jan Stary:

> On Sep 18 02:00:14, TJF wrote:
>> I think there is a bug in writing wav-headers (i.e. 24 Bit). I've done
>> this with a "normal" 16/44,1 kHz wav-file :
>>
>> sox input.wav -b 24 output24.wav
>>
>> input.wav has a filesize of 27.579.596 bytes (without wav-header
>> 27.579.552 bytes). Doing the command above, you should get
>> 27.579.552 * 3 / 2 bytes plus 44 bytes (= 41.369.372 bytes)
> Why should you? The size of the WAV header is not fixed.
> Typically, the WAV headr contains just the "fmt " chunk
> and is 44 bytes long.  For sample sizes bigger than 16bit
> (as in 24 bit), there is also the "fact" chunk.
>
> See e.g. http://www.sonicspot.com/guide/wavefiles.html
> for a good description of the WAV format.
>
> Look at your files with the wavmeta tool to see the header:
> http://stare.cz/~hans/.tmp/wavmeta.tar
>
>> The same with 32 Bit. The way back the same.
> 32 is bigger than 16, too.
>
> Jan
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> Sox-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Jan Stary
On Sep 19 00:32:09, TJF wrote:

> Hi Jan,
>
> I get this with your tool:
>
> ----------------------------------------------------------
> CHUNK: fmt  (40 bytes)
> extensible, 2 channels, 44100 Hz, 24 bits
> 22 bytes of format extension
> valid bits: 24
> speaker map: 3
> subformat: 1
> CHUNK: fact (4 bytes)
> 6894888 samples
> CHUNK: data (41369328 bytes)
> This is the audio data chunk
> ----------------------------------------------------------
> or here:
>
> Length        : 41369408
> RIFF          : 41369400
> WAVE
> fmt           : 40
> Format        : 0xFFFE => WAVE_FORMAT_EXTENSIBLE
> Channels      : 2
> Sample Rate   : 44100
> Block Align   : 6
> Bit Width     : 24
> Bytes/sec     : 264600
> Valid Bits    : 24
> Channel Mask  : 0x3 (L, R)
> Subformat
> esf_field1    : 0x1
> esf_field2    : 0x0
> esf_field3    : 0x10
> esf_field4    : 0x80 0x0 0x0 0xAA 0x0 0x38 0x9B 0x71
> format        : pcm
> fact          : 4
> frames        : 6894888
> data          : 41369328
>
> Sample Rate   : 44100
> Frames        : 6894888
> Channels      : 2
> Format        : 0x00130003
> Sections      : 1
> Seekable      : TRUE
> Duration      : 00:02:36.347
> Signal Max    : 8.03712e+006 (-0.37 dB)
>
> ----------------------------------------------------------
>
> Here the file before (16 Bit):
>
> ----------------------------------------------------------
> CHUNK: fmt  (16 bytes)
> linear PCM, 2 channels, 44100 Hz, 16 bits
> CHUNK: data (27579552 bytes)
> This is the audio data chunk
> ----------------------------------------------------------
>
> Sox makes from a linear PCM file (uncompressed WAVE_FORMAT_PCM) another
> format: WAVE_FORMAT_EXTENSIBLE with chunk "fact", what is used in case
> of compressed files (s. your link).

Yes.

This seems to be the relevant piece of wav.c:


    if (wFormatTag == WAVE_FORMAT_PCM && (wBitsPerSample > 16 || wChannels > 2)
        && strcmp(ft->filetype, "wavpcm")) {
      isExtensible = sox_true;
      wFmtSize += 2 + 22;
    }
    else if (wFormatTag != WAVE_FORMAT_PCM)
        wFmtSize += 2+wExtSize; /* plus ExtData */

    wRiffLength = 4 + (8+wFmtSize) + (8+dwDataLength);
    if (isExtensible || wFormatTag != WAVE_FORMAT_PCM) /* PCM omits the "fact" chunk */
        wRiffLength += (8+dwFactSize);

    /* ... */

    if (isExtensible || wFormatTag != WAVE_FORMAT_PCM){
        lsx_writes(ft, "fact");
        lsx_writedw(ft,dwFactSize);
        lsx_writedw(ft,dwSamplesWritten);
    }



> This is still a correct 32 Bit  WAVE_FORMAT_PCM (with 44 byte header):
>
> CHUNK: fmt  (16 bytes)
> linear PCM, 2 channels, 44100 Hz, 32 bits
> CHUNK: data (55159104 bytes)
> This is the audio data chunk

Yes.

I am not sure why SoX chooses to make the file EXTENSIBLE,
with a "fact" chunk, instead of letting it PCM, with just
the 32bit bitwidth specified in the "fmt " chunk. Chris?


        Jan


------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Chris Bagwell
On Mon, Sep 19, 2011 at 5:09 AM, Jan Stary <[hidden email]> wrote:

> On Sep 19 00:32:09, TJF wrote:
>
>> This is still a correct 32 Bit  WAVE_FORMAT_PCM (with 44 byte header):
>>
>> CHUNK: fmt  (16 bytes)
>> linear PCM, 2 channels, 44100 Hz, 32 bits
>> CHUNK: data (55159104 bytes)
>> This is the audio data chunk
>
> Yes.
>
> I am not sure why SoX chooses to make the file EXTENSIBLE,
> with a "fact" chunk, instead of letting it PCM, with just
> the 32bit bitwidth specified in the "fmt " chunk. Chris?
>

I can't really recall the background now but I believe it should be in
email archive if anyone is really interested.

Chris

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry&reg; mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry&reg; DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Rob Sykes
From: Chris Bagwell <[hidden email]>
To: [hidden email]
Sent: Monday, 19 September 2011, 15:18
Subject: Re: [SoX-users] Bug in RIFF-Wav-Header

On Mon, Sep 19, 2011 at 5:09 AM, Jan Stary <[hidden email]> wrote:

> On Sep 19 00:32:09, TJF wrote:
>
>> This is still a correct 32 Bit  WAVE_FORMAT_PCM (with 44 byte header):
>>
>> CHUNK: fmt  (16 bytes)
>> linear PCM, 2 channels, 44100 Hz, 32 bits
>> CHUNK: data (55159104 bytes)
>> This is the audio data chunk
>
> Yes.
>
> I am not sure why SoX chooses to make the file EXTENSIBLE,
> with a "fact" chunk, instead of letting it PCM, with just
> the 32bit bitwidth specified in the "fmt " chunk. Chris?
IIRC, SoX does this because it's required to (since 2001) by the MS spec. Prior to adding this support, SoX would create wav files that MS tools (e.g. media player) would refuse to load.  However, there are also tools that refuse to read a correct-per-spec EXTENSIBLE wav, so for this reason, there is -t wavpcm (see the soxformat man page).

HTH,
Rob

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry&reg; mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry&reg; DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Doug Cook-2
>>> This is still a correct 32 Bit  WAVE_FORMAT_PCM (with 44 byte header):
>>>
>>> CHUNK: fmt  (16 bytes)
>>> linear PCM, 2 channels, 44100 Hz, 32 bits
>>> CHUNK: data (55159104 bytes)
>>> This is the audio data chunk
>>
>> Yes.
>>
>> I am not sure why SoX chooses to make the file EXTENSIBLE,
>> with a "fact" chunk, instead of letting it PCM, with just
>> the 32bit bitwidth specified in the "fmt " chunk. Chris?
>
> IIRC, SoX does this because it's required to (since 2001) by the MS
> spec. Prior to adding this support, SoX would create wav files that MS tools
> (e.g. media player) would refuse to load.  However, there are also tools
> that refuse to read a correct-per-spec EXTENSIBLE wav, so for this reason,
> there is -t wavpcm (see the soxformat man page).
> HTH,
> Rob

There is no such thing as a correct 32-bit WAVE_FORMAT_PCM structure.
WAVE_FORMAT_PCM supports max 16 bits and 2 channels. This is for
backwards compatibility with the original specification of the
structure which indicate that the valid values for WAVE_FORMAT_PCM
included only 8 or 16 bits and 1 or 2 channels. Since the original
specification for the structure only allowed for those values, instead
of extending the definition of the original structure, Microsoft
switched to a new structure - WAVEFORMATEXTENSIBLE. I can't say
whether this was a good or a bad decision, but I can say that sox is
behaving correctly.

MSDN reference page:
http://msdn.microsoft.com/en-us/library/dd390970(v=VS.85).aspx

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in RIFF-Wav-Header

Thomas Foerster
Hi,

I think this MS stuff is uninteresting. Sox has a consistence: If you
do: "sox input.aiff -b 24  output.aiff , Sox doesn't change samplerate,
doesn't change format and doesn't change other things - except that what
is written in the command (-b 24). If you want another format than the
existing format, you should write that in into the commandline.

By the way: Every music-label (I know) uses formattype 1 for highres PCM
data. I.e. http://www.chesky.com/ on their 96/24 ...

Yes "−t wavpcm" doesn't change formattype 1. Good to know. But like I
said: It isn't logical.

Sox should first look at the existing formattype (1,2,...) and then use
the same formattype ... :-)

Thanks a lot!
Regards
Thomas



Am 19.09.2011 23:32, schrieb Doug Cook:

>>>> This is still a correct 32 Bit  WAVE_FORMAT_PCM (with 44 byte header):
>>>>
>>>> CHUNK: fmt  (16 bytes)
>>>> linear PCM, 2 channels, 44100 Hz, 32 bits
>>>> CHUNK: data (55159104 bytes)
>>>> This is the audio data chunk
>>> Yes.
>>>
>>> I am not sure why SoX chooses to make the file EXTENSIBLE,
>>> with a "fact" chunk, instead of letting it PCM, with just
>>> the 32bit bitwidth specified in the "fmt " chunk. Chris?
>> IIRC, SoX does this because it's required to (since 2001) by the MS
>> spec. Prior to adding this support, SoX would create wav files that MS tools
>> (e.g. media player) would refuse to load.  However, there are also tools
>> that refuse to read a correct-per-spec EXTENSIBLE wav, so for this reason,
>> there is -t wavpcm (see the soxformat man page).
>> HTH,
>> Rob
> There is no such thing as a correct 32-bit WAVE_FORMAT_PCM structure.
> WAVE_FORMAT_PCM supports max 16 bits and 2 channels. This is for
> backwards compatibility with the original specification of the
> structure which indicate that the valid values for WAVE_FORMAT_PCM
> included only 8 or 16 bits and 1 or 2 channels. Since the original
> specification for the structure only allowed for those values, instead
> of extending the definition of the original structure, Microsoft
> switched to a new structure - WAVEFORMATEXTENSIBLE. I can't say
> whether this was a good or a bad decision, but I can say that sox is
> behaving correctly.
>
> MSDN reference page:
> http://msdn.microsoft.com/en-us/library/dd390970(v=VS.85).aspx
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Sox-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users