While working on a sample player, I noticed that the sample sounded slightly different when played through Audacity and when played through my Pd patch. It's hard to notice the difference (unless you have perfect pitch, which I don't), but when played through Audacity, it has a slightly higher pitch. If you play them both at the same time, the difference is obvious.

So I extracted just the essentials from my patch to illustrate. I don't know if I'm doing something wrong in my patch, but I don't see any problem. I used Audacity to create the sample in the first place, which is exactly 44,100 samples long, at a sample rate of 44,100.

Anybody see any problem with my patch?

Patch: https://drive.google.com/file/d/151cvF_9_4ViebScR_zOS-IRaQXok0XIJ/view?usp=share_link

Sound file: https://drive.google.com/file/d/18UyB1o6mOfS1oW2OhIUtpA1KdJhHBTm9/view?usp=share_link

@seb-harmonik.ar Yes, muddled thinking from me. Confused with [readsf~].
Yes..... the Audacity window has the project rate at 44100.
David.

I would test Pd by recording a few seconds of [phasor~ 1], and measuring the number of samples per cycle. Obviously this should be the system sample rate, give or take floating point rounding error.

The worry in this thread is that Pd is playing at the wrong speed.

The only way this could happen is if [phasor~ 1] is running at the wrong speed, because in the demo patch, phasor~ is the only thing controlling the speed.

Therefore, if there is no evidence of phasor~ running at the wrong speed, then Pd must be playing the file at the true speed!

"But what if the system sample rate differs from the file's?" The file is at the lowest sample rate in common use. If Pd is playing it slower than Audacity, then Pd would have to be running below 44.1 kHz, which is unlikely to be supported in hardware. So I'm comfortable ruling that out (not to mention that scaling the phasor~ by the file's number of samples already accounts for this). Common scenario would be: 44.1 kHz file, 48 kHz system SR, without correcting for this then Pd would play faster, but that isn't the report.

is audacity running at 44100?

I'm pretty sure Audacity has no power to override the hardware sample rate. I've never heard of soundcards issuing separate, per-app interrupts at different rates (imagine how difficult that would be, to make it work, highly implausible). AFAIK Audacity does sample rate conversion when the file is at a different rate from the hardware... just like all other audio software.

Is it 100% guaranteed that Audacity is playing it at the right speed?

hjh

@lacuna That wouldn't explain the difference in frequency, I don't think. It might cause a click at the start, that's all. And as for the sample rate, both Audacity and Pd were running at 41000. Did anyone try running the patch? Links to the patch and the sample file are attached.

@dfkettle said:

That wouldn't explain the difference in frequency, I don't think.

True. log2(44100 / 44097) * 1200 = 0.12 cents, not at all easily detectable to the ear.

BTW here's one test of phasor~ duration (48 kHz) -- it's spot on.

hjh

@dfkettle no, phasor is running with it's speed (should be 1Hz) the readhead and 44100 samples is still one period.

Is it 100% guaranteed that Audacity is playing it at the right speed?

That would explain trouble we had with video-audio out of sync which was appearing after >30 minutes?, at that time we blamed the cheap audio recording device's clock for it, but could possible have been Audacity, too!?

I would test Pd by recording a few seconds of [phasor~ 1], and measuring the number of samples per cycle. Obviously this should be the system sample rate, give or take floating point rounding error.

I think phasor~ has jitter due to precision limits but that shoud be +- 1 sample, not more.

I rebuilt the essential logic in your patch and I get dead-on accurate pitch between Pd and Audacity.

hjh

As for the missing guard points (even though they don't explain the difference in frequency), I loaded the file (which has exactly 41,000 samples in it) using [soundfiler] and the "-resize" option. So I guess [soundfiler] doesn't add guard points. Should it?

@dfkettle yes, you have to add them. This is for less artifacts only. And only if you playback at different speed and/or samplerate tabread4~ would be needed. For original speed, you can playback with tabread~ or tabplay~ without any interpolation, sample by sample.

I did not open your uploads.

EDIT: here is an abstraction for it https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-to-a-table-for-4-point-interpolation-of-tabread4-ect

@ddw_music said:

I rebuilt the essential logic in your patch and I get dead-on accurate pitch between Pd and Audacity.

I don't really see any difference between your patch and mine, apart from the fact the you hard-coded the name of the file and replaced the horizontal slider with a constant value of 0.1.

@lacuna

That would explain trouble we had with video-audio out of sync which was appearing after >30 minutes?

Soundcard clocks are famously inaccurate -- if you record exactly 10 minutes of real world clock time, you probably won't get exactly sr * 600 samples. Normally this is not a terrible thing, but if you're trying to sync with video that was recorded according to a different clock, then yeah, it's a common problem. I've seen it myself. I have a SuperCollider script saved somewhere that will faster-than-realtime resample the audio to match video duration (based on by-hand duration measurements).

However, Audacity doesn't deal with video, so it can't be the problem here. If you read /n/ samples into Audacity and then export them to a different file, you should still have /n/ samples. Resampling is for playback. AFAIK if your sound card is at 48 kHz but the file is 44.1 kHz, there is no magic way that Audacity can "run at" 44.1 kHz while everything else is at 48 kHz. But the fx etc in Audacity should be working at the file's rate.

@dfkettle

So I guess [soundfiler] doesn't add guard points. Should it?

I would say no, because [soundfiler] doesn't know what you plan to do with the data.

hjh

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely, but as far as I remember Audacity on a Mac has been involved in the post-production, too.

@lacuna said:

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely, but as far as I remember Audacity on a Mac has been involved in the post-production, too.

I didn't record the file with Audacity, I used the generate function (Generate->Pluck... in the main menu). So I don't think the clock would even be involved in generating the file. Playing it back would involve the clock, I guess, but the file is only one second long. The clock would have to be very inaccurate to produce a noticeable difference in such a short period of time.

Yes, also Audacity and PD should rely on the same clock. And for playback of the same file, the recording clock doesn't matter.
But we don't know what Audacity does, that's all I wanted to say.
@dfkettle said:

a noticeable difference in such a short period of time.

how much is it off?

@lacuna said:

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely

In SuperCollider, after booting the audio engine, you can ask it .sampleRate and .actualSampleRate. The latter fluctuates, sometimes as much as a dozen or two samples per second (especially for built-in audio interfaces).

Once the signal is sampled, you're stuck with it, apart from resampling after the fact.

but as far as I remember Audacity on a Mac has been involved in the post-production, too.

Audacity should not resample anything unless you tell it to, by "Change Speed." It will not automatically fix a recording rate mismatch (it can't, because there's no way to determine from a stream of audio samples how fast it was actually recorded vs the nominal sample rate) and it should definitely not make matters worse. Let's nip this bit of folklore in the bud. Audacity, /n/ samples imported --> /n/ samples exported.

Audacity playback and Audacity export are different mechanisms.

hjh

@ddw_music You could well be right........ waspi soundcard rate mismatch in windows 10 (the screenshots look like Windows >7)..... https://forum.audacityteam.org/t/audacity-playback-is-too-fast/45964

Except that the sample was copied to Pd from a recording in Audacity, and the Audacity problem is famously intermittent.
David.

@ddw_music
agree with everything you said about how such an offline DAW, as Audacity, should be working, but do not remember how the recordings have been processed, just know it has been rather complicated, there might have been some resampling involved as well.

Is it 100% guaranteed that Audacity is playing it at the right speed?

was your question and I read it like: can we trust Audacity more than Pd? My answer was no, with my experience, which is most likely offtopic.
Now I realize that you might have adressed the settings with your question.
....
@dfkettle said:

The clock would have to be very inaccurate to produce a noticeable difference

Agree with this.

anyway

.actualSampleRate

is interesting. Do you know how SC measures this?

In PD, all I could come up is this:

clock-jitter-pd.pd

but feels like measuring bullshit, as it just compares the drift of two clocks against one another, or worse, one calculation on top of a clock against another, within the same system (while the control objects have a lower priority in the schedule, are not time-critical). I think a "real" measure would require an external calibrated frequency-counter device.

How accurate is [realtime] ?
[cputime] doesn't seem to work here on Windows.

re: guard points: You're still telling tabread4~ to go from 0 to 44099 in 1 second. The only thing that will happen is that the read point is clipped between the 2nd and 2nd-to-last samples, but that doesn't influence the playback rate at all. You'll get repeated values where you 'would' read the 1st and last samples, that's it.

@seb-harmonik.ar
to be precise: reading from sample 1 (skipping sample 0, as it is a guard point) to arraysize-2
makes still 44100 samples. And yes, doesn't influence the playback-rate, neither the perceived pitch at all.

also I don't think I can hear any difference in vlc vs. pd here in jack on linux. So I don't think it's a pd issue.
edit: maybe you could somehow record the stuff going to your soundcard (or some capture software) and try to figure out the difference between the sound files when they're played in pd vs. played in audacity, if you're really curious. To me it seems most likely to be an audacity playback issue.
edit: seems possibly like what's mentioned in david's forum link above. Check your device playback and recording advanced property settings in the windows settings. (specifically device sample rate)
https://forum.audacityteam.org/t/playback-is-too-fast-and-high-pitched/61159/2

@lacuna you tell it to read from 0 and go to arraysize-1, but where it would read the 1st sample it outputs the value of the read point for the 2nd sample (as the 1st is a 'guard point') and where it would read the last sample it reads the value at the read point for the 2nd-to-last (as the last is another 'guard point')
I'm not sure I'd say they get 'skipped', but maybe 'replaced' or 'clipped'