The above article at Gearslutz explains inter-sample peaks quite well. Just to simplify it a little bit here is a time-domain plot of a sample. This could be part of any type of sound - bass guitar, synthesizer, but this is more of a 'designed' plot, since the chance of a similar sequence appearing is minimal (there are drastic changes in sample values).
view image
The areas marked with 'ISP' are the actual problems. ISPs are a digital-to-analog (DAC) conversation issue. Your digital medium such as CD-A may contain tracks that does not clip at all on normal meters, but in theory there is a chance that at certain sample configurations such as the shown above, the reconstructed (via interpolation) analog audio signal, exceeds 0 db. Such peaks will be introduced as distortion in listening conditions.
"Would this type of distortion be really that audible?"
It really depends on the playback system (DAC), the listener, the audio material. But it may be quite audible.
"Well how to prevent it?"
There are algorithms in some DSP limiters, that deal with the problem quite well. From my understanding of interpolation in mathematics, the only way to deal with such problems is to change values of the neighbor points (samples) forward and probably backwards in the time domain. Another important thing that must be done is to over-sample the signal so that more points are introduced in the plot.
Here is the list of the know limiters that prevent ISP:
Sonnox Limiter, Voxengo Elephant, TC Limiter, Izotope Ozone, PSP Xenon and others.
Note, that you must engage the oversampling mode of the limiter to enable the desired functionality.
As you may know most of these limiters are commercial products. The only free tools you would find are the meters, such as: John Schwartz's Bitter, SSL's X-ISM and others.
Still, if you are willing to buy a DSP limiter for your needs, I could not recommend a better limiter than Elephant. Its the cheapest, the most flexible and arguably the best sounding one.
Do the listed above tools really work for ISP?
Well here is the tricky part. There are certain conditions in which the ISP prevention may not work for any of the above products. However most of these conditions are quite extreme.
Recently I've conducted some tests with two very popular audio compression formats - MP3 and FLAC. The idea behind the test was a simple question: Does audio compression over a ISP free signal, introduces back the ISPs? Well the answer to that question ended up slightly complicated.
My first test was with a "designed" WAV file with series of samples that would positively introduce ISPs:
view image
I've used Elephant 2 to add 24db of gain to the signal, while oversampling to x2 and limiting at -0.1 db. Then created a MP3 file directly from Reaper with LAME encoder at 320kbps, normal quality. While decoding the resulted MP3 file into Cooledit I've noticed that there is no sample clipping or eventual inter-sample peaks. Then I repeated the same test with lower bitrate MP3 - still no problems were found, after the decoding. But then I've realized that this test is flawed for the following reasons:
- the frequency response of the input signal wasn't really 'sufficient' for testing (it was just a waveform peaking around 2khz)
- the average RMS level after limiting was still quite low.
So I'vee decided to do a little bit more testing on the subject. This time with pink noise and some extreme settings.
Without explaining more I will directly post the test results. There are two tests included (for FLAC, MP3) at different RMS levels.
input: 20 sec pink noise (WN trought 6pole 'pink' filter, simple pseudo-random
numbers generation, extended with XOR)
limiter: voxengo elephant2, default settings, 4x os, roof -0.2db, test dependant
input gain.
decoding: outputs decodeded with reaper 2.55
meter: SSL X-ISM
### test 1 -12db rms:
output wav (-12db_rms_24bit.wav): 24bit, 44100hz, no dither
* result: no ISP & no clipping
output mp3 (-12db_rms_320kbps.mp3): lame 3.98, CBR 320kbps, normal q
* result: no ISP & no clipping on decode
output mp3 (-12db_rms_96kbps.mp3): lame 3.98, CBR 96kbps, normal q
* result: no ISP & no clipping on decode
output flac (-12db_rms_q8.flac): flac 1.2.1, 24bit, q8
* result: no ISP & no clipping on decode
output flac (-12db_rms_q0.flac): flac 1.2.1, 24bit, q0
* result: no ISP & no clipping on decode
### test 2 -6db rms:
output wav (-6db_rms_24bit.wav): 24bit, 44100hz, no dither
* result: no ISP & no clipping
output mp3 (-6db_rms_320kbps.mp3): lame 3.98, CBR 320kbps, normal q
* result: ISP present & clipping on decode
output mp3 (-6db_rms_96kbps.mp3): lame 3.98, CBR 96kbps, normal q
* result: ISP present & clipping on decode
output flac (-6db_rms_q8.flac): flac 1.2.1, 24bit, q8
* result: ISP present & no clipping on decode
output flac (-6db_rms_q0.flac): flac 1.2.1, 24bit, q0
* result: no ISP & no clipping on decode
### Tests summary:
Lower RMS levels for both MP3 and FLAC decode with no clipping and ISP.
Decoding of mp3 streams with higher RMS level introduce clipping,
but when normalized, ISPs are not present. Higher RMS level flac q8 does
not clip, but strangly ISP are present. Lower compression q0 for FLAC preforms
very well for higher RMS values.
The tested compressors deal much better with lower RMS values.
Test files can be downloaded from here:
mirror1
mirror2
Regarding the MP3 tests:
Decoded MP3 audio signal would only clip if the RMS of the input is very high.
There are ways to deal with this problem:
lame -b 320 --clipdetect [file]
...
WARNING: clipping occurs at the current gain. Set your decoder to decrease
the gain by at least 0.1dB or encode again using --scale [arg]
(For a suggestion on the optimal value of [arg] encode
with --scale 1 first)
You can use the --scale command in LAME or tools like mp3gain to fix this.
But still this is sample clipping. There is a chance that no ISP will be present after normalizing the MP3 singal!
Still I should point out that there are way to many parameters involved, when conduction these tests and the test results may vary a lot.
I've also did a another much more extreme test with -1db RMS values (not included). Various limiters did not perform well in prevent ISP in these extreme conditions.
Excessive levels does not do well for ISP prevention and for audio compression.
"How to deal with compression of audio?"
- always use ISP prevention over the track.
- lower the limiter roof to -0.3, -0.5db, or even -1db
- decode the resulted mp3 file with an audio editor and check for clipping
- use statistics in your encoder (such as --clipdetect in LAME)
- of course use the best encoder possible
But still, as the above test proved moderate RMS levels, may not need any normalizations and lowering of the limiter roof at all.
Lubomir
Posts
0 comments:
Post a Comment