• SONAR
  • cwp file balloons in size till it's unusable.
2013/05/23 07:22:08
flyingvivaldi
I have a project which started to take a long time to load and save. It got to the point where it would take up to 30 minutes to load, and then it didn't load at all. I looked at the size of the file and it was around 250 MB! I went back to a previous version which was around 19 MB (itself way too big for what's in the project) - opened it, and immediately saved it under a different name - checked the file size and it had almost doubled at 35 MB.

I assume this is just a corrupt project file. I think the only way out of this is to rebuild the project from scratch by saving each track as a template and dragging in the audio again. But has anyone else come across this behaviour before? I searched the forum but nothing came up.

I'm using X1 on a Dell Core i7 Win7 with 8 GB RAM.

Thanks
2013/05/23 08:54:36
gswitz
when i extend the length of a project to hours by rolling out a drum loop, i notice project size gets really big. for me, this is the most common and avoidable cause of project bloat. paste special a zillion times. ha ha.
2013/05/23 09:46:43
bitflipper
I'd suggest opening a support ticket and sending the project to CW for analysis. We'd all be interested in finding out what causes this (not new) phenomenon.

Project files naturally grow in size as you work on them. They contain properties for each audio and MIDI clip (a few KB extra for each frozen track), plus all MIDI data, AudioSnap transient data, and V-Vocal files.

In order to support nondestructive un-do for everything, autosaves would necessarily have to re-save MIDI, AudioSnap and V-Vocal data, causing the cwp file to grow dramatically. Split a clip and you now have to save information on 3 objects. Merge a bunch of MIDI clips into one and you have to replicate all that track's MIDI data.

My own theory, and this is purely speculative, is that the saves are not incremental but rather full backups, meaning much of the backed-up data will be redundant. If you've ever administered databases you'll know what I'm talking about: you can fill your entire disk with transaction logs, the database world's equivalent to SONAR's autosaves. You can't hang on to everything forever.

(I do not use autosaves. My largest project files are typically 2-3MB. The biggest ones contain a lot of MIDI data and frozen tracks but most are instrumentals and therefore cannot contain A/S or V-V data.)
2013/05/23 10:14:55
clintmartin
Does the "save project as" trick, make this better?
2013/05/23 11:37:29
daveny5
That's awfully big for a CWP file since CWPs don't contain any audio data. 

I did a little research on this. Did you perhaps use AudioSnap on the project or put AudioSnap in Transients mode? Seems like that may be the culprit. Try a Save As to a different name to see if it gets cleaned up. 
2013/05/23 12:46:05
flyingvivaldi
Thanks all for the input. I did a process of elimination with a cwp which was at 35 MB by deleting each track in turn until I found the culprit - it was a lead vocal track which had been put through Melodyne - but not directly. There is a bug apparently in Sonar where Melodyne doesn't get rendered to a final mix if Fast Bounce is on.

As it takes far too long to wait for mixes to render in real time, my process was to move any vocal bits which needed processing to a dedicated Melodyne track, work on it, then track bounce it back onto the lead vocal track (without Fast Bounce). My lead vocal track then ended up with multiple clips, consisting of raw lead vocal and lead vocal which had been put through Melodyne and track bounced. In my process of elimination, each time I deleted a clip which had been track bounced, the size of the subsequently saved cwp dropped dramatically.
I restored all the clips, confirmed that the saved file size went back up after a save, then clip bounced all the clips on the vocal track to a single clip, saved the file, and hey presto, a tiny cwp!

It's interesting that this issue (bug?) compounds itself each time a cwp is saved, even though nothing has changed on the track in question. Whatever extraneous data is being saved to the cwp is saved additionally every time a save is carried out after loading the cwp.

What I haven't established yet is whether it's the bounce to track process itself which caused the problem, or the fact that it was done with Melodyne on the track which caused the issue. I'll try and establish that and post back here when I get a few minutes.

Thanks again!

2013/05/24 04:19:25
flyingvivaldi
Well I tried it all out on a new project, with and without Melodyne, and had no problems at all. Guess it was a one-off. At least I know how to fix it now 
2013/05/24 08:55:59
bitflipper
Always use the slow bounce with Melodyne.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account