I am planning to do a project that will involve using .wav files that will be about 25 hours long. Does anyone have experience using very long/large audio files in SC? I am using a fairly recent MacBook Pro, so I hope my computer and the program will be able to handle it. I think the file size will be about 24GB. Is SC suited to this?
WAVs are not suited to this (4GB limit, if I recall).
Probably try .caf files.
Okay thanks for this. Most helpful. I’ll try think of a way to create a 25 hour .caf file, and test it within SC. The weird things I end up doing for music!
Appreciate your reply, I´m sure it saved me a big headache.
no need to do 25h, you can do a 24 track 24 bit wav file, it only has to be 23 minutes long
Thanks for your reply tremblap, forgive my ignorance, but I can’t see how that is equivalent to a 25hr .caf file?
Here is info on caf files - this doc states that caf files can be of ‘unrestricted file size’.
I would probably test this before believing it:) I would also consider creating chunks of say 1 hour files instead one long 25 hour file, so that if something goes wrong (like SC crashing), you don’t loose everything. On the other hand, even if SC crashes, the caf file could probably be saved but would most likely require some ‘header-repair’ (I would assume). I would suggest recording a caf file and then intentionally crash SC or force-quit it to see if the caf file can be played or resurrected somehow.
it was just to see if SC supports the extended wav (which allows for larger files than the 4gig limit - the wav format is quite a beautiful mess, I’ve done a parser earlier in my life and now I use the HISSTools one and manage to still find bugs in stuff)
24 tracks of 24 bit audio will generate 4320 meg of audio data, so a file that will load, or not. it might be simpler to test, or not.
anyway, sorry for the noise and have fun. @Thor_Madsen’s idea of multiple files to not lose the past in case of crash is a very good one indeed, if you are recording 25 h long.
SC can do a w64 file, which is good if you want to load the file into Reaper or another daw. Reaper supports w64, but not caf.
What version of libsndfile is used in latest SC release?
Would it be possible to support uncompressed BWF / RF64 ?
? can create a separate discussion thread if this is slightly too much off topic ?
No, thank you for all replies tremblap. I just was curious!
Here is my current plan. I don’t aim to record in SC. One reason being I think the easiest method will be to use something like an H4 handy recorder or equivalent, make multiple recordings with a few small gaps, then glue them together in something like Logic. What I want to use SC for is to process that audio afterwards.
The idea of breaking it down into chunks is a good one Thor, however I have a feeling it will make the programming – for me at least – a bit more difficult, as it would be more elegant to just deal with one audio file, even if it is huge!
I´m having to work on this during tiny gaps in my schedule, so progress is sporadic. Next stage for me is to try to create a dummy 25 hour audio file and see if SC can handle it. I will report back!
Thank you as ever for the support and ideas!
What do you mean by “handle it,” though?
Just whether SC loads the file, and if it’s stable and behaves like a smaller file. Without having a particularly technical reason I feel somewhat intimidated by using such a large/long audio file. I suppose because I have not done it myself, nor seen someone else do it.
I can’t speak for your machine, but my machine has 16 GB of RAM, so if I tried naively to load an entire 25 GB audio file into RAM, the only reasonable expectation would be failure. If you have enough RAM, then there’s some chance of it working… but… loading the entire file every time would at minimum be slower than loading a short file.
My point is, think first about realistic ways to use it. You could load segments into buffers, using the startFrame and numFrames arguments. You could cueSoundFile and stream it with (V)DiskIn. Those should be more or less indistinguishable from working with shorter files (except that frame addressing will get less and less precise, the later in the file you go).
You make a very good point, thanks. Naive is probably the optimal word here, in addition to lazy. Your suggestions are good ones. I am thinking to work with 24 one hour audio files just to avoid a lot of headaches.
Still have not had the time to work further on this - two kids - but hopefully will report back one day with a working version of it.