xxEngine3.exe, ticks at SFS boundaries, and perhaps new clues

[charliemb]

I may have stumbled a new clue or two tonight about SFS-boundary ticks.

Background

Only with the more recent versions, maybe z8, have I noticed that there are faint ticks throughout tracks, and so I've read these are at SFS boundaries.  These ticks are not the expected ticks at the beginning of a track, they are faint and throughout the tracks.  They are something like vinyl ticks, and are probably something like missing samples.

I've been told or I've read that this is known and that a solution is to kill xxEngine3.exe with the blue button on the right.

I experience the ticks exactly at boundaries when I have tracks of mixed resolutions.  So if I have tracks of 96, 96, 96, 44, 96, 96, 96, 44, etc., I will experience the ticks at the first 44, and if I fix it, I will start hearing them on the very next 96 song which in this example is the very next song.

I am using fx, 4x, PE, and ArcPrediction.

The New Discovery (at least for me)

I have found that there is no need to kill xxEngine3.exe.  There are at least two other solutions:

• 1) Hit alt-s, alt-p at the beginning of a track when you first hear the ticks happening;  and
  2) Hit alt-n just before a track ends.

Commentary

(Does this help?)

Even with Vista 32, I can feel that we are truly approaching a v1.0.  If this gets fixed, at least for unattended, we are close.

I wonder if there is no permanent solution nearby, could we have an option to have this done autonomically; this being alt-s, alt-p or alt-n, at the expense of being able to perfectly go from one track to the other within an album like Pink Floyd's Dark Side of the Moon?

[PeterSt]

Hey Charlie,

Great post. This is already a great post because you confirmed a problem still to be there which could have been solved. However, as I hinted in the other topic (the "A-B" I think) the ticks from today possibly exhibit after format changes. So they do ...
(and btw, similarly happened to when a HDCD album jumped in, that too implying a format change (16 to 24 bits) - and that was solved ... hopefully).

Maybe it is not necessary to tell that these are very tough problems, usually because we don't know when they exactly happen, also knowing how faint they are. There's even a topic floating around which refers to a situation which can be mimiced by everyone (in a particular version), and many can't even hear it (this is a "system resolution" test).

With this at hand I should be able to mimic it too. And what can be mimiced, can be solved.

Thank you Charlie,
Peter

[PeterSt]

So ... Solved for the next version ! (current version is 0.9z-8-3a).

The particular problem was introduced 0.9z-8-1a. However, a quite similar problem already was in there and let's say that both problems masked eachother.

Now, since it could easily be mimiced, it also could easily be seen on the analyser and no anomalies show anymore. We must be a bit cautious though, because where this is related to one format going into the other which is also subjective to the output sample rate, the number of combinations is quite infinite (also think about 44.1 going to 96 *and* 96 going to 44.1). Only a few combinations were tested, and they look fine (like the bug found was a general one, so chances are fair the problem is solved).

Thank you Charlie.
Peter

[charliemb]

Impressive.  Great.  Can't wait to get the next version.

Thanks to you too.  And you're welcome.