View Single Post
Old 2011-12-11, 15:49
JiggeryPokery's Avatar
JiggeryPokery JiggeryPokery is offline
Join Date: Aug 2002
Posts: 5,081
Discussion: Non-embedded Audio and Reason file sizes

There's been a handful of random mentions of this, but I can't recall a dedicated discussion.

tl;dr : Do you want an option to disable embedding audio recording/wave files and merely read those files from a hard-drive folder?


We all know that as soon as you record audio into Reason, or import .wavs, the Reason file size jumps, since the wave files are embedded into.

This is fairly basic example of typical usage at JPHQ, and is probably familiar to a lot of users, given that we don't yet have "punch".

Some of us, i.e. me, unfortunately are not "one-take wonders". I usually just set loop points then record multiple takes on that loop until I feel I've got enough to comp together. This means that the saved file is huge. Ok, so I record ten takes, and let's say the file I now save is 700mb.

The next stage is going into comp view and creating a "single" take from that from all the takes made.

From there is where the issue really arises. Good practice is to save a song file with incremental numbering, so you can always go back to the previous version when you realise you screwed the mix up on the current one. So here, for example, v1 would probably be the track as far as I'd got it without doing any audio. v2 would have audio, v3 would be comped. The file size of course is still 700mb, since we haven't bounced anything.

If I continue working on the track as is, with additional increments, then I could soon have v6, and I'd be up to 3.5 GB of disk space.

So ok, instead one needs to bounce that comp'd track, but the first time you'd really have the opportunity to do that, is, in this example , is for version 4! If we say your comp'd track is 100mb, you've still got the entire recording twice - in versions 2 and 3 taking up 1,500 MB.

You can't delete both of those, since you'd lose other takes. If I later (heh, "If"! "When"!!) decide that actually "that bit thar" sounds crap and I need to check alternative takes, I've got to go back to v3, then do another bounce, and re-import it into version 4. Of course, maybe there isn't a better take, so I need to do additional recording in version 4 - but in practice I suspect you'd want to do it in version 5.

So, you recorded new takes in version 5 (another 400mb), save, comp, bounce and save as version 6!

Let's say our file size is now 150mb, and you might end up with a few more versions, v10, and you've got another 600mb there in addition to the earlier versions.

To this day I still haven't figured out what "save and optimise" actually does It doesn't bounce, it doesn't minimise audio tracks to edits or clips.

One anti-argument I've seen is that HDs are massive and cheap. Yes, that's true, but the more HDs fill up, the slower they become, and you have more issues with defragged files. Sometimes you just want to be able to go straight to the original wave file of the recording, maybe for external editing, or just previewing.

One other thing to note: currently, there is also an issue regarding comp mode with tempo changes that both selig and I independently discovered, whereby changing tempo during a track causes the comp positions to adjust - the only current way to avoid that is bouncing. (Incidently, this was No. 4 on the Cuts Death List, although it may not be such as "small fix"). So to have tempo changes in songs with comp'd audio, you have to bounce.

I can understand the ethos behind the auto-embedding in Record 1. After a couple of years in practice, it can be it limiting, and thus I'd like to see a more traditional set-up with an audio-pool system derived from the recording folder.
Vintage Keyboard & Guitar ReFills for Reason

Last edited by JiggeryPokery; 2011-12-11 at 22:49.