Zp 24/96

I am shocked you can't see why:

It's because it drags eyeballs and customer use AWAY FROM THE SONOS controller environment to a third party UPnP Control point like bubbleupnp.

Because the number of eyeballs is negligible. Why put significant development resources into solving a problem which only affects a tiny number of people, and for which there are easy workarounds for.

I'm astounded you think Sonos should spend any time on this at all, given the very small number of people who it would benefit.

BarryM has provided another solution: transcode your files into a standard resolution version. This is, actually, the most sensible option as it's not particularly difficult to do, disk space is cheap, and you only need to do it once for each file.

May I politely ask why you've not looked at this approach as I am sure it's been suggested many times in the past.

I'm expecting a rational reason, by the way. Something like "I don't see why I should have to" is not a rational reason.

Cheers,

Keith

Guys, can we calm down here please. It's getting a bit silly on all sides.

Keith
Possibly - and if I came across as rude, sorry. I did not mean to. I expressed genuine puzzlement - but more strongly than I ought to have.

In fact users with local libraries of any format probably represent a diminishing share of Sonos' new customers, who increasingly pull all their music from the Internet.


Exactly. I would guess well over 90% of customers do not bother with locally stored files anymore. Ripping CDs is a chore. Virtually all of my ripped CDs are now readily available on Google Music, in transparent 320kbps form, so the local NAS is rarely used.

Because the number of eyeballs is negligible. Why put significant development resources into solving a problem which only affects a tiny number of people, and for which there are easy workarounds for.

I'm astounded you think Sonos should spend any time on this at all, given the very small number of people who it would benefit.

BarryM has provided another solution: transcode your files into a standard resolution version. This is, actually, the most sensible option as it's not particularly difficult to do, disk space is cheap, and you only need to do it once for each file.

May I politely ask why you've not looked at this approach as I am sure it's been suggested many times in the past.

I'm expecting a rational reason, by the way. Something like "I don't see why I should have to" is not a rational reason.

Cheers,

Keith

Hi Keith.

I have always found your support and replies on this forum measured, rational and logical. So I thank you for your patience in this matter.

I continue to use Sonos as my main multiroom setup. All these years on, because IMHO it remains THE BEST digital networked multiroom platform. And has by far and away the most outstanding GUI. Others have come and gone. As we all know. This however doesn't mean passionate Sonos users, who want an easy way of dealing with our 24 bit files, don't have a legitimate case to continue to explore better ways of handling these files both outside and within the Sonos platform. Trancoding "on the fly" is one of these ways. As is the others mentioned by BarryM. There are two rational reasons why I favour transcoding over the BarryM method. The first is time. Once set up, transcoding takes no further time. The second is transcoding leaves the end user with one library to manage. Both 24 and 16 bit files can remain in the one library. I accept in full why Sonos may never want to support 24 bit. I accept this. It would make it easier for me obviously if Sonos allowed 3rd party UPnP server share points. To this day, I'm still not sure why they can't do this. Whether it's too difficult, it interrupts their own menu handling, or they simply don't want to: I have no idea. I guess I will have to accept this as well. In the meantime, I'll continue to use Sonos, the great Rhapsody, Pandora and Spotify and other services (that work so well within the Sonos GUI) and use this BubbleUPnP workaround to stream 24 bit files: both to additional non Sonos renderers which can directly handle 24 bit within my network, and as 16bit transcoded files directly to my Sonos ZP's. It's messy and obviously not ideal. Of course I'd much rather remain 100% within the Sonos GUI, but at the moment, the company leaves me with no other choice.

For some time now, these files have been available to use and purchase. As I have said in the past, it really is nobody else's business to tell anyone else, whether or not there is "any difference" between these files and 16 bit files. And whether or not any individual should purchase them. That's irrelevant. The arguments for/against will continue add infinitum! 🙂

Some users just want to play 24 bit files. With a minimum of fuss. It is as simple as that. At the end of the day, "someone owns" the problem here. It's either Sonos or customer's who want to play them.

Other followers of this thread can be the judge who that might be.

Cheers and thanks as always for your help and constructive comments in this matter.

Regards

Exactly. I would guess well over 90% of customers do not bother with locally stored files anymore. Ripping CDs is a chore. Virtually all of my ripped CDs are now readily available on Google Music, in transparent 320kbps form, so the local NAS is rarely used.

I agree with Ratty and these comments as well. I too, am probably playing more and more music from streaming services and less from my NAS. The problem still won't go away though. It will resurface when the first 24bit streaming service becomes available.

Exactly. I would guess well over 90% of customers do not bother with locally stored files anymore. Ripping CDs is a chore. Virtually all of my ripped CDs are now readily available on Google Music, in transparent 320kbps form, so the local NAS is rarely used.

That many people now stream? Is there evidence for this assertion? Not being argumentative, by the way, just surprised...

I agree that ripping CDs is a chore, but I suppose that ones views on streaming may be influenced by whether or not you have a fast reliable internet connection...

I've never had both, so always prefer to have full control over where my music is stored and how it's accessed...

Some users just want to play 24 bit files. With a minimum of fuss. It is as simple as that. At the end of the day, "someone owns" the problem here. It's either Sonos or customer's who want to play them.
As we've said, it's the customer's and there are simple workarounds. There are strong technical and business reasons why Sonos would see no interest in supporting hi-res. Ergo it's clearly not a problem for Sonos.

It will resurface when the first 24bit streaming service becomes available.
Never say never, but given that 16/44 lossless streaming services (Qobuz, WiMP) are territorially restricted with relatively small userbases I wouldn't place any bets on hi-res streaming appearing any day soon.

As we've said, it's the customer's and there are simple workarounds. There are strong technical and business reasons why Sonos would see no interest in supporting hi-res. Ergo it's clearly not a problem for Sonos.

Indeed. I see this as similar to the people out there who wish to use less common music file formats, like WavPack, Monkey's audio, or FLAC with Cuesheet.

At least Sonos reads almost all of the mainstream formats, whilst companies like Apple do not.

At the end of the day it's impractical to cater to the varied and obscure whims of every individual user and there are very few real barriers to the user solving the problem themselves.

Honestly WappingHigh i think one of the reasons that people have been quite scathing towards you (sometimes unreasonably so), is that your campaign for a solution seems to be based on very shaky ground. To many of us you are asking for Sonos to provide you with a solution to a problem that hardly exists, even for the handful of people it does affect.

Firstly, managing a duplicate music library is not hard. It's not hard at all. I speak from a position of experience having managed a parallel library of lossless FLAC and lossy MP3 for many years in order to support use on portable devices. I know that many of the others on this thread have done the same.

If you really do genuinely believe maintaining a parallel is "difficult" (and I suspect this is more a convenient argument than a real belief) then I can only conclude it is because you haven't committed to trying it, because it really isn't that hard.

It is also not time consuming: using one of the suggested tools, you could have performed all the manual steps required to batch convert your entire collection in the time it took to make one of your recent posts. In fact, your whole collection would probably have been converted in the time it took you to type one of your longer posts!

It's very easy to form the view that you are far more committed to complaining about this than you are to getting a working solution.

IMO these are weak arguments to why Sonos should solve this for you.

Cheers,

Keith

In my opinion the only way SONOS could make the business case of supporting higher bit rates and wider words, is if the hires proponents successfully position their wish as a "must have" pre sale "check box" in the marketplace. "Expert" equipment reviewers are contributing to the creation of this check box when they deride SONOS for "not supporting WiFi".

Currently, SONOS competitors are beating the "our system supports WiFi, SONOS is not WiFi" drum -- indicating that SONOS has a shortcoming, when this is actually a technology advantage for SONOS. The competition struggles with their WiFi connections while SonosNet is robust. It's an easy check box against SONOS because a large segment of the public equates "wireless" and "WiFi" -- in this view SONOS cannot be truly wireless without WiFi. Since SONOS has announced that it will support a WiFi link at some point, the air will disappear from this check box in a quick blast of flatulence.

It will not be as easy to deflate the hires check box.

Yet another option if you're sharing your files from a Linux server or NAS:

http://arbiter.sevensinsystems.com/?p=18