Also if i have [...] a 48kHz 16bit audio file does it make sense to downsample these to 44.1kHz 16bit aswell or i'm hurting the audio quality more than what i'll benefit filesize wise?

- Not checked "Allow aliasing/imaging"

If the -a option is given, then aliasing/imaging above the pass-
              band is allowed.  For example, with 44.1kHz sampling rate, and a
              resampling  band-width of 95%, this means that frequency content
              above 21kHz can be distorted; however, since this is  above  the
              pass-band  (i.e.  above the highest frequency of interest/audi?
              bility), this may not be a problem.  The  benefits  of  allowing
              aliasing/imaging  are  reduced  processing time, and reduced (by
              almost half) transient echo artefacts.

I see just advantages of allowing aliasing/imaging above the passband. Does anyone know why is it not then default?

I see just advantages of allowing aliasing/imaging above the passband. Does anyone know why is it not then default?

I use aliasing because i had some less clipping on heavily compressed material. Not audible but maximum no clipping gain changed.

That said, I usually don't bother reducing 48 to 44.1 because it doesn't save much space. I may feel differently when my drives are all full, though.

Any resampler can change the maximum level of a signal, particularly if done at high precision.  This is what resampling does:  compute new points from old points.  Because the new points aren't in the same locations as the old points, they will have different values, sometimes higher, sometimes lower. 

If your sample is already clipping, its a good idea to replaygain it, or at least renormalize it so that you do not introduce even more clipping when converting back to integer PCM.  Using a different resampler won't help with this though, unless the new one is secretly renormalizing for you, which would probably not be great.

sox -G / --guard: Automatically invoke the gain effect to guard against clipping. I.e. sox will slightly attenuate the file when clipping may occur.

I indeed had the impression that it is disabled by default just to please people that don't understand the concepts of a lowpass filter and the upper limits of human hearing but just don't want 'aliasing' because it is considered as generally bad. However, transient echo artifacts *are* noticeable and reducing them could be a (albeit very small) advantage.

Quote from: saratoga on 2013-11-17 17:02:32

Any resampler can change the maximum level of a signal, particularly if done at high precision.  This is what resampling does:  compute new points from old points.  Because the new points aren't in the same locations as the old points, they will have different values, sometimes higher, sometimes lower. 

If your sample is already clipping, its a good idea to replaygain it, or at least renormalize it so that you do not introduce even more clipping when converting back to integer PCM.  Using a different resampler won't help with this though, unless the new one is secretly renormalizing for you, which would probably not be great.

Thats why i do and aliasing has a slight advantage here.

Quote from: skamp on 2013-11-17 17:22:24

sox -G / --guard: Automatically invoke the gain effect to guard against clipping. I.e. sox will slightly attenuate the file when clipping may occur.

When i remember right the guard command is not very intelligent. It simply applies a gain that sox thinks is safe for the operation. For resampling this means simply a gain of -3

• original (24 / 88.2): -0.1 dBFS peak (0.98843944 FS), -5.92 dB track gain
• resampled to 24 / 44.1, with -G: very slightly below 0 dBFS peak (0.99999559 FS), -5.47 dB track gain
• resampled to 24 / 44.1, without -G: 0 dBFS (1.0 FS), -5.92 dB track gain

I tried (on a single file, admittedly):

• original (24 / 88.2): -0.1 dBFS peak (0.98843944 FS), -5.92 dB track gain
• resampled to 24 / 44.1, with -G: very slightly below 0 dBFS peak (0.99999559 FS), -5.47 dB track gain
• resampled to 24 / 44.1, without -G: 0 dBFS (1.0 FS), -5.92 dB track gain

I tried (on a single file, admittedly):

• original (24 / 88.2): -0.1 dBFS peak (0.98843944 FS), -5.92 dB track gain
• resampled to 24 / 44.1, with -G: very slightly below 0 dBFS peak (0.99999559 FS), -5.47 dB track gain
• resampled to 24 / 44.1, without -G: 0 dBFS (1.0 FS), -5.92 dB track gain

It also may have done something wrong when used with realtime resampling at my Squeezebox server. I only know i didn't use it.

Quote from: Wombat on 2013-11-17 17:59:23

It also may have done something wrong when used with realtime resampling at my Squeezebox server. I only know i didn't use it.

Its impossible to perform a processing step that must scan the entire file in realtime, so no, you did not use it

If you want to do this without processing the entire file first, use replaygain.  Essentially all the guard option is doing is computing the replaygain track peak after processing.  If you use replaygain, you can simply skip that step and so perform the resampling in real time.

How is it when you guard an album with single tracks? Does it apply different gains?

• if the guard parameter needs to do its thing in order to avoid clipping, the attenuation is very small;
• other tracks with high peaks will be attenuated by a similar (close enough) amount;
• even if some tracks get slightly attenuated, and others don't, the difference won't be any larger (most likely lower) than the differences in Replaygain track gains one can find in pretty much all albums (i.e. the tracks in any given album are almost never of the same perceptual loudness, as computed by Replaygain).