Hello All,
This is a really important topic for a relatively small number of people, and those are some of the toughest feature requests to deal with.
I want to make clear that this isn’t a situation like UPnP or Folder Browsing where we have a fundamental objection to the feature. There is nothing wrong with the idea of supporting this. It’s always been a judgement call: “How much value does this add to the product and for how many people?”
We’ve looked at the data–even in a user base of enthusiasts like ours, not many people have DSD ISO files at all, and only a minority of those people have DSD ISOs in large enough quantities to make conversion an impractical workaround. This feature, as critical as it is for some, does not touch many people in a significant way.
Making decisions about how to spend our limited development resources is hard. If we simply stopped accepting feedback and cleared out the backlog of the things that we want to do with the product that we know about today, it would be years before that queue emptied. This is pretty normal for product teams. There is always a huge backlog of work to be done, and we have to make decisions constantly as to what gets our attention.
It’s tempting to work on smaller and smaller incremental improvements in particular niches like this one and lose sight of the bigger stuff that everyone needs–like a proper mobile app that allows for listening outside of the home, proper radio/browsing features that work outside of your library, a better phone app, and other things that will impact all of our users, instead of just the few with these files.
As for this feature, there are a few factors worth mentioning:
First, this feature requires real work, and in Roon’s case, more work than some of the other software products likely had to do. This is in part because of how much more complex our product is in its handling of files and data, and in part because of where we are going with it. Mobility support, multi-location support, remote access, export functionality, etc, all become more complicated if we break with the current “1 track = 1 file” assumption. This isn’t a showstopper, but it has architectural implications, so it deserves a conservative approach. I’d like us to fully understand how this might complicate those larger projects before we take this step.
Another factor is that building this feature without also supporting .flac/.cue and .bin/.cue would be strange. Supporting one new scheme for storing disc-based content would likely multiply into three related projects released at the same time.
A third factor is that the tagging possibilities for these disc-based schemes are limited. This will expose some inconsistency in capabilities between DSD ISO and standalone files which we think will cause some pain and possibly motivate further work that is not well defined.
I know that some people in will read that and say “but why not give us a minimal version of the feature as a band-aid, and accept that it may have limitations, and deal with the other stuff later?”. Well…because we’ve been around the block enough times to know that that doesn’t usually work out too well. It’s better for us to wait until it can be done right than do it a way that makes for bad product, or in a way likely to cause future complications or immediate demands.
We have a serious talk about building this feature every few months. Perhaps one of those times, the balance will tip. There are plenty of scenarios where I see that as a possibility–which is why this feature request remains open. We will continue to revisit it as a potential work item. At the same time, if you’re holding your breath waiting for this to be released very soon–don’t. I am still hopeful that we will support this one day, but I don’t know when that will be.
Thanks to everyone for leaving your feedback in this thread. We read it, appreciate it and take it into account when making decisions.