mu-law companding

[bmcfee]

Reference Issue

Related to #1007 , but different.
[EDIT by @lostanlen: closes #1034]

What does this implement/fix? Explain your changes.

This PR implements mu-law compression and expansion, with and without quantization.

Any other comments?

A couple of things to consider here:

• Should we also add A-law companding? Does anyone even use it?
• Would it make sense to separate the quantization parameter from the compression parameter? Right now, it quantizes to lg(1+mu) bits, which derives from the common setting of mu=255 and 8-bit quantization. But there's technically no reason that these things have to be tied together.
• Should we worry about dtype inference based on the number of quantization levels? Numpy doesn't make it totally trivial to infer the minimum dtype for a given value range, but it's something we could do with a bit of work. It just seems wasteful to use int64 to hold 8-bit quantized values.

[lostanlen]

Thanks for doing this. It looks great but i'm curious as to the practical purpose. Given that all of this operates on IEEE 754 arithmetic, i doubt it reflects the effect of mu law in practice (e.g. audio sensing with limited resources)

Suppose that i have a WAV file in PCM (~fixed-point) format, encoded with a bit depth of 16 (or 24, or 32, etc.)
Suppose that i want to simulate how 8-bit compression affects the audio quality of that file upon listening to it.
How do i do this in librosa?

[bmcfee]

Suppose that i want to simulate how 8-bit compression affects the audio quality of that file upon listening to it.
How do i do this in librosa?

z = librosa.mu_compress(y, quantize=True)
y_compand = librosa.mu_expand(z, quantize=True)

I don't think we need to go as far as to add an explicit compand shortcut function, but above should do the trick,

[bmcfee]

One more question raised offline: should quantization be the default behavior? Or are there more compelling use cases for continuous mu compression?

[lostanlen]

LGTM. I would prefer quantize=True by default though. The main application of mu-law is to have it quantized, be it for storage or for multinomial modeling à la WaveNet. Furthermore, the quantization is actually non-trivial, with a call to np.digitize and a -int(mu + 1)//2 offset.

[bmcfee]

Ok, I'm onboard with quantizing by default.

Final question: i put this in the audio submodule, because it seemed like the most logical place. But I could also see it living under effects alongside preemphasis and other time-domain transformations. What do you think about migrating it there?

[lostanlen]

I would prefer audio over effects. Although it is true that back-and-forth companding and expansion does result in an audible effect, it's not the main purpose of why we have it here.

Please merge at your convenience

[bmcfee]

I would prefer audio over effects. Although it is true that back-and-forth companding and expansion does result in an audible effect, it's not the main purpose of why we have it here.

Please merge at your convenience

Fair enough, thanks again!

Should we bump this up to the 0.7.2 release then?

[lostanlen]

Sure. I just bumped it to 0.7.2

[bmcfee]

whoops, forgot to set quantize=True to default. Fixing and then will merge again.