Create Audio feature
For optimal storage, it would be better to:
- store only the audio file path in the cache Arrow file
- perform decoding of the audio file (into audio array and sample rate) on the fly, while loading the dataset from cache (or by adding a convenient `load_audio` function) Thanks a lot @lhoestq for your helpful insights! 🤗  Just one step before having a first running example to benchmark.

Decision to make: how to call the function `dataset.features.decode_example`:
- The usual approach until now in speech applications: call it in a subsequent `.map` function
  - Pros: multiprocessing can be used out of the box
  - Cons: large disk storage required for caching decoded audio files, although having it cached will enhance speed for further usage
- Approach suggested by @lhoestq (see above: https://github.com/huggingface/datasets/pull/2324#discussion_r660758683): doing it in formatting
  - Pros: no large disk storage required, as it will be done on the fly while iterating on the dataset
  - Cons: it is not cached; need to implement multiprocessing for this case
- Other pros/cons for the previous options?
- Other options?

cc: @lhoestq @patrickvonplaten @anton-l  @albertvillanova I'm in two minds about this, to be honest. For example, if we consider CommonVoice, which is encoded in lossy `mp3`:

- If we decompress `mp3` into raw `wav` arrays,  loading a batch will speed up about 40x.
- However, a 60gb English mp3 dataset will blow up to about 600gb raw (iirc), which is why loading on-the-fly (optionally?) could be very beneficial as well. Users can do the conversion from mp3 to wav by themselves if they want to using `map`.

IMO it's better if we can keep the decoding part with the minimal features to be both easy to understand and flexible, i.e. just having the on-the-fly decoding of the audio data (with the sampling rate parameter)

Decompressing from mp3 to wav sounds like an optimization that depends on the problem that the user wants to solve, the constrains from its environment (disk space, IO speed), and other parameters (optimal training speed for example). Therefore I would leave this to the user to decide whether it has to do it or not.

Let me know what you think about this @albertvillanova, In my opinion the pros strongly outweigh the cons in the @lhoestq's suggestion which is why I think we should go forward with it. 

The cons:
- "the operation won't be cached" is not to important as the user will most likely access just a couple of audio array to see how it looks like and then for the "full" feature extraction she/he will make use of `.map(...)` anyways which means that the result will be cached. 
- Regarding the multi-processing - if I understand correctly it'll follow the same logic here -> the user will only access some audio arrays for testing playing around with the model but use `.map(...)` for larger operations where multi-processing would still work as before.

The advantages mostly solve the main poinpoints being:
- exploding disk space
- bad user experience since the audio is not loaded on the go

=> So I'm very much in favor of the "direct-access" feature Update: I've retaken this issue.

If the decoding logic is implemented when "examples are accessed", then if afterwards we use the `.map`, it tries to apply the decoding twice (as maps iterates over the examples, thus "accessing them", before trying to apply the map function)...

I'm thinking on some other approach... I have reimplemented the previous approach, so that we can discuss about it: examples are decoded when accessed. What about creating a new specific formatting, just for decoding? This would be only active within a context manager. Hi @lhoestq, as we discussed, I've followed your suggestion of implementing the decoding step within the formatting logic: extract-decode-format. Feel free to tell me what you think.

@patrickvonplaten and @anton-l, could you have a look at the use case in the test (https://github.com/huggingface/datasets/pull/2324/files#diff-58e348f6e4deaa5f3119e420a5d48ebb82875a78c28628831748fb54f59b2c78R34-R50) and tell me if this is aligned with your needs? Thanks. Hi @lhoestq, if you validate this approach, we could merge the Audio feature this (or early next) week. Sure it looks nice this way :) Feel free to continue !
Create `Audio` feature to handle raw audio files.

Some decisions to be further discussed:
- I have chosen `soundfile` as the audio library; another interesting library is `librosa`, but this requires `soundfile` (see [here](https://github.com/librosa/librosa/blob/main/setup.cfg#L53)). If we require some more advanced functionalities, we could eventually switch the library.
- I have implemented the audio feature as an extra: `pip install datasets[audio]`. For the moment, the typical datasets user uses only text datasets, and there is no need for them for additional package requirements for audio/image if they do not need them.
- For tests, I require audio dependencies (so that all audio functionalities are checked with our CI test suite); I exclude Linux platforms, which require an additional library to be installed with the distribution package manager
  - I also require `pytest-datadir`, which allow to have (audio) data files for tests
- The audio data contain: array and sample_rate.
- The array is reshaped as 1D array (expected input for `Wav2Vec2`).

Note that to install `soundfile` on Linux, you need to install `libsndfile` using your distribution’s package manager, for example `sudo apt-get install libsndfile1`.