Retrieve information about a song's encoding/file format

[rien333]

Feature request

Clients can currently request various pieces of technical information about the current stream, such as its bitrate and samplerate (though in the latter case, the samplerate may not reflect the file's actual samplerate but the samplerate mpd has been asked to output to).

Would it be possible to also report information about the file format/encoding of the current stream? Say, whether the file in question is a mp3, or at least, mpeg encoded? That way, clients can inform their users about the technical characteristics of the files in their library, without having to guess these characteristics from the file's extension.

A naive analysis of mpd's code tells me that mpd indeed determines a file's encoding using more information than just the file's extension (though this is something of an informed guess on my part). See for example this function:

https://github.com/MusicPlayerDaemon/MPD/blob/9ff8e02e543ede2b1964e5ea3f26f00bf2ff90ec/src/decoder/Thread.cxx#L309

Being able to report the decoder that's currently being used might be a viable alternative (assuming, of course, that most decoders are file format specific).

[MaxKellermann]

That part only knows which decoder plugin is being used. We could provide that piece of information easily. Would that be good for you?

[rien333]

Would that be good for you?

Hm, on second thought, that doesn't really aid the use case I'm after. I was hoping to add some more technical information about currently playing file to my favorite mpd client, which currently only the displays bitrate:

My assumption was that "if the current decoder is mad/vorbis, the file is probably an mp3/ogg file". However, that assumption is misguided on multiple counts.

For instance, mpd support ffmpeg as a decoder, which doesn't allow you to infer anything about the file you're currently playing. After all, ffmpeg decodes every music format I've ever heard of, and then some.

That said, being able to query the current decoder could be of interest to some people. I for one don't know if my mpd installation ever uses anything but ffmpeg, even though on Arch, mpd is configured with support for a plethora of decoders.

[MaxKellermann]

Then what do you want, exactly? "mp3" is neither a container/file format nor a codec. Neither is "mpeg". "mp3" is a commonly used filename suffix for MPEG Layer 3 audio, but filename suffixes are not unique; think about "ogg" which is just a container format that commonly contains Vorbis, FLAC or Opus (or arbitrary other codecs). You could name MIME types, but those aren't useful either, because they, too, often only describe the container format, not the actual codec. But I assume you want to know the codec. What are canonical names for all the codecs and how does MPD obtain them?

[rien333]

"ogg" is just a container format that commonly contains Vorbis, FLAC or Opus (or arbitrary other codecs)

I did not know that, sorry. And I see why my request is ambiguous. Being able to query the file/container format would be great, but so would being able to query the underlying codec. In hindsight, I shouldn't have shoehorned both these things in one issue.

I can update the issue based on which of these two things are most easily implemented. Or I could close in case neither option is particularity viable.

What are canonical names for all the codecs and how does MPD obtain them?

Hm, this might be difficult indeed, because I imagine MPD would have to obtain a codec name by asking the decoder plugin in question (though I could be wrong again). That, in turn, will probably lead to a mess/lots of extra code, because there's no standard way to ask that.

If a codec goes by different names I suppose people interested in that information would probably recognize the different variants. But yeah, there's an additional problem there, which is probably outside of the scope of MPD to fix.

[MaxKellermann]

If a codec goes by different names

That's why I asked the codec name to be "canonical", so there is one reliable name for each codec. It does not need to be technically complete/correct and it does not need to be human-readable - for example, "mp3" instead of "MPEG Layer 2 Audio" would be fine, and "vorbis" instead of "Vorbis". For each supported codec, a code name would need to be defined and documented.

If codec names are not canonical, then clients would have the burden to normalize them. Such complexity doesn't belong in clients, MPD is the entity that should provide useful abstractions to clients.

Your feature request is possible, it just needs somebody to do it (properly). This effort does not need to be complete - the initial commit does not need to add support to all decoder plugins and all supported codecs. A partial implementation is fine, and the MPD status would just omit the line when there is no well-known codec name.