An elegant one would be for the player to scan your files at import and flag the compensation in the form of metadata.
For those interested, foobar2000 has this feature built-in:
An elegant one would be for the player to scan your files at import and flag the compensation in the form of metadata.
The peak amplitude of any waveform represented in PCM will exceed the amplitude of the samples unless a given sample happens to fall exactly on a peak. This is a fundamental property of PCM encoding. The playback hardware should be capable of reproducing any reasonable band-limited non-clipped waveform that has been encoded in PCM. 3 dB of headroom is sufficient.
Some DACs invert the audio when an intersample peak occurs. The inversion can extend before and after the actual peak (due to the length of the FIR filter) The polarity inversion is caused by a failure to recognize an arithmetic overflow in the DSP. DACs that have an inversion problem, produce very nasty distortion. It is very audible. I believe some of these have been tested on ASR, but this problem was missed.
I am not sure that I understand properly. Below is the AA analysis of the full length digital signal that was sent to the DAC. There is a zero occurrence of "possibly clipped samples". No sample value equals to or exceeds +/-32767.@pma, could you please show the input signal,
I don't see clipping
@pma, thanks, now I see the clipping ;-)
wrt waveform, what I meant is the sample-train, basically a square-wave but which points or frequency exactly? Below example for a 300Hz square:
- Lossy compression systems (such as MP3) tend to create an abundance of intersample overs. A DAC that clips intersample overs will sound especially bad when playing MP3s. MP3 compression can add intersample overs even when none were in the original non-compressed track.
also show the last plot again, but with reduced input amplitude?
Would be interesting to see how the imtersample clipping distortion profile is with different brickwall filter settings. Could that be one reason why some people prefer "slower" brickwall filters? The filter ringing itself should be inaudible.
Would be interesting to see how the imtersample clipping distortion profile is with different brickwall filter settings.
10 - 3.91 = 6.09 dB overshoot$ sox -R -r 44100 -n -n synth 100 white vol -10dB rate -v $((8*44100)) stats 2>&1 | grep "Pk lev"
Pk lev dB -3.91
10 - 2.42 = 7.58 dB overshoot$ sox -R -r 44100 -n -n synth 100 white vol -10dB rate -vI $((8*44100)) stats 2>&1 | grep "Pk lev"
Pk lev dB -2.42
10 - 1.99 = 8.01 dB overshoot$ sox -R -r 44100 -n -n synth 100 white vol -10dB rate -vM $((8*44100)) stats 2>&1 | grep "Pk lev"
Pk lev dB -1.99
10 - 6.56 = 3.44 dB overshoot for the SoX very high quality (band-width 95%), minimum phase.$ sox -R -r 44100 -n -n synth 100 white vol -10dB sinc -10k rate -vM $((8*44100)) stats 2>&1 | grep "Pk lev"
Pk lev dB -6.56
The question is what you get from such plots. Sudden, even shortest change in the signal continuity has always dramatic effect on signal spectrum. Now we are not in the steady state sine wave area.Question is whether different brickwall filter slopes lead to different distortion profiles caused by intersample clipping.
This seems to be in line with "more overshoot" visible in minimum phase impulse responseA random white noise stored in PCM might require more than 8dB attenuation to not clip when resampling. The value depends on the selected filters:
SoX very high quality (band-width 95%), linear phase:
10 - 3.91 = 6.09 dB overshoot
SoX very high quality (band-width 95%), intermediate phase:
10 - 2.42 = 7.58 dB overshoot
SoX very high quality (band-width 95%), minimum phase:
10 - 1.99 = 8.01 dB overshoot
The issue seems to be more caused by high-frequency content, but even if we use steep sinc filter to cut everything above 10kHz, there are still some overshoots:
10 - 6.56 = 3.44 dB overshoot for the SoX very high quality (band-width 95%), minimum phase.
This might very well be the case. The gentler the transition into the stop-band of the filter, the lower the peaks and the less likely they undergo clipping or nastier artefacts.Would be interesting to see how the imtersample clipping distortion profile is with different brickwall filter settings. Could that be one reason why some people prefer "slower" brickwall filters? The filter ringing itself should be inaudible.
JRiver also has this feature built-in:
could you please show the input signal, and also show the last plot again, but with reduced input amplitude?
10 - 9.2 = 0.8 dB overshoot$ sox Steely\ Dan\ -\ 01.\ Gaslighting\ Abbie.flac -n vol -10dB rate -v $((8*44100)) stats
Overall Left Right
Pk lev dB -9.20 -9.27 -9.20
RMS lev dB -26.40 -26.17 -26.64
10 - 7.47 = 2.53 dB overshoot$ sox Steely\ Dan\ -\ 01.\ Gaslighting\ Abbie.flac -n vol -10dB rate -vI $((8*44100)) stats
Overall Left Right
Pk lev dB -7.47 -7.98 -7.47
RMS lev dB -26.40 -26.17 -26.64
10 - 7.37 = 2.63 dB overshoot$ sox Steely\ Dan\ -\ 01.\ Gaslighting\ Abbie.flac -n vol -10dB rate -vM $((8*44100)) stats
Overall Left Right
Pk lev dB -7.37 -7.37 -7.58
RMS lev dB -26.40 -26.17 -26.64
Your document says:The assumption that "a huge amount of music ... doesn't have this problem" is incorrect.
The vast majority of 44.1 kHz recordings have intersample peaks that exceed 0 dBFS. Curiously, tracks with minimal compression can have some of the highest and most frequent intersample peaks. See my application note on this topic: Intersample Overs in CD Recordings
When intersample peaks overload a DAC, a DSP, or an ASRC, the distortion reaches very high levels and it is often non-harmonic. This playback defect is huge compared to all of the other THD, IMD, and SNR issues in playback hardware.
I would assert that the intersample over test is the single most important test from the standpoint of detecting audible defects in a digital audio product.
The cure requires a 3-dB loss in SNR. This a small price to pay for eliminating the single most audible defect with most DACs, especially when most modern DACs have a higher SNR than the power amplifiers that they will be driving.