add slaney normalization

[vincentqb]

Fixes #287

[cpuhrsch]

Do we expected further normalization schemes? Does it make sense to split these normalizations out into its own layer? Are they useful in other contexts (maybe for volume normalization and such)?

[vincentqb]

Do we expected further normalization schemes?

Yes, we could, see librosa/librosa#1050. Librosa itself is in process of adding other normalization as mentioned in this pull request.

Does it make sense to split these normalizations out into its own layer?

Not according to this comment.

Are they useful in other contexts (maybe for volume normalization and such)?

The normalization is done against f_pts which is computed within create_fb_matrix. I'm not aware of other use case.

[cpuhrsch]

If you're exercising torchscript I'd pass the less trivial type which is a string instead of None.

[vincentqb]

You mean: default to empty string? We don't use that elsewhere, but sounds good to me.

[vincentqb]

done

[codecov]

Codecov Report

Merging #589 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #589      +/-   ##
==========================================
+ Coverage   88.99%   89.01%   +0.01%     
==========================================
  Files          21       21              
  Lines        2254     2257       +3     
==========================================
+ Hits         2006     2009       +3     
  Misses        248      248              

Impacted Files	Coverage Δ
torchaudio/functional.py	95.53% <100.00%> (+0.01%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b499840...7270e6e. Read the comment docs.

[vincentqb]

@mthrok -- do you have any feedback?

[mthrok]

Sorry for the late reply. Looks good to me. One nit.

[mthrok]

As a public API signature, I think Optional[str] looks cleaner.

[vincentqb]

This was made due to comment. I'll leave it as it is for now. We can always extend the str to Optional[str] without BC breaking later :)

[mthrok]

It looks to me that, that comment was meant for the type of variable to pass when running Torchscript test, not about the function signature.

[vincentqb]

If we allow None in the signature, then the code should work with/without jit when passing None. It wasn't though. Is that what you meant?

[mthrok]

If we allow None in the signature, then the code should work with/without jit when passing None.

Yes, it works.

from typing import Optional

import torch
from torch import Tensor


def bar(foo: Optional[str]=None) -> Tensor:
    if foo is None:
        return torch.zeros(1, 2)
    if foo == "a":
        return torch.ones(1, 1)

    return torch.empty(1, 1)


ts_bar = torch.jit.script(bar)

for v in [None, "a", "b"]:
    print(v)
    print(bar(v))
    print(ts_bar(v))

produces

None
tensor([[0., 0.]])
tensor([[0., 0.]])
a
tensor([[1.]])
tensor([[1.]])
b
tensor([[-2.8910e+12]])
tensor([[0.]])

also dcshift uses Optional[float] and it works fine. for both None and float input for torchscript.
#558

[mthrok]

It's just when type is optional, it firstly needs to compare against None using if var is None or if var is not None.

[mthrok]

https://pytorch.org/docs/master/jit_language_reference.html#optional-type-refinement

TorchScript will refine the type of a variable of type Optional[T] when a comparison to None is made inside the conditional of an if-statement or checked in an assert. The compiler can reason about multiple None checks that are combined with and, or, and not. Refinement will also occur for else blocks of if-statements that are not explicitly written.

[vincentqb]

Alrighty, #641 :)