I could incur for it myself last night (in this case by pressing Next (XXOSK) in Unattended which failed - but with Q1 of 48x50) and while the "51 cracks"  were reported on-screen, totally nothing was audible of it.

51 is the maximum which can occur but it will be caught before pushed out and 16 is the maximum which could be pushed out, hence what can slip through before it is detected. This counts for all sampling rates, so at the lowest rate of 44100/sec we'd have 0.00036 seconds of burst. You won't hear that. At 16x upsampling this duration is 16 times shorter. Etc.
Notice that in the sofar posted "beta solution" (2.09-X2) 44100 (1x upsampling of 16/44100) is not covered for but in the final solution it will.

Regards,
Peter

Here is a new XXEngine3.exe which does not trip so fast as the previous one. At least it solves the situation of Arvind (which btw only happened with native Arc Prediction).

Edit Nov 17, 2017 : This is now here.

Anyone gets the Crack Detect message unjustified ? please let me know.
(unjustified is when you can repeat it at the same point in a track or a ttrack boundaries)

Regards,
Peter

Hey, I found a situation where I can incur for the noise. Actually thanks to the new tripping + logging of it, I saw it happening while actually trying something else (with amplifiers off ).

Do not use End After Track
or Kill XXEngine3 (click blue led in right hand border) when you did after all.

Peter

Colin, thank you. Don't spend too much time on it and notice that I think this only occurs with Attended playback.
And the example you gave was with an MQA, so maybe that helps too ?

Thanks,
Peter

Richard, no idea. To me it looks like you are the only one with this. Maybe you now are bothered by the Blocked File thing ? See the properties of the file.

Peter

Richard, that is the one I had too and once you hear that, better press stop.

An hour ago, coincidentally I could reason out what this should cause (something replays from an already played buffer) and I should be able to solve that one.
Btw the underlaying cause is that we use the huge Q1 (x  xQ1) - in my yesterday's case even 48x50 (you can't do that yet).

But please let ke know ASAP whether you used the new XXEngine3 or not, because if Yes, it apparently does not help for this situation (which is sort of logical).

Regards,
Peter

Thank you so much for your extensive reporting, Richard. This should be very helpful. And if not today, then "tomorrow".

The Wallpaper thing remains to be intrigueing ...

Best regards,
Peter

Hello Richard,

It was the idea that you downloaded XXEngine3-209-X1.rar and use that. See a couple of posts back. Did you do that ?

Thanks,
Peter

OK, Thank you.

This is a sort of compiler bug - it's described in the program. Ever back this was solved by putting in an extra dummy line of code, but apparently things changed in there and now it happens again. Or can happen.

Do you perhaps have an idea how this behavior can be persistently/consistently copied ? perhaps with a certain track ?
We must have some means to decently check whether my "solution" to this helps.

Thanks and regards,
Peter

Colin,

The message "Not enough space on Playback Drive" denotes a (1) or a (2) in it. Which is it ? (please don't guess, I need to be sure about it - thanks).

Peter

Arvind - great, thank you.
I am looking into it. When I changed something I will but up a next XXEngine3.exe in this topic (probably today). This will happen as long as needed and after that it will be final.

Regards,
Peter

Btw, someone else came up with the same problem. Maybe that was you yourself, Colin ?

Hi Colin,

Can't this be because you are playing MQA ? This all (OK most of them) expands to 24/96 you know ...

Otherwise you should be able to see the content. So if this happens and you just open Explorer and look in B:, then it should be clear what has filled it up, no ? But leave the message be when observing the content. And if you are not sure, make a screenshot and show me. I will be able to make something of it, I think.

Regards,
Peter

Hi Arvind,

No no, we need some stronger cases for Murphy's law. Like my own case from yesterday :

I did something, heard something which did not belong, put my hand on my ears - the rest of the family thus doing that too and ... bingo. With a large set buffer somewhere it lasted for 10 seconds or so and I just held on, quickly thinking how in the world this could avoid my newly made "tripping" code. Then music started again and when that played for 10 seconds, the noise started again. There I stopped playback.
A few minutes later Murphy's law told me that where I had my regular share of 1 - 2 times per year, BUT challenging for it with the larger buffer (not yet in 2.09) ... I had forgotten to install the XXEngine3-209-X1 on my own audio PC.

Nice eh ?

I actually also wasted 3 hours of time in discovering myself whether the tripping would be too soon. Which ...
I told you would happen.

So Arvind, I talked about that. Please read back on it and respond adequately because I must solve this if there is something to solve. OK ?
If it really is repeatable I'd even like to receive the track (via FileMail etc.).

Thanks !
Peter

PS: The great thing is that while I intended to test matters on the Audio PC and had switched on my Logging on it, but thus never did any testing over there starting with not even putting the program to it, the Logging remained on and I had log data of the happening. If I can find where it happened of course.

Bert, maybe I can agree with you. But partly because of an other reason : the highs are too gray.
As far as I can see, this is controlled by the SFS alone. So have this high Q1 setting and the SFS controls the character of the highs and in the end this started to disturb me (too much of a flavor). My SFS is back to 0.9 and the rest is unchanged (see my sig as of this moment).

OK, (for myself) I added a small gag as announced : Q1 can now be 48 and xQ1 can be 50. All still works and I am not sure whether it makes a difference again.

Peter