What is "Encode 'On-the-Fly'"?

[Blushock]

In Encoder settings, there is the titular option, but I have no idea what it does, and if I should use it. Checked for documentation, but no luck. Please explain.

[Lee-Carre]

To my understanding, it means that encoding is performed as part of the pipeline between input (CDDA or other files) and output files, without intermediate steps (especially writing other files to disk).

Without it, when extracting from a CDDA, then (either I imagine, or vaguely recall from a very long time ago), first Fre:AC would write uncompressed (eg WAVE) files while doing the extraction. Then it would encode those uncompressed files into whatever your chosen output format is. A 2-(step|stage) process.

With ‘encode on-the-fly’ the encoding is done without the intermediate step (likely in-memory), and Fre:AC only writes the final result (along with logs, cuesheets, and anything else you've told it to) to disk.

---

So, why does the toggle exist at all? This is speculation, from various (technical or otherwise relevant) experience, on my part. enzo1982 would have the definitive (design-(choice|decision)s) answer.

• multi-step is simpler (to implement), and likely what was done in early development — to extract, encode/compress, and then (possibly) verify, re quires a multi-threaded approach, which is more complex (read: bug-prone) to implement, risking race-conditions (a category/class of bug) and other catches
• it allows more possibilities, flexibility, adaptability/customisability to unanticipated use-cases — this is about avoiding artificial restrictions on the user, and enabling him to have control, and configure things to his liking and needs; a wise design philosophy which makes for quality software
• imagine that your friend is visiting, and brought some CDs. Let's imagine that you end up chatting, and only listen to the audio he's brought shortly before he has to leave. Let's imagine that you really like one of them, and ask him if you can borrow it briefly to make a copy (because sharing culture is good, regardless of what copyright-trolls might think/say). If your friend has to leave very soon (and wants/needs to take his CDs with him), and you have literally only a few minutes with his CD, then the important part is extracting the audio at all (because you can always compress it later; especially if you want strong compression which takes non-trivial CPU-time), and so the fastest way would be to run the extraction process configured to output uncompressed files (since CDDA is uncompressed; just straight linear PCM) Once you have those uncompressed files, which shouldn't take long, you can return the disc to your friend, without drama/conflict, and then later spend as much time as you like compressing them however you wish, because you're no longer dependent on having the physical CD.
• encoding on-the-fly will use less disk space, but more RAM; whereas without on-the-fly encoding should use less RAM, but (at times) more disk space and more writes to disk — more writes to disk might be fine for rotational-magnetic HDDs, but not for EEPROM (flash) based (SSD) storage which has different characteristics to magnetic HDDs
• before we had meh! (that's the Multi-Encoder Hub), if you wanted to output multiple encodings, without having to re-extract from a CD each time, then having the intermediate uncompressed files is very helpful; one extraction, which can then be used to seed multiple transcodings — though, a more structured way of doing this, would be to explicitly output to a lossless format, and then transcode from that to your final formats
• keeping extraction & encoding separate might mean that it's easier to perform parallel processing; we'll take my case, for example: I want maximal (lossless) compression, which means that the encoder takes quite a while, and is considerably slower than the optical drive it's reading from. Thus, (while using on-the-fly) the optical drive is waiting for the encoder, and frequenty spins down (and then back up, when another chunk of data is needed). Whereas, without insisting on encoding-while-extracting, then the two could be decoupled, and the extraction can run at full-rate (of the optical drive) outputting uncompressed intermediate files, while the encoder chugs along afterward. Ideally, I'd then be able to swap CDs for the next one to extract, much sooner than the encoder is finished with the batch of tracks from the first CD. Though, this depends on other implementation details, of course. At the very least it'll significantly reduce the spin-up/spin-down duty-cycle of the optical drive to around once per track (actually, track-count plus 1), instead of multiple times per track. Yes, it's somewhat a variation on the previous scenario of only having the loan of a friend's CD for a few minutes.
• more generally, the one-step-at-a-time approach may be more efficient; the host is focusing on one type of task at any given moment, rather than trying to do everything simultaneously, with lots of context-switching, more likely resource-contention, which (ironically & counter-intuitively) risks slowing everything down
• there's likely other scenarios I can't think of, but hopefully you get the (general idea|gist)

With a non-ancient computer, with non-extreme encoder parameters, and non-exotic hardware, you very likely want to keep on-the-fly encoding enabled.

But, by all means, play around with it; that's often the best way to learn.

Checked for documentation, but no luck.

Yes, it needs much attention & work. It's on my to-do list (since enzo1982 is busy, and his time is better spent developing the code of Fre:AC than from-scratch documentation (most of which could be authored by experienced users)).