I’m curious if there is a way to export to FLAC from an NRT score. I seem to be able to record into FLAC and playback FLAC without any difficulty - but doing a recordNRT to FLAC produces the following error: Couldn't open non real time output file.
Not too sure, but judging from the error message, I assume the NRT process needs be able to write the samples directly into the file and because FLAC is encoded (and therefore the samples might not appear simply consecutively) it can’t do that.
What happens if you record into a buffer and then try to save the buffer as a FLAC?
Using the first example from the NRT guide (which I won’t quote in full, just the rendering statement), this way does not reproduce the problem – the file is created with the expected, correct contents:
So my best guess, with available information, is that you might be setting the wrong sample format. FLAC supports int16 and int24, but is incompatible with float samples.
SC uses libsndfile for all sound file reading and writing. We just ask libsndfile to open the file, and pass the raw sample values to libsndfile. Then libsndfile is responsible for any codec involvement. From our side, access to any sound file format that libsndfile supports should be completely transparent.
Ah, interesting. I did try the sample format arguments for int16 and int24 and still got the same issue. I wonder if it might be an issue with my libsndfile. I’ll try that next.
nrt : setting clientID to 0.
-> nrt
VSTPlugin 0.5.4
read cache file /Users/bd/.VSTPlugin/cache.ini
Found 0 LADSPA plugins
Couldn't open non real time output file.
done
My suspicion is that this means SC is looking for libsndfile in that weird VST cache file. I’m not sure why this would be or how to go about fixing it.
For completeness sake:
It’s true that we depend on libsndfile for all sound file operations and in principle every format supported by libsndfile should be supported by SC.
That’s only partially true, because there’s a translation from strings in SC indicating sample format to proper symbols in libsndfile and that part had at least one bug regarding the vorbis format (this is fixed in SC 3.13). Flac however was not, and is not broken, as far as I know.
Also, when new format is added to libsndfile, we need to manually update that part of SC sourcecode to support new formats, and we need to make sure our Windows and macOS builds ship with the updated version of the library. E.g. this was recently done to add mpeg support.
nrt : setting clientID to 0.
-> nrt
VSTPlugin 0.5.4
read cache file /Users/bd/.VSTPlugin/cache.ini
Found 0 LADSPA plugins
Couldn't open non real time output file.
done
It seems that VSTPlugin indeed messes something up here. Your example works for me if I remove VSTPlugin from Extensions, but I get the same error as you when VSTPlugin is installed. I’m also on macOS, SC 3.13.0-rc1
This is a shot in the dark, but when something weird is happening, it could be any little difference.
Looking into the sources:
NRT output file is prepared in SC_World.cpp, L579 ff.
b_write output file is prepared in SC_SequencedCommand.cpp, L996 ff.
The steps are:
Have a SF_INFO variable.
Set sample rate and output channels on this object.
Call sndfileFormatInfoFromStrings() with header and sample format strings.
sndfileOpenFromCStr() gives the audio file handle.
For NRT (where there’s a problem with FLAC in some systems), these are: L579 (declare variable), L585-586 (SR/numCh), L587 (format info), L590 (open).
For b_write (where no problem was observed), it’s: SC_SequencedCommand.h L337 (member variable), L1013-1014 (sr/numch), L997 (format info), L1016 (open).
All these appear to be functionally the same… except that b_write initializes the memory for the file info object – memset(&mFileInfo, 0, sizeof(mFileInfo)); – while I cannot see anything like this in the NRT code.
I think C does not automatically initialize memory for functions’ local vars (but I could be wrong). If not, and we aren’t initializing, then it’s a possible source of otherwise unaccountable behavior. (Seems unlikely to me, because I didn’t see a problem… but… when things are weird, anything could be a culprit.)
It would be nice if scsynth would also print the actual libsndfile error message…
@b.d Does it work with Supernova? If yes, we know it is a scsynth bug.
@jamshark70 The missing memset is certainly a bug and should be fixed. Looking at the libsndfile sources, it does not seem to cause any immediate problems, though, so it could be a red herring.