Oh, man.... I can not imagine your pain and frustration.
I sincerely hope someone from Adobe looks at this thread. The ususal know-it-alls who frequent this forum aren't even responding.
Perhaps my lame response will get somethig going. People will doubtlessly want to know details about your machine & system enumerated here for diagnostic purposes.
If no good comes of it, I hate to say this: if you don't need the features in CS6, I strongly recommend reverting to CS5 just to get the job done.
No idea, but I've seen several errors lately in conjunction with Avid vs. Adobe. Most of them referred to reference QT's, though and there the fix is simply re-exporting, possibly consolidating your media in MC beforehand. If it affects your native files, then I guess you're pretty FUBAR'd and in the future can only hope to duplicate all footage or use video mixdowns, not media linked to the original master clips...
Can you post links to some sample footage for this? A pre-corrupted file, and the corrupted file. Just a couple of seconds should be enough.
I will try to get a Sample project for you.
You can believe we are scared to death to open CS6 on any mashine.
Try to find a computer that is not involved into production...
Ok here you go:
This is a Demo-project that will kill your quicktime.
You must restart to get back to normal.
The AVID Quicktime will be unreadable even after this.
Use it at your own risk!
Someone experiecing the same problem?
Is the footage that becomes damaged stored on a local drive or on a network?
In one of my clients' facilities we've discovered that using the Madia Manager tool in FCP7 mangles the Quicktime files it tries to process. So far, my only conclusion is that it may be related to a long-standing bug in Quicktime that prevents writing Quicktime files over 2.5GB across certain networks. When FCP attempts to change the metadata of clips over that size, the file becomes unuseable.
I wonder if this is a similar issue - perhaps CS6 AE writes something into QT metadata?
Is does not matter if the files are stored on the network or on the local drive.
You can try the Demo-Project (post 5)
We are painfully aware about the 2.15 GB bug and are astonished that since two Years nobody feels in charge to fix this problem.
I do very much hope that this new topic will be treated different...
I got your footage and it was behaving badly for me as well. It was on a local drive and shouldn't have anything to do with the 2.15 GB bug. That is about writing to a network, which is not supported in CS6.
I would file a bug report, making sure to include the codecs used in the quicktime footage, and the link to those sample files you uploaded. They helped a lot when recreating the issue.
The bug report link is here - https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
good to know that we are not the only one!
Made the Bug-Report right away.
We are having the exact same problem. Just lost a few hours of work. Gone is the grading. Unbelievable!
We could not believe it either.
I just cant imagine what it could have destroyed if we had not copied the footage before to a different location...
Having the exact same problem. is there a fix yet?
Make sure you all post a bug report and link to any media/projects that show this behavior.
Screaming in this forum doesn't help, you must make yourself heard via the bug report database that is monitored by the development team.
The bug report form is available at http://adobe.com/go/wish
thanks! tomorrow i wanted to talk to them. but i'll post a bug report now.
Wes Plate, one of the initiators of Automatic Duck (which is the "parent" software of the Pro Import module) pointed out that the problem doesn't seem to occur if
Preferences>Media & Disk Cache>Write XMP IDs to Files on Import
I confirmed this, testing it with two lenghty projects that had been totally destroyed whe that setting was enabled (thankfully we had full backups).
Try it out, there's a very good chance it will work for everyone.
I still did file a bug report – it is inacceptable behavior, I hope they at least disable that "feature" by default.
THIS IS ACTUALLY WORKING! you made my day. thank you very much!
I DID send a Bug Report with Demo Files and Media/Project.
There was absolute NO Reaction and Comment from Adobe.
You can not make yourself heard when no one is listening
Please understand that you can't expect a personal response for a bug report or feature request to a software that has several hundreds of thousands of users.
I very much understand, and I really do not expect to get a personal response wrapped in paper.
But this topic is by far not a feature request, but a very serious problem.
Every bug report filed is stored in a ginormous database and is used to prioritize what the team works on.
As Jonas says, we can't and don't respond to every bug report. If you need a response from Adobe personnel, then you need to contact Adobe Technical Support:
Note that there has been an Adobe technical staff member on this thread for a while now, Greg Baber.
A real person does read and process every bug report that we get through this form. In fact, that person is sometime me---though the rotating responsibility right now happens to be in the hands of one of my colleagues. Similarly, a real person (me at this time) reads every feature request that we get through the same form.
Regarding this specific bug: We are looking into this and are discussing how we can prevent this problem in the future. For now, the best thing to do is to disable that preference for writing XMP IDs to files on import.