Re: FLAC v1.3.2 Final

Good call. I'll check it out if it works for me. Would be nice if more hardware supported Matrsoska, though.

Would be quite a scenario if your hardware does support FLAC and does support > 8 channels, but not Matroska ... ffmpeg has experimental support for FLAC-in-mp4, but I don't know if anything would play it.If WavPack is an option, then I see a list of 18 channels at http://www.wavpack.com/wavpack_doc.html

Re: FLAC v1.3.2 Final

Would be quite a scenario if your hardware does support FLAC and does support > 8 channels, but not Matroska ... ffmpeg has experimental support for FLAC-in-mp4, but I don't know if anything would play it.If WavPack is an option, then I see a list of 18 channels at http://www.wavpack.com/wavpack_doc.html

Management decision, so to say. I use FLAC to save the panadapter section of my ham radio receiver. Using FLAC makes it relatively easy, because I can handle it like any other sound file in things like Audacity, and I can still use the 655MHz bandpass FLAC allows to encode the entirety of my 10MHz window maximum of baseband. Why the >8 Channels I hear you ask? Because I'm using up to 20 of these windows side-by-side (20 receivers). Putting them all into one file (as they're recorded simultaneously), is just more convenient.

Re: FLAC v1.3.2 Final

Management decision, so to say. I use FLAC to save the panadapter section of my ham radio receiver. Using FLAC makes it relatively easy, because I can handle it like any other sound file in things like Audacity, and I can still use the 655MHz bandpass FLAC allows to encode the entirety of my 10MHz window maximum of baseband. Why the >8 Channels I hear you ask? Because I'm using up to 20 of these windows side-by-side (20 receivers). Putting them all into one file (as they're recorded simultaneously), is just more convenient.

Huh, now you made me read specs ... So FLAC has max 8 channels (so obviously not intended for multitrack recording, hm? To the level where they could not afford even a full byte?). Good news is that you can set the number of samples to zero for "unknown", since then you are not bound by the less-than-an-hour 2^36 samples for 20 MHz sampling rate. WavPack on the other hand provides for custom sampling rates and 256 channels - but is not supported by Audacity. According to https://wiki.audacityteam.org/wiki/FFmpeg_integration#table , Audacity can read WavPack by way of ffmpeg - but not write. IDK whether that is an ffmpeg limitation, but the ffmpeg doc says it only supports WavPack encoding at 32-bits integer, and that was maybe not what you wanted. But same source claims Audacity can read & write .mka by way of ffmpeg, so why not try your luck at FLAC ...

The more obscure formates, like True Audio are a lot better: 0 (DC) - 4GHz sampling rate, up to 65535 channels (same specs as MPEG-4 ALS). Unfortunatelly, those formats are also not the best when it comes to software support. I mainly handle them in command line, too, as in this case latency isn't really much of an issue, etc. For Recording I use either FFmpeg or SoX.

Re: FLAC v1.3.2 Final

I prefer command line programs doing one thing but doing that rather convenient. I know FFmpeg is fully featured and everything, combines everything into one thing, nice, etc. but tbh. I prefer having a flac, opusenc, or an mkvmerge.

SoX is almost always my go-to solution, when something has to be rigged up there and then. I found myself numerous times having to fix something up, so it "just records" or "just converts" something. Having something "just stream" a video, I did that a couple times with FFmpeg. Some things I can only do with FFmpeg, short of using libavf and libavcodec in my own program.

Nevertheless, it doesn't mean CMake is abstracted away from the IDE.Usually you want to pass some build options to cmake or something, but they are not configurable as in the ordinary Visual Studio project settings, so you have to know CMake to some extent, and you have to look for the available options in the project (by digging CMakeLists.txt in the project tree).

Re: FLAC v1.3.2 Final

But there is some benefit using this build? I only noticed now...I'm using FLAC 1.3.2 released - 1 Jan 2017 from xiph site. Release from xiph.org it's a good choice anyway compared to FLAC v1.3.2 (Git-2019-03-07)?

Re: FLAC v1.3.2 Final

But there is some benefit using this build? I only noticed now...I'm using FLAC 1.3.2 released - 1 Jan 2017 from xiph site. Release from xiph.org it's a good choice anyway compared to FLAC v1.3.2 (Git-2019-03-07)?

32 bit windows build from 1 Jan 2017 has bug: it can't encode if source wav(w64) file is bigger than 4 GB. It was fixed later in git. Also current git version contains fastCRC patch that slightly increases encoding speed.