Jump to content
IGNORED

Differences between SACD ISO vs DSF(DIFF)


daviddlch

Recommended Posts

I use JRiver MC19 and exa 28 DAC

 

I have multi channels DSF files extracted from SACD ISO via sacd_extract. When these files are placed in JRiver, the DSF file size is as much as 2.5x the size of ISO for the same single song. Obviously ISO is a compressed format.

 

But what shocks me most is I can actually notice an obvious difference in sound quality between SACD ISO and its DSF. I can't say which is of better quality but the difference is very obvious.

 

Has anyone out there share this same observation ?

Link to comment

JRiver needs to decompress a DST-encoded ISO (as Skeptic said, most ISOs containing mch content have DST to fit all the music) or you decompress it during extraction. So a SQ difference is likely your cpu doing less work with already-processed DSF vs dealing with the ISO. Kind of a FLAC vs wav thing. All my mch DSD, to this point, is DSF..but I will try and do an a/b soon. Do you hear differences in stereo-only ISOs (that do not contain DST compression) vs their DSF tracks?

Link to comment
JRiver needs to decompress a DST-encoded ISO (as Skeptic said, most ISOs containing mch content have DST to fit all the music) or you decompress it during extraction. So a SQ difference is likely your cpu doing less work with already-processed DSF vs dealing with the ISO. Kind of a FLAC vs wav thing. All my mch DSD, to this point, is DSF..but I will try and do an a/b soon. Do you hear differences in stereo-only ISOs (that do not contain DST compression) vs their DSF tracks?
IMO the best way to avoid issues with the same cpu being involved in the decompression as well as the playback is to use two machines, the first more powerful one to do any music file transcoding, even possibly including correction, etc and the second machine to simply playback the doctored 'file' over the network connecting the two machines. The UPnP/DLNA model fits this scenario quite well with the UPnP media server machine transcoding the music files for the UPnP renderer simple playback machine.

We are far more united and have far more in common with each other than things that divide us.

-- Jo Cox

Link to comment
No I did not for stereo track but will do a comparison soon. Thanks.

 

Not any stereo track, but from an ISO that is stereo only with no DST (i.e ISO is 2GB or less is good first indication).

Link to comment
IMO the best way to avoid issues with the same cpu being involved in the decompression as well as the playback is to use two machines, the first more powerful one to do any music file transcoding, even possibly including correction, etc and the second machine to simply playback the doctored 'file' over the network connecting the two machines. The UPnP/DLNA model fits this scenario quite well with the UPnP media server machine transcoding the music files for the UPnP renderer simple playback machine.

 

I don't understand. In what way would any cpu be involved in sacd_extract extraction and DSF playback at the same time. Extraction to DSF is an offline function. My point was that your cpu has potentially less to do during multichannel playback of a DSF track vs multichannel playback of an ISO (cuz mch playback of an ISO might require realtime DST decompression too). It's a nit, most likely, anyway, but I don't follow your concerns about needing two different cpus.

Link to comment

Personally, after reading all of what Ted has gone through in the past I should've just converted all my ISO's to DSF and been done with it. However, after getting my ARIES I was forced to do so since it can't play ISO (Minimserver doesn't support them) so I did convert all ISO's. That really is the way to go IMO since it does take less resource and if you should move on to something else that is DSD ready it can play the file anytime.

W10 NUC i7 (Gen 10) > Roon (Audiolense FIR) > Motu UltraLite mk5 > (4) Hypex NCore NC502MP > JBL M2 Master Reference +4 subs

 

Watch my Podcast https://www.youtube.com/channel/UCXMw_bZWBMtRWNJQfTJ38kA/videos

Link to comment
I don't understand. In what way would any cpu be involved in sacd_extract extraction and DSF playback at the same time. Extraction to DSF is an offline function. My point was that your cpu has potentially less to do during multichannel playback of a DSF track vs multichannel playback of an ISO (cuz mch playback of an ISO might require realtime DST decompression too). It's a nit, most likely, anyway, but I don't follow your concerns about needing two different cpus.
To transcode means to decode on the fly during playback - so not offline and it's a common feature, eg built-in transcoding functions of some UPnP media servers. There are several applications now capable of loading the SACD ISO file and presenting them as if it were separate DSD file tracks, during playback (eg Foobar2000 & JRiver).

 

The concern comes with 'having' to use a single powerful machine to handle everything and possible influences on SQ, when a simpler less powerful machine could be used at the front end for music playback/handling the realtime audio signal to the DAC only and a more powerful one at the back end to do everything else: classic client/server.

We are far more united and have far more in common with each other than things that divide us.

-- Jo Cox

Link to comment
To transcode means to decode on the fly during playback - so not offline and it's a common feature, eg built-in transcoding functions of some UPnP media servers. There are several applications now capable of loading the SACD ISO file and presenting them as if it were separate DSD file tracks, during playback (eg Foobar2000 & JRiver).

 

The concern comes with 'having' to use a single powerful machine to handle everything and possible influences on SQ, when a simpler less powerful machine could be used at the front end for music playback/handling the realtime audio signal to the DAC only and a more powerful one at the back end to do everything else: classic client/server.

 

Yes, I understand all the terms, have created JRIver video tutorials, understand DSD and ISOs, run a dual pc setup (for Jplay, for example, which can handle client/server tasks but is not a subject here)...and still no idea what you are trying to get to. There is no process I know of where one would want to extract an ISO to DSF and then, in continuity, play it in realtime. Transcoding is realtime but does not include extraction! One either plays an ISO (where JRiver decompresses the DST, if present, in realtime and takes a few cpu cyles to do that) or one plays individual DFF/DSF files (which have PREVIOUSLY been extracted offline).

 

So, again I ask, what is the deal with needing two cpus? What do you mean by "do everything else"? If you mean Jplay, then ok but the controlpc or front end is not presenting to a DAC..... but it's not at all what the OP is talking about. ISO playback does not permanently create extracted individual tracks (that a UPNP renderer could use to further process), but instead uses a sort of cue file mentality (JRIver reads the TOC from the ISO and shows the user a list of virtual tracks but the file is still one file). Please give me an example of using two cpus to listen to an ISO.

 

Back to the subject: transcoding on the fly takes more processing than offline conversion. That is a simplified (but true) statement. Offline conversion takes more hd space and often more time and work, so transcoding is often seen as a solution...but unless your cpu is large enough there is no free lunch (hence my initial, what I thought was simple, explanation that the OP's ISO playback of mch content could well sound different from DSF mch playback if your cpu is not quite up to the task of multichannel ISO playback).

Link to comment
Yes, I understand all the terms, have created JRIver video tutorials, understand DSD and ISOs, run a dual pc setup (for Jplay, for example, which can handle client/server tasks but is not a subject here)...and still no idea what you are trying to get to. There is no process I know of where one would want to extract an ISO to DSF and then, in continuity, play it in realtime. Transcoding is realtime but does not include extraction! One either plays an ISO (where JRiver decompresses the DST, if present, in realtime and takes a few cpu cyles to do that) or one plays individual DFF/DSF files (which have PREVIOUSLY been extracted offline).
Ok, then I don't see how you were not able to realise that what I was talking about couldn't possibly have been referring to the (permanent) extraction of SACD ISOs to DSF files - an offline process, as you've pointed out. It was you that mentioned 'extraction', not me. I did try to choose my words carefully when I said that the SACD ISO file is 'presented as if it were separate DSD file tracks'. The UPnP control point is 'tricked' by the UPnP server's transcoder into seeing DSD file tracks (that the UPnP renderer supports) and not the actual SACD ISO file (which the UPnP renderer is not required to playback). If you know how transcoding works in a UPnP media server, then you would know that conversion does actually take place on the fly during the streaming process and the UPnP renderer is actually streaming converted data belonging to a different file format of the original, so DSF file data instead of SACD ISO data in this example. So as far as the UPnP renderer is concerned, it is streaming an actual DSF file and not the original SACD ISO file. BTW, I said 'on the fly' so as to avoid the sometimes confusing term used in audio, 'realtime'. UPnP media server's transcoding process occurs parallel to, but has nothing to do with, the actual realtime audio signal being created by the UPnP renderer, from the networked streamed music file data, to pass on to the DAC.

 

 

 

So, again I ask, what is the deal with needing two cpus? What do you mean by "do everything else"? If you mean Jplay, then ok but the controlpc or front end is not presenting to a DAC..... but it's not at all what the OP is talking about. ISO playback does not permanently create extracted individual tracks (that a UPNP renderer could use to further process), but instead uses a sort of cue file mentality (JRIver reads the TOC from the ISO and shows the user a list of virtual tracks but the file is still one file). Please give me an example of using two cpus to listen to an ISO.
The two CPUs or slightly clearer perhaps, the two machines are: one containing the UPnP media server with its transcoder and the other with the UPnP renderer.

'Do everything else' is anything that may be required and likely to be CPU intensive in 'doctoring' the original music file data and can be handled by the transcoding stage, eg resampling, applying filters, DSP, etc.

An example of two machines being used to 'listen to' a SACD ISO: A Windows PC with access to the stored ISOs, running Foobar2000 plus the foo_UPnP plugin component (to provide the UPnP media server and transcoder) plus the foo_input_SACD plugin component (to provide the foo_UPnP transcoder with conversion functions from SACD ISO to DSD) and the second machine is a UPnP renderer that supports the playback of DSD files.

We are far more united and have far more in common with each other than things that divide us.

-- Jo Cox

Link to comment
I asked this on the giant A+2 thread and the gist was that this is endemic to DSD and how it handles differences in signal values as it goes from one song to the next. Maybe it's worse with ISOs than DSF.
And maybe it is better/worse with different hardware/software. I do not get them with my PC-based server or my Mac-based server, both using JRMC, thank goodness.

Kal Rubinson

Senior Contributing Editor, Stereophile

 

Link to comment
Anyone get them with a DAC that does DSD native?

 

I can hear the clicks between tracks on some albums (and between some albums) playing back DSF files from A+2 via my Mytek. The clicks are audible but very low level in relation to the music and aren't particularly troublesome to me. This doesn't seem to occur with all DSF files.

 

I can't swear to it, but I believe I've read that the click problem may also have a hardware dimension, in terms of how a particular DAC handles muting between tracks.

 

--David

Listening Room: Mac mini (Roon Core) > iMac (HQP) > exaSound PlayPoint (as NAA) > exaSound e32 > W4S STP-SE > Benchmark AHB2 > Wilson Sophia Series 2 (Details)

Office: Mac Pro >  AudioQuest DragonFly Red > JBL LSR305

Mobile: iPhone 6S > AudioQuest DragonFly Black > JH Audio JH5

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...