Skip to main content
Topic: Advanced Limiter: Why does it manipulate what it doesn't need to? (Read 3640 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Advanced Limiter: Why does it manipulate what it doesn't need to?

Lately I've been playing around a little with the Advanced Limiter DSP found in foobar2000. Now I've found out (by using the Binary Comparator plugin found on the foobar2000 website) that it does not only limit the signal when it goes above 1, but also when it's below.

For that I've converted a track to WAV with no DSP enabled and RG set to "off". Then I used the Binary Comparator on the converted and the original file. There was no difference, as expected:

Code: [Select]
All tracks decoded fine, no differences found.

Comparing:
"H:\Persone - Povus Esti Simple\Povus Esti Simple.cue" / index: 11
"F:\Temp\1 Nun Mallumas Ekstere.wav"
No differences in decoded data found.


Now what I get when I ONLY enable the advanced limiter in DSP (all other options are left as they are):

Code: [Select]
Differences found in 1 out of 1 track pairs.

Comparing:
"H:\Persone - Povus Esti Simple\Povus Esti Simple.cue" / index: 11
"F:\Temp\1 Nun Mallumas Ekstere.wav"
Differences found: 4232827 sample(s), starting at 0.5084127 second(s), peak: 0.0000610 at 2.0639229 second(s), 2ch


RG value of the source track: -1.78 dB
peak of the source track: 0.746246

RG value of the track created by Advanced Limiter: -1.78 dB
peak of the track created by Advanced Limiter: 0.746185

It happens with many (if not all) tracks, that's just an exemple. So you can try it yourself if you don't believe.
Why does the Advanced Limiter mess around with the signal when it's peak is so low? That's a bug, isn't it?

EDIT: Maybe I should add that I'm using foobar2000 v0.9.6.5 together with it's included Advanced Limiter.
flac 1.2.1 -8 (archive) | aoTuVb5.7 -q 4 (pc, s1mp3)

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #1
The difference is twice the size of the LSB for 16-bit audio (i.e. if you multply the -1 to +1 normalised amplitude by 32768, it's the integer value 2). Hopefully it's a good 80 dB or more quieter than your typical audio. (The same difference of 2 in 16-bit applies whether comparing the RG peak or the max difference reported by the binary comparator at roughly the 2 second point in the file)

It's conceivable that the source was lossy, so is dithered in both conversions or you have FB2K set to always dither (but always with no noise shaping). If the dither is a truly random pattern (i.e. not deterministically seeded identically for each rendering of the file) and it's unshaped triangular dither, then a maximum difference of 2 is probably to be expected at some point in the file as one random number pushes the sample to the next higher level and the other one (when doing the conversion again) pushes the sample to the next lower level.

Have you tried the simple case of exporting the file with no DSP twice and comparing those (which should be identical other than the effect of any dither)? This could explain a difference of twice the LSB and needs to be ruled out before we call into question the Advanced Limiter.
Dynamic – the artist formerly known as DickD

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #2
Thanks for your answer!

The difference is twice the size of the LSB for 16-bit audio (i.e. if you multply the -1 to +1 normalised amplitude by 32768, it's the integer value 2). Hopefully it's a good 80 dB or more quieter than your typical audio. (The same difference of 2 in 16-bit applies whether comparing the RG peak or the max difference reported by the binary comparator at roughly the 2 second point in the file)


At least the difference is not audible for me (I've done an ABX Test but failed badly). I understand that it's very small, but nevertheless it is there.

It's conceivable that the source was lossy,

Nope, it's not. It's 44100 Hz Stereo 16-bit PCM Wave.

so is dithered in both conversions or you have FB2K set to always dither (but always with no noise shaping).

No, I've set foobar to never dither in the 'Other' tab of the Converter window, so there should be no dither.

If the dither is a truly random pattern (i.e. not deterministically seeded identically for each rendering of the file) and it's unshaped triangular dither, then a maximum difference of 2 is probably to be expected at some point in the file as one random number pushes the sample to the next higher level and the other one (when doing the conversion again) pushes the sample to the next lower level.

Maybe the Advanced Limiter itself dithers?

Have you tried the simple case of exporting the file with no DSP twice and comparing those (which should be identical other than the effect of any dither)? This could explain a difference of twice the LSB and needs to be ruled out before we call into question the Advanced Limiter.


Yes, they are absolutely identical (No differences in decoded data found). Even converting the file twice with the Advanced Limiter enabled produces exactly identical output. I've also tried to put the EQ with all controls set to zero in the DSP chain: It has absolutely no influence on the output.

EDIT: Maybe I should make clear that the EQ was alone in DSP chain. I suspect foobar to go to 32-bit mode when using Advanced Limiter and rounding back to 16-bit when saving to WAV. Maybe that's the problem. I'll go investigating.

EDIT2: No, that's not the problem. I've set foobar to output 32-bit WAV. Still I get different output between using the Advanced Limiter and not using it.  (The file created by not using it is also different from the original one (why? shouldn't 16-bit --> 32-bit be lossless!?) but what I mean is that both converted files are different). The problem must definitely be in the Advanced Limiter itself.
flac 1.2.1 -8 (archive) | aoTuVb5.7 -q 4 (pc, s1mp3)

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #3
I passed 32-bit float WAV through Advanced Limiter. It really changes signal. Approximately, out_signal = in_signal * 0.9999 or out_signal = in_signal / 1.0001

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #4
So where can one file a bug for foobar2000? It certainly is one, isn't it? While it might be okay for listening purposes, I think it's no good for use with the Converter.
flac 1.2.1 -8 (archive) | aoTuVb5.7 -q 4 (pc, s1mp3)

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #5
I made the limiter trigger on clip or near-clip. Exact parameters are forgotten, and it's likely trimmed up via more efficient coding since original code.

It's indeed originally only for listening, for conversions you should already know what peak your files have.

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #6
Okay so there's nothing one can do about that, right?
I understand that it's better to attenuate the input as required so that it doesn't clip. But then again, there might be situations where one has to achieve a given loudness without clipping.

For now I think it's better not to use it for converting.
flac 1.2.1 -8 (archive) | aoTuVb5.7 -q 4 (pc, s1mp3)

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #7
For now I think it's better not to use it for converting.
I guess it depends on what you are converting the files for. I use Advanced Limiter when creating silence-skipped and a bit compressed files for my DAP and couldn't care less about slight volume differences.
Full-quoting makes you scroll past the same junk over and over.

Advanced Limiter: Why does it manipulate what it doesn't need to?

Reply #8
For now I think it's better not to use it for converting.
I guess it depends on what you are converting the files for. I use Advanced Limiter when creating silence-skipped and a bit compressed files for my DAP and couldn't care less about slight volume differences.


Indeed, and not to mention this is completely inaudible to gasmann's example.
To be harsh this is unnessesary bitnitpicking.

 
SimplePortal 1.0.0 RC1 © 2008-2020