What is "time resolution"? Options

[Axon]

So I've become involved in a rather colorful argument (I'm Publius in the thread) with somebody on stevehoffman.tv. The original thread revolved around shooting down an old audiophile canard, about how subsample delays cannot be represented in PCM. In the course of that debate, I've begun to question a couple things.

• Is it ever accurate to use the term "time resolution" in any sort of technical context? To the best of my knowledge, it has no universally agreed upon technical definition. Most of the times I've seen it used are either for SACD/DVD-A marketing fluff, or to describe FFT window lengths. I'm tempted to just go quasi-logical-positivist on everybody and say that it is a completely meaningless phrase.
• Is there any meaningful time-domain constraint on audio quality that is directly related to the sampling period? Subsample delays (as I've shown above) are not meaningfully related. Bandwidth is a frequency-domain attribute. Pre-echo potentially gets more audible at lower sampling rates, but this is not a concern with sigma-delta ADCs, and it is of debatable audibility at 44.1 to begin with. Some DSP operations may be harder to implement at lower sample rates, but most of the issues involve seem implementation-related. I'm suspecting that there are no clear general limits as to what can and cannot be accomplished in PCM, except with respect to very domain-specific or system-specific situations; and so any claims of 44khz always being limited in ways different from bandwidth may be regarded with skepticism.

[legg]

Fine forget about the code and do try to provide mathematical proof of your statements instead of blabbering. I'm sure a person that names himself smart ass will be able to provide such proof.

FYI, java is NOT a low level language, it is actually FAR from being one. C is closer but it isn't considered low level either, the actual term to describe C is middle level.

[MedO]

If I understand you right, you are saying that the time when the signal reaches a certain level in the recorded PCM waveform may be different from the time in reality.

This is equivalent to saying that the recorded waveform is different from the real one. Which is true if you are sampling with less than twice the highest frequency which will occur in the source.

The signal will be reconstructable to great accuracy if it is bandlimited to half the sampling frequency. It won't if it isn't. Why make it so complicated?

[ChiGung]

Hello all, I left this discussion in a tizz and have only just checked again to find these constructive replies.

A 'thought' experiment occured to me which would illustrate my point about PCMs 'time resolution' -which could be performed computationaly to generate precise data... Ill set it out hopefully:

I assume 'resolution' can refer to the ability to resolve discrete details of source material in pcm records. And there must be a difference in the potential of detail resolution in 'the source' and that in 'the record'.
eg if the source was just a CD, and the target record was 11kHz pcm,
- then their potential to have detail resolved in them would differ.
Fundamentaly the 11kHz pcm's potential to resolve detail 'should' seem to be 1/4 of the CDs 44kHz record.

That would go,
44kHz pcm 'time resolution' = 4* 11kHz pcm 'time resolution'

oddly, here and elsewhere this formula is eclipsed with not insubstantial excursions into test pattern replications and counter intuitive textbook quotations.

If i needed exact data on the capability of 'time resolution' in PCM records, here is how I would go about generating it:
Write a small program to read in pcm, and locate exact time of specifiable conditions in it. Conditions such as (level=0) or level=p(test),
or gradient =0, or gradient =p.
To avoid porting in or trying to write my own bandlimited solution of the pcm record, id write the code for simple linear interpolation and feed it high quality upsamples in order to achieve near 'bandlimited accuracy' in discernment of 'time location' of 'conditions'.

So a program can read in a bandlimited upsample of source pcm, and generates a list of times of all matching conditions which are found/resolvable within the upsample.

eg. hq upsample of cd track at 44kHz to ~192kHz
>list of times of peaks and troughs (gradient=0) found in 192kHz pcm rendering.

Next, high quality downsample the cd track to 11kHz (1/4 sample rate)
Then upsample to 192 again (for hq interpolation), and generate its list of (gr=0) times.
//(the upsample to 192 is only to facilitate high quality bandlimited interpolation)

At this stage in the thought experiment, I would note, that although both list of timings look for the same condition, there may be considerably less occurences of the condition (peaks or troughs) found in the predownsampled record, which would depend on the nature of the source material.

The two lists plotted on a graph should illustrate an observable time correlation between conditions found in each record, as well as 'orphaned' conditions represented only in the higher pcm.

Disregarding the orphaned conditions, the detail of 'time resolution' rests on how closely correlated the pairable condition times turn out to be.
A plot could be made of their distribution of correlation, perhaps it would tend to be a bell curve? for pink noise only? What would the limits of correlation be?

Additional explores: Compare accuracy of correlation of surviving details, in CD to 11kHz, then CD to various other rates. White noise, to some rates, then pink noise..etc.. Also do some comparisons in using different upsample rates, to discern the programs simpler linear discernments inherent innacuracy.

If we can spot a condition occuring at a time in a pcm record, with correlation data, we could indicate probabilities of that condition occuring within temporal distances in higher sampled records of the same kind of source material

It would be interesting to look at.

If I ever spend my sparse powers of collected concentration to generate the info myself, Ill post it here for all your troubles'

best'
cg

This post has been edited by ChiGung: Nov 16 2006, 18:20