BUG: C15.0.6 Huge CPR file sizes due to OmniVocal MIDI parts
Project cpr file size ~5Mb!!
add a couple of Omnivocal instrument tracks, record some parts and enter lyrics (impressive for songwriting )
carry on working on the project over a couple of days.
regular saving of course
Noticed the cpr file size has grown to over 600Mb !!!
took a while to find the cause,
Tracked it down to the actual Omnivocal MIDI parts. Empty Omnivocal Instrument tracks cause no problems.
Delete just the Omnivocal MIDI parts, save the project and the cpr is back down to ~5Mb as it should be. CTRL-Z to restore the parts, resave and the project file is ~600Mb again. Eeeeek!
It was impossible to flatten an arrangement with a 600Mb project file (this alerted me to the issue), Cubase just locked up
The only way I could fix the project was to recreate the MIDI parts. But then with these new fresh MIDI parts the project file started to grow in size again.
NOTE: Very impressed with Omnivocal. It’s no Aretha Franklin, but its integration into the midi editor makes it a breeze to use for getting song ideas down for those of us who’s singing voice is nearly as bad as Taylor Swift.
Hopefully the Steinberg Devs can find a speedy fix for this.
OK, so I created a new empty project with the intent of importing the Omnivocal midi parts into it to archive so I can render the vocals in the main project and delete the MIDI parts there.
unfortunately Cubase locked up, repeatedly while trying to Import these MIDI parts into the empire project, even when I tried moving them to regular MIDI tracks.
I haven’t used Omnivocal all that much, but, in the two projects I’ve used it on, one is only about 2.5 MB (and it has two Omnivocal instrument tracks in it, one male and one female, as well as two virtual piano tracks), and the other is about 25 MB (lots of other instrument tracks, but only one male Omnivocal track – when it just had OmniVocal with fewer instrument tracks, it was only about 3.5 MB).
If the data is in the MIDI notes, is it possible you have something like an MPE keyboard putting out huge amounts of data when tracking OmniVocal? Perhaps looking at the MIDI data in the List view could give some hint on that?
FWIW, I’m on Windows 11, though I wouldn’t think that would make much difference here.
There’s no extra control data in the MIDI notes, other than the text to drive Omnivocal.
I created a MIDI part and entered notes with the pencil, and the increase in file size ballooned from that too, increasingly as you kept saving the project
MIDI CC messages aren’t recorded in the notes anyway, they’re recorded into the MIDI part.
I was specifically wondering about note expression (I haven’t used it personally, but that is what I was thinking might show up in the notes somehow in the list manager). Of course, CC information shows up in the list manager, too, though I wouldn’t think that would hugely affect file size.
It’s definitely curious on the big difference in our experiences on this. Perhaps it may be worth noting that I did not create the MIDI parts by hand – I played them from a keyboard controller. But I wouldn’t think that should matter in terms of file sizes.
The original MIDI parts I recorded from a keyboard. I recreated them by hand, as the original project was F***cked when it got to over 600Mb. The cpr size started creeping up again from the replacement drawn MIDI parts.
To rule out any conflicts with other plugins and VSTi’s, I’m soon going to create a project from scratch and only use Omnivocal ( barber shop choir? :)). And then see if the CPR file size balloons
Are you by any chance using any ARA extensions in the project? Some that store audio data in a project (e.g. SpectraLayers, WaveLab, some preference settings if Synchro Arts RePitch) can make for very large CPR files while the ARA extensions are active. At one point, I was trying the option of Synchro Arts RePitch that stores the data in the files (versus in a system location as the other option in their preferences), and I started noticing Cubase pausing every so often, which turned out to be when it was doing its .BAK file creation every 10 or 15 minutes. It turned out the CPR files were quite large (and I think I was still using a hard disk for my Cubase projects at that time) due to all the RePitch cache-type files being stored in the CPR file instead of elsewhere on disk. They’d sometimes get upwards of 1 GB. (I generally work at 96 kHz, so that makes for significantly larger audio data than 44.1 kHz or 48 kHz would.)
I did come across ARA related issues with cpr sizes during some long searching. I’m not using any of those.
Besides, when I delete the Omnivocal MIDI notes a 600Mb cpr size can go back to being about 5Mb, regardless of whatever else is inteh project
However do you raise a point ……
I’m guessing omnivocal caches the “singing” in the Midi Notes which are saved in the cpr file.
and it could be a BUG in which the cache isn’t being replaced but simply added to, accounting for an exponential increase in file size,without adding more MiDI notes.
Hopefully Steinberg Devs have seen this thread and take a look.
I just tried a little test, starting with my own original Omnivocal test project (piano-vocal version of “The Star Spangled Banner” where I’d had both the female and male voices in a single project along with transposed piano tracks). I removed the extra version of the Omnivocal and piano tracks, getting down to just the male version, then replaced third-party plugins to make the project be able to run on anyone’s Cubase system. The total project CPR file is now down to 706 KB (from 2,535 KB with IK’s PianoVerse for the piano and a bunch of other third-party plugins – I think it was a bit above 1,300 KB after just removing the female version tracks but keeping PianoVerse and the rest of the original plugins). I also saved the project at various intervals to see how the size changed along the way. Nothing seemed other than I might expect, with the first big reduction coming from removing the two tracks, the second from swapping in Halion Sonic with a stock piano for PianoVerse, and a little bit more when changing other plugins.
One thing worth noting is that I am on Windows 11. I went back through this thread, and I’m not seeing if you indicated whether you are on Windows or Mac. But, just in case there is some system-level difference, I’d be curious if my small project somehow ends up growing if you save it repeatedly on your system, perhaps making various changes along the way to see what, if anything, ends up starting significant growth.
When reading back through the thread, I also came across one specific thing in your original note that I either hadn’t caught or hadn’t registered (in terms of a potential key difference between our experiences):
This made me wonder if the use of arranger mode might have some impact on CPR file size. As much as Google’s AI results can often be wrong or not useful, the response did at least flag a couple of areas that made me curious if the arranger mode might somehow be accounting for the differences in our experience. Here is the full response:
Large Cubase .cpr file sizes, particularly when using the Arranger Mode, are often caused by the accumulation of plugin state data, ARA data (like Melodyne or SpectraLayers), or excessively generated automatic hitpoints. While Arranger Mode itself organizes existing data, it can lead to massive file bloating if combined with plugins that save large amounts of data for every Arranger event or if the project has exceeded the 2GB/4GB limit that can cause file corruption.
Causes of Large .cpr Files with Arranger Mode
ARA Plugins (Melodyne/SpectraLayers): Using ARA extensions frequently causes the .cpr to jump from a few megabytes to hundreds of megabytes (e.g., from 1.5MB to 74MB or 400KB to 317MB).
Plug-in State Data: Specific VST instruments (like Kontakt or Arturia plugins) can store massive amounts of session data within the project file, causing it to double in size with every save.
Automatic Hitpoints: If enabled, Cubase may generate excessive hitpoint data for long audio files, adding hundreds of megabytes to the file.
Arranger Events: If the Arranger track has many events that require plugins to update their states frequently, this can exacerbate data storage issues.
Critical File Size Limits
Pre-Cubase 13.0.30: Projects exceeding 2GB could become corrupted, with a hard limit around 4.29 GB.
Cubase 13.0.30+: A new 64-bit project format supports much larger file sizes, but files saved in this format are not backward compatible with older versions.
Troubleshooting and Reducing File Size
Remove Unused Media: Open the Pool (Ctrl+P/Cmd+P), select “Remove Unused Media,” and ensure you empty the trash to permanently delete unnecessary files from the disk.
Disable ARA Extensions: Removing ARA plugins (e.g., SpectraLayers) can drastically reduce file size (e.g., from 576MB to 11MB).
Disable Automatic Hitpoints: Turn off automatic hitpoint detection in Audio Preferences to prevent bloated file sizes.
Import Tracks into New Project: If a project is already corrupted or too large, create a new project and import tracks from the old one.
Bounce Audio: Frequently bounce audio parts that use intensive processing to finalize the edits.
The two items that I’m wondering about are in the first set of bullets, plugin state data and arranger events.
The former about virtual instruments (which Omnivocal is) storing plugin state data (which it would have to) and potentially doubling the size of that data in every save (which seems counter-intuitive to me, but I haven’t used arranger mode much and don’t know what it might or might not do behind the scenes), if applicable here might well explain the huge growth across a lot of saves – e.g. if 5 MB goes to 10 MB on the next save, which goes to 20 MB on the next save, and so on.
If you attempt to do some experimenting with my test project and don’t find any significant growth through just some minor changes and saving, switching it into arranger mode somehow and playing around a bit from there might at least help narrow down if the heavy growth your seeing is exclusive to using Omnivocal in arranger mode.
Thanks, I will give your cpr project a test a bit later.
I’m on windows 10
As for using the arrange feature, the file size had ballooned before I even dded an arranged track, and as said it was when Cubase locked up while trying to flatten an arrangement that triggered me to start trouble shooting. Projects without Omnivocal were flattening arrangements just fine.
After deleting the omnivocal MIDI parts the errant project also flattened just fine
[quote]
Pre-Cubase 13.0.30: Projects exceeding 2GB could become corrupted, with a hard limit around 4.29 GB.
Cubase 13.0.30+: A new 64-bit project format supports much larger file sizes, but files saved in this format are not backward compatible with older versions.
[/quote]
This is good to know. the project might be unstable, but at least it wont’ get corrupted.
I’ve looked up a list of ARA plugins and I don’t use any of them thankfully.
[quote]
Disable Automatic Hitpoints: Turn off automatic hitpoint detection in Audio Preferences to prevent bloated file sizes.
[/quote]
worth knowing and I shall do that
Revisiting this post after having used Omnivocal on my latest project. FWIW, adding four Omnivocal tracks, with lyrics – background vocal parts, so not singing the full song, but three full choruses, small sections of two verses, and about three quarter of the bridge on a roughly 4-minute song, the 4 Omnivocal tracks added a total of about 5 MB to the CPR file, taking the size from approximately 36 MB to approximately 41 MB. The additional size between just adding the Omnivocal tracks with MIDI and adding lyrics was negligible (about 400 KB).
My recent project file seems to get a lot bigger since I made use of Omnivocal.
Before Omni it was around 22 MByte. With three Omnivocal tracks in the chorus it’s grown to 39 MByte. I’m now at around 100 MByte. I just noticed because it needs more time to save.
And Omnivocals is heavy on the asio guard on my system (AM4-based, Ryzen 5 5600, 44,1/512). Three Omnivocals and I get drop outs. Have to freeze. Without Omni the asio guard is around 20 to 30 percent on that project.
I remember those behaviour when I tried Spectralayers Elements (or how it was called) once in Cubase 12 or 13, the project file was up to 300 MByte. After deleting the Spectralayers track it was back to 20 MByte or so.
As indicated in my responses above, I’m not really seeing significant (at least on the order of magnitude suggested in this thread) growth in CPR file size due to Omnivocal. I thought it might be useful if I posted a screen shot of file sizes on my current project in the period before I started using Omnivocal through after I disabled the Omnivocal tracks (after rendering to audio so I could do more manipulation at the audio level):
I already had one disabled instance of Omnivocal in the project that I’d used as a temporary lead vocal prior to track, comping, tuning, etc. my live lead vocal and doing the same with live background vocals.
Extracted MIDI from each of the four background vocal parts and used it on four Omnivocal instrument tracks, but did not yet add lyrics. This added on the order of 5 MB to the project, which went from around 36 MB to 41 MB. This seems reasonable for four instrument tracks. Just to give some sense of comparison, prior to tracking the piano part (probably 4-6 takes?) with IK PianoVerse, the track was around 7.5 MB, and the one PianoVerse track (with multiple MIDI lanes) took it to 11.6 MB, so a gain of 4 MB. I’d already had the Omnivocal part in there prior to that, and the whole project after having that in there with lyrics was only around 3.5 MB. Each additional instrument added gradually to the size.
Finished adding the lyrics, including cleaning up the MIDI where needed, to all four Omnivocal parts for two verses, three choruses, and a bridge. Total song length was a little shy of 4 minutes (there was also one more chorus with no background vocals).
Rendered the four Omnivocal instrument tracks to audio and disabled the instrument tracks.
Converted the audio version of the Omnivocal tracks from stereo to mono, then, using the mono tracks, used Waves Sync Vx to tighten the Omnivocal BGVs against their respective live BGV tracks in both pitch and timing. (This is largely because of inaccuracies in the audio to MIDI conversion.)
Added some processing on each of the tightened Omnivocal audio tracks to get to a new work mix with the Omnivocal BGVs blending with my live BGVs. The entire project had grow from about 36.5 MB to about 43.7 MB since the previous work mix that had only the live BGV tracks, and the growth represents not only adding Omnivocal itself, but also additional track-level processing for the four Omnivocal audio tracks (I think three plugins on each track).
It may be worth noting that this project’s sample rate is 96 kHz. I’m not sure to what degree, if at all, that may affect file size.
)