Large re-amp on the torchaudio/docs

[jamarshon]

-With new features added and legacy code gets removed, the docs (rst) also have to be updated
-The current docs looks very shady/broken (some code missing e.g transforms forward) or formatted poorly
Preview: https://jamarshon.github.io/audio/

[vincentqb]

MelScale renders a little strange here.

[vincentqb]

MelSpectrogram has inconsistent ":" in subtitles, see here.

[vincentqb]

One thing that we should add: just like in #169, we should give the mapping between shapes for transformations.

[vincentqb]

Looks good to me! Thanks for doing this!

[vincentqb]

On Spectrogram.forward, the shape is listed as "Channels x frequency x time (c, f, t)". I would stick with either convention, but not both. I would lean for "a tensor of shape (channels, frequency, time)", and not abbreviations to as explicit as possible for both input and output of forward.

[vincentqb]

Do we settle "(channel, ...)" or "(channels, ...)" ? :) I'm leaning for singular, since all other words are singular. Thoughts?

[vincentqb]

Similarly, do we settle on "a tensor of size (...)" or "a tensor of shape (...)"? That's one of those size/shape/dimension discussions :)

[vincentqb]

Do we settle "(channel, ...)" or "(channels, ...)" ? :) I'm leaning for singular, since all other words are singular. Thoughts?

Also, I noticed we had agreed on n_freqs to refer to frequency, so we should update that in the documentation. But then this is a little inconsistent with time and channel. Should we have n_times and n_channels or leave it? Thoughts?

[vincentqb]

Let's use the convention described in #169 for the comments quoted below now that we've settled on it.

Do we settle "(channel, ...)" or "(channels, ...)" ? :) I'm leaning for singular, since all other words are singular. Thoughts?

channel, and singular words

Similarly, do we settle on "a tensor of size (...)" or "a tensor of shape (...)"? That's one of those size/shape/dimension discussions :)

dimensions (for "dimension names") and size for sizes (we'll avoid shape as much as we can)

Also, I noticed we had agreed on n_freqs to refer to frequency, so we should update that in the documentation. But then this is a little inconsistent with time and channel. Should we have n_times and n_channels or leave it? Thoughts?

n_freq, n_channel, n_time, etc. for sizes

[vincentqb]

See comment about #169