Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
You have to save both to same drive (configured on Directories tab).
Is there any way to recover the "plus sign" instead of the angle brackets for the dropdowns items in the new versions?
https://hydrogenaud.io/index.php/topic,118963.0.html (Kitly was in beginner mode and I didn't realize. Replace spaces by underscores issue mentioned in this thread was fixed in v1.6).
If ripping each track to separate files, a CUE sheet may be useful if you want to burn a CD or re-verify the accuracy of the FLAC files later. If ripping all tracks to one large file then a CUE sheet is needed for the start position of each track within the file and for metadata.
Wouldn't it be a good idea to have it optimized for sines of standard scales and round ones? 440Hz, 1000Hz etc.
The thing about a signal that is a single sine, is that you can predict them by two coefficients of which one is = -1.
You have a predictor x(N+1) = x(N) * 2 cos q - x(N-1) and with q fit to pi* 2f/F where f is the sine's frequency and F (>2f) is the sampling frequency, then you are all good - provided that the format can offer high enough precision for that 2 cos q.
So if you want a flac encoder that beats the official reference on sines and does nothing else worse, then - with reservation for that precision - you can do that by including a special algorithm for the order two predictor, and spending extra effort on every signal doing that number-crunching only to ditch it because the signal isn't close to a sine.
I have absolutely no idea how much it would slow down the encoder.
(Actually when I first started playing around with codec performance, I was indeed surprised at how bad codecs compress sines - I'd have this hunch that if you started to fiddle around with lossless compression, one would try to get those signals going first. But there are reasons why the engineering approaches have rather targetted real-world applications where data perfectly suiting the models are just not going to show up.)
Ideally, from my point of view a different approach to the original foo_streamer plugin would be desirable:
I would find it optimal if such a plugin would only add metadata to the audio data, but not re-encode the actual signal at all. Unfortunately, my programming skills are not sufficient to write such a plugin myself.