XXHighEnd

Peter I have never had issues with this until now.

But odd tracks on albums throw this message up. They are from ripped CD's. I re ripped them but still Crack message. I see there is a Disable Crack button recommended for Engine 3,4. This does work when activated. Is this OK? I see you have been playing with Crack Detect in your latest Mach III post. I don't know anything about Crack Detect which is why I'm cautious.

Robert

Hi Robert,


No, it is not advised at all to disable Crack Detect; it is your protection to software failure and how otherwise static (the most loud noise) can emerge.
When you are sure it will be or the rip which is not 100% OK or when it is just "the music" (see below) you can switch it off for the occasion.
If Crack Detection trips on two different SFS settings, you can be ensured that it is just the rip or the music (and not software failure) and nothing will go wrong when it is switched off.
For your own "safety", don't forget to switch it back on after you played the album.

With the (internal) thershold setting in 2.10 it very occasionally trips on normal music although the music will be the most dynamic.
Indeed with bad rips and glitches in the resulting file, it will tip too.

Indeed it will be so that a next XXHighEnd version will allow more of "inordinate" dynamics hence it accepts more ("glitch") as normal music.

If not clear, please ask further.

Best regards,
Peter

It did trip with same SFS settings. One track was from a Bob Marley remastered ripped CD Kaya. The other from Peter Green The Best of ripped CD not remastered. I didn't think either were that dynamic being older recordings. Anyway I have left Crack Detect on. Thanks

Robert

Robert, to be clear ... if it trips with two different SFS settings, then it is OK and just the music (or the rip). Notice that both are harmless.

The software failure would be that e.g. 1 bit (out of a 16 bit audio word) is missed/skipped, which from there on would make a mess of the remainder (a softest bit will become the loudest etc.). This can theoretically be incurred for by the relatively complex "alignment" of the memory player vs the SFS controlling what you actually want in memory. I (XXHighEnd) can do something wrong there - Windows can do something wrong. However, this is highly unusual unless I introduce mistakes myself. This was so with IIRC 2.07 or 2.08. Then it started to happen to many people, but depending on the SFS setting ...

Best regards,
Peter

Peter, I had this kind of issues very rarely:

24 bit second stage crack dedect !  -> 34
playback has been stopped

But since yesterday it happend for 4 different tracks. I tried with different SFS setting and it still happens.
All these tracks play well with other players. Nothing strange to hear. I have downloaded these track from Tidal and Beatport, they are no rips (at least they shouldn't be).

Download from Tidal:
Artist: "KMLN", Album: "2015 - Alhambra"
The crack detect error occours for the first 3 tracks of this album.

What's maybe interesting: The first track "Alhambra (Original).flac" I also downloaded from Beatport in aiff format and then converted it to flac. Same thing: crack detect occours for both versions.

What to do about this?

Kind regards
Richard

Hi Richard,

What to do with this ?
- Wait for the next XXHighEnd version;
or
- Use Custom Filtering.

OK ?

Best regards,
Peter

Ok, Peter,

I didn't know that it's related to AP filter.
Custom filter works well with these tracks.

Kind regards
Richard

Hi Richard,

It is not related to the AP filter - it is rather the other way around;
The Custom filter smears (relatively) so much, that the as illegal regarded transients are smoothed to "no problem".
The Arc Prediction filter is far more the reality.

So the Custom filter can act as a trick to avoid the issue.

Kind regards,
Peter

This has occured again on the weekend but hasn't been a problem since last noted here.

I stopped XX engine(blue button) and clicked out of XXhighend but kept Ram OS going. I restarted XX and everything has continued normally since.

So guess this has solved it until next time.

Robert

Hi Robert,

Are you saying that when you restarted XXHighEnd, you played the very same track and then it didn't reoccur ?

Thanks,
Peter

Yes thats correct.

Robert,

In that case, if all is right, you were really protected by the CrackDetect functionality. I mean, without that I think it would have been a lot of noise.

Best regards,
Peter

Peter,

Yesterday, I had a small brainfart, I turned off my music PC while the audio PC was playing music.

Which shouldn't really be a problem I guess, but it is...

I lost RDP (obviously) so I turned off the audio PC (after the music had stopped playing) by pulling the plug. I didn't know how else.

The result is that I now always get:
24 bit Second Stage Crack Detect!-> 51
Playback has been stopped.

So I have no sound at all, even when I disable crack detect, It seems to play, but I still have no sound.

Any idea what I can do about this?

Hey Henk,

I suppose this requires Teamviewer surgery. Mind you, already because I think it is "interesting" as such. I really have no clue what causes this (but it is software anyway).

Peter

This is one intermittent bug that's also come back to haunt me even on the old low SFS settings. Happens on quality rips and downloads. I've tried different SFS settings this doesn't stop it. No stress I just change the music or switch Crack detect off.

Robert

I got so annoyed I had disabled Crack detect, since 12 August post. No problems at all.

Today I noticed you have changed balanced rate and nervous from 18/100 to 35/10.

With 35/10 and Crack detect enabled I have a better sound similar to 18/100 with Crack Detect disabled. Crack detect certainly has a major influence on the sound.

I do wonder that your XXhighend software is probably very stable and unlikely to cause cracks. I have re enabled Crack detect and have yet to experience any problems with it. I recognise that some owners may create a situation that could cause cracks.

I've updated my settings and its all sounding excellent.

Robert

Robert - Interesting ...

I would say that the Crack Detect setting is unable to influence sound (quality), but if I read what you just wrote ... : :scratching:

The Balanced Load at 18 is a "tricked" one. All under 43 is. Maybe you recall that ever back under 43 was not allowed because it did nothing. Until that changed and I recall it was about Windows 10 or some Build of it. It allows the processor to be tuned all the way to about 0Hz frequency BUT one has to check what happens for reality responses, because it can be too slow. For example, 430Hz is still workable, but one step lower (which goes by several steps in the Balanced Load because one step does nothing) that ending up at 300Hz and the PC becomes unresponsive and what I recall ... erroneous.
Point is also that this depends on the processor.

The combination with the Nervous Rate is almost even more interesting (for your description) because it tells how fast the processor adapts to a "more speed" request. Thus, if it runs too slow (notice : while it runs at an about fixed speed anyway), the Nervous Rate tells how often to look to adjust the speed. Think in terms of 1ms vs 1000ms (mentioned figures are not absolute) with the idea that 1000ms is equal to "never" (in the terms of this domain) - and which is not meant to let error the system, but to let it behave in steady fashion instead of being "wild" en nervous.
This gets complex when we see that the numerous other tasks in the system (which can be 1000s) also need their "time slice" and while they are being kept out of the door (because the system does not respons fast enough) in the end the OS itself may fail on accomplishing whatever it is.

Summarized, it looks like you, Robert, are able to let the OS error, possibly up to the sense of not being able to process complete audio words and a few bits are chopped off, *because* an other process on the same thread (so to speak) received priority and it has to continue. Example of this in general, is the audio not being allowed to speed down. This can be solved by the system to keep track of the speed but chop off complete samples, while more internally and detail, also bits can be shopped off. Both are as illegal, although the skipping of samples would be acceptbale, as long as it isn't about charachters in a Word document.

I must add that shutting off Crack Detect does not help a thing in avoiding the real cracks (because of incomplete audio words or whatever) BUT that the process of checking for Crack Detect is an additional read of the complete stream (though it goes per chunk). Thus one could say that while the processing of the file for that part takes a certain amount of processor cycles, the checking (Crack Detect) for it to be OK takes maybe 10% more. Apart from that possibly influencing SQ to begin with (all processes do) it also requires 10% more of the processor and that just could underwhelm what's necessary.
So if your processor runs at e.g. 500MHz and just can cope, then this "feature" actually requires 550MHz which isn't available. And together with the Nervous rate at a highest number, also not a little bit and at least too late (the system does not detect that the processor must speed up a little).

This is a lot of hoopla and blahblah, but a means of explaining the situation you ran into.

Regards,
Peter

I got Crack Detect occurring recently but discovered my volume was 0dB in XXHE. Went back to my normal -3dB and no more Crack.
0dB with upsampling filters can cause Cracks, I think it was mentioned on the forum a while ago.

Colin

Colin,

Hmm ... that would be a filter anomaly. Not that I am going to solve that instantly, but with which filter does that happen ?
If you don't know for sure any more I rather learn that. :)

Regards and thanks,
Peter

Hi Peter

Its:- Custom Filter 352800 low (NOS)

It happens on peaks in music. Also on 0dB sine test tone, switch your amps off first if you try this.

Not particularly a problem, I posted this in case others are using 0dB & get cracks.

Colin
:15a:

Thank you, Colin.

Regards,
Peter