DSD ISO Support

I think to remember that was said in the past. Dont remember the date though.

What I do is simply splitting up the Iso in DSF tracks. Thats an easy exercise with no sound manipulation.
I use the software Xrecode 3, which is also very usefull for any conversions you might need.

1 Like

Using an i5 PC, can anyone give a ballpark of how long it might take to extract a 5.1 tract from an ISO to DSF?

I find it depends on whether the ISO is on a local drive or on a NAS. Converting multichannel also takes longer (obviously) than dual channel.

Throughput locally is approx 3.4MB per second from memory. You should really spend a little time tagging the DSF as well, as the metadata are inconsistent and frankly poor on a lot of discs.

I use an iMac i5 to convert my rips from iso to 2channel DSF and extraction seems to go very quickly (less than a minute) if the source material is not DST cmpressed. If it is compressed however it takes around 15 minutes.

My experience with ISO to FLAC (files stored on a NAS) using Foobar is that 2-channel files take just a couple minutes, but multi-channel can take 30 m8nutes or more. I was just curious if DSF would speed up that time.

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.


Yes. Even as someone with lots of ISOs, please keep your resources focused on things like the above. I will happily accept the trade off and continue to work on extracting my ISOs to FLAC or maybe now DSF files. Appreciate you chiming in on this Brian.

1 Like

I have converted all my ISOs to dual-channel DSF, Edward, but keep the original discs and ripped ISOs as well. The ISOs are on an entirely different NAS that I repurposed when I switched to QNAP. The NAS only gets switched on when I need to copy a newly ripped ISO to it then it gets switched off again.

None of my DACs handle DSF, so my Roon Core transcodes on the fly when I play a DSF file. I haven’t converted the ISOs to FLAC as one day I may buy a DAC that natively handles DSD.


Another reason for dual systems. I still keep JRiver alive and well it supports sacd iso plus other things.

I see nothing wrong in two systems. Neither does everything the other does so keeping both you get the best of both worlds

Just a thought


1 Like

I saw that, but Brian didn’t really commit to anything in that response.

I can’t speak for the other fervent SACD enthusiast, but for me, right now, what would work is for Roon to simply scan all of my .iso files, figure out which ones are SACDs - if it can from the file name or some other way, or if it can’t just show me all .iso files you found.

Even though I can’t play them from Roon, it would be nice to at least have an inventory of all of them inside Roon, and see the album art for the SACD.

Can we have this as a starting point? I don’t believe this should be a tremendous amount of work.


I’m not speaking for Roon however, having collaborated with the guys even before Roon as we know it existed … I can say is that they don’t invest in half measures … so if ISO support is added one day it will be fully integrated into Roon.

Please don’t interpret lack of commitment as dismissal / ignoring this request. I know Roon’s product development group review this request periodically.


I’m not sure anything more can be said about this. I’m closing this out until we make movement on this feature.

Roon still aren’t moving on this, however, I’ve reopened this topic and will be merging other posts discussion ISO support … so the history is in one place.

[Mod edit: Merged into this topic and added quote box for context.]

ISO support has been asked for before (just search the forum), and my reading of the tea-leaves is that chances of support are slim. Same for Blu-ray audio, I suspect.

As for the search function suggestion, the search function already seems to account for misspellings; “daivd” is recognised as “david” for example…

However, the Roon Labs team read all the posts here, so it’s down to them what they will do…

I’m not trying to sound snobby, make is sound easy, or like this is bad software on its own.

But, why wouldn’t you do everything, and more than what competitors can do? I have to switch between JRiver and Roon all of the time. And, why should I have to if they can listen and either combine the two, or add these features.

1 Like

Perhaps because they have limits on their development and budgetary resources, and a prioritised list of what needs to be done? Rome wasn’t built in a day. Then again, they may have very well decided that they don’t want to build Rome anyway; Amsterdam is much more attractive… :grinning:


I agree. It needs to be a well thought out, and planned release. Hence, I’m just saying for future release. But the sooner the better! haha. Get off your a$$'s! just kidding Roon, you know I love ya.

For the same reason JRiver doesn’t add rich metadata and streaming services.