just doing a very very basic test with spectral layers pro 7 in cubase pro 11
create a new project
insert a stereo music track (i used a flac of amy winehouse back to black)
apply spectral layers and unmix stems
drag the stems to new tracks
mute the original spectral layered track
save the project
result the .CPR is 499mb!
update:
Add a second audio mix and do the same procedure as above, save again and its now 820mb
I would surmise that SL is creating (lossless) PCM files, which are inherently quite larger than FLAC, MP3, AAC or other âlossyâ âend userâ formats. PCM files, typically <.wav> can be re-encoded to whatever for end-user distribution in your favorite audio editing, DAW or standalone encoder. I do not think SL has lossy type file encoders.
after testing again, the size of the project jumps when saving after performing the âunmix stemsâ the .cpr file goes from 400KB to 317mb+
new project - save - 361kb
import stereo audio file & save - 362kb
drag audio to audio track & save - 399kb
open event in spectral layers & save - 400kb
process - unmix stems & save - 317MB
and just to add this is with cubase 11 pro, spectral layers pro 7.0.21 on windows 10
These unreasonable sizes have been pointed out before, krevvy, but your demonstration is very useful. I, for one, would very much like it if this cpr size growth could be stopped. Despite of it, I went for the special pricing right now and upgraded to Pro.
It would be fantastic, Robin, if this could be addressed.
krevvy, the âARAâ files you can see outside your project were created by Cubase when the layers were exported out of SL (by drag and drop) - but itâs unrelated to the lossless ARA data itself that SL needs to store somewhere, and the ARA standard recommends storing it in the host project for portability.
Hereâs the math, basically:
SL works with float32 data. If you unmix a 4 minutes song into 5 stems, you end up with 6 layers (counting the root layer) 4 minutes long each, which is 6 (layers) *4 (min) *60 (seconds) *44100 (sample rate) *2 (stereo) *4 (float32) = 508 MB.
That being said:
-if you bounce your tracks, including the extracted stems (since they are also assigned as SL layers), completely removing SL after the operation is completed, your CPR file should be back to its original size
-weâre working on a solution to make it optional, so that ARA data could be stored outside the host project as well (but beware that could cause portability issues then)
this has been reported before on V6 - and storing all the audio data inside the CPR isnât satisfactory for larger projectsâŚyour CPR size soon becomes unmanageable. Saves can take several minutes. You say that the ARA standard ârecommendsâ but that is not the same as âdemandsâ ?
Re: portability - I think this is a non issue, as long as it is inside the project folder in a clearly labelled folder then I canât see why it is any different from ânormalâ audio - there are even other areas of Cubase/Nuendo that donât follow this standardâŚ
Previously you have suggested people use Git or Subversion to manage thisâŚI really donât think that is a sensible solution
Itâs wonderful how quickly and promptly you reply to everything here. I am not krevvy, but I have pointed this issue out here before, so I will pitch in. Doing what you say above, does not result in the cpr reverting back to its original size. I did this when I beame aware of the issue: bounced the track/s, removed SL, saved the cpr. It still had the same alarming size, well over 1,5 GB!!! So this doesnât work. But it would be great if it did. That would save this issue for me completely.
Indeed, itâs only a recommendation, nothing prevents an ARA plugin to make external saves instead.
However the issue regarding portability is that there is no way for an ARA plugin to know where the host project is saved. SL only has access to memory buffers when reading and writing audio, it doesnât know anything about your project location and files location.
So I could add an âARA Folderâ setting in SLâs Preferences, but it will be common to every ARA projects then; which can quickly become an issue by itself.
Ah ! Good to know. Itâs a Cubase issue then - if SL is not assigned anywhere, thereâs no way it could store any data in the project. Iâll report to the Cubase team. Having this issue fixed could already solve most of the inconvenience.
it would certainly help - but itâs not the optimum solution obviously. The beauty of a modern DAW is that you donât need to commit so you can go back and edit later if needed.
It depends - most of the big inflating size (>100MB) is due to this new Unmixing feature; but if you move the unmixed layers out of SL back to Cubase, then SL doesnât have to store any modification internally.
Small spectral fixes in SL (like removing unwanted noises) should not use that much size.
The Cubase team has now been made aware of the issue, and will try to fix it for the next Cubase patch.
Hi many thanks for the prompt info & making the team aware!
just to confirm that with spectral layers totally gone, the project file is still the same size, so from my example above if i now
remove spectral layers from source audio track
remove the source audio track
render the bounced stems to new files
cleanup & remove trash in the audio pool
âbackupâ and minimize files⌠the .cpr still remains 317mb
and just to confirm there is no 3rd party plugins involved⌠its only a test project, but im so glad i hadnât used this on a real project (without a backup)
Last post is from Dec 2020, so Cubase should be aware of this.
They talked bout CB11 and SL 7. I have the latest builds of CB11 and SL8. Clearly nothing has happend yet. Dividing to small projekt and then sync all together? Better than loose all, include last saved.cpr file. Pity on a otherwise really good sound cleanup tool. But not very professional. Me doning what computers are ment to do!