IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Can SoX handle float file with volume over 0dBFS?
bennetng
post Jul 20 2013, 08:00
Post #1





Group: Members
Posts: 224
Joined: 22-December 05
Member No.: 26587



I have such files and foobar shows 7.079733 in replaygain scan (track peak) but when I use SoX's stats command I got the following

CODE
Input File     : 'D:\bennet\@\sox\float.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:00:26.43 = 1165375 samples = 1981.93 CDDA sectors
File Size      : 9.32M
Bit Rate       : 2.82M
Sample Encoding: 32-bit Floating Point PCM

In:100%  00:00:26.43 [00:00:00.00] Out:1.17M [!=====|=====!]        Clip:926k
             Overall     Left      Right
DC offset   0.000284  0.000284  0.000283
Min level  -1.000000 -1.000000 -1.000000
Max level   1.000000  1.000000  1.000000
Pk lev dB       0.00      0.00      0.00
RMS lev dB     -3.61     -3.61     -3.61
RMS Pk dB      -0.27     -0.27     -0.27
RMS Tr dB      -1.#J     -1.#J     -1.#J
Crest factor       -      1.51      1.51
Flat factor    37.26     37.26     37.26
Pk count        463k      463k      463k
Bit-depth      32/32     32/32     32/32
Num samples    1.17M
Length s      26.426
Scale max   1.000000
Window s       0.050
Done.


I tried SoX's −G and the gain and norm commands to process the files but clipping distortion persists. In foobar I can use replaygain>preamp to reduce volume without distortion. Is this SoX's limitation? Thanks!
Go to the top of the page
+Quote Post
[JAZ]
post Jul 20 2013, 10:29
Post #2





Group: Members
Posts: 1787
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



I see the file is stored in floating point (as suggested by the name, but confirmed by Sox with "Sample Encoding: 32-bit Floating Point PCM" (and indirectly by the Bitrate, which is double of stereo 16bit 44Khz).
But said that, Sox is not operating in 32bits floating point, but in 24bit integer as indicated by "Precision : 24-bit".

That's why min and max level are clipped to 1, which is the max value that can be stored in integer (because it represents full scale).

I don't know/use sox, but in case it can use the gain when doing stats, and you say that the file has a peak of 7, you should be applying a gain of 0.14.
I don't really know if it might be a bug, an implementation limitation, or an erroneous use of commandline parameters (maybe you need to specify the output format).
Go to the top of the page
+Quote Post
bennetng
post Jul 21 2013, 12:31
Post #3





Group: Members
Posts: 224
Joined: 22-December 05
Member No.: 26587



I guess SoX really unable to deal with float files above 0dBFS. Just tried TAudioConverter > Filters > SoX > Guard against clipping, but files still clipped even when writing to 32-bit float format.
Go to the top of the page
+Quote Post
[JAZ]
post Jul 21 2013, 16:14
Post #4





Group: Members
Posts: 1787
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



Out of curiosity, i've downloaded 14.4.1 and played with it a bit.

The sad thing is that you are correct.



The instruction
CODE
>sox -S testfloat.wav -t wav -e floating-point tmp.wav
clips the output just like you say, even when the input file is in floating point, and i am asking the output to be floating point (which is is, but clipped).
Adding -G didn't change anything (i guess that's for when it applies multiple effects).

Finally, i tried the following:
CODE
>sox -S testfloat.wav -t sox -e floating-point tmp.wav
And that generates a 32bit *integer* file.

So it's like sox works internally in 32bit integer, although that's sort of incompatible with having a "clip guard".


Not even a gain operation on the input file is free of that:
CODE
>sox -v 0.1 -S testfloat.wav -t wav -e floating-point tmp.wav
(i.e. reduce the volume at 10% on the source)
Reduces the volume, but after clipping the input.
(again, same result with or without -G)

I tried explicitely a float format, but still the same result:
CODE
>sox -S -t f32 -e floating-point -b 32 --endian little -c 2 -r 44100 testfloat-raw.wav -t f32 -e floating-point -b 32 --endian little -c 2
-r 44100 tmp.wav


This post has been edited by [JAZ]: Jul 21 2013, 16:17
Go to the top of the page
+Quote Post
phofman
post Jul 21 2013, 20:12
Post #5





Group: Members
Posts: 310
Joined: 14-February 12
Member No.: 97162



Internally sox operates in int32. Therefore, all input formats are converted to sox_sample_t first.

http://sourceforge.net/p/sox/code/ci/maste.../src/sox.h#l894

The variable clip will contain number of samples outside of the allowed range -1, +1 in the input stream.

Therefore, it is not possible to use sox for IMO incorrect files with float samples larger than 1 without clipping.
Go to the top of the page
+Quote Post
[JAZ]
post Jul 21 2013, 21:47
Post #6





Group: Members
Posts: 1787
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



Ok, after reading a bit more the manual and that, the options that sox offer to prevent clipping are in the context of effects/switches (so, the result). In any case, above full scale is always clipped, and the options either advise about the clipping, or apply a gain when it sees it will clip.

But that means that, if I wanted to decode an MP3 file with sox (and apply whatever effect i wanted), the origin will probably be already clipped if it is not mp3gained. (I hope this example is more real than the "float with above full scale values" situation).

Feels strange... it's a bit misleading to have options to operate in float, but not have the benefits of what float means.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th October 2014 - 08:33