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

[Mario Buoninfante]

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/979d511a/attachment.html>