Offline Upsampling

[Superdad]

You know I'd like to see this.

 

Be warned though Jud:

If Peter does this, then I will be shipping you a 1TB drive filled with tracks and a blank 10TB array and asking you to use XXHighEnd w/ArcPrediction to convert my entire library to 352.8/384.

That way I can enjoy XXHighEnd without having to install Windows on my Mac or endure Peter's frightening "cockpit" and color schemes! I'll just play it all back with A+ (or take it further to DSD512 w/HQPlayer if we build a discrete DSD DAC for that).

[bogi]

I found this comparison: Archimago's Musings: ANALYSIS: A Comparison of DSD Encoders & Decoders (KORG AudioGate, JRiver MC, Weiss Saracon)

 

It shows that JRiver performs better than Audiogate as offline PCM <--> DSD converter.

It's pity we cannot use Maxim's foo_dsd_asio offline.

[Paul R]

Be warned though Jud:

If Peter does this, then I will be shipping you a 1TB drive filled with tracks and a blank 10TB array and asking you to use XXHighEnd w/ArcPrediction to convert my entire library to 352.8/384.

That way I can enjoy XXHighEnd without having to install Windows on my Mac or endure Peter's frightening "cockpit" and color schemes! I'll just play it all back with A+ (or take it further to DSD512 w/HQPlayer if we build a discrete DSD DAC for that).

 

Hah! Don't listen to that guy Jud - I'll make it a 4GB disk and a 16th RAID5 array! Okay, two of each, and you can keep one set.

 

-Paul

[Miska]

That's why it's a good idea to perform some up-sampling first, either offline or as a pre-process, then HQPlayer has less work to do.

 

Please note that there are two factors of roughly equal importance regarding sound quality of playback chain digital processing; 1) oversampling filters and 2) delta-sigma modulators.

 

If you use some off-line upsampler to pre-process to higher rate the end result will be vastly different from using the HQPlayer's algorithms. In effect you will have add at least one extra cascade filter to the chain. And you will lose some processing resolution by doing so. With cascaded filters, first step of upsampling will have higest impact on the end result.

[Miska]

Sorry if it's an obvious answer, but what is it about the Exasound which makes it preferable as regards isolation issues?

 

Because it has galvanic isolation for the USB interface. There are other DACs with isolation too, but most on the market don't have it...

 

Just for fun, compare their measurements with/without galvanic isolation:

exaSound Audio Design > e22 > e22 Measurements

The results I've got with my NAA experiments and non-isolated DACs are somewhat similar. However, with direct connection it always depens on both the source computer and the DAC; how much the computer injects noise (hardware issue) and how much the DAC is able to isolate the noise (hardware issue). So there is no single simple answer that would apply to all configurations...

[Jud]

Jud, yes. But I didn't know this thread existed. Edit :

And you know that I know that you know that ...

 

Anyway thanks,

Peter

 

And I know that you know that I know that you... Wait, how many was that?

[PeterSt]

Be warned though Jud:

If Peter does this, then I will be shipping you a 1TB drive filled with tracks and a blank 10TB array and asking you to use XXHighEnd w/ArcPrediction to convert my entire library to 352.8/384.

That way I can enjoy XXHighEnd without having to install Windows on my Mac or endure Peter's frightening "cockpit" and color schemes! I'll just play it all back with A+ (or take it further to DSD512 w/HQPlayer if we build a discrete DSD DAC for that).

 

1TB x 8 = 8TB + (0.5 x 8TB) = 12TB. IOW don't forget that it's 16 -> 24 bits. If not 32 for some.

And then there comes the Mac die-hard with NOS1 who likes to have the files 24/705.6. So now 1TB becomes 24TB.

 

Maybe not ...

[matthias]

.......or take it further to DSD512 w/HQPlayer if we build a discrete DSD DAC for that.

 

I hope so.

 

Matt

[PeterSt]

OffTopic Alert

 

Originally Posted by joelha

Sorry if it's an obvious answer, but what is it about the Exasound which makes it preferable as regards isolation issues?

 

 

Because it has galvanic isolation for the USB interface. There are other DACs with isolation too, but most on the market don't have it...

 

Just for fun, compare their measurements with/without galvanic isolation:

exaSound Audio Design > e22 > e22 Measurements

The results I've got with my NAA experiments and non-isolated DACs are somewhat similar. However, with direct connection it always depens on both the source computer and the DAC; how much the computer injects noise (hardware issue) and how much the DAC is able to isolate the noise (hardware issue). So there is no single simple answer that would apply to all configurations...

 

Although to me this is totally clear (read : correct what Miska is saying) to others this may not be so obvious or believable. But I can testify it - seen from the other angle. So, the Phasure DAC does not show this difference at all (nothing actually) which will be a reason why USB cables also don't matter (or if so, totally marginally). Btw, I mean for the Phasure the noise stays as low and not as high. Again in other words : that noise does not show at all.

With this as a base, isolation still matters, although we apply it elsewhere. And in all events it is the jitter which differs. So where I can't measure/see any difference in the noise, I sure can measure the difference in jitter. But keep in mind, with that base of the noise being so low to begin with.

 

Something else is that this noise (as shown from the Exa) is not USB noise or "PC noise" of any kind. What happens though is the implied ground loops which travel over the mains and then this for sure can happen. But to add another dimension to what Miska says, this now is about the inherent noise in your mains. This may sound strange, but I always have the example and measure of the PWM (Pulse Width Modulated) pump I have in the house on a totally separated mains ring (separate earth pin and all), which gets rid of its super square (like DSD haha) noise through the air. So if you only look at my situation :

1. I have that pump and you might not have it;

2. I have antenna working somewhere (like a metal grid in the concrete floor) which you might not have;

3. I solved that antenna working in the DAC which is not possible as general solution for all DACs.

 

So what this tells is that this is different for everybody plus out of control (if you can see/measure it to begin with). This is also how for one a certain USB cable (topology) may help, why for others it doesn't do a thing (think like nothing being the matter in the first place). Same with mains cords, same with interlinks.

 

So there is no single simple answer that would apply to all configurations...

 

This is the worse part; there is no general rule to solve such issues which starts with not knowing about the issue (can't see it).

 

Peter

[audiventory]

Geoffrey,

 

pre-conversion is good compromise for current situation. Possible do it transparently for user. Must be some volume of cache. If it overloaded, then most old album is cleared and new album converted. If we play album already exists in cache, we havn't delay for conversion.

 

 

Hi Yuri,

 

That patent you refer to is not about converting PCM to DSD as such. This is at least not how I read it;

It is about a method of converting PCM to DSD in lossless fashion, resulting in a "stream" that is both PCM and DSD compatible (also nice) for hardware which adapts to it. Actually the result is PCM with a a small portion of added bit code that allows the hardware to convert it to DSD if wanted.

 

So I wouldn't worry and you can do what you want.

Btw, I didn't read the whole patent, but as I see it at first glance it involves hardware, while it all can be done in software just the same (again, looked at first glance). This wouldn't break the patent ...

If you really want to know (do it this exact way) I first must read it more thoroughly.

 

Regards,

Peter

 

Hi Peter,

 

In this patent present phrase about PCM to DSD LOSSLESS conversion. DSD there is pulse-density modulation. Also there talks about algorithm. Other algoritm not covered by the patent. If you learn it - will great! I like this idea!

 

I don't will convert PCM to DSD. I will convert PCM 16/24/32... bit to PCM 1 bit, no more Sample rate will oversampled by usual AuI's algorithm.

 

I have idea supply AuI as dynamic link library in future. But I think more important release qualitative 1-bit conversion algorithm.

 

Now AuI (Audiophil-E and PROduce-R versions) able connect with other software as command line tool. Able batch pricessing. Set up target directory, etc.

Here command line options:

Command Line Control

 

If need more info I'm ready give it. Also I always ready to cooperate with developers of audio software for compatibility.

 

Best regards,

Yuri

[PeterSt]

Looking good Yuri. By the time you want me to test something let me know (sales phasure com).

 

 

An interesting notice about that patent (maybe more for others than for you Yuri) :

 

What this proposes is indeed a lossless method for ...

well, storing DSD in a smaller format than it is originally. How ? by storing it in PCM. Now LYAO.

So say the larger DSD "hires" is stored in "Redbook size" PCM. But with some trickery.

 

Regards,

Peter

[PeterSt]

And Yuri,

 

pre-conversion is good compromise for current situation. Possible do it transparently for user. Must be some volume of cache. If it overloaded, then most old album is cleared and new album converted. If we play album already exists in cache, we havn't delay for conversion.

 

I am not sure whether you talk in general or whether you at your side want to make something like that. Notice though that XXHighEnd operates exactly like this already (at the track level).

 

Peter

[Geoffrey Armstrong]

The combo box contains values only up to 192k, but just write 352800 in the input box. It really functions so.

 

Aah, got it! Thanks.

[Geoffrey Armstrong]

Please note that there are two factors of roughly equal importance regarding sound quality of playback chain digital processing; 1) oversampling filters and 2) delta-sigma modulators.

 

If you use some off-line upsampler to pre-process to higher rate the end result will be vastly different from using the HQPlayer's algorithms. In effect you will have add at least one extra cascade filter to the chain. And you will lose some processing resolution by doing so. With cascaded filters, first step of upsampling will have higest impact on the end result.

 

Part of the reason Jud performs offline up-sampling and started this thread, is that he doesn't have the processing power to do up-sampling and conversion to DSD using the best filters in realtime.

 

In my case there was still the need for up-sampling with or without conversion in real-time using HQPlayer and I wouldn't want it to be otherwise, because I really like the results I get with HQPlayer in each case. i.e. 1/ When all up sampling and conversion is performed by HQPlayer, 2/ When PCM is first up-sampled to PCM 352.8 offline and then converted to DSD and further up-sampled to DSD256 for the exasound DAC and 3/ When PCM is first up-sampled to PCM 352.8 offline then converted to DSD128 offline by J River, leaving HQPlayer to still up-sample the DSD128 to DSD256.

 

The results are indeed different in each case. I was already happy with having HQPlayer do all the processing in realtime; but there may be some advantages to doing some offline up-sampling or pre-processing first.

 

Can you expand a little on what you mean by "you will lose some processing resolution by doing so" ?

I'm also a little curious as to why there is a roughly 2 minute wait in HQPlayer when either poly-sinc or poly-sinc-mp filters are selected with a DSD modulator before the first track of an album or playlist begins playing. Is this the time it takes to construct the filters or is this when up-sampling is performed?

 

Just curious. Of course, I understand if you don't want to reveal what's going on. The results are always fantastic with HQPlayer and I wouldn't want a situation where HQPlayer had no work to do, because the file had already been up-sampled and converted to DSD256 offline.

 

That brings me to one more question. If I play a native DSD128 file and don't ask HQPlayer to up-sample it further to DSD256, the poly-sinc; etc filters. are still selectable. Are they actually doing anything in that case?

 

Thanks,

 

geoff

[jhwalker]

Part of the reason Jud performs offline up-sampling and started this thread, is that he doesn't have the processing power to do up-sampling and conversion to DSD using the best filters in realtime.

 

In my case there was still the need for up-sampling with or without conversion in real-time using HQPlayer and I wouldn't want it to be otherwise, because I really like the results I get with HQPlayer in each case. i.e. 1/ When all up sampling and conversion is performed by HQPlayer, 2/ When PCM is first up-sampled to PCM 352.8 offline and then converted to DSD and further up-sampled to DSD256 for the exasound DAC and 3/ When PCM is first up-sampled to PCM 352.8 offline then converted to DSD128 offline by J River, leaving HQPlayer to still up-sample the DSD128 to DSD256.

 

The results are indeed different in each case. I was already happy with having HQPlayer do all the processing in realtime; but there may be some advantages to doing some offline up-sampling or pre-processing first.

 

Can you expand a little on what you mean by "you will lose some processing resolution by doing so" ?

I'm also a little curious as to why there is a roughly 2 minute wait in HQPlayer when either poly-sinc or poly-sinc-mp filters are selected with a DSD modulator before the first track of an album or playlist begins playing. Is this the time it takes to construct the filters or is this when up-sampling is performed?

 

Just curious. Of course, I understand if you don't want to reveal what's going on. The results are always fantastic with HQPlayer and I wouldn't want a situation where HQPlayer had no work to do, because the file had already been up-sampled and converted to DSD256 offline.

 

That brings me to one more question. If I play a native DSD128 file and don't ask HQPlayer to up-sample it further to DSD256, the poly-sinc; etc filters. are still selectable. Are they actually doing anything in that case?

 

Thanks,

 

geoff

 

Not sure what you mean by "two minute wait" ??? - my music begins playing immediately I use poly-sinc-short-mp, DSD 5v2, DSD128.

[Geoffrey Armstrong]

Not sure what you mean by "two minute wait" ??? - my music begins playing immediately I use poly-sinc-short-mp, DSD 5v2, DSD128.

 

There is no wait with poly-sinc-short-mp or most of the other filters. There is a wait for poly-sinc and poly-sinc-mp though.

[Miska]

Can you expand a little on what you mean by "you will lose some processing resolution by doing so" ?

 

The intermediate format will suffer some resolution loss when saving it to a file...

 

I'm also a little curious as to why there is a roughly 2 minute wait in HQPlayer when either poly-sinc or poly-sinc-mp filters are selected with a DSD modulator before the first track of an album or playlist begins playing. Is this the time it takes to construct the filters or is this when up-sampling is performed?

 

It is the time it takes to initialize the DSP engine, which in turn depends on combination of source and destination formats. Upsampling itself is performed on-the-fly. For example if you go from 48k PCM to 5.6 MHz DSD or 44.1k PCM to 6.1 MHz DSD the initialization time is longer than when going from 48k to 6.1 MHz and 44.1k to 5.6 MHz. It also depends on selected filter and modulator.

 

By using AMD CPU you can significantly shorten the initialization time, but then the on-the-fly processing in turn is slower.

 

That brings me to one more question. If I play a native DSD128 file and don't ask HQPlayer to up-sample it further to DSD256, the poly-sinc; etc filters. are still selectable. Are they actually doing anything in that case?

 

If you have "Direct SDM" enabled, those don't have any effect when and DSD goes through as-is. If "Direct SDM" is disabled, then SDM DSP engine is enabled and the settings are used to control re-modulation of the DSD stream, depending on input/output formats.

 

So there are two separate DSP engines, PCM and SDM. By default, the SDM engine is disabled.

[silv]

It's a pity that he didn't test conversion to/from higher bit PCM.

Here's what 32bit float 384KHz test signal conversion looks like with Weiss Saracon:

RightMark Audio Analyzer test: comparison

Also, as you can see, from Dynamic Range point-of-view, within the 20KHz audible range, 384KHz/32bit float fits nicely into even the "slow" DSD 2.8MHz format.

I found this comparison: Archimago's"]http://archimago.blogspot.sk/2014/04/analysis-comparison-of-dsd-encoders.html"]Archimago's Musings: ANALYSIS: A Comparison of DSD Encoders & Decoders (KORG AudioGate, JRiver MC, Weiss Saracon)[/url]

It shows that JRiver performs better than Audiogate as offline PCM <--> DSD converter.

It's pity we cannot use Maxim's foo_dsd_asio offline.

[jhwalker]

There is no wait with poly-sinc-short-mp or most of the other filters. There is a wait for poly-sinc and poly-sinc-mp though.

 

OK, I guess it's dependent on the equipment you're using, as Miska points out later on - on my system, playback startup is instant with all filters.

[Geoffrey Armstrong]

OK, I guess it's dependent on the equipment you're using, as Miska points out later on - on my system, playback startup is instant with all filters.

 

Hmmm … interesting! You can run poly-sinc with a Mac Mini without any delay? I'm running a 2013 Mac Pro, which in every other respect really screams. What can I be doing wrong? BTW this is converting 16 bit 44.1khz to DSD256 using poly-sinc and DSD7. Perhaps you're starting with already high-res or up-sampled files?

[jhwalker]

Hmmm … interesting! You can run poly-sinc with a Mac Mini without any delay? I'm running a 2013 Mac Pro, which in every other respect really screams. What can I be doing wrong? BTW this is converting 16 bit 44.1khz to DSD256 using poly-sinc and DSD7. Perhaps you're starting with already high-res or up-sampled files?

 

OK, now I see what you're talking about . . . I have been using DSD64 and (primarily) 24/96 FLAC files, not 16/44. When I start with 16/44, it takes about 15 seconds to start (during which time, there is no indication anything is happening, by the way, which is kind of an interface issue, IMO - should get a "loading" indication somewhere).

 

Note that I'm using my 16GB, 2.5 GHz i7 MacBook Pro for HQPlayer, not the Mac Mini highlighted in my signature. I'll do some tests there, but I'll bet my performance will be similar to yours on that platform, given the jump from "instantaneous" to "15 seconds" when I moved down to 16/44 tracks!

[jhwalker]

OK, now I see what you're talking about . . . I have been using DSD64 and (primarily) 24/96 FLAC files, not 16/44. When I start with 16/44, it takes about 15 seconds to start (during which time, there is no indication anything is happening, by the way, which is kind of an interface issue, IMO - should get a "loading" indication somewhere).

 

Note that I'm using my 16GB, 2.5 GHz i7 MacBook Pro for HQPlayer, not the Mac Mini highlighted in my signature. I'll do some tests there, but I'll bet my performance will be similar to yours on that platform, given the jump from "instantaneous" to "15 seconds" when I moved down to 16/44 tracks!

 

Follow-up: on my mid 2011 Mac Mini (8GB RAM, 2.5 GHz i5), playback start is 20 seconds.

[jhwalker]

OK, now I see what you're talking about . . . I have been using DSD64 and (primarily) 24/96 FLAC files, not 16/44. When I start with 16/44, it takes about 15 seconds to start (during which time, there is no indication anything is happening, by the way, which is kind of an interface issue, IMO - should get a "loading" indication somewhere).

Note that I'm using my 16GB, 2.5 GHz i7 MacBook Pro for HQPlayer, not the Mac Mini highlighted in my signature. I'll do some tests there, but I'll bet my performance will be similar to yours on that platform, given the jump from "instantaneous" to "15 seconds" when I moved down to 16/44 tracks!

 

Follow-up: OK, now I'm sat here transfixed, listening to k.d. lang's "Absolute Torch and Twang", converted from iTunes 256kbps to FLAC via XLD, then upsampled to DSD128 via HQPlayer - best sound I've ever heard from this album!

 

Jussi, you sly devil you . . . I am going to have to buy this player and break my "no software over $100" rule

 

I still do have a couple of questions I posted earlier, if you don't mind the bump:

 

 

1. Can you use the same license for more than one computer? I have both a MacBook Pro and a Mac Mini I'd like to license.
   
2. Can the Mac client also function as an NAA? I'd love to be able to do the "heavy lifting" on my MacBook Pro and send the output to my Mac Mini.
   

[Geoffrey Armstrong]

Follow-up: OK, now I'm sat here transfixed, listening to k.d. lang's "Absolute Torch and Twang", converted from iTunes 256kbps to FLAC via XLD, then upsampled to DSD128 via HQPlayer - best sound I've ever heard from this album!

 

Jussi, you sly devil you . . . I am going to have to buy this player and break my "no software over $100" rule

 

I still do have a couple of questions I posted earlier, if you don't mind the bump:

 

 

1. Can you use the same license for more than one computer? I have both a MacBook Pro and a Mac Mini I'd like to license.
   
2. Can the Mac client also function as an NAA? I'd love to be able to do the "heavy lifting" on my MacBook Pro and send the output to my Mac Mini.
   

 

Now we're more on the same page. I can answer these questions. 1/ Yes you can. 2/ Yes it can.

 

The difference in lag time is probably because (greedy me) I'm going all the way to DSD256, because it is supported by the exasound E20. which euroDriver has generous let me have on an extended loan, so I could carry out just these experiments.

 

You are experiencing the joys of what HQPlayer is capable of. Welcome to the club

[jhwalker]

Now we're more on the same page. I can answer these questions. 1/ Yes you can. 2/ Yes it can.

 

The difference in lag time is probably because (greedy me) I'm going all the way to DSD256, because it is supported by the exasound E20. which euroDriver has generous let me have on an extended loan, so I could carry out just these experiments.

 

You are experiencing the joys of what HQPlayer is capable of. Welcome to the club

 

Thanks, Geoffrey! Yes, I'm hoping more of the DAC makers will program ASIO for Mac: I have an iFi Micro iDSD on the way, which will go to DSD512 . . . if they'll write a driver for it