Re: [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.buoninfa...@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.sala...@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.buoninfa...@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@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
>>
>> ssala...@calarts.edu | +1 831.277.4654 <(831)%20277-4654>
>> https://spencersalazar.com
>>
>>
>> ___
>> chuck-users mailing list
>> chuck-users@lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
___
chuck-users mailing list
chuck-users@lists.cs.princeton.edu

Re: [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 
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.buoninfa...@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@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
>
> ssala...@calarts.edu | +1 831.277.4654 <(831)%20277-4654>
> https://spencersalazar.com
>
>
> ___
> chuck-users mailing list
> chuck-users@lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
___
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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

[mario buoninfante]

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@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Re: [chuck-users] ChucK FLOSS - MIDI reference

[mario buoninfante]

Hi Mitch,


thanks. I have to say I'm really happy to do that and honestly I should 
say thanks to ChucK developers and ChucK community, since for me (and 
for everyone else) this is an opportunity to learn a lot. It's amazing 
having the possibility to work on a FLOSS document (that of course 
hasn't been created by me) and at the same time check the source code 
(since is open source)


so thanks to the ChucK community.


cheers,

Mario


On 24/03/18 09:21, Mitch Kaufman wrote:

Mario,

I wanted to thank you for all your efforts in putting together this 
FLOSS manual.  There are many things covered here that are not covered 
elsewhere.  Thanks again.


Regards,
Mitch

Regards,
Mitch

*From:* chuck-users-boun...@lists.cs.princeton.edu 
 on behalf of mario 
buoninfante 

*Sent:* Friday, March 23, 2018 3:31:23 PM
*To:* ChucK Users Mailing List
*Subject:* [chuck-users] ChucK FLOSS - MIDI reference
Hi,


I merged the new chapter with the Event one, I thought was the best
thing to do. so now everything is under the Event chapter like it was
before, which is simply been expanded.


cheer,

Mario



___
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users


___
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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

[mario buoninfante]

Hi,

It seems like SndBuf deals in a different way with audio files which 
have different sample rate.


I tried this simple program where the 2 audio files samples are compared 
(perc.wav and perc2.wav which are the same file one 44100 and the other 
48000 Hz sample rate), so that I can check if they are different. it 
looks like for SndBuf they are different. am I missing something? does 
SndBuf convert in some way the audio files?


cheers,
Mario

SndBuf sample => blackhole;
SndBuf sample2 => blackhole;

sample.read("perc.wav");
sample2.read("perc2.wav");

<<< sample.length(), sample2.length() >>>;

0 => int err;
for(0 => int c; c c){
    if((sample.valueAt(c) - sample2.valueAt(c)) != 0){
    1 +=> err;
    }
}
<<< err >>>;
___
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users