Tír Na HiFi

Several months ago Gordon asked if it was time to wrap up and move on the DSD material. Foolishly I replied that it was a waste of time as all I had heard were Foobar conversions and they were flat and boring. When Hugo came along I was introduced (by Cvrle) to DSD material played via JRiver and Jplay and the sound quality was stunning so it's certainly well worth pursuing . I have since acquired around 100 DSF albums . Would it be better to have a MQN DSD version which simply played the files without any scripts etc ?. Interesting to see what Gordon could dig out of DSD material considering what has been achieved with PCM.

Ken Moreland wrote:Several months ago Gordon asked if it was time to wrap up and move on the DSD material. Foolishly I replied that it was a waste of time as all I had heard were Foobar conversions and they were flat and boring. When Hugo came along I was introduced (by Cvrle) to DSD material played via JRiver and Jplay and the sound quality was stunning so it's certainly well worth pursuing . I have since acquired around 100 DSF albums . Would it be better to have a MQN DSD version which simply played the files without any scripts etc ?. Interesting to see what Gordon could dig out of DSD material considering what has been achieved with PCM.

Ken

Hugo requires DoP (DSD over PCM).

JRiver converts the DSF files on the fly giving additional noisy CPU activity, just what we are trying to avoid with MQn.

Maybe Gordon can give his view on this, it could be the repackaging doesn't introduce that much additional activity. I'm not into the details of this repackaging.

Also a DSD version of MQn needs to encapsulate any dsf files into DoP format, it is quick enough procedure, but if done on the fly, will generate noise.

So my scripts will convert dsf files into new DoP files in an offline manner, and a regular PCM-version of MQn can playback these DoP files without introducing any additional noise.

There are very few DACs that play native DSD, most of them require DoP and so conversion has to be done for nearly all DACs.

So offline conversion into DoP is the least noisy solution.

Cheers

Aleg

Clear. I see your thinking , I know Hugo uses DoP, so the conversion from DSF to DoP would be a one-off. Have you tried this using one of the old MQN versions which did all sample rates including 24/176?
KM

Ken Moreland wrote:Clear. I see your thinking , I know Hugo uses DoP, so the conversion from DSF to DoP would be a one-off. Have you tried this using one of the old MQN versions which did all sample rates including 24/176?
KM

I should indeed still have those old 32-bit versions somewhere in the dungeons of my MQn archive.
I must say i had forgotten about them, so I can jndeed give it a try now.

Thanks for the head up

Cheers

Aleg

UPDATE:
No, MQn R1.1 does not play DoP versions. It did play a regular 176.4 PCM version but not a DoP in a 176.4 PCM.
Perhaps there is a check on regular PCM format and doesn't allow other formats?

Foobar does play the dop-in-pcm-wav just fine.

Aleg wrote:

Ken Moreland wrote:Several months ago Gordon asked if it was time to wrap up and move on the DSD material. Foolishly I replied that it was a waste of time as all I had heard were Foobar conversions and they were flat and boring. When Hugo came along I was introduced (by Cvrle) to DSD material played via JRiver and Jplay and the sound quality was stunning so it's certainly well worth pursuing . I have since acquired around 100 DSF albums . Would it be better to have a MQN DSD version which simply played the files without any scripts etc ?. Interesting to see what Gordon could dig out of DSD material considering what has been achieved with PCM.

Ken

Hugo requires DoP (DSD over PCM).

JRiver converts the DSF files on the fly giving additional noisy CPU activity, just what we are trying to avoid with MQn.

Maybe Gordon can give his view on this, it could be the repackaging doesn't introduce that much additional activity. I'm not into the details of this repackaging.

Also a DSD version of MQn needs to encapsulate any dsf files into DoP format, it is quick enough procedure, but if done on the fly, will generate noise.

So my scripts will convert dsf files into new DoP files in an offline manner, and a regular PCM-version of MQn can playback these DoP files without introducing any additional noise.

There are very few DACs that play native DSD, most of them require DoP and so conversion has to be done for nearly all DACs.

So offline conversion into DoP is the least noisy solution.

Cheers

Aleg

I know that you dig into this to understand it well, but it is still so confusing...
If JRiver is converting, why do they (Chord) say this (in bold) in their manual? Does this actually mean DoP?
From Hugo's manual..
Red – 44KHz, Orange – 48Khz, Yellow – 88KHz, Green – 96KHz, Light Blue – 176Khz, Dark
Blue – 192KHz, Light Purple – 352Khz(DXD), Purple – 384KHz(DXD).
White indicates DSD operation at either DSD64 or DSD128.

I would like to have MQn to play DoP too. I can only imagine how that would sound, if it's already so good by JRiver with all that conversion happening.
Didn't Gordon say that he ran out of the ideas...there you go...:)))

if someone can tell me what to code, then I'll try. So far I've read that it is 16/176 with an 8 bit indicator. would probably buy an ifi nano to try it out.

cvrle59 wrote:

Aleg wrote:

Ken Moreland wrote:Several months ago Gordon asked if it was time to wrap up and move on the DSD material. Foolishly I replied that it was a waste of time as all I had heard were Foobar conversions and they were flat and boring. When Hugo came along I was introduced (by Cvrle) to DSD material played via JRiver and Jplay and the sound quality was stunning so it's certainly well worth pursuing . I have since acquired around 100 DSF albums . Would it be better to have a MQN DSD version which simply played the files without any scripts etc ?. Interesting to see what Gordon could dig out of DSD material considering what has been achieved with PCM.

Ken

Hugo requires DoP (DSD over PCM).

JRiver converts the DSF files on the fly giving additional noisy CPU activity, just what we are trying to avoid with MQn.

Maybe Gordon can give his view on this, it could be the repackaging doesn't introduce that much additional activity. I'm not into the details of this repackaging.

Also a DSD version of MQn needs to encapsulate any dsf files into DoP format, it is quick enough procedure, but if done on the fly, will generate noise.

So my scripts will convert dsf files into new DoP files in an offline manner, and a regular PCM-version of MQn can playback these DoP files without introducing any additional noise.

There are very few DACs that play native DSD, most of them require DoP and so conversion has to be done for nearly all DACs.

So offline conversion into DoP is the least noisy solution.

Cheers

Aleg

I know that you dig into this to understand it well, but it is still so confusing...
If JRiver is converting, why do they say this (in bold) in their manual? Does this actually mean DoP?
From Hugo's manual..
Red – 44KHz, Orange – 48Khz, Yellow – 88KHz, Green – 96KHz, Light Blue – 176Khz, Dark
Blue – 192KHz, Light Purple – 352Khz(DXD), Purple – 384KHz(DXD).
White indicates DSD operation at either DSD64 or DSD128.

I would like to have MQn to play DoP too. I can only imagine how that would sound, if it's already so good by JRiver with all that conversion happening.
Didn't Gordon say that he ran out of the ideas...there you go...:)))

Hi cvrle59

When I said converting I meant repackaging into DoP format, inside DoP it is still DSD (with some extra coding to tell the receiver that the 176.4/24 PCM data actually contains a DSD 1-bit stream) and in the Hugo DoP gets unpacked into DSD again.
I'm not familiar with act of repackaging in detail, but obviously it does require some processing, they actually call it encapsulating rather than converting.
And as Gordon says each stereo pair sample contains an 8 bit indicator designating the sample as a DoP-format.

@Gordon
I don't understand why MQn isn't playing a DoP wav file? Does mqncontrol check for a regular PCM format? So in effect blocking the playback of a DoP even though it is just a PCM 1764./24?

Here is the standards document: http://dsd-guide.com/sites/default/file ... rd_1v1.pdf

The DSD2FLAC seems to support also a DSD2FLACDoP. dSD2FLAC is an open source project found here:
https://code.google.com/p/dsf2flac/


Cheers

Aleg

5.65 sse2/avx2 quite a few changes

All new versions (I tried so far) are pretty good, but 5.14 is the one that makes me tired every morning. I can't stop listening late evenings, whatever I get going with it...so musical.

Ken Moreland wrote:Clear. I see your thinking , I know Hugo uses DoP, so the conversion from DSF to DoP would be a one-off.
KM

Yes, the conversion would be a one off. So you build a library of DSD-files encapsulated into DoP format.

MQn doesn't have to do anything special with those files, just pass them through as though they were PCM 176.4/24 files.

The only thing is MQnControl doesn't appear to see them as valid files at the moment.

This would be the simplest way for Gordon to build DoP support.
He could then check as another change if on-the-fly encapsulation could be a viable option.

Cheers

Aleg