Burst of noise

[PeterSt]

Dear Ramesh,

I must say that now when I hit Play after selecting an album, I always tense up just a bit!!

Justified. And I set myself to solve it (today).

The culprit is this one :

- Hit Play; waited a while, nothing seemed to be happening
- Hit Stop;
- Hit Play again, fairly soon after Stop

Meaning : if one doesn't have the "senses" that this may end up in misery, then, well, it will.  And btw, this should trigger the alarm bells :

- Hit Play; waited a while, nothing seemed to be happening

So if I see this, I will think "uh-oh" and next be in control (like quitting XXHighEnd would be the best solution, but which I do not do because I want to run into the issue (learning from it, so to speak).

- Track begins very briefly; Alert pops up (the Crack 24 alert);

If it would always be accompanied by this message, I would definitely have solved it soon. But people are telling that they don't see the message (after playback stopped !) so I better don't believe those people or otherwise I don't know where to start. And mind you please, this is completely different from the situation that playback continues after the noise.

Btw Ramesh :

Playing with Peter's new settings: Q1: 30/40; Q3,4,5: 1; SFS 120; Clock 15ms; do nothing with cover art

There are two errors in that. 

Thank you for your clear description !
Peter

[PeterSt]

Edit, Nov 15, 2011 : Mentioned download of XXEngine3-209-X1.rar has been replaced by the X2 version in this post.

Dear people,

I found an issue with the determination of a wrong byte order (this is what causes the burst of noise). And the thinking error (or maybe race-incident) which has been in there is quite unbelievable;

Ever back the analysis of the correct byte order was applied on the more native music data. Later, when more of filtering applied and which processing can all end up wrongly, this analysis was moved more "down" so the filtering processing would be caught just the same. Small problem : the code more down incorporates the digital attenuation. And since the analysis comprises of "detect too high difference values from sample to sample", the attenuation "squeezes" that.

Then I found that the analysis (deliberately) does not work over SFS (Split File Size) boundaries. But, the effect of that was never noticed : the smaller the SFS the less chance too many too high deviating values would be detected. This is hard to explain, but ever back (like 9 years) I determined that more anomalies had to happen in sequence before further playback would be rejected. A kind of : one tick is fine, but not 200 in a row.
*That* idea I now have abandoned;

The version of XXEngine3.exe you find below, trips with a "Crack Detect" message after 3 subsequent relatively wrong samples. This allows one glitch (of one sample !), a next to go back to normal levels, and not more. So if right after this "coming back" a next sample appears to go sky high (for deviation), something is regarded to be wrong and playback stops right away.

Regarding the latter, things vastly changed;
Previously the current buffer (which already could contain wrong sample data) played empty and the next one - the one with the detected wrong samples, was not further offered for playback. Sadly, a buffer can easily play for 30 seconds and even many minutes for "only" 16/44.1 (48) capable DACs. From of now, when the filling of a buffer detects wrong samples, playback is stopped immediately (but it will still depend on some amount of internal buffer). The difference thus is that playback is now explicitly stopped, while previously it played until the main buffer was empty (this is the SFS buffer).

Remark : We will "obviously" see that a 100 people (probably including myself) will have many occasions of the Crack Detect message occuring, while they think it is false alarm. Well, it won't be really, but it depends on how wrong things really are, and we can not know that in advance. What I am talking about is ripping glitches (envision you hear them as scratches) and the Crack Detect routine may trip on that now easily, if only close to the maximum voltage span is covered from sample to sample, and if only that happens 3 times within one SFS buffer. So indeed, when you play at a sampling rate of 705600 and imply an SFS of 30 seconds, then all this time actyally nothing is allowed to go wrong and a poor rip will let it go wrong. Do notice that a poor rip includes scratches on the CD and if these imply mentioned voltage span, then bad luck; playback will stop.

Of course everybody is going to report about their experiences and the tripping can be made less tight. But as we now know, when too loose we are going to hear it and we don't like that.

Anyway, it is good to realize that from 3 dimensions or so, the noise now is attacked and the most important one is the not thinking of the attenution in there; Nothing tripped forever, if only the attenuation was large enough. This also explains the not even occurring of the Crack Detect message, because the anomaly was not detected (in continuous form).

Lastly, when you receive too many stops (with mind you, most probably hardly audible anything at all - maybe a little LP-tick) then before reporting it, you should try to repeat the situation; Is it repeatable "on the second" (you can drag the time slider button to right before the happening, press Pause and next Play) ? then it will be a scratch in the CD *or* a for real too high transient. Is it not repeatable, then you ran into the real thing and the purpose of this topic ...

So let's have it !
Peter

PS: Kill XXEngine3.exe (click blue led in right hand border of XXHighEnd), unzip the below to your XX folder and start listening again.

[arvind]

Hi Peter,

Since 2009, when I first started using XXHE, I have never experienced this burst of sound or crack detect. For the first time after updating Engine3, I got a crack detect msg, on a playlist which I generally listen to at least twice a week.

Call it Murphy’s law!!

Best regards,

Arvind

[PeterSt]

Call it Murphy’s law!!

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.

[arvind]

Hi Peter,

The crack detect occurs at the same point (3 attempts). This playlist has 5 tracks totally, from 3 different albums. The first 3 tracks play just fine. Right at the end of the 4th track, just when it is moving to the last track, playback stops & crack detect msg appears.

I tried to reduce SFS from 20/20 to 0.9/120 but the same result.

Sending you the 4th & 5th track by file mail.

Best regards,

Arvind

[PeterSt]

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

[Rmalits]

Today I have got this burst of noise again, scaring loud and this time it didn't stop itsself until I pressed the stop button.
I was playing the same song, the last one in the playlist, like 4 or 5 times before it occured.

Yesterday I had another phenomeon: After selecting new songs in the playlist and pressing "play" the last seconds of the previous song were played (out of the buffer?) and playback stopped after this without any error message.

As reported I didn't have any of these problems for aboit 16 month before I upgraded t o 2.09 and changed the Q settings a lot.

Kind regards
Richard

[PeterSt]

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

[PeterSt]

Yesterday I had another phenomeon: After selecting new songs in the playlist and pressing "play" the last seconds of the previous song were played (out of the buffer?)

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

[Rmalits]

Peter, I now downloaded XXEngine3-209-X1.rar.
After I had copied this new XXEngine3 exe, in XXHE the output device is not found any more. Under setup this field then is empty and there is nothing to choose.
I tried it one more time after a reboot and got the same result. When I copy the older 2.09 engine3 exe over it, it's working fine again.

Kind regards
Richard

[PeterSt]

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

[PeterSt]

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

[PeterSt]

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

[Rmalits]

Peter, yes, it was the blocked file problem. It's working now (version X1). I could have known that myself.

Yes, I am using the "End" button pretty often. I will avoid it now and see if burst of noise still happens.

Kind regards
Richard

[PeterSt]

I will avoid it now and see if burst of noise still happens.

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