Reading file may hang if offset is greater than file duration

[frankenjoe]

I have a MP3 encoded stereo file of the following length:

>>> audiofile.duration(path)
3.996734693877551

Reading in the full file works:

>>> audiofile.read(path)
[[0. 0. 0. ... 0. 0. 0.]
 [0. 0. 0. ... 0. 0. 0.]] 44100

Also reading with an offset of 3 seconds works:

>>> audiofile.read(path,   offset=3.0,)
[[0. 0. 0. ... 0. 0. 0.]
 [0. 0. 0. ... 0. 0. 0.]] 44100

But when I try to read with an offset greater than the file duration it hangs instead of returning an empty array.

I tested with a WAV file and there it worked. So it seems to be related to reading encoded files with sox:

[hagenw]

This seems unfortunate as the bug is coming from sox.

One easy solution would be to change (inside audiofile.read())

            convert(file, tmpfile, offset, duration)
            signal, sampling_rate = soundfile.read(
                tmpfile,
                dtype=dtype,
                always_2d=always_2d,
                **kwargs,
            )

to

            convert(file, tmpfile)
            signal, sampling_rate = soundfile.read(
                tmpfile,
                offset=offset,
                duration=duration,
                dtype=dtype,
                always_2d=always_2d,
                **kwargs,
            )

But this has the disadvantage of having to convert the whole file even if only a very short segment of it is requested.

So maybe we first ask how long the file is and adjust duration accordingly, or return an empty array directly if offest is already out-of-bounds.

[hagenw]

In order to check the exact duration of the file, we also need to convert it first completely to WAV, so I guess we can just go with my proposed change to first convert the whole file.

[hagenw]

I added a test for out-of-bounds offset reading of a MP3 file in #104.

On Github all tests passes, but it might still be safer to first do the conversion.

[hagenw]

soundfile does now also support MP3 files, so the bug should no longer happen for those files.

There might still some file formats left that are read by sox and not ffmpeg, but we would need to find those first.
Not sure if this is worse the effort.