Fwd: Bug#823417: sox: output file truncated when "upsampling" large files

Fwd: Bug#823417: sox: output file truncated when "upsampling" large files

[Pascal Giard]

[-- Attachment #1.1: Type: text/plain, Size: 402 bytes --]

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

Regards,

-Pascal
-- 
Homepage (http://www.ece.mcgill.ca/~pgiard1)
Debian GNU/Linux (http://www.debian.org)
TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca)
COMunité/LACIME: École de technologie supérieure (http://comunite.etsmtl.ca)

[-- Attachment #1.2: Type: text/html, Size: 881 bytes --]

[-- Attachment #2: Type: text/plain, Size: 404 bytes --]

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Re: Fwd: Bug#823417: sox: output file truncated when "upsampling" large files

[Måns Rullgård]

Pascal Giard <evilynux@gmail.com> writes:

> 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.

-- 
Måns Rullgård

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Re: Fwd: Bug#823417: sox: output file truncated when "upsampling" large files

[Dave Lambley]

[-- Attachment #1.1: Type: text/plain, Size: 2584 bytes --]

On 6 May 2016 at 10:35, Måns Rullgård <mans@mansr.com> wrote:

> Pascal Giard <evilynux@gmail.com> writes:
>
> > 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

[-- Attachment #1.2: Type: text/html, Size: 3425 bytes --]

[-- Attachment #2: Type: text/plain, Size: 404 bytes --]

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel