[SoX-devel] Fwd: Bug#823417: sox: output file truncated when "upsampling" large files

[Pascal Giard]

Hi guys,
can anyone have a look at http://bugs.debian.org/823417 please?

Regards,

-Pascal

[Måns Rullgård]

Post by Pascal Giard
Hi guys,
can anyone have a look at http://bugs.debian.org/823417 please?

------------------------------------------------------------------------
$ cat orig/STE-000.wav | /usr/bin/sox -V3 -t wav - -t wav -r 384000 -b 32
--buffer=8192 - gain -h rate -v -M -b 90.7 384000 > test.wav
/usr/bin/sox: SoX v14.4.1

Input File : '-' (wav)
Channels : 2
Sample Rate : 48000
Precision : 24-bit
Duration : 00:38:06.69 = 109761216 samples ~ 171502 CDDA sectors
Sample Encoding: 24-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no


Output File : '-' (wav)
Channels : 2
Sample Rate : 384000
Precision : 32-bit
Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'

/usr/bin/sox INFO sox: effects chain: input 48000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: gain 48000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: rate 384000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: output 384000Hz 2 channels
------------------------------------------------------------------------

That output is way over the 4GB limit of the wav header. Sox will write
the full amount of data, but it obviously can't express this in the
header. The value written appears to be simply the low 32 bits of the
correct size. Arguably, writing the maximum value would be preferable,
but it would still not be correct.

Some applications either ignore the header value and uses the file size
instead, or notices the discrepancy and return all the available data,
whereas others trust the header and thus only return the amount
specified there.

Hope this helps.

[Dave Lambley]

Post by Måns Rullgård

Post by Pascal Giard
Hi guys,
can anyone have a look at http://bugs.debian.org/823417 please?

------------------------------------------------------------------------
$ cat orig/STE-000.wav | /usr/bin/sox -V3 -t wav - -t wav -r 384000 -b 32
--buffer=8192 - gain -h rate -v -M -b 90.7 384000 > test.wav
/usr/bin/sox: SoX v14.4.1
Input File : '-' (wav)
Channels : 2
Sample Rate : 48000
Precision : 24-bit
Duration : 00:38:06.69 = 109761216 samples ~ 171502 CDDA sectors
Sample Encoding: 24-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Output File : '-' (wav)
Channels : 2
Sample Rate : 384000
Precision : 32-bit
Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
/usr/bin/sox INFO sox: effects chain: input 48000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: gain 48000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: rate 384000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: output 384000Hz 2 channels
------------------------------------------------------------------------
That output is way over the 4GB limit of the wav header. Sox will write
the full amount of data, but it obviously can't express this in the
header. The value written appears to be simply the low 32 bits of the
correct size. Arguably, writing the maximum value would be preferable,
but it would still not be correct.
Some applications either ignore the header value and uses the file size
instead, or notices the discrepancy and return all the available data,
whereas others trust the header and thus only return the amount
specified there.

I looked into large file behaviour some years ago. SoX partially respects a
magic length value, 0x7ffff000 to mean "ignore headers and read until end
of file". I couldn't find any mention of this constant in the Microsoft (or
any other other) specification, or any other justification for it. The
constant does appear in MPlayer and other source code.

https://sourceforge.net/p/sox/code/ci/master/tree/src/wav.c#l39

The right thing may be to upgrade the WAV file to an RF64 file when the
length exceeds 4Gb.

Dave