[chuck-users] SndBuf - audio file with samplerate different from 44100

[Mario Buoninfante]

Hi,

a quick update, basically there are a couple of things I missed before. I
was using a stereo file in a mono SndBuf and the Phasor I was using to
drive the Wavetable (I was copying the audio file into a Wavetable) needed
twice the normal freq. it seems like loading a stereo file in a mono SndBuf
means filling an array with samples form both left and right channel,
something like:
sndbuf = [1_left, 1_right, 2_left, 2_right, 3_left, 3_right, ...] - numbers
indicate sample number
of course I'm not sure about that, but this will justify the fact that
Phasor needs a freq twice faster then the expected one when I load a stereo
file, and also the fact that the sample length is half the original.
apart from that, I think .valueAt() and .sample() both access to the raw
data, as expected.
basically I think there's no issue with SndBuf at all, it was me not
considering all this obvious thing when I used Phasor to read the file, and
the issue I was experiencing with this can be fixed simply multiplying
phasor frequency by (audio file sample rate / ChucK sample rate).
ie to read the entire file at the original speed: phasor.freq(
(1000*(audioFileSR/ChucK_SR)) / (sample2.samples()::samp/ms) ) - sorry for
the terrible syntax, it's just to show the logic behind.
all this makes me think that it would be great having a method that returns
the sample rate of the audio file loaded. :)

cheers,
Mario

cheers,
Mario

On Sat, Mar 24, 2018 at 5:29 PM, Mario Buoninfante <
mario.buoninfante at gmail.com> wrote:

> Hi Spencer,
>
> thanks for your help, you're perfectly right about the floating point
> comparison, I didn't think about it. and I think you're also right when you
> say that valueAt() and samples() are ignoring the sample rate conversion
> made by SndBuf. What I didn't say in the previous mail is that the way I
> discovered this discrepancy is when I transferred all the samples from
> SndBuf to Wavetable (chugin). basically I load an audio file in SndBuf then
> read trough it using valueAt() and copy all the samples into an array
> (array length set using .sample() ). then this array is used with
> Wavetable. I noticed that something was wrong when I played Wavetable with
> a Phasor and the pitch was wrong. only at that point I ran the test where I
> compared the 2 two SnbBuf .valueAt().
> Btw later I'll have another look at .valueAt()/.samples()  and try to
> figure out whether they consider the sample rate conversion or not.
>
> cheers,
> Mario
>
> On Sat, Mar 24, 2018 at 5:11 PM, Spencer Salazar <
> spencer.salazar at gmail.com> wrote:
>
>> Hey Mario,
>>
>> Thanks so much for your work on the manual, its looking great!
>>
>> SndBuf/SndBuf2 are designed to resample the audio file to the native rate
>> when doing audio playback, although off the top of my head I don't know if
>> valueAt()/samples() are also resampling (seems like they shouldn't, to
>> allow true sample-level access).
>>
>> Generally speaking, comparing two floats for exact equality is too
>> rigorous for digital audio. Its preferred to test that they are "close
>> enough" within a desired order of magnitude, e.g. Math.fabs(f1-f2) <
>> Math.fabs(f1)*0.0001 (see e.g. [1]).
>>
>> Secondly, there are at least two resamplings involved in this test (when
>> you created perc2.wav, it was resampled from perc1.wav at 44100 to 48000,
>> and then ChucK might be resampling it back to 44100). Under certain
>> conditions resampling can be theoretically "perfect," but otherwise its
>> just making a guess what the sample would be at the new rate. Even under
>> perfect conditions, the inexact nature of floating point arithmetic means
>> that resampling from 44100 -> 48000 -> 44100 will most likely result in a
>> different series of actual values.
>>
>> Spencer
>>
>> [1] http://floating-point-gui.de/errors/comparison/
>>
>>
>> On Sat, Mar 24, 2018 at 8:59 AM, mario buoninfante <
>> mario.buoninfante at gmail.com> wrote:
>>
>>> I forgot to say, that the program I posted in the previous mail returns
>>> a lot of errors, basically 97% of the file length. I suppose the samples
>>> which are the same are all 0. btw the bit depth is the same, they're both
>>> 16 bit.
>>>
>>>
>>> cheers,
>>>
>>> Mario
>>>
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>>
>>
>>
>> --
>> Spencer Salazar, PhD
>> Special Faculty
>> Music Technology: Interaction, Intelligence, and Design
>> California Institute of the Arts
>>
>> ssalazar at calarts.edu | +1 831.277.4654 <(831)%20277-4654>
>> https://spencersalazar.com
>>
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20180324/28db927f/attachment-0001.html>