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