x1b bug: project corrupted - please help me save face

Load a new project in PT.  Show your client the blank screen and say "Look what PT did to your hard work..."









Then run...

Karyn


Load a new project in PT.  Show your client the blank screen and say "Look what PT did to your hard work..."

Then run...

LOL. I'm trying to have a sense of humor about this :)

JoshWolfer

I know I should have had auto-backups enabled. I turned them off on another project I was working on because it kept causing stutters on what I was working on and I forgot to turn them back on. So please don't be critical about this. I'm in a really bad place and am not looking for flames. I've already churned over and over on how I could've and will prevent this from ever happening again.

I can't help you with your corrupted project, but I can tell you I used to use A-S all the time and it never once caused a stutter, and I had it set to to Auto-Save every 60 seconds. Sounds like you may have something else going on with your system possibly?

I turned A-S off because there is a bug in X1c (and all previous versions X1) that causes your Tool Bar to go blank and turn gray when A-S is enabled. It was driving me crazy so I stopped using A-S and the Tool Bar problem stopped.

A-S=Auto-Save

The Tool Bar thingy doesn't seem to effect all systems so I would figure out why A-S is causing stuttering and turn it back on ASAP.

Try importing the audio into a new project. You may loose the editing but the audio may be still there.

That really sucks, Josh. You have to wonder if a product is really ready for professional applications when something as critical as backups can't be relied upon. You did everything right and prudent and still got burned.

Good for you for not going ballistic over this. I'd be pissed, and I'd certainly be in no mood for another "it's your configuration/sound card/Windows version/video driver/works fine here" type of excuse. No, this is Cakewalk's problem.

That after all these years SONAR can still corrupt a project file after taking an error is inexcusable.

You may not be totally out of luck, though. If someone high enough up in the tech hierarchy at CW gets your project, there is a chance that they can repair the file. But if it was truncated, then you may have no choice but to fall back to a backup. (Take a look at the cwp and compare its size to one of your backups.)

bitflipper


That really sucks, Josh. You have to wonder if a product is really ready for professional applications when something as critical as backups can't be relied upon. You did everything right and prudent and still got burned.

Good for you for not going ballistic over this. I'd be pissed, and I'd certainly be in no mood for another "it's your configuration/sound card/Windows version/video driver/works fine here" type of excuse. No, this is Cakewalk's problem.

That after all these years SONAR can still corrupt a project file after taking an error is inexcusable.

You may not be totally out of luck, though. If someone high enough up in the tech hierarchy at CW gets your project, there is a chance that they can repair the file. But if it was truncated, then you may have no choice but to fall back to a backup. (Take a look at the cwp and compare its size to one of your backups.)

In all honesty I've never had a corrupted project (that wasn't my fault) in the 15 or so years I've been using Cakewalk products. I've had my share of PT and Logic files getting corrupted as well. Heck, I've had data loss on a HD24 too....good thing there was a spare running as well
 
If he's been working on something in virtual memory for 6 hours his hard drives very well could have shut down. Maybe SONAR can't handle that eloquently but, that's why I make it so the HDD's never spin down and I save like it's going out of style.

True, there are sensible precautions one can take. What I'm talking about is transactional integrity. Before the save starts, there is a working project in memory and all the required data is there. If an error is raised during the save, that should not corrupt the file because you're writing to a temporary file. The original should not be deleted until the new version has passed an integrity test, and even then a renamed copy of the original should be available for recovery purposes.

This is pretty basic stuff when working with high-availability data. Sure, if you're talking about saving off a Halo level, that's another matter. But when you're saving data that you are charging a paying client for, it deserves more respect than that.

Another helpful thing is if you use per project folders, the audio recorded will be in that folder.

You can put those files into the old project and work on getting the m lined up-

This is a fall back way to try to get things back.

Lance

Noel: nice option you offerd, pro support..

This may sound crazy but instead of trying to load it conventionally, have you tried locating the corrupted file in your browser and simply dragging it into a new project?

> I'l second that one John, sometimes you just have to go for it !!<

kc2ine


yeah, I also sometimes get out from the car and get back in when it's broken thinking it will fix it...

Welcome to Options/Tech support, if you try you cant fail
but in your case ..Sir.. btw how X-1c running for you.Chk
Mate

"That's good to know, Noel! That begs the question, though, as to how corrupt CWP files ever happen at all."


I thought the very same thing.

I guess if SONAR hicups and starts storing a file with errors than it'd be hard to expect it to run a comparison diagnostic against the copy without the errors to check for errors in the copy with errors?

Or something like that?



best regards,
mike

That's good to know, Noel! That begs the question, though, as to how corrupt CWP files ever happen at all. And why that failsafe apparently failed for Josh. Sure, disk files can become corrupted for many reasons, but SONAR project files are more prone to it than other data files I come into contact with. I work with very large and complex data files in my day gig, and have never once had the application that created them corrupt the data. It's always been faulty drives, power failures or network problems. Although corrupt project files do seem to be far less frequent nowadays - a quick scan of my projects indicates that all of the corrupted project files I have date back to SONAR 5 and SONAR 7. I'm guessing that's an indication that you've found and preempted some of the causes in subsequent revisions. Any thoughts on what we as users can do to prevent and recover from corrupt cwp files? Have you considered adding a checksum to project files so that SONAR could verify data integrity after writing?

 
If SONAR detects a problem at save time, the save is aborted and your original file is intact. However on occasion corrupt files can happen without SONAR's knowledge. This can be due to a several sorts of bugs. Persistence code is enormously complex since every object in the application is saving its state. If any object has been corrupted due to heap corruption, an errant plugin or any other reason, the integrity of the data being saved can be bad. If the file save succeeds without a fatal error like a crash then you now have a file saved which will load with errors the next time. It is extremely rare for something like this to happen but it can. Saving a large data file is not necessarily the same sort of problem situation. SONAR is a host within which many outside components live. Any one of these components can potentially corrupt the application state in memory leading to a compromised state. This is unlike most database programs where the environment is more controlled and testable in a deterministic way.
 
Over the years we have made the our files self correcting in many circumstances. Almost all the recoverable files from issues in earlier versions are auto repaired. At load and save time any detected problems are auto repaired behind the scenes. Its not something we advertise as a feature but there is a lot of effort that we have put into the application to make file load and save as robust and resiliant as possible.
 
>>Any thoughts on what we as users can do to prevent and recover from corrupt cwp files?
 
One tip to recover from a situation where sonar reported an error on save - If the appliction is still functional, open a new document and copy and paste all the track data to it and then save it as a new document. Thats one way of capturing the current state.
The other thing I do is always save as a new version every 20 mins or so. Then at the end of the session I will go back and delete all the superfluous versions. Another tip is to frequently close and reopen the file you are working on - that way you know you have a workable file at all times.
One more safety measure especially when working with projects containing lots of plugins is to shut down and restart SONAR once in a while. That helps ward off problems related to memory leaks or potental data corruption.
 
>>Have you considered adding a checksum to project files so that SONAR could verify data integrity after writing?
A checksum wouldnt solve the problem I just described since there is no way SONAR knows the project is safe until it was reloaded the next time.
 

I would guess no... I imagine that dragging and dropping from the browser just invokes the same load operation as going through a file dialog. It's only a guess though.