audio: Info length and rate returns different values for different backends

🐛 Bug

torchaudio.info returns the info objects directly from the respective backend. Due to same property naming, users might forget to check how the metadata is calculated. This results in metadata being reported differently depending on which backend is reported. E.g. sox calculates the length summed across channels whereas soundfile does this per channel (correct)

I would propose to add wrapper for the info objects that - independent of the backend - the most important metadata (length and rate) is identical.

Currently, the sox backend reports a missleading length and the rate parameter is of type float instead of int.

To Reproduce

path =  "any/wavfile.wav"
# soundfile
torchaudio.set_audio_backend("soundfile")
info = torchaudio.info(path)
print(si.length)
print(type(si.rate))

# sox
torchaudio.set_audio_backend("sox")
info = torchaudio.info(path)
print(si.length)
print(type(si.rate))

Expected behavior

soundfile reports the correct metadata, sox should be corrected so that:

# sox
torchaudio.set_audio_backend("sox")
info = torchaudio.info(path)
print(si.length // si.channels)
print(int(si.rate))

Environment

torchaudio==0.5.0 from pypi

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 19 (10 by maintainers)

Most upvoted comments

Regarding the first issue, this is probably a just a matter of setting the right vocabulary to make a formal distinction between frames and samples as it’s done in libsndfile. Over there:

A frame is just a block of samples, one for each channel.

and

…seeks are defined in number of (multichannel) frames. Therefore, a seek in a stereo file from the current position forward with an offset of 1 would skip forward by one sample of both channels.

which makes totally sense to me (also soundfile is the defacto standard when it comes to proper handling of audio I/O). However this would probably lead to too many changes here but it makes sense to put the definition that is used here (“we define samples are the number of frames in an audio signal per channel”).

For the second, I second adding a stereo test for consistency of course. 😃 One of the two would need to be updated to match the other. Since sox has been there longer, soundfile’s si.length is the one that should be adjusted. A warning when someone invokes info with soundfile would need to be raised, and the documentation aligned.

I agree this is probably the simplest solution

Do you want to open pull requests for this?

I started with a new test #639 that is expected to fail and can propose a fix for this as well ( in the same PR?)

faroit on May 15, 2020