Wrong audio metadata stored for MP3 files in dependencies about audb

[frankenjoe]

I guess this can happen if we publish on a device that does not have MP3 support when using audiofile.

I think it's because of this line: https://github.com/audeering/audb/blob/master/audb/core/dependencies.py#L164 Since we don't know which formats are supported by audiofile, we are pretty conservative here and only read the meta data if we know a file is WAV or FLAC.

[hagenw]

OK, so it's not really a bug, but a case where it would make sense to return None instead of 0 ;)
But I still think returning 0 is ok, if we don't know it.

I think one of the other reasons why we didn't included the metadata calculation for formats beside FLAC and WAV is that it can take longer for other formats, compare https://audeering.github.io/audiofile/benchmark.html#id4

So maybe we should just stay with the current behavior?

[frankenjoe]

So maybe we should just stay with the current behavior?

I would say so. And we should encourage users to always convert audio files to WAV and FLAC.

[hagenw]

And we should encourage users to always convert audio files to WAV and FLAC

Maybe internally, but for other users there might be good reasons to store the data in the original format.

Also internally we loose the information what was the original format when not storing it in a table (might not be needed, but just wanted to mention it).

[frankenjoe]

Maybe internally, but for other users there might be good reasons to store the data in the original format.

At some point I had the idea that a user can register custom functions that read the duration, sampling_rate, etc. for file types that we do not support with audiofile. But I dropped it as I didn't see a real use-case for the moment.

[hagenw]

As we will not change this immediately, but we should also revisit it at some point I marked it as wontfix