Ok, I wanted to put this in a separate topic, but actually it is 100% related, so here goes :

Mani, I don't know about your signal processing skills, but personally I don't understand what I'm seeing, looking at your plots.
Remember what I said elsewhere : "I don't like to apply an AA filter, because it would roll of the highs" (similar). Mind you, this thinking of mine is taken from what can be read all over the place;

Your plots show (and mine obviously will too) that the roll of is already there *without* an AA filter. Now what ? was everybody looking only after the AA filter had been applied ? Or IOW, what is actually going on here ?

a. there's a problem in the (XX) software;
b. the DAC isn't capable to cope with the high frequencies at the higher resolution (that's what it would come to) (for others : keep in mind that this goes over the analogue output of the Fireface, with or without loop back cable (the loopback it can be done internally);
c. the aliases influence the phase of the audible side of the mirror, and therewith attenuate;
d. the method of measuring is faulty;
e. this is just normal signal processing theory stupid, get your books !

Please keep in mind that I look at this all from the context of knowing what the program does. So unless a. above is applicable, I can't think of why a sequence of samples coincidently implying a higher frequency, would decrease in volume (that's what the plots show) other than c.
I don't change that volume, nor is there any arithmetic that implies it ...

All correct Mani. Including the last one.
There are some more combinations though, like playing a 96/24 over a 16 bit (set) DAC. That too is processed in real time, and that too can be setup differently.

Note that at some stage the advised 2GB of internal memory will go low ...
(just think of 96/24 files being pre-processed; they are really over 2 times the size of anything which I had  in mind of needing to be in memory ONCE MORE hehe).

Allow me to say this latter is a good remark, or one I try to deal with explicitly anyway. On that matter, keep in mind the explicit change I wanted in 0.9t, which was about "more metal" where things had gone too plastic.
In all cases this can be compared with (digital) imaging, where added noise perceives (nothing more than that) more sharpness, while the opposite - denoising makes the image litterally plastic. Ok, this is not abpout (de)noise, but for "sharpness" things come down to a similar matter. The key to my last referred to link above, just *is* in the area of sharpness ...


DAC Needs is a technical setting by itself, but when set to a lower rate than actually possible (which would come down to choosing a 16 bit setting for DAC Is (!)), higher bit depth files will be (explicitly) cut.

Your suggestion that it doesn't change anything would be true for your context given, but you are forgetting the volume control. Only for that, a higher bit depth setting is of life importance.

"Tap my feet more" is a perfect description. In fact the best where other descriptions fail.

Ok. Why do the both sound different ? well, for me this is perfectly explainable, but let's say for now that the code for both situations is different. And -so far- (see later) this had a purpose;

The 44.1/16 code has remained exactly the same as before to the point of sound quality. I did this on purpose, in order to not dissatisfy people which were satisfied. By itself this is related to the necessary code changes to allow the larger bit depth. Thus, actually the latter should have urged for different code for everything, but I just retained the "old part". In fact I was hoping for someone to notice the difference (and remember, I myself won't use the old code because I want the larger bit depth to be active, that by itself because of the volume control).

Now, because the old code too is (has been made) subject to volume control, *and* I wanted to pertain the old code for SQ, this is pre-processed for the volume control. After that has been done, te playing code is 100% the same. This is similar(ly woking) to how I can guarantee FLAC not making a difference.
Once a converted bit depth comes into play it was more easy to do this real time, and the necessary code for that influences sound.
And thus, we already can see the next sound improvement coming up for those who exploit the additional bit depth (which already is in order at 96/24 files, no matter your DAC can do 24 bits only, and which is related to all being transported over 32 bits ! ("DAC Needs")).


For a few reasons this gives the major impact on SQ. But careful though, because your Hypexes may respond to the vast improvement on transients, and so far accepted sibilance could become unacceptable. I don't know really, since the only D/T amp we skipped at the time (about one year ago) was the Hypex, but all the others had unacceptable sibilance to begin with. According the principle used in there, I expect the Hypex not to be different, and I only want to say : be careful in your judging on what you actually hear / listen to.

When you use the volume control, you should not avoid the additional bit depth, unless your attenuation will not be more than, say, 24dB.
For now this means using the "bad sounding" (hehe) code, but I will change that since I now know that it makes the tapping feet difference indeed (no matter it is only you saying it ).

On the digital vs. analogue volume control much more is going on than allowing for the pre-amp to be eliminated. What I found on this remains a secret so far (The 0.9u what actually happened topic ... ).

Haha, I can tell you, flat as a (vertical) pancake (I tried that same plots to find all the bugs ).


Well, you got my message right ...  
On that matter it is my idea that anyone who compares apples with apples (which I can't, and I'm not sure whether Mani uses the same DAC in all cases) could come to the conclusion that Quad/Upsample (but into 18 bits at least !) is better. And as I said earlier, the sole fact that I heard more information on known records, kind of makes me urge to explore it further (but see next post !).

For others : keep in mind that we all don't use the same amps. However, when the battle has to be fought over Leo, Mani and me, they are equal regarding the speed (which IMHO is an important factor to the subject).

Haha, that's why I'm asking (and why it is important). Two other questions please :

1. Do you use the volume control (either case) ?
2. Could you describe the difference between both cases (always playing 44.1/16 of course) ?

Btw, I already know my answer, but want to learn the perceived difference in the end result of things. Also note that I never listen to the "DAC is" 16 bit anymore, because I use the volume control (and really want to use my extra 2 bits (from the 18 bit DAC)).

Thanks,
Peter

Hi Bernard,

Keep in mind that the user(id) itself must have Administrator rights as well. Not only at changing the UAC settings, but also when running XXHighEnd.
Otherwise I can't think of anything.

You are not using Vista/SP1 I suppose ?


PS: Quite some fast system you have !

Well, what can I say ...

I based my enthusiasm (in the release notes) upon more perceived detail hence things there which I didn't hear before, things not getting wrongly to my brain, and an important factor - listening though the Fireface as the DAC with the pre-amp in between again.
I did not A-B anything, knowing that the Fireface as DAC already would make the situation a loosing one, BUT, I don't recall ever being able to listen to/through the Fireface actually hearing better elements.

After a couple of hours it started to loose its interest, but (for me) more importently : when I shut down the music at dinner time, my wife said she was glad I did. In the mean time I had been turning down the volume at some tracks (also an indication of the very wrong), and all 'n all ... it can only be so that this is not it. No matter how I want it (like the movie thing), it probably can't work.

Maybe if I do build in an AA filter afterall (of which I'm near sure it will be for the worse).
First some other things though.


Can you please confirm that this is actually what you do and want to say ? I mean, this is different from "setting" the DAC at a higher bit depth (the frequency is unrelated), still listening to the native track (hence not doubled etc.).
The answer is kind of important (will tell later why).
Please, I don't ask you to sit down and (re-)listen (actually you should not), and only want to know what you meant to say.

Peter

It is strongly advised to not use your system without a preamp (or the pre-amp at max volume for that matter) if you or your speakers won't be able to handle a situation that e.g. the file contains wrongly formatted data or otherwise - because of which cracks may emerge with an energy beyond imagination.

With many thanks to Mani (manisandher) :

a. bugs were found influencing SQ largely related to ... see title;
b. those bugs could be solved by stupid measuring;
c. which saved ages of listening instead.

My personal opinion on the SQ improvement on Upsampling with an 18 bit DAC at least : this is the first time I hear what I always perceived from "upsampling" movies which works so very well. But don't let me placebo you ! (ok, I just did, so please try to listen with the necessary dose of honesty).

Also you're entitled to receive apologizes from me at making those programming errors. On that matter I again thank you for the honest listening as I just pointed out *and* opening your heart instead of liking something because someone else tells you should.


Additionally a bug at the available checkbox options for Double/Quad/Upsample was solved.

Peter

What happened to the imaging ? Well, I can tell you.

Quad/Upsample :
First pair (L/R) of samples (out of the total of 4 pairs) was written ok, then 3 interpolated samples went to the left channel, then 3 interpolated samples went to the right channel. So, 25 % of samples was ok, 75% ended up in the wrong channel, implying a high degree of mono sound.

Double/Upsample :
3 wrong lines of code indeed caused that a.o. the part of one sample (think of first 8 bits vs. the last 4 bits) ended up in the wrong channel.
This was expected as per the plot Mani showed (a torned circle).

It's actually fun learning to read these plots related to program errors.
Again, Mani, thank you.
Peter

Ava,

It may sound really really stupid, but I don't have a clue. If 1, 2, 3 or however many other people would jump onto this, than I'd scratch my mind as long as it takes, but now ? I don't know where to even start scratching ...
Again, if you can tell that the behaviour changes over versions, I really hope you can make something of that.

Whatever I can do to help you ... I will. But this just puzzles me.

Btw, start TaskManager in advance, and try to see what is actually consuming the cpu ...

OK. I've got a small "confession" to make;

Double/Upsample is working OK now here, and I imagine myself to have heard the most undisturbed sound so far. Don't matter higher buffer settings and all, I enjoyed the music VERY much the last couple of hours. Does it work afterall then (my remark about movies where upsampling just visually works for 100 % sure) ?

Quad/Upsample does not work yet other than "wrongly", and it kind of needs the program to be re-written which I will do.

Mani, thank you once more for your remarkable justification on ... well, the title of this topic;
With or without justifying pictures I listen. Now or in the future.

Peter

If I tell you that on those matters really nothing was changed between versions you mentioned, I hope you can find something yourself ?

Ho Joaquin,

When I say something like that, I only mean to say that as far as I can tell SQ might have changed, but I really don't know for the better or for the worse. That's all really.
"Assuming worse" is kind of legit, because if it is unintentional, chances are kind of 50% that it got better or worse. Of course this is a kind of negative look on things, but I can't see you'e wrongness on this.

Everything will be finished when everybody agrees upon things working out OK *and*, say, workable.

Peter

Ah, I'm sorry, I wanted to respond to that in the previous post, but got stuck in the 6000 lines of code.

Indeed, what will have happened, is that PARTS of the samples (oh yes) have been assigned to the wrong channel, or just aren't upsampled (but repeated = doubled (or quadrupuled)). This may look strange as something which can happen (in decent program code), but it really is not if you know what all has to happen to utilize the additionally available bits (because remember, this is so far about 16 bits only, while 24 are avaialble, and I just use them). All in combination with the digital volume, DACs which allow for 16 bits only *but* where Doubling/Quadding is allowed just the same, and some more stuff like the calculations themselves which may be just wrong.

Anyway Mani, what I see here indeed, is or :
a. a mixture of aliasing and wrongly assigned sample parts or
b. all upsampling just being plain wrong (on that matter I forgot to check "DAC is 16 bits") or
c. aliasing influencing the whole spectrum, but which doesn't show on the frequency plots.

At this moment I can't even see how a. can be in order, but I keep in my mind that the RME software just *will* show the theoretical frequency full range, coming from the sampling frequency, hence up to 44100 Hz at 88K2 sampling. So it will incorporate the anomalies above 22050 just as well (but you can't see them seprately in the Gonio plot I think).

But let me first try to find the now 100% sure culprit in the program. Then we can start looking for other things.