Skip to main content

Something that I have found frustrating about playback of FLAC encoded files (on a local media server) is that playback can be very inconsistent, and it’s often not obvious why.

After a bit of investigation, it seems that one reason is that the track can be encoded in a way that Sonos doesn’t support, and yet the system tries to play it anyway. The example I have here is OK (2-channel, 44.1kHz) except for one parameter: it is encoded at a bit-depth of 32, while Sonos only officially supports up to 16 bit-depth.

The problem is that the track plays OK for about 2 minutes and then just stops playing. Oddly other tracks from the same album - also encoded with bit-depth of 32 - play fine to the end. If I re-encode the problem track with bit-depth of 16, it plays OK to the end.

My request is this: the bit depth is readable in the track metadata before playback even starts. Please can we have tighter enforcement so that the system simply refuses to play a track if it is not in a supported format? IMO it is preferable for the system to do this (and, critically, to return an appropriate error message) than to try to play it and fail (with no error message).

Hi @Antifon 

Thanks for your post!

Thank you - I've marked this thread as a feature request and it will be seen by the relevant teams for consideration. Keep the ideas coming!

By the way, we support bit depths of up to 24 bit.


Thanks Corry - I had noticed that 24-bit is now supported, though 32-bit seems the more commonly used option. It seems like tighter enforcement should (in theory) be an easy change to make, though I appreciate that at present there are probably other higher priority demands on your dev team!


Hi @Antifon 

We have supported 24 bit for longer than I have worked here, which has been a while.

Given that it is practically impossible to identify 24 bit audio as compared to 16 bit in a blind test, I imagine there is not much call for 32 bit use or support. I would not expect 32 bit support anytime soon - especially as it takes up extra space to store and transmit (the latter being key to Sonos performance) . What you suggest, however, is fair - if a Sonos speaker is not going to accept 32 bit, it should not start playing it.

You might be right there!


We have supported 24 bit for longer than I have worked here, which has been a while.

Understood, but the problem is that if I use an internet search engine to find what bit depths are supported, my first hit will be this one:

https://docs.sonos.com/docs/flac-best-practices

And that clearly says “we only support 16-bit FLAC”.

And agreed - I can’t really see why anyone would choose to be so wasteful of bandwidth but… people seem to like doing it!


Hi @Antifon 

You are correct - it does indeed say that! Thanks for providing the link - I’ll see if I can get that page updated.

It is interesting that that is the first page you come across - I would have hoped it would be this one: Supported audio formats for Sonos music library. For me, when searching “sonos flac bit depth”, it is the first result. What search term were you using, please? We may be able to tune results for that too - I’m unsure, but it would be worth checking.

Arguments could be made for using higher bit depth and sample rates in the recording studio, but once audio is being delivered to the listener the advantages quickly fall away.


Correction - the first result that I get back is the one that you link to. That page does not (as far as I can see) tell you the supported bit depth, but the table on that page has a link to FLAC under the Codec column, and that links to the page with the out of date (we only support 16-bit depth) info in it.

 


We have supported 24 bit for longer than I have worked here, which has been a while.

Understood, but the problem is that if I use an internet search engine to find what bit depths are supported, my first hit will be this one:

https://docs.sonos.com/docs/flac-best-practices

And that clearly says “we only support 16-bit FLAC”.

And agreed - I can’t really see why anyone would choose to be so wasteful of bandwidth but… people seem to like doing it!

For myself, the main reason I usually end up with Flac files with sample rates, rather than bit depth, above the Sonos playback spec is because my Qobuz subscription has a substantial discount when purchasing the hires versions from the Qobuz store. The savings I make buying the hires vs cd version more than covers the higher subscription cost.

For streaming it is a non-issue as Qobuz is limited to match my playback device capabilities, but for the purchased downloads they either need resampling or played back on other devices.

32 bit audio has two different versions.

32 bit float has definite uses in the sound recording, digital studio and production side.

32 bit int, such as that used by flac, helps sell to a specific segment of the consumer market but is usually best to keep well away from that can of worms. 😂


Hi @Antifon 

Correction - the first result that I get back is the one that you link to. That page does not (as far as I can see) tell you the supported bit depth, but the table on that page has a link to FLAC under the Codec column, and that links to the page with the out of date (we only support 16-bit depth) info in it.

I beg to differ:

Perhaps you are not looking at the same page as I am, however - I deliberately gave you a link that will automatically adjust to your locale, and the screenshot above is from the UK’s en-gb (in the URL of the page) version, but the US’s en-us version shows the same. Which version are you looking at, please?

URL in my Browser

 


Ah yes, we are looking at different pages - I was going by the page title but I didn’t check the complete URL. The page that first appears for me when I search for “Sonos supported audio formats” is this one:

https://docs.sonos.com/docs/supported-audio-formats

It has a link in it (embedded in the table I mentioned) which points to the erroneous info here:

https://docs.sonos.com/docs/flac-best-practices

I guess this is a problem when the same document (originally the same) gets put in multliple locations. It’s then hard to keep track of which ones have been kept up to date and which haven’t!


Hi @Antifon 

We’ve already flagged the out-of-date documents with the web team, so that should be resolved soon. I am still puzzled over your search results, however. Obviously, we want the more relevant results to show up when searching.

When I search ““Sonos supported audio formats” (without quotes), I get my linked support page as the first result. I re-read your previous post and noticed the phrase “if I use an internet search engine to find”, when most would probably say “when I Googled it”. Are you searching on Google, or another search engine like Bing, for example?

 


Certainly not Google - I’ve not used Google for many years, not least because they dominate the search engine domain, and there is evidence to suggest that they abuse that power.

At the moment I use DuckDuckGo.


Hi @Antifon 

Well that explains it! Thanks!

I’m not sure if my manager will be in a position to improve the results on DuckDuckGo, but I will certainly report it.


@Corry P while ddg uses many sources, its primary search engine source is bing.

Performing the same search on Bing does return the docs website above the support website links, the same as DuckDuckGo, so if the Bing search results order can be influenced that may well reflect in ddg.