SQ of 0.9z-1

[manisandher]

I'm not sure if this is particular to 0.9z-1, but I now have an 'issue' with the sound of Arc Prediction. When it was first released, I thought it was a revelation, exposing detail that just wasn't there on 16/44.1 material.

However, I've just done a pretty thorough listening session and have come to the conclusion that AP is making everything sound too 'thin'. The body, weight and substance of instruments is definitely diminished. I have three versions of the same track from Linn Records - 16/44.1, 24/96 and 24/192. Without going into all the permutations that I've tried, I can say that 4xAA on the 16/44.1 sounds sounds closer to the 24/192 version than 4xAP does. Furthermore, the native 24/96 sounds closer to the 24/192 than 2xAP does.

Peter, what has changed with AP? Anything? I really hope we can come up with something, because right now, I can't listen to it...

I did do a few tests with RME's Digicheck, but couldn't see anything that obviously points to a thinning of the sound. (There is however an HF 'click' on pressing play with 4xAP - and perhaps intermittently throughout the track also.)

Mani.

[AUDIODIDAKT]

Mani,

I did not gave the latest (0.9z-1) version a thorough listen.
And I am restricted to DAP (88,2 is my dac max), so i was hoping (looking forward) to your listening experience.
Especially on the hirez stuff

I have one question: is your signature still up-to-date ? I see you use 32 samples with Adaptive mode
Try 1024 samples instead.

Did you missed the 1024 samples discussion ?

Roy

[manisandher]

Hi Roy,

Yes, I saw the thread and I agree with you - 1024 seems to be the sweet spot.

I've been all over the place lately with buffers, as I've been trying to improve my AES connection. What totally amazes me is that everything seems to matter, down to the voltage of the AES connection. In some instances, 32 samples is better, in others 1024 is better. With 4xAP, taking it right up to 4096 helps, but doesn't solve the issue IMO.

FWIW, the comparisons that I mentioned were done with the buffer set to 1024. I'll change my sig...

Mani.

[manisandher]

4xAP seems to work well with HDCD.exe. This doesn't sound thin to me. Maybe I'm just losing the plot...

Unfortunately, I can't make a direct comparison with the HDCD decoder in my DAC as I now use the XX vol control and have no preamp in the chain (one of the best improvements in the sound of my system BTW, and I was a die-hard anti digital vol guy, until I tried what Peter's been suggesting all this time).

Mani

[PeterSt]

Hi Mani. Thanks for your clear reporting. And of course everything what is beyond that to get there.

I'm not sure if this is particular to 0.9z-1, but I now have an 'issue' with the sound of Arc Prediction.

Can you please clarify this a bit ? I mean, you did listen to 0.9z(b) as well, or didn't you ? Thus, if not, the quote above makes much more sense to me than when so.

From 0.9y to 0.9z things sure changed, and this change implied a change of KS being the best at Secial Mode and low latency, to KS Adaptive Mode at high(er) latency. This by itself was not intended, but this is how it worked out to be.
From 0.9zb to 0.9z-1 nothing changed explicitly BUT I can have made a 1000 mistakes in the code. This is related to the 24 bit upsampling, and *everything* had to change. This is why I am the most happy you had a glance with DigiCheck, which actually I should have done myself, but it can't be done for all the combinations.

Maybe I'm just losing the plot...

Yes, this could be key, and I am serious. This is exactly what bugs me anyway. So, at least overhere I am in the stage of things getting theoretically better, but the sound may get worse from it. A maybe too simple example - but which shows what I mean - is the now being even of all the frequencies I have always been seeking for, and then mainly thinking of the SPL of cymbals. So, I was just listening to Heard it through the Grapevine (CCR) of which I always thought it was a nice cosey long track. It is early in the morning here, so I thought to keep it smooth at testing something. But this now appears to be one big long row of hitting cymbals throughout, and whoever wrote the track he must have been on cymbal dope. As said, the example may be too simple, but if you hear these cymbals all over and for 11 minutes long, they better be 100% good. And, since this is the foremost difficult "part" of it all, maybe they are not. Sweep in a preamp, and you may be better off in this case.

The interpretation of things become complex once things are overdriven. Also, it may be impossible to overcome it (overdriven = overdriven), unless the part concerned is changed for the better.

Allright, the above is totally unrelated to anything about "but this can't be XX !" ... the contrary. I am only trying to explain how difficult it is for myself.

At this moment, I too, am in the stage of something can happen to the PC at a reboot. Or maybe after a hang and a reboot. It happened to me day before yesterday, and besides I can see that the PC is behaving a little different (such as a stupid little thing the tasks won't go to the taskbar by means of the "blue screen" button as fast as before), and I think by now we all understand how important the response of the PC is. If that changes for, say, 10%, the sound will just be totally different. So, am I suffering from that without knowing what to do to solve it ? or did I too loose the plot.

Peter

[manisandher]

I'm not sure if this is particular to 0.9z-1, but I now have an 'issue' with the sound of Arc Prediction.

Can you please clarify this a bit ? I mean, you did listen to 0.9z(b) as well, or didn't you ?

My comments apply more generally to 0.9z vs. 0.9y. With the latter, I simply never had an issue with AP.

I've (finally) finished making up some cables that will allow me to record from analogue. What I want to try is recording the same track at 16/44.1 (with and without Peak Extend) and at 24/176.4. This is what I'll then do:

1) Tune the 'XX chain' playing the native 24/176.4 file until it sounds as close as possible to the analogue source going through the 'A-D/D-A chain'. This will entail playing with all the variables in XX, my PC, the PCI/firewire interface, power and cables. The biggest issue I have here is that I am going to have to use a vol control for the A-D/D-A chain. To make it consistent, I will use the same vol control for the XX chain and set the XX vol to -0.0. (The vol control will be an Audio Synthesis ProPassion connected to the power amp via 0.5m cables.)

2) Find the configuration in XX that gets the two 16/44.1 files closest to the 24/176.4 file.

Then I think I'm done.

Mani.

[Marcin_gps]

Mani, underclock/undervolt your CPU as much as possible and run it on a single core! In my system there is a huge difference between one and two cores (voltages, clocks and other setting are the same). On a single core I can pump up the volume to the limits, while on 2 cores I can barely stand the sound at 11 o'clock.

[PeterSt]

A maybe stupid question Marcin : What would be your opinion on an Appointment Scheme which excludes the second (and 3, 4) core completely ?

And don't you have problems at track boundaries now ? (ticks)

[Marcin_gps]

I don't know Peter, what difference would it make if I only have one core available? :D And no, I don't have any problems with ticks and pops, I only have to choose Low/Realtime priority for hi-rez files. I prefer High thread priority, I think that the sound is fuller this way.  Split size at 75 MB. Of course, my PC is hardly usable while listening to hirez tracks with quad arc predicion. My cursor freezes every 30 seconds or so, but no ticks Any plans on improving memory management? You wrote that it's impossible to load the whole album into memory. Isn't that Engine3 "stability issue"?  Anyway, like you wrote in other topic, the bar is so high right now... 

[PeterSt]

I don't know Peter, what difference would it make if I only have one core available?

The question was a little different (please reread) and about the simulation of one core, instead of tweaking the PC (bios) so. Do notice that you'll always be happier with more cores at the preprocessing stuff. So ... during playback all must think there is one core only, and I can do that with a new Appointment Scheme. BUT, it won't be a hardware solution, and for sure no Undervolt solution. That is how I asked the question ...

while listening to hirez tracks with quad arc predicion.

As in : 192 x 4, right ? Hahaha, show me.
I can show you though.

[Marcin_gps]

I don't know Peter, what difference would it make if I only have one core available?

The question was a little different (please reread) and about the simulation of one core, instead of tweaking the PC (bios) so. Do notice that you'll always be happier with more cores at the preprocessing stuff. So ... during playback all must think there is one core only, and I can do that with a new Appointment Scheme. BUT, it won't be a hardware solution, and for sure no Undervolt solution. That is how I asked the question ...

Yes, I know what you mean, but the difference is in power consumption of CPU and noise/ripple related to number of cores active (hardware). But who knows, maybe a special scheme for one core would bring some further improvements.

while listening to hirez tracks with quad arc predicion.

As in : 192 x 4, right ? Hahaha, show me.
I can show you though.

I meant 24/48 files 

[PeterSt]

Let's call that underrated hires.

[PeterSt]

Mani,

From your description, and from what I can hear myself, it could be a 16bit -> 24 bit issue.
Notice that HDCD is converted to 24 bit before (thus outside of) the normal Arc Prediction program code.

You didn't see any anomalies to this (16 - 24) respect in DigiCheck ?
Or maybe now you know there could be a theoretical problem, you recall something strange afterall ?

Thanks,
Peter


PS: So yes, we both defined a clear difference between 192 and QAP within two seconds. But today the difference seems larger. Difficult to compare with the past for me though (DAC changes).

[easternlethal]

Hi Peter - Yesterday I compared (with my ears) XXhighend against Foobar with SoX Resampler - mod version (with resampled to 196) + Convolver with correction filters created by Audiolense.

I am not sure if others have experienced the same thing, but as usual XXhighend had better imaging and a more 'black' background. On the whole it is more musical. However, there were 2 things which XXhighend was weaker: 1) it was not as lively, in that it seemed to be putting its effort into creating a beautiful sound but it seemed to lack the 'oomph' for certain pieces (especially symphonic pieces such as Schubert's 9th or Beethoven's 7th and did not sound as dynamic).  2) it also lacked a certain detail in the middle register (for jazz pieces with a lot of details in it such as the 1st track of Chick Corea's Ultimate Adventure, or Corryell, Asad and Abercrombie's Three Guitars). I think that for 2) was a combination of Convolver and the higher resampled frequency (compared to XX's 176hz) but I can't explain 1).

When I switched to XX last year it was clearly better than Foobar but recently with these comparisons I am not so sure. I will experiment some more and update with more of my experiences, but perhaps if you have the time you can also try and let me know what you think.

[PeterSt]

Well, first of all thank you very much for your extensive reporting and explanations. Really good.

Of course, at this moment I can't have explanations myself, and the only thing I can do now is trying to put things in (some) perspective;

First of all, it obviously is very hard to judge any setup which uses third party (additional !!) solutions occuring on one side (Foobar/Convolver), with not such a solution on the other side (XXHighEnd). Of course, you speak relatively (a comparison with the past), but it still is as difficult to judge, unless you are goingto tell me you never changed those convolution files (which you can of course ).
I could add to this that you could have created that solution for XXHighEnd just the same, if you had the hardware to do it.

But is it important ? ...

Your suggestion that the higher frequency used (192 opposed to 176.4) is a nice one, but I would forget about that as a reason. The whole method is different,, and since this too (SoX resampling) is a third party product and you didn't compare with that ... anything may happen.

But is it important ? ...

No, I don't think so, because it all will be too much apples and oranges. What *is* important though, is the relative change, when the past is compared to the present. And it is just this which IMHO can only flaw too, because too many things will have changed on both sides.

So is that important ?

In the end there is only one thing important : what sounds best to you with your environment and all the tools you can find to do that job, right ? And if that is Foobar with its possible additional tools, then it is that ...

So, having said this all, for now there is really one thing for me to do, and this is the attempt to make clear when apples become oranges, and comparison is not allowed. Or better the other way around : what to do to compare better, with in the end just the best means of playback. So, assumed we can agree upon this, here is my advice for today :

If you (with respect !) think playback gets better from room correction stuff, well, you better keep on thinking that, but I never will. It is just sheer impossible for me to think that, because all what I do at the far less than micro level to get things right, is destroyed at world level by such a thing. And maybe I am allowed to remind you about my thinking that GOOD playback removes everything which looks like a standing wave or anything, and no room correction is needed anymore. Maybe in a completely undecorated concrete room, yes, but then the base is just too wrong to begin thinking about improvement.

In between the lines : I know, when you are using XXHighEnd you won't be using the room correction (well, I think you don't), which is priceworthy for XX of course. So, by letting you know I understand this, I hopefully indicated that this isn't a debate or such; instead it is about how to approach things ... uhm ... in my view.

When you are using SoX resampling, you may wonder what to do that for. If you think the sound gets better from that, well, you must be wrong somewhere. And more nicely put : "It" must be wrong somewhere. The point is, SoX resampling doesn't improve on one single thing looking at it technically. IOW, if you think it does, maybe you can explain to me where that is. At this moment it is (IMO) one of the best resamplers, but it still rings as hell. And what are your resampling ? well, something your Weiss does in the first place. So, it is my firm conclusion that your SoX resampling has only chances of making things worse, and it had *no* chances of making things better. Again, if you differently, please let me know. However ...
There are so so many things which can be wrong in your chain which "allow" such process to make things sound better, that there is no way to even begin with explaining how it can happen and what could be the cause. BUT :
When Arc Prediction Upsampling from XX is wrong at this moment, this is always the explanation of course ! And so, we are never allowed to forget this possibility. And of course, it is in this context you wrote your post, and before you forget it : good ! and thanks !
But still ...

Now notice how all starts to come together ...

What you most probably don't know, is that AI upsampling is just ... SoX. Aha. It may be more optimized than what is used in Foobar, it may be less - I can't tell that. The only thing I know is that I set the parameters myself so there's an optimum result for at least going from 44.1 to 176.4. Going from 44.1 to 192 shouldn't differ much, but it uses the same optimization as going from 44.1 to 176.4. I wouldn't bother about a possible difference anyway.

Now read back what Mani told a few posts back, and see the potential of the same technical merit (hence anomaly) you found. And you see, no matter you incorporated convolution, you still can be very much right ...

With this maybe unexpected change, you too could try AI (4x) with the knowledge the convolution isn't there. So, assumed the optimization of the filter in Foobar is equal to what I did, you will perceive the difference of the convolution not being there. From there you could hop over to QAP, and now judge what the actual merit of that is, in today's form ...

Now, and only now -but with some absolute memory on how things sounded in a "before" situation- you have created apples and apples.
And now you know why I thought it was necessary to spend a few lines of writing on this, just because it is important. And you also know I am not here to defend XX or anything, but to improve it, or keep ahead if you like.

All 'n all, if you would be able to just agree with Mani's findings, this is very valuable to me. Not that I won't believe Mani in the first place, but he too is not sure about his observations, because they are not consistent (why does QAP with 24 bits still do the best job ?). It is my finding too, though from another angle : just plain hires which is too much better compared to before.

Long story short : I think I must agree with you, but try to have the oranges out of the equation. Then I won't think it, but just know. The latter is because I believe you all unconditionally (but with the condition of leaving the orange out ).

Great thanks,
Peter