A critical announcement about CPR files larger than 2GB getting corrupted

Yes! And I would add … it would be good if Cubase gave a warning that the 2GB limit is being approached. No surprises that way, and no fear of failure if one neglects to add a step to check how big the file is.

2 Likes

Hi,

This fix is part of the upcoming release.

Cheers,
Armand

4 Likes

Still planned for the first quarter ?

Does this only affect C13 as this notice is not in the c12 Forum.
Perhaps the solution is to back up the files only saving used media>

1 Like

It affects every version of Cubase since CPR / NPR file extensions were released.

Does this only relate to the .cpr file, irrespective of the audio or video files? (usually kept in a separate folder)

If so, how on earth does a CPR project file even get close to 2GB?

Hmmmmm, like a decoupled vst rack, perhaps???

Hi @zooterman

Yes

You can find all the root causes in the OP and the Knowledge Base Article. :slight_smile:

Cheers,
Armand

1 Like

Yes, this limitation only affects the CPR file itself.
Some VST plugins and ARA extensions save large portions of WAV and XML data directly into the CPR file.

2 Likes

I was thinking of something less exciting that you wouldn’t notice as a user.

If ARA plugin data is stored separately, then it avoids storing large audio data inside of the project file.

Of course, there’s nothing wrong with fixing the file size limit anyway.

I guess were a ARA plugin saves is data is up to the plugin Developer, which are not under steinbergs control, nor the whole ARA protocol.

1 Like

Hi,

It’s being under investigation and treated as a parallel, yet orthogonal, topic. No matter what your project shouldn’t be corrupted just because it’s reached a specific size.

Correct. Same goes for all data coming out of VST plugins. Everything ends up in the CPR / NPR project at some point.

Cheers,
Armand

Even though it has been mentioned already, it’s worth saying again that it also affects versions of Cubase below 13. I’m using Cubase 12 and have the same issue. It’s very consistent, it happens every time exactly when the file exceeds 1.99 GB.

This just hit me a couple days ago in Nuendo 13. The culprit was using lots of SpectraLayers as ARA in a mix. Didn’t realize the project file size was ballooning. Final mix project file got completely corrupted. Luckily a previously saved version that only got to 1.7GB was used to rebuild the lost work. Definitely shook my confidence in a normally stable platform.

This 2GB issue has a flavour which recalls a quite… distant past (in computer science).

As to the possibility, suggested by some, of a retroactive correction (also applied to previous versions), I’m afraid a software program, in some ways, resemble an already constructed and operational machinery or building: some changes can be done very easily, others are more difficult (and exepensive), others are practically impossible as they would go well beyond the concept of “modification”.

When renovating a house, for example, much can be made, but if you ask for something that involves the structure of the building itself (foundations, load-bearing walls), like making the house narrower and longer, any technician will almost certainly reply that such a “change” means actually tearing down and re-building from scratch. Which is undoubtedly “possible” but not at all convenient.

1 Like

2 GB cpr ?!! Mine are usually 5 to 10 MB …
Which offending plugins create that issue?
I haven’t used Spectral Layers yet, and not sure which of my plugins use ARA either.

1 Like

Same here. I’ve always been in the habit of bouncing audio parts often while using things like Melodyne.

I’ve found, and this is true for all DAWs I’ve worked with, that a little house cleaning goes a long way. If you keep your projects as clean and simple as possible you’ll have less problems and a much faster workflow.

With that said, this is a very nasty bug and needs fixing immediately. Known issues in shipped software is unfortunately a reality, but bugs that involve loss of user data is no-no land.

3 Likes

Well said !
And a TIP for those who don’t do it, use versioning !
That means frequently save new versions of your song, especially just after loading a new plugin. This can help you go back to a previous version in case of a mess up.
And if you do client work you definitely know this (client asks for a modification, later says prefered the older version, have to roll back, learn lesson …!)

3 Likes

And "frequently " is never frequent enough!
Not only with songs but also with any type of files, unless they are totally devoid of any importance and, therefore, “loseable” without any kind of inconvenience or annoyance (quite rare, actually).

Furthermore, anyone who has a (not too) little experience with computers and programs knows well that, sadly, a file can very well be damaged even during a normal “save” or “save as…”, with no error messages at all:
you save your document, you close the program, you turn off the computer and then, when hours or days later you try to open the very same document with the very same program that had (regularly) saved it, the file simply no longer opens because it is “corrupted”:slightly_smiling_face:

2 Likes

I also use the save new version option always and like this a finished project has anywhere from 50 to 100 unique saves.
But my save files are small, I would not know where to keep 75 saves per project if they where 2gb each. 100projects X 75 saves X 2gb is 15TB wow. That is without any audio files.

2 Likes