Yannick, nah ... Each Windows version is explicitly dealt with. If the version is newer than what is supported, it just falls out (to not supported, hence XP).

At this moment, the latest versions supported are WS2019 for Server and 14393 for normal W10. Within that we have guidelines line "only use the .0 version". For this latter we have the 14393.0 version and any 14393 version beyond that, will sound worse (it is loaded with more stuff not dealt with and obviously I can't make new XXHighEnd versions each day or week or even month. This is also not necessary as no 14393.x will have better SQ versions than the most native one (the .0).

You will (hopefully soon) see that for W11 there will be a supported "base" version. Next, XXHighEnd will not allow updates to that supported version because it may break things (this is similar to current W10 versions not being able to boot into MinOS unless you got that working yourself). There is (or could be) too much in the way.

Each newly supported OS version (and e.g. 14393 vs 00074 are formally supported versions with 4 or so in between) takes many weeks to get there. And 100s of boot attempts.

Peter

Hi there Yannick,

XXHighEnd must explicitly anticipate on W11. And it does not. Then indeed it falls back to XP mode and nothing will work.
When W11 is more definitive I will dive into it and make it work (if possible).

Kind regards !
Peter

Hi there George - thank you.
Kernel streaming surely is installed. Without that no sound.
You probably were thinking of WASAPI.

Kind regards,
Peter

Interesting ...

I don't think you can tweak like that because XXHighEnd does similar itself. Additionally I never took into account 2 processors in the sense of the total core count emerging by that. I mean, 12 + 12 would be 24 and 24 cores are not supported as far as I recall (I could look into the program - haha). So for example, 12 would be supported, 16 would be, 20 would be, 28 would be, 32 would be, 40 would be. But not 24 because I never saw a(n interesting) processor with 24 cores.
I would not think that things error out because of this (but apparently it can ?) but at least SQ would not be as intended (processor tasks would overlap / be mixed while all should be dedicated (no taskswitching implied)).


I think it is good to know (as said) that XXHighEnd does these things itself, and that possibly this implies anomaly because of the two levels this now occurs. Thus, you do this by means of TaskManager, and XXHighEnd does this internally. I'd say this will overrule but ... how will this unroll the stack ? Think of you quitting XXHighEnd and all nicely being undone (this really is so). But if XXHighEnd bails out because of demo-end time, then I am not so sure. It could be a too hard-quit falling back to ? ... Your settings ? ... I just never thought about this. And thus :

Interesting ...


PS: And thinking some more ... The Demo version does not allow explicit Core Appointment (see the according field in Settings for that), BUT one scenario is set anyway. It can well be that at "bailing out" this is not sufficiently taken into account. "If Demo then Don't reset Appointments because no User Settings applied". And this all in the midst of quitting playback right where it is (doing its job), which is different from you stopping playback where all is reset (mind you, for the whole system, not only the two XX executables). So yea, the bailing out with playback going on may not do even anything about resetting Affinities ... (call that a bug).

Thank you Robert.

I refrained somewhat to mention this over here, because it relates to other XXHighEnd settings as well, and in combination with the Blaxius^2.5 (as I mentioned over there) it is already difficult enough. The fun could be :

While you could know about XXHighEnd settings and change them accordingly, I did not tell them and you did thus not apply them and THUS out of all context it is even better that you like the
A:W-Y-R-G, B:W-Y
better than the "original".

So I like to be quiet about the XXHighEnd settings (I have been playing with them for 2-3 months by know, thinking it was about the Blaxius^2.5 only (allowing for again better settings hence sound), and obviously eventually I will tell about them. But while we're at it anyway, I rather like people to tell about their findings out of this context. we all could learn from it, just like *I* learned from you that possibly now Arc Prediction is for the better. So I am gong to try right now !

The combinations never end, do they ?

Best regards,
Peter

Hey there vhs,

Well, not that I knew about this error, but it will only occur because of the demo version "quitting". So between 6 minutes and 30 minutes or so, the demo version shuts down automatically, and apparently there something goes wrong now. But it would have quitted anyway ...

Thank you very much for mentioning this and of course I am going to look into it !
Peter

Mani, Thank you.

David, in your case I think it should be (about-ish) :

The DC Offset of your NOS1 is ~ –04.4mV/+00.6mV.

(from April 5, 2015 - unless you have a NOS1a by now - at quick look I could not find that)

Peter

Btw, assumed that you don't have isolator transformers (like Mani), key should be the ground reference which for the NOS1 is 0V (it is set up differentially). For that amp it is most probably no 0V at all because derived from the mains. The difference in voltage could be the noise you perceive.

David,

I have just been reading in that topic you quoted from and stopped halfway page 2 . If you ignore what you quoted (about Nick's -144dB which was a totally different subject as I recall it turned out), it should be something like what's being dealt with in that topic. It is quite complicated.

So instead of trying to repeat what's all in there, I think it could be a good idea to at least read the first two pages in there. Btw, very clever that you found that topic !

Best regards,
Peter

Hmm ...


David, then I'm afraid this can not be correct (or something is plain wrong with that).
Switch #2 Off means the DAC board is without power. So it shouldn't be able to play/show music.
Do you hear a relay clicking when you flip switch #2 (either direction) ?

Peter

Hi David,

After reading this a couple of times, I only now see the relation with the battery. So what if you detach the battery ? in this case Switch #4 can't do anything.

I take it (though wild guess) that something is amiss with the internal wiring related to the meters inside. The two wires running to the meters from of the middle section of the DAC connect via single pins (detachable on purpose). Maybe they are not joint thoroughly any more ?

The NOS1 should be completely silent, like my own and 30W into the 118dB sensitive speaker (no volume control).

I never heard of what you describe ...
Best regards,
Peter

All right, thank you David.
Quite some things have changed, and let's hope that the upgrade solves this. If not, we'll definitely work it out.

Thank you again,
Peter

David,

This shows as normal as can be with my current version here (2.11b, due 2.12).

First screenshot is how it shows after search (with the link you gave). Second is with playing a track (no explicit Prepare, but that won't matter).


Do you mean nothing like the "96" shows ? just blank, that little area ? If that is so, XXHighEnd could not hand the album to the decoder for some specifics which is caused by some authorization problem. But, it should give a message about that. This could be the message "this only impacts the Coverart Icon" or something similar.

If we can not get hold of this specific issue, then we better wait until I uploaded 2.12. But I don't think it can make a difference regarding this specific issue. However, notice that your rights over there (USA) can be different from mine here (Netherlands). But ... this should just be Tidal rights and not specifically MQA related.

Best regards,
Peter

Hi David,

Do you have the Album ID of that for me ?
(or just share (copy/paste) the link from Tidal)

I could show you how it shows today (all tests OK so far).

Thanks !
Peter

All,

Not the update yet, but an update on the status.

Quite some people have complained about the Search function not working any more in Tidal. Also, MQA albums suddenly cut prior to their end.

Both issues have been solved, although the MQA problems require some more "live" testing.
When this has been done, a first update will be posted (expect this somewhere this week). Right after that I will continue with some more functionality, especially in the Tidal Search department. And for example, Tidal Playlist are broken too, for a while now, so that should be solved in a later update as well.

The MQA thing appeared to be a tricky one, as these new(er) 16/44.1 MQA's seem to be quite the same as the 24/44.1, *but* with the "extension" of those being presented as 16/44.1 now, which expand to 24/44.1.
Can anyone follow ? ... maybe not. It took me many weeks (throughput) to finally see what is going on. Btw :

Nobody elsewhere will really notice (have noticed) because I think XXHighEnd is the only player which shows all the native data from various angles (like the 44 and 48 blue icon) as well as the bit depth before decoding, the expanded bit rate after decoding and some more which does not show elsewhere (including the possibility to not upsample by default so a 16/44.1 seems to be a 24/88.2 natively) ... but it was exactly these features which let things go wrong because they were not anticipated. Thus, if it is the assumption that MQA is always 24 bits in the delivered file, things go downhill fast when this is not the case any more, like today.

Notice that I assume that the 16/44.1 delivered file is in the end the exact same as any file which is - or previously was delivered as 24/44.1 and thus the decoding of MQA is justified (sounds better than leaving them undecoded).
However, it is to be kept in mind that normal Redbook CDs from before, have now turned into 16/44.1-delivered MQA and this is not the same at all as the original Redbook (I checked). And it is up to you which of the two (original vs 16/44.1 MQA) sounds better.

The upcoming update will have a provision to enable the Preparation of the new 16/44.1 MQA while your old 24/44.1 is left untouched; the file name of the 16/44.1 MQA will contain something like {MQA16} instead of {MQA} - I must decide on the definitive format of it.

When talking about MQA anyway, I noticed that previously existing decoded 24/88.2 and 24/96 largely disappeared from Tidal and changed to 16/44.1 (blue icon) versions. I have no idea why that is. Here too, your formerly Prepared 88.2 and 96 (or 176.4 and 192) versions, differentiate from the others, at least by means of again the {MQA16} tag, but possibly they also differentiate by a new Tidal Album ID - the large number between {}.

If I have more to say about this first upcoming upgrade, I will add new posts in this topic.
Questions ? shoot.

Peter