Does flucoma have a read as raw file method? To get it to read things like movie files as a raw wav file.
The question is more: does SC have a read raw file, since FluCoMa doesn’t do audio files - it uses host buffers… Buffer doesn’t seem to, but SoundFile seems to be more permissive. I am not a specialist, so I recommend changing the title of this thread and you might find more answers.
Why not open the file in Audacity under File->Import->Raw Data, then save it as a wav. Then it will open in SC.
Sam
One could also use SC and its ability to call the terminal (libsndfile utilities would do that)… but I was also thinking of SoundFile which might be able to do that right in the language. Or File. If it is an array, then one can dump that right away in a buffer and voilà !
I was thinking of using sox to read as raw, but the format must be specified to give hints to the convertor, and so far my one preliminary try has been that it’s white noise, though not fully randomised white noise.
@Lukiss this is what I meant indeed but had never done it Thanks.
To make it much faster with a large file, maybe we should allocate c
’s memory first then write in it? IIRC .add
reallocates so that will get more and more expensive as the file grows.
I haven’t tried it but as I am the eternal learning of SClang, I’m checking my understanding here
Array
grows its storage geometrically (by factor of 2), similar to std::vector
, so that add
has (amortized) constant complexity.
I think the bigger problem is reading each byte individually. (File I/O is typically buffered, but still…)
I guess the following would be both the shortest and most optimal code:
f = File(Platform.resourceDir+/+"scsynth","rb");
c = Int16Array.newClear(f.length); // change to Int16Array or Int32Array accordingly
f.read(c);
b=Buffer.loadCollection(s,c);
one question: File.length will return the number of bytes, so I reckon we should allocate f.lenght / 2 for Int16 raw? Or am I missing something?
I start to love SC a little too much
File.length will return the number of bytes, so I reckon we should allocate f.lenght / 2 for Int16 raw? Or am I missing something?
Good catch It is okay because
File.read
will resize the Array accordingly. At least in theory. Now that I looked at the source code, it seems that it just sets the size
field, but does not actually shrink the memory… So if you want to save memory, you need to divide File.length
accordingly.
Thanks… I had a feeling my idea would not work well with bigger things. This solution is so much better.
These are great examples of how ffile reading is done. It should be in the tutorial somewhere.