Greetings
is it possible to use Server.default.record
to record compressed audio formats such as ogg, flac, or mp3?
cheers
T.
is it possible to use Server.default.record
to record compressed audio formats such as ogg, flac, or mp3?
cheers
T.
It depends on libsndfile
. This dependency at SC compile time is all that matters regarding this question
SC compiled with that is not available (especially mp3) Still, you can find it or compile it yourself.
Real time audio rendering is time critical. Lossy compression algorithms are designed to be computationally heavy for encoding (recording) and lighter for playback. Probably not a good idea to add computationally heavy work on top of time critical real time audio processing. Modern CPUs can probably handle it but why introduce risk?
Second, a recorded file from SC probably has extra space at the beginning and end, and is probably not well normalized. So you’d need to open the file in an editor anyway, and trim off the excess, fade in/out, normalize, maybe a touch of EQ and/or dynamic compression. Now if you started with an mp3 directly out of SC, and wrote a cleaned-up mp3 from the audio editor, that would be two lossy encoding cycles = reduced audio quality. So it would be better to begin with either an uncompressed audio file from SC, or lossless.
hjh
This is partly true.
Let’s look at FLAC. Playing back a FLAC audio file on a modern CPU consumes 1% more than a WAVE file (highly optimized for PCM conversion for playback) and 5% more than a wave file for recording (that’s a bit more, it’s true).
In addition, there is no loss of sound quality. Unlike formats like WAVE and AIFF, the file content in a FLAC sound file is checked with a hash function (the same md5 and sha used in cryptography) to ensure with “mathematical certainty” that the content that went in is the same as the content that came out.
This must be a good thing since there are not many things we have this level of certainty in life.))
We will find a more substantial option when we choose a PCM Wave file in 16-bit, 24-bit fixed-point, or floating-point 32-bit format. There is an insane difference between them.
Yes, true. When exporting from a DAW, this is not real-time, so the extra encoding time doesn’t matter. Well, tbh, the extra encoding time probably doesn’t matter that much in SC either, because the file-write operations get pushed off to a lower-priority thread; if the scsynth DSP thread is very busy, the OS can assign the lower-priority thread to a different core. But “probably on a different physical core” isn’t the same as zero possibility of any impact at all, so I would measure that risk against the benefit of saving disk space (where that benefit is less significant for short recordings).
I record live sets to 32-bit float “just in case” there are out-of-range samples (and also to maintain full 24 bit resolution at lower amplitude). FLAC supports only integer sample formats, so you lose these benefits of floats.
It’s true that recording to FLAC, editing, and then encoding to MP3 would go through only one lossy encoding, and be no worse than WAV → editing → MP3.
Anyway: SC has FLAC support out-of-the-box AFAIK, so you can already record compressed to this lossless format. I presumed that the question was mainly about mp3, where – as correctly noted above – a user who needs this can build libsndfile with mp3 support, and SC will not prevent taking advantage of that. But there are reasons not to actually use that support
hjh
I always use floating-point 32-bit WAVE, especially for the kind of music we do. I don’t understand why one would do otherwise. Other styles of music are much more predictable, or the style sets some limits. But that’s not the case for most people here, I believe.
… with the caveat that the noise floor, at +770 dB, will be +626 dB, somewhat less than useful
hjh
One doesn’t need to know exactly the minimum and maximum levels before a performance. How does one do that in a free improvisation setup? With fixed-point, that is a matter of life and death.
And what if one plays with four other musicians, and they all play incredibly delicate soft materials for half of the performance?
That’s uncommon in commercial music technology. Score editors (Sibelius, Dorico, etc.), MIDI and other standards, etc., all those experts know better than the artists what our work is about, even when there is no technical reason to leave it open, which is usually a good thing (to leave things open).
The reason why I posted my comment is because readers (including future Google-search readers) may get the impression from the graphic that floats can record up to > 700 dB and that the sound would be equally transparent throughout that dynamic range – the first part is true, while the second (transparency) is not. That’s all: stop others from misunderstanding posts and spreading folklore, before that process starts.
hjh
I’m sorry, but our messages clearly explain the reasons for each choice (and we agree on our choices, for instance). The reader will understand what we meant.
A bit of irony is good, and people also get it. I liked your comment, by the way. I didn’t take it literally; it helped show how deceiving the comparison based on dB would be. My reply helps show that it’s not just about dBs in a controlled and predictable situation; there is more. On est ensemble
(Images could be misunderstood out of the context of this conversation; that’s why I removed the dB comparison image)
i know that libsndfile is a c++ library for handling sound encoding, and that it may eventually be part of the gnu/linux standard libraries. bearing this in mind, i guess like i would have to extend the primary functionality of supercollider source, and adding it some additional methods for supercollider, consisting of extensions to Server.default.record
. right? by the way, nothing wrong about asking a swedish or norwegian metal mastering studio to give supercollider audio a very beefy sound with saturation and so although there is a correct mean of doing it which is mastering it to -24 dB, with 48 dB minimmum dynamic range, and then knocking the audio up and letting it kick in. but that’s mastering, and nothing to do with recording
I’m not clear what extensions you mean.
You can set the recording format with methods recHeaderFormat
and recSampleFormat
:
s.recHeaderFormat_("flac")
.recSampleFormat_("int24");
Now you’re all set to record to a compressed format, without adding any features.
If you mean mp3 and ogg support specifically, IIUC that would require SC sources to import libsndfile sources and build and ship our own libsndfile with mp3 support – which is not a bad idea but not very high on the priority list. If somebody really wants the feature and can submit a working pull request, it would probably go in (I guess? unless there’s a reason not to, that I don’t know about). That would be a change to SC build scripts but not to SC’s source code (no need to add methods).
hjh
Maybe that’s folklore now. Times have changed.
Fedora package for libsndfile-devel
actually has mpg123-devel
listed as a dependency.
Dependencies
flac-devel
libogg-devel
libsndfile = 1.2.2-4.fc41
libvorbis-devel
mpg123-devel
opus-devel
pkgconf-pkg-config
Fair enough. It seems debian-packaged libsndfile doesn’t include mp3 support though (at least in Ubuntu 22.04 – however 24.04 seems to have added it).
f = SoundFile.openRead("~/Music/*.mp3".standardizePath.pathMatch.choose);
-> nil // oops, failed to open, so I'd better upgrade my OS over the semester break
hjh
The very idea behind a NRT thread is that it doesn’t interfere with RT audio processing. If it’s ok to stream audio from/to disk, then it’s also fine to add a little bit of encoding/decoding on top of it.
that may be something to fix in the supercollider development group. anyway, right now i am not on github. deleted my account. i am just a supercollider user from now onwards. still have a lot to learn before i can turn serious into sc-dev. and one thing is learning how to do everything from community standards first, in terms of supercollider usage. the other thing is supercollider development users stuff. anyway, the earlier i focus on realizing that i may be an intermmediate user, and a noob/failed developer the better <3 anyway, at least i can now use jitlib correctly, write classes in supercollider (maybe not 100% accurately but in a better way), and reading throughout xox based patterns, and modifying them. just have to learn how not to post modifications of third party code, because that’s not correct at all