Re: When Generating RealTracks and RealDrums For A Song Where Are The Rendered Tracks Saved?
D F Tweedie
toggle quoted messageShow quoted text
Makes sense, David ... except for when you copy a generated RealTrack to the Audio or Utility Track. Since you can copy/ paste and edit those ... as well as import your own audio into BIAB, I'm thinking those type files
must actually be stored somewhere?
I have discovered where BIAB places the files that are rendered when using the DAW Plugin. Unfortunately it is on the C: drive in a bb subfolder. While you are supposed to be able to change the path for this from the DAW Plugin Preferences to a drive of your choide, currently it does not function. That's the same issue I mentioned before regarding changing the paths to an internal drive for your RealTracks and RealDrums. As of update 814 it is not functioning.
There is some voodoo with Pro Tools. Normally when you import audio into Pro Tools you are asked if you want to copy the audio to the project folder or simply add a linked path to where the files are located at the time of import. So I checked in the session subfolders 'audio' and 'bounced' to see if the DAW Plugin rendered files were in either location ... and they weren't. So Pro Tools allows BIAB to automatically create that linked path behind the scenes. The sticky wicket is that Pro Tools is very nasty about not finding files it believes are supposed to be in a certain location, so you have to think long and hard about when and how to use the 'Clear Rendered' button in the DAW Plugin preferences.
One final puzzle I've yet to encounter is what happens when you load the DAW Plugin into a session other than 44.1 K sample rate. In those instances with audio file importing Pro Tools then does sample conversion and places the files in the 'audio' sub-folder.
On Friday, January 29, 2021, 2:48:38 AM PST, David H. Bailey <dhbailey52@...> wrote:
On 1/28/2021 9:01 PM, D F Tweedie via groups.io wrote:
> I may totally misunderstand this, but it occurs to me that at some point
> there must be some bloat from rendered RealTracks and RealDrums and the
> need to cull them for songs you no longer are using or want to delete. A
> 3 minute 16bit 44.1k stereo file is about 40 MB, so a BIAB 5 track song
> with RealTracks and RealDrums depending on how many are stereo or mono,
> but for an example lets say 2 stereo and 3 mono, would be about 150 MB.
> Even in today's storage that can add up pretty fast.
> They are obviously not part of the *.SGU files as those are measured in
> KB. So then, are they stored as rendered files or does the *.SGU file
> simply pull up specific sections of RealTrack or RealDrum from the last
> time you played the song, assuming you haven't regenerated?
> This or course assumes you haven't used the Audio Editor to copy/ paste
> a RealTrack onto a utility track. It seems to me that such copied tracks
> must be saved in their entirety somewhere.
Are you talking about the files that are created when we click the Play
icon? My guess (and it's only a guess) is that those tracks are
compiled in RAM only and not written to the hard drive unless/until we
ask BIAB to render a wav or mp3 file. These days, with computers all
coming with at least 8GB of RAM, placing 150MB of data in RAM is a drop
in the bucket.
I guess that the "utility tracks" are also stored in RAM while the song
is being worked on.
My guess also is that BIAB works with "frozen" tracks by using pointers
to sections within the realtracks and realdrums files, not by actually
saving that audio data anywhere on a computer's hard drive.
As you say computer's hard drives would fill up fairly quickly for a
person who might work with 10 or 20 BIAB files each day, if all those
tracks are actually saved as audio data.
I also guess that PGMusic is not about to release any information on any
of this because that's all part of the BIAB "magic" -- all these
wonderful backing tracks and not needing a lot of extra storage for .sgu
files over and above the huge amount of storage needed for the actual
realtracks and realdrums files.
David H. Bailey