-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retrieve information about a song's encoding/file format #2118
Comments
That part only knows which decoder plugin is being used. We could provide that piece of information easily. 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 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. |
Then what do you want, exactly? |
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.
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. |
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. |
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:
MPD/src/decoder/Thread.cxx
Line 309 in 9ff8e02
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).
The text was updated successfully, but these errors were encountered: