libfargan - FARGAN forked out as a library...on what appears to be a slow boat to a full Vocoder...

FARGAN is an incredible higher performance speech synthesizer usable as a generator that is fairly resilliant to Hallucinations especially if the origin audio being Voice Coded having been cleaned with a suitable application to RNNoise first to remove things like engine noise gunshots, etc.

The problem begins with being tightly coupled to Opus in...an odd way...with someone having to do special compile flags to peel out a usable FARGAN module that can be used separately with something like a high-grade speech synth or an extreme low bitrate vocoder system.

I suppose that it's more...convenient...to have this mushed together source code. As a monorepo it allows you to quickly work on the whole work (Dare I say, "Opus"...) but the problem begins with someone not wanting the trappings about for CELP or SILK in the way to confuse things. Things should be kept simple and modular, really so you can clearly understand it better (Opus, sadly, has evolved over time so it's quite confusing and I'm...unsure...how Valin and Company are maintaining it the way it is.) only drag in enough of the Codec's parts to do the job at hand.)

To that end, this project and related to it (e.g. if there's a need for a libopusfft, etc. then there will be those repos on this server until such time as they absorb the fork back or Opus becomes irrelevant (Don't think so- it's the WebRTC sound/voice codec of choice...)). There are multiple ways to efficiently make a monorepo out of code trees using CMake, Meson, SCons, etc. to build out the whole of the project and maintain the composite as if it were a single repository with tools like AOSP's repo tool, and others.

So, without further ado...

Current state of affairs...

• Only the crucial parts out of the Opus source tree were pulled to allow us to have the actual FARGAN engine build and run as "FARGAN" instead of the whole of Opus so as to get the initial part up and consuming the Analyzer's output from out of Opus.
• We will be pulling in more as time goes along. Does no good to not have an analysis tool to produce the inputs for FARGAN so we can train, etc. as well as quality test.
• Moved away from Opus specific nomenclature to FARGAN specific within the codebase.
• Moved away from non-standard variable types (e.g. opus_uint16) to ANSI standard ones where called for. It's there for a reason, one should probably use it.
• Removed Autotools. Put in CMake as it's my preferred build management solution. Autotools was a tool for fixing problems the FSF had in making GCC build on BROKEN compilers on Ancient systems. It was only ever adopted for other purposes because there wasn't any better. Autotools is baroque, relies on the M4 text macro processing engine and is blindingly fragile and HARD to maintain...just to be able to handle the old AIX/Solaris/etc. broken cowpilers on those systems. Time for a bit of a cleaner answer that can build easier with modern cross-compilation systems like OpenWRT and Yocto.
• Added back in the analyzer codebase, even though it's needing a refactor to be a proper library instead of a bit of a hack underneath the fargan_demo binary. We're probably going to move more towards something that could probably be called a real Vocoder than just the FARGAN engine. It will be a proper library of lego blocks, FARGAN itself, separated out, but the whole will be the bulk of a proper Vocoder.
• Why the last bullet? Weeelll... The results have been every bit as stunning as I'd hoped them to be. This has quality and rates that shoudn't be...but still are.

Currently, the speech synthesizer is capable of consuming the floats generated by the demo/tools code out of Opus for FARGAN. Same quality output every submitted sample. This being said, there is an...obvious...bug in FARGAN's current implementation that I don't think it's code...or rather there's a lack of handling code in the front-end and the analyzer for longer runs of coherent speech or of inadequate training of the GAN (Shows up in their test app and in mine on conversion out to 16 bit signed PCM... What happens is at about the 8-10 second mark on a classic Harvard sentences sample being replayed over the synth interface, it hallucinates a bit and acts slightly like the town drunk. Still intelligible, but that it's happening at-all on the float feed with no drop outs/quantitization/etc. is not really what I'd call acceptable at this time.)

Check the issues base for what is the roadmap/plan going forward. Check the issues base for known issues (like the basically showstopper I mentioned above). This is currently a privately managed project being exposed to the world in a release early, release often manner. It will eventually be released to the world on a more amenable to contributions server at a later date.