Add feature to specify transcode behavior for mono tracks

Feature description:

An additional setting somewhere (ideally one next to both of the existing menus where you can choose a transcode bitrate), with an option where the user can choose what behavior should happen if a mono file would be transcoded to one of these higher bitrates, I imagine something like an option between playing/downloading at original quality or transcoding to the highest compatible bitrate.

Problem solved:

When downloading a mono file with the download settings set to transcode downloads to 256 or 320 kbps (or when the mobile/wifi maximum bitrate is set to these values), the download (or playback) will fail. The reason is because the opus codec only supports up to 256kbps per channel, so these higher bitrate options on mono files cause the transcode to fail. There isn’t really any information given by the app or media provider about this failure (at least as far as my setup goes, using Navidrome) so the user has a hard time figuring out why certain tracks fail when others succeed, and if they do realise why, have to go through downloading those specific files at either original quality or a lower bitrate, which can be frustrating to do if they are in an album with stereo files (or have to set their maximum bitrates to original quality or lower values).

(Sorry for the potentially confusing brackets, I only realised while writing this that there were playback bitrate options and didn’t want to rewrite the whole thing)

Brought benefits:

Adding an option to specify the behavior would change this problem (which I’m surprised isn’t more common) from an unintuitive error that gives no feedback to the user (I had to go into the ffmpeg logs inside the docker container running Navidrome to get an idea of why it was failing, neither Navidrome nor Symfonium gave any clue) to something that handles itself automatically and doesn’t confuse the user.

Additional description and context:

Hi, sorry if this is an overly specific feature since I couldn’t find any record of anyone else ever running into the issue, but it was such a hassle to figure out and it is kind of a big problem if you happen to run into it that I figure some sort of solution could be made. And if not then at least it’s documented for anybody running into it in the future. Amazing work on the app so far, it’s really stunning.

With the current api this is something that needs to be handled on Navidrome side.

There is a new OS Api that Navidrome could also handle to better handle this at API level.