We have spotted a special border case within the latest releases of Cubase / Nuendo where projects became corrupted without the user knowing. This border case arises when the project file size exceeds the 2GB threshold. This is because the original specifications of the project file format were not conceived for project files larger than 2GB. This seems to happen more often with projects relying on VST plugins saving raw WAV data or large XML data within the project, as well as the ARA plug-ins of SpectraLayers and Wavelab. We recommend you closely monitor the size of your project when you are dealing with similar use cases and to have reliable back-up strategies when approaching the 2GB landmark.
We deeply regret this limitation has not been addressed until now and we are working on unlocking this limitation in an upcoming update.
We will also make sure the upcoming version of Cubase /Nuendo will prevent projects from being saved in this case.
If your project reaches the 2GB landmark, our Support department has listed all known workarounds for you. This should hopefully unlock the situation until the new version of Cubase / Nuendo is available.
Better safe than sorry. I only read about this because I’m looking for update announcements for CB13. And here I am.
The other day someone spoke about their file getting corrupted, so it seems that this is not a hypothetical situation for those deeply invested in ARA and other tech inside the project file. Mass email with a heads-up warning would be a good choice.
Politicians here in Germany would regard such problems as suboptimal behavior.
By the way: How many film music producers who have a deadline for a blockbuster in Hollywood are currently affected?
Good luck to Steinberg. I am sure you will solve the problem. Get a good night’s sleep first and concentrate on the boulettes the day after, then you will find the optimal solution.
Backing up, creating new unique saves is something I have always done, it is ingrained in my workflow - it does not mean that I have not been caught out at least 5 times in the last 2 months with this bug. Creating new saves and backups have JUST BARELY saved my skin (I never noticed my backups were also engorged!). The other alternative is finding the offending plugin.
I predominantly use Cubase with VSTs in my productions - not so much recording. This issue is essentially a ticking time bomb, that needs to be observed at all times, as one will never know when it might hit, and to defuse can potentially take hours of painstaking going through a project to find the offending plugin. Essentially this means we cannot currently trust cubase with our creations - this is quite a creativity blocker!
The statement from Steinberg, while good, is interestingly missing the key point of my post - that the save file is essentially doubling on each subsequent save (thus hitting the 2Gb limit). The statement also means Steinberg now owns the problem.
So the key question - why are some plugins not saving information correctly in the first place (hence the doubling)?
Letting users know the 2Gb limit is being hit is good, but even better would be a notification of which Vst is causing the issue. Then users can render it/bounce it or remove it.
Key question - is this predominantly VST instruments, or do effects cause the issue too? (This would help massively in tracking down offending plugging - (I have way more effects than instruments in a project!)
And solutions must be rolled out to all versions, not just 13 (and Nuendo equivalent)
As I said, I more than happy to support the Steinberg dev team solve this problem with crash logs, project files, whatever - I’ve invested too much of my life into Cubase to change, and I want what is best for the system and the community around it!
ARA was added in cubase10. Cubase is supposed to be a 64bit application so a 2GB limitation seems a bit of charts. It is missing 33 bits. It is expected to be 8589934592 times better.
Sorry if this isn’t clear. We are referring to the file size in this case, not the amount of RAM the project requires. This is not a matter of running a 64-bit application consequently. Cubase can load several dozens of GB in RAM.
Could there be a way to upgrade the project file format in such way that ARA does not write audio data into it?
I think of the benfit of a smaller project file size when it comes to auto-save and creating manual saves.
Personally I am not using ARA in Cubase anymore as I dislike the bloated file size and the resulting time it takes every time I or Cubase saves the project.
Yea. It can keep it in ram but not on disk.
64 is a address space limitation. It is the expected lowed limitation. You can of course have bigger files than your address limitations. But you won’t be able to file operations like lseek(). In OSX you are also limited by the filesystem. Files can be bigger than 9223372036854775808 (63 bits) on mac. Windows and linux go full 64 bits. But I doubt that it have been tested in practice.
So your limitation on 2GB is fully synthetic home-grown problem. The only valid limitation is your underlying hardware and OS.
2GB is a the limitation of int32_t. And there have been some other issues with Cubase where you are using int32 types. It might be time to clean them out once an for all.
