The yellow bar only means that this material does not meet the sequence settings, which is completely understandable when you use 720 x 480 resolution for your sequence and import 640 x 480 with square pixels.
Thanks, that makes sense.
Would it help if I encoded those 640 x 480 AVI files into 720 x 480 in AME and then imported those into my project instead? Would that take care of the red line and repeated rendering?
1 person found this helpful
The problem is that AVI is just a container and can contain all sorts of stuff. PR really likes when everything in that container is MS DV AVI type2 with 48 KHz stereo PCM/WAV audio. If it is anything else, you are better off with converting first. Use Google to search for a suitable converter.
It's probably something specific to the source AVIs you're using. Odds are that, if you either a) transcoded them into a new file, or b) brought in source material captured directly from a camera, you wouldn't be experiencing this.
The background: PPro uses XMP technology when it comes to footage & metadata. When it's rendering either preview files or PEK/CFA files for audio, it uses XMP's unique file identifier as part of the hash ID, as well as the modified timestamp of the source file. The idea is that a preview or PEK/CFA file is valid until either a) the user makes an edit & the material needs rendering again, or b) someone directly edited the source material (like, an Edit in Audition operation where you're cleaning up audio background noise) and so again the previews and/or conformed audio files aren't valid anymore.
The hunch: if XMP can't write into the file, things fall apart. This could be either because a) the file is write protected, or b) XMP detects that the file internals of your source media have some kind of structural error and decides to play it safe & not inject data into the file. If this happens, every time you open that project, a new random XMP ID is generated for that given source file, and this will make your previews & PEK/CFAs regenerate on every load.
One workaround that you can try: in the prefs, there's an option somewhere to disable XMP write to media. See if flipping that option off fixes your problem.
Thank you for the "under the hood" look at things.
if XMP can't write into the file, things fall apart. This could be either because a) the file is write protected,
One observation on other "working files," is that Windows Indexing will "lock" those files, while it attempts to do its indexing. This can take some time on large files, and Indexing will keep trying, even if there is no useful data in those files.
In Photoshop, users have had issues trying to do a Save with large fies, if Indexing was busy with those files.
I wonder if this could possibly be a contributor to your thought a.).
Just thinking here,
Thanks, Wil. I disabled write XMP ID to files on import, but it's still generating peak files every time I reopen the project without any changes made.
BUT while staring at the file names as it generated those peak files, I noticed that one of my AVI files is only 32kHz, while the other two are 48kHz. Could that be the problem? My sequence is a DV NTSC Standard 48kHz, so one of the video imports doesn't match.
I'm going to try a project with just the other two 48kHz AVIs...
Or, is it even possible to re-encode the 32kHz to a 48kHz? I only use the audio track from the 48kHz one, so I don't mind if the sound quality won't be ideal.
Alternatively, would I have the same issues with a standard 32kHz sequence with 48kHz files?
Probably the easiest way to handle the 32KHz Clip is to Render/Replace, which will convert the instance to a PCM/WAV @ the Project's/Sequence's specs. If that does not solve the issue, then you can certainly convert the source material to 48KHz 16-bit PCM/WAV. One way to do this would be to set the WAB (Work Area Bar) over that Clip, and Export as DV-AVI w/ 48KHz 16-bit PCM/WAV. When done, Delete that original Clip from the Project Panel, and Import the newly Exported file, and drag it to the Timeline.
Good luck, and hope that it'll help,
The audio sample rate won't have any bearing on PEK file generation - this happens for all audio sources (PEK files are what's used to display waveforms on the timeline - the idea is that the app only needs to generate this info once instead on every load like you're seeing). Other than forcing a project save after you disabled the write on XMP option, I'd probably go with Bill's suggestion with breaking out the audio into separate wave files.
@ Bill: I don't think Windows indexing is the problem here - I mean, yes, theoretically that could happen, but it should only index once in a blue moon. The odds that the OS is indexing everytime the OP is opening his project are pretty slim.
Thanks, that seemed to help somewhat. I did the Render/Replace, and then made sure I wasn't using the old clips anywhere else. But after closing and reopening the project, it's still generating peak files and rendering the sequence before I can play it. Not sure if it's because I created/edited those sequences before. I hate to have to re-create those multicam sequences, but if it works...