Description
Until this is built, some users will be able to get away with breaking the audio into chunks like in my comment on #124
Try implementing the StreamingAudioSegment class - which should be an API compatible implementation of AudioSegment (which may use AudioSegment internally?) which provides the same interface/methods, but does not load the complete audio into RAM.
If there are significant roadblocks there, perhaps just utilities which do individual memory-intensive operations (not as nice a solution).
Outline of an approach:
The new VeryMemoryConsciousAudioSegment (still workshopping names) could do the audio conversions up front (like they are now) to standard wave data on disk in temp files. All operations on these instances would just pile up in a list until the moment when the actual audio data is needed (like an export, or retrieving info like duration, or loudness).
When the audio data is needed, all pending operations would be applied and the result stored in a new temp file on disk in order to avoid reapplying the operations over and over.
As I think more about this, it seems like this has some downsides (much more disk intensive, harder to do operations that inspect the audio data like getting loudness). I'm becoming more convinced that the current in-memory AudioSegment will need to stick around for some uses even if we get to a completely feature complete Streaming/On-disk implementation.
note: I was originally going to commandeer #124, then #51, and finally settled on adding a new ticket.
Also related: #101