Dedicated 16/44 and hi-res DAC

[aps]

The common assumption, one which I’ve made, is to look for a single DAC that deals with all digital formats. I wonder, though, whether the better answer is a dedicated 16/44 DAC that sits beside a dedicated hi-resolution DAC. Yes, this would be more expensive and involve a little hi-jinks to set-up but wouldn’t it deliver the best result?

 

Regards,

APS

 

[The Computer Audiophile]

Interesting post. I believe the ultimate DAC would support only one sample rate. A step down from that would be to support either 44.1, 88.2, 176.4 or 48, 96, 192.

 

This gets far beyond my knowledge so I will bow out now.

 

[PeterSt]

Indeed this is interesting, and it is even important when you'd be into comparing redbook with hires (of any kind). So, how to avoid the apples and oranges ?

 

An easy answer could be this : It doesn't matter much.

 

This answer would count for a random oversampling DAC which runs on a high internal rate (2MHz region) and where it doesn't matter much whether the input is 44.1KHz or 96 (etc.) KHz. In either case the OS DAC runs on the same rate, so you wouldn't speak of "the higher the worse the specs".

Note : This leaves out the receiver chip which' burdon will be higher on higher sample rates to receive but which has jitter implications only (if all is right).

 

Theoretically this does - or should not leave out the "uneven" vs "even" sample rate conversion, like Chris indicated two groups : 44.1, 88.2, 176.4 and 48, 96, 192, while converting within a group incurs for better results (which is very relative, but still) opposed to converting over groups (like from 44.1 to 96).

 

Normally we should let stick it to this.

 

But on this Friday I don't like to be much normal (will I ever ?), so here's the more difficult story :

 

If you pay some attention, you'll notice that the OS DAC already runs on a crazy high rate (can be far beyond that 2MHz) compared to the Non Oversampling type (which runs at 768KHz max), which is ... well, just what your question implies. The OS type should be "worse" to begin with. Specs should be lower, things are more difficult etc. etc., and -as said- whatever you do, it remains as "bad" (did I say that already this way ?).

 

Assumed for this Friday I am right, this implies that looking for NOS types is better to begin with. And *NOW* starts the problem, because an NOS DAC (chip) will run on the rate it is told. And *NOW* you can theoretically speak of "the lower the better". Thus, 44.1 will be better than 192 (or 176.4).

 

Done. Clear. I hope.

 

Wrong.

 

Coincidentally, the NOS (for what it's worth) has to run at 4 x redbook at least to overcome harmonic distortion because of the "digital stepping" response otherwise. This means that no matter what, the NOS type has to run at 176.4Hz at least. This is convenient, because it disallows to let it run at a lower speed with the probably better specs. That would be apples and oranges again. Thus, whether you play redbook (44.1) or hires (88.2 and above) it always runs at the same speed, and it really doesn't matter for the SQ it exhibits. Note that I assume 44.1 to be upsampled "even" (= to 176.4) and that I consider the difference between 176.4 and e.g. native 192 to not make a difference for the chip.

 

Allright. *Now* we are done really.

One small problem : this needs a 24/192 capable NOS DAC, with dedicated filtering per input rate (not per output rate, which is always the same). Go find one.

 

:-)

Peter

 

 

 

[manisandher]

I think I have one... :-)

 

Mani.

 

[PeterSt]

I am sure I have one. :-))

 

But yours is famous.

 

Peter.

 

[manisandher]

I'd like to remind people of the following thread, which I consider to be one of the best on CA:

 

http://www.computeraudiophile.com/content/Multi-Bit-DACs-vs-Delta-Sigma-DACs

 

However, I'd like to point out that I_S seemed only to consider the effects of NOS at 44.1KHz SRs and not 176.4/192KHz SRs.

 

I agree entirely with Peter when he says, "Coincidentally, the NOS (for what it's worth) has to run at 4 x redbook at least to overcome harmonic distortion because of the "digital stepping" response otherwise. This means that no matter what, the NOS type has to run at 176.4Hz at least."

 

Mani.

 

[Wavelength]

Aps,

 

If someone asked me to design the ultimate 16/44.1 dac and someone else asked me to design the best 24(32)/192 dac the designs would be totally different and different sounding.

 

There are a lot of good 16/44.1 dac chips that are no longer made that are excellent in their own domain.

 

There are also a lot of new chips that are really showing promise for full support of high res music.

 

It would however be pretty easy to make each to a really high standard and many would like both and some would like one or another. This is one of the reason's I like to use DAC modules. I can make up something really cool and don't have to make a complete product, only the DAC module.

 

Thanks

Gordon

 

[manisandher]

Gordon, when you say, "There are a lot of good 16/44.1 dac chips that are no longer made that are excellent in their own domain", are these OS or NOS?

 

For me, right now, the ultimate 16/44.1 DAC is a 24/176.4 NOS DAC!

 

16/44.1 files then need to be upsampled to 24/176.4 using a filter with no pre- or post-ringing. Right now, the only way I know of doing this is to use 'Arc Prediction' upsampling in XXHE.

 

Mani.

 

[Wavelength]

Mani,

 

Depends on how you use them. Any dac can be OS and most of them can be NOS.

 

Upsampling sucks the life out of music. Look I play a freaken ton of instruments. Heck in my lab I have easily 20 of them... Upsampling kills music... Best to leave it the way it is and don't let the math get in it's way.

 

Even your piece kills the sonic quality of the original matter. You have only a 40 fixed point ALU in that beast that means you are trowing away just a ton of the remainders that make the nuance of the music.

 

Thanks

Gordon

 

[manisandher]

Gordon, I totally agree with you: the common ways of upsampling 16/44.1 just kill the music. I've been banging on about this for as long as I can remember. I therefore have never used any of the upsampling capabilities of the DACs I've owned and currently do not use any of the interpolation capabilities of the PMII (even though the manual strongly recommends that you do with 16/44.1).

 

But, unless you have a 16/44.1 NOS DAC, your DAC is going to oversample anyway. And if upsampling (even by an integer) kills the music, then so too does oversampling, right? And hence why there are people out there (maybe you're one?) who prefer using a NOS DAC for 16/44.1, even with the 30% harmonic distortion that comes along with it.

 

BUT, I've found a method of 'upsampling' 16/44.1 IN SOFTWARE that I really like. It is the 'Arc Prediction' upsampling in XXHE. Naturally, Peter is keeping the math(s) close to his chest, but apparently, there is no pre- or post-ringing associated with the filtering.

 

I have done extensive listening over the past few months comparing the following:

1. leaving 16/44.1 files untouched (at these rates my DAC will perform oversampling, which I cannot switch off)

2. upsampling 16/44.1 files to 24/176.4 with Arc Prediction (at these rates my DAC does not perform oversampling - it becomes a NOS 24/176.4)

 

The benefits of 2. over 1. are clearly audible. I hear the 'magic' that the NOS die-hards have been banging on about for so long. Although I don't have the means to measure it, I doubt I'm getting very high harmonic distortion in the audioband at these rates.

 

Incidentally, XXHE also allows you to upsample in the more traditional ways - linear interpolation and using anti-aliasing. Both of these just kill the music in exactly the way that I've come to expect from upsampling.

 

Mani.

 

[manisandher]

You said, "... most of them [DACs] can be NOS."

 

Really? How can a delta-sigma (i.e. 99.9% of them) be NOS? Without noise-shaping, surely these things just wouldn't work. Miind you, even with noise-shaping they don't work IMO, but that's for another thread...

 

Mani.

 

[PeterSt]

Hi Mani,

 

Please notice that what you call Anti Aliasing from XXHighEnd's one means of upsampling, really is Anti Imaging. I can 100% understand why AA is still in your head, because that was ever back created for playing DXD onto 176.4 (which is downsampling an requires AA). At that time I called it AA and it was AA. *and* it showed as a choice. What is in there now I call AI, and when used for upsampling, well, it is AI.

 

The AA is still in there too, but it doesn't need an explicit choice; play DXD on a lower res DAC and it activates.

 

So now you know ... :-)

Peter

 

[Wavelength]

Mani,

 

Yes I actually build and have sold a ton of NOS dacs. You can actually make almost any dac NOS by using the 8x input which bypasses the internal filter. Not saying this will sound good but it is possible.

 

Only really the multibit dac chips make for good NOS implementations.

 

Peter I would look to see some results of your filters. As from my understanding there is no way to make a zero ringing digital filter.

 

All digital filters will ring because they are sampled and not continuous like an analog filter is. Upsampling is basically a filter all of this stuff is.

 

What I want is a player that can keep the INT format without going to Float32 and out put to the dac the way it came off the disk. It appears like Stephen Booth is pretty close to doing that on the MAC.

 

Thanks

Gordon

 

[manisandher]

"Peter I would look to see some results of your filters. As from my understanding there is no way to make a zero ringing digital filter."

 

Whadda you say?

 

Mani.

 

[PeterSt]

Hi Gordon,

 

I'm not sure if I can be of any help here, but here is my attempt (I am assuming XXHighEnd to be used) :

 

If you want you can output what came from disk (any "bit perfect" player will do that); just don't apply any "Double", "Quad" and Upsampling. But this is not what you'd want I think, unless you're in for 30% HD indeed (try above 5KHz).

 

Without upsampling the output to the DAC is int16, unless the digital volume is applied, then it's INT32 (no floats are applied internally).

At Upsampling the output to the DAC is INT32.

With Linear Interpolation only integers are used internally.

With Anti Imaging the usual sin(x)/x is used; this uses floats internally.

With Arc Prediction 32 bit float is used internally.

 

Notice that with "24 bit only" DACs (you know the story) above mentioned "32's" are to be replaced with "24's" for the output.

 

Arc Prediction only interpolates, and therefore needs the upsampling to do it. The higher the better, but 4x (from 44.1) is sufficient. Because it only interpolates there is no ringing (but the interpolation is "smart", opposed to linear interpolation which leaves you with only more HD, depending on the frequency).

Arc Prediction measures 0.04% at worst over all frequencies, which includes the (1704 based) DAC and (2m/6') interlinks.

 

You can easily see on the scope what it does and how the different means of "filtering" (because that's what it is of course) differ hugely. Don't get puzzled with what you see on Arc Prediction, because it is mathematically correct (and what your measuring equipment will tell you). With this I don't say it can't be improved. It is best to use 0.9y-4 to see it on the scope, because 0.9y-5 lowers the amplitude by 3dB once Arc Prediction is used, so the "HDCD" Peak Extension can be applied when necessary.

 

Thank you,

Peter

 

PS: Like Mani, I never liked upsampling, and I really tried (with the software and all). As you say, it kills the music. The life gets out of it. Not with Arc Prediction, which even adds to the resolution (which by itself is logic when the upsampling/interpolation is being done well). No music has passed my system yet where I wanted to shut it off for the past 4 months. Also notice that with the NOS/Filterless DAC I *need* some means of filtering, for which the AI setting originally was created. It is workable (read : I had it on for a month or two), until I switched it off again, and knew what I missed. This is when I created A.P.

 

[cfmsp]

"If you want you can output what came from disk (any "bit perfect" player will do that)"

 

"Without upsampling the output to the DAC is int16, unless the digital volume is applied, then it's INT32 (no floats are applied internally)."

 

Peter, AFAIK, it is not always the case that bit perfect players send what came from disk as int16 (or int32) to the DAC.

 

Amarra sends everything through double precision float, I think, as this was one of the early 'rationales' for it's improvement to the sound, per Jon.

 

I'm also guessing that Core Audio expects float, and that it is more work for music players (that utilize it) to maintain int16/32. Can someone else confirm or deny this?

 

 

I've no idea what Rob is doing with PV although he 'advertises' that PV's internal signal chain resolution is 64 bit double precision. Perhaps he's got some bypass to maintain as integer when no processing is required? Anyone know?

 

 

clay

 

 

 

 

 

[Mr.C]

"Perhaps he's got some bypass to maintain as integer when no processing is required?"

 

 

I don't know about Amarra, but I think the HiFace was supposed to perform some sort of bypass with its driver.

 

[PeterSt]

Hi Clay,

 

Apart from everything I *don't* know, at least I can say that in the Win environment nothing (for soundcards and stuff) needs float 32, or otherwise I'd sure would have heard it.

 

The "fact" heard that one can improve on things by better float calculations (which sure is not an easy task) is to me, well, non-sense, because in normal circumstances there is no reason to switch to float in the first place. Of course it depends on what is needed, but common behaviour will be "when it may be needed underway, we better do it by standard". At least I explicitly do not, ensuring myself to get the results I want, which is a kind of impossible with floats (remember, 1/3 will never return to 1 once the result is multiplied by 3 again --> which of course isn't solved by integers, but by avoiding this whole kind of math in the first place and *then* you don't need floats).

 

If you have some time, here's a nice example of guys working on the good old ReClock (from Ogo, it may say nothing to you) : http://forum.slysoft.com/showthread.php?t=19931&page=426

and how they struggle with another man's code and also seem to have problems with understanding in general. To keep in mind at strolling through this, ReClock is a highly respected product used by half of the world, and internally (I saw parts of the code) it is "guessing" all over.

 

If something like CoreAudio requires floats (once 32 bits are output) I'd say : only convert the due output, and then still you won't be "telling" what you want, because a (float)3 is no whole 3 ...

 

Anyway ... If the player wouldn't output exactly what is on disk (no DSP assumed of course), there wouldn't be much chance on "measuring" bit perfect, which I do myself by looping back the digital data and compare.

Notice though that the means (always) used here is the useage of integers again. Thus, if a (float)3 is captured, it usually is captured in normal PCM again, which is integer. And, no matter what number, an e.g. (INT32)(float)3 will result in an exact 3. This is different from calculating with it, where an (INT32)((float)1/3 * 3) may have a result of 0 because this is cut, and not rounded (I didn't try this exact piece of code, but you'll get the geste). C is full of traps on this matter, and here Jon was correct in telling that one can do better by doing it good. But more better is to avoid it ...

 

Don't think I know it all, and much of it is as difficult for me as for anyone else, I guess. I currently use code within the Kernel Streaming environment that uses some formal math on 32 bit words, while (by accident) 16 bit words go through it as well, implying "math" can be done at two channels at the same time. I'd say this can't work, but it just does, and I don't know why ... No complaints about bad sound either.

 

I hope I wasn't too much confusing.

Peter

 

 

[aps]

Thanks for the all the interesting responses.