Sure! But that’s not what’s already been established in this discussion. You say “in any software.” There are already two major playback apps that will reproduce the tick, either from start or when playing the full album (of individual tracks). Given streaming services don’t have to disclose what apps they use for playback, I’m certainly not comfortable telling a client that the tick will not be heard on Spotify et al.
You seem to completely discount or disregard that ticks can be be heard in a couple of apps, and when viewed spectrally, there’s all the markings of the same sort of discontinuous tick (sharp transient high volume almost like the spike created by a wordclock error).
¿Que? This doesn’t jive with earlier findings that, I would have thought, made this not much of a conclusive finding:
I’ve always maintained that this doesn’t occur in a long render. I don’t know why it doesn’t happen in a continuous render. The above is the best explanation I’ve got as to why single continuous waveforms don’t show it. But that should make it pretty clear why a full render of the mockup doesn’t put an end to it. It’s just rehashing what’s already been established, and not getting at the fact that rendering the individual tracks that the ticks appear.
But it isn’t just my finding. Indeed, you wrote the same thing as the post immediately proceeding:
So no, I don’t think one should assume that a full render of this mock up should “put an end to it.” It’s odd to me that the same procedure and outcome will first support a position that something weird is happening and warrant further investigation, but later serve as some sort of Q.E.D.
At any rate…
This seems to be a question of gradation - different apps react differently to playing a track at certain non-zero values as the first data point of the sine wave. Note that this isn’t some cherry-picked ‘worse case scenario’ here - just came across this in my usual workflow. I don’t see any reason to think that the ticks couldn’t be louder if the source material was different, but still reasonable conditions for a final production master. E.g., lots of digitally created sounds with sharp envelopes of low frequencies that could have waveforms that aren’t as easy to reproduce from an actual acoustic instrument. This issue has arisen from time to time, and indeed, happened to me from time to time. But I am no wiser in knowing how fully address the ways to mitigate it, to say nothing of a clear roadmap in knowing how things will happen downstream should these circumstances present themselves. Given I’m in the business of making recordings sound as good as possible on as wide a variety of playback systems and conditions as possible, I don’t feel I’m doing right by my client to just put this issue to sleep now. Instead, I’m hoping there will be more knowledge shared so we can all better understand the conditions that contribute to these occurrences and tools provided to address said conditions in successive WL iterations.
Here’s my latest discovery:
When I initially listened in Reaper, I heard the tick, and it was of the same magnitude and character as heard in iTunes and VLC (and even JRiver if a user has the Switch Tracks value is set to ‘Standard’ gap 0.1s’). When Justin mentioned he didn’t hear any tick in Reaper, I went back and found a possible explanation for why I did and he didn’t. I had inadvertently set the playback rate of Reaper at .500 / half-speed. When at a slower speed, it’s clear as day. But moving it to full speed, I couldn’t detect it. I then tried at each interval of .9, .8., .7, .6, and the click became progressively easier to hear. So, I suspect that part of the issue here is that it these particular ticks may be below the threshold of detection. But regardless of what Weber would say, the fact that other conditions, as noted above, could produce a stronger transient is still cause for concern, or at least further discussion with PG and others.