[PROBLEM] MPD not recognizing the .aif file extension

[Tim Curtis]

It appears to be an issue with ffmpeg due to the fact that [aif] is no longer listed in the list generated by ffmpeg -formats

From the ASR moOde Thread user @amper42 posted a ticket to the ffmpeg Bug Tracker.
https://trac.ffmpeg.org/ticket/11595

The response to the ticket indicates that .aif file extension should be supported (even though it's not a listed format). If thats the case then possibly the issue is upstream in MPD when it probes the file to determine which codec to use.

I don't have the bandwidth to debug this issue but if someone else wants to take on the challenge then by all means go for it :-)

[TheOldPresbyope]

Aha. That revives a thought I had previously about mpd. Something to chase with a glass of wine at the ready.

Regards,
Kent

[Tim Curtis]

Aha. That revives a thought I had previously about mpd. Something to chase with a glass of wine at the ready.

Regards,
Kent

lol, just don't do any drunk coding ;-)

[TheOldPresbyope]

Grrrr. Tracing through MPD's C++ codebase makes my brain hurt. In the end, I resorted to putting ChatGPT to work. (Motto: Let a minion do the thinking while you enjoy the wine.)

The core problem appears to be that, no matter what file formats/types ffmpeg can actually process, the ffmpeg decoder plugin sources don't explicitly declare ".aif" / "audio/aiff" as an recognized file extension/MIME-type pair so the mpd build process doesn't pick it up and add it to its list of known extensions (as can be seen in the mpd -V output).

The way all this decoder information gets manipulated in mpd makes me dizzy. In the end, mpd builds an in-memory hash table of the mappings during startup. (This way, it can accommodate mpd.conf settings.)


I think one either has to add ".aif" to ffmpeg sources and rebuild it, or find a way to make mpd recognize ".aif" as a synonym for ".aiff" when scanning files and map it to the ffmpeg decoder plugin accordingly. Maybe I'll get lucky and find an easy way to do that but it seems counter to good practice: MPD expects the plugins to tell the truth about their capabilities.

Or, it could be I'm having a senior moment and someone with better neuro-plasticity will immediately see a trivial fix.

An alternative would be to rebuild mpd with the sndfile decoder plugin included. It also recognizes ".aif". I have no idea what the implications of doing that are in the bigger picture.

Regards,
Kent

ETA - Just realized a better motto is "let the minion do the thinking while you do the drinking." Don't know how I missed that.

[Tim Curtis]

Grrrr. Tracing through MPD's C++ codebase makes my brain hurt. In the end, I resorted to putting ChatGPT to work. (Motto: Let a minion do the thinking while you enjoy the wine.)

The core problem appears to be that, no matter what file formats/types ffmpeg can actually process, the ffmpeg decoder plugin sources don't explicitly declare ".aif" / "audio/aiff" as an recognized file extension/MIME-type pair so the mpd build process doesn't pick it up and add it to its list of known extensions (as can be seen in the mpd -V output).

The way all this decoder information gets manipulated in mpd makes me dizzy. In the end, mpd builds an in-memory hash table of the mappings during startup. (This way, it can accommodate mpd.conf settings.)


I think one either has to add ".aif" to ffmpeg sources and rebuild it, or find a way to make mpd recognize ".aif" as a synonym for ".aiff" when scanning files and map it to the ffmpeg decoder plugin accordingly. Maybe I'll get lucky and find an easy way to do that but it seems counter to good practice: MPD expects the plugins to tell the truth about their capabilities.

Or, it could be I'm having a senior moment and someone with better neuro-plasticity will immediately see a trivial fix.

An alternative would be to rebuild mpd with the sndfile decoder plugin included. It also recognizes ".aif". I have no idea what the implications of doing that are in the bigger picture.

Regards,
Kent

ETA - Just realized a better motto is "let the minion do the thinking while you do the drinking." Don't know how I missed that.

Interesting. Does the plugin source declare other file extensions for example .aiff, .flac etc?

[TheOldPresbyope]

@Tim Curtis

From SndfileDecoderPlugin.cxx

Code:

static const char *const sndfile_suffixes[] = {
       "wav", "aiff", "aif", /* Microsoft / SGI / Apple */
       "au", "snd", /* Sun / DEC / NeXT */
       "paf", /* Paris Audio File */
       "iff", "svx", /* Commodore Amiga IFF / SVX */
       "sf", /* IRCAM */
       "voc", /* Creative */
       "w64", /* Soundforge */
       "pvf", /* Portable Voice Format */
       "xi", /* Fasttracker */
       "htk", /* HMM Tool Kit */
       "caf", /* Apple */
       "sd2", /* Sound Designer II */

       /* libsndfile also supports FLAC and Ogg Vorbis, but only by
          linking with libFLAC and libvorbis - we can do better, we
          have native plugins for these libraries */

       nullptr
};

Some of those are dusty relics of the past (anyone other than me ever work with audio on workstations from folks like SGI, Sun, and DEC?)


Almost every plugin seems to declare differently so it's hard (for me, at least) to compare them head-to-head.

InterWeb™ opinion appears to be that, due to its optimized codebase, ffmpeg offers better performance decoding AIFF files in realtime in linux than does sndfile (well, the code in libsndfile, really). I also see words like "robustness" but who knows what that means without any qualifiers.

Regards,
Kent

[Tim Curtis]

So it sounds lie maybe the issue is that the ffmpeg plugin used by MPD doesn't declair aif, it only declares aiff, correct?

[Nutul]

It all sounds fantastic, from a diveing-into-the-code perspective, but from the lazy-developer-as-I-am POV, a straight

Code:

mv *.aif *.aiff

looks pretty reasonable... 
After all, AIFF is A.udio I.nterchangeable F.ile F.ormat, hence the 4-letter acronim is more adequate...
I mean, it's like we used .fla and .flac for FLAC files, just because of (what it indeed looks like) DOS 8.3 filenames...

[TheOldPresbyope]

It all sounds fantastic, from a diveing-into-the-code perspective, but from the lazy-developer-as-I-am POV, a straight

Code:

mv *.aif *.aiff

looks pretty reasonable... 
After all, AIFF is A.udio I.nterchangeable F.ile F.ormat, hence the 4-letter acronim is more adequate...
I mean, it's like we used .fla and .flac for FLAC files, just because of (what it indeed looks like) DOS 8.3 filenames...

No argument here. I just enjoy an occasional round of yak shaving.

Since I don’t actually use AIFF, it’s all the same to me.

Regards,
Kent

[steve4star]

Not claiming an experience or knowledge of the plugin mechanism, however

https://github.com/MusicPlayerDaemon/MPD...Plugin.cxx

Is missing aif

ETA: it looks for the file metadata, not sure if it use file extension name ?