PT won't relink audio despite me seeing the files

[viaspiaggia]

This crops up at random, haven't been able to track down the series of steps that gets me to end up here. PT 10.3.3, Mac OS 10.8.2, HD Accel 3

Open a session that was archived and now restored (simple Finder copy backup and restore). I've got a few files offline, that were sourced from an OMF. I can drill down in my Audio Files folder and find the exact file it's looking for - name matches, file size matches. Because they're listed as ".omf" files, PT will not calculate a waveform or list a unique ID. And PT WILL NOT agree to see these files as viable candidates, even thought I'm looking right at the identical file! Is there a fix?

I have my live backup still active, and I can't find the files in question in that session - I see them in the original folder structure as larger OMFs, but somehow they're not showing up as such in the session; even showing "full path" in the clip bin I can't find them. I must have "linked to audio" when importing those OMFs originally I'm guessing.

Resaving from my original production session with "convert to specified format" checked which I'm assuming will fix it, but still wondering if there's a way to FORCE PT to relink as I've seen this before.

Thanks.

[Postman]

I wish I had a helpful suggestion. I hate this bug and am thankful it hasn't caught me very often. Its bad enough when PT will only relink by name only. That seems to happen regularly. When relink is impossible even though the name match appears perfect and the file(s) have already been in use in the same session, that's when I get mad.
It happened about a month ago. (The session folder was copied from my mix room 10.3.5 to an edit room on 11.) I could find the file, the name looked right, the id number looked right. I finally gave up on relink and imported the file again and just remade a few simple edits. (I don't recall seeing a warning that the file would need a new id stamp, but I was in a hurry so maybe.) Thankfully it was not a heavily edited soundfile.

I wonder if PT is looking for some "hidden" characters, a.k.a garbage? In the Olden Tymes, back when I did a lot of Apple II coding, we would sometimes get tricky by including "control codes" in ascii file names. You couldn't see the codes inserted randomly between visible characters but they had to be there in order for the program to recognize the file. Maybe PT is looking for something that it thinks should be there but is not or was not transferred in an OS copy? I dunno.

[C]

Unfortunately the only way to do what you need is to reopen the embedded OMF with the Force to Session Format option instead of Copy, Link or Consolidate.

New workflow fun and games introduced with PT10.

[Postman]

I guess I should read more carefully....

When re-opening while linked to an embedded aaf, when the location of that aaf file was changed, it helps to put the aaf file back to its original location in order to relink. Exact disk and folder names.

I have finally learned to ALWAYS convert to session file format (not copy, which preserves omf or mxf status) for anything that I think will remain part of my session. Doing so seems to sidestep troubles. I think the only time this step can be done is when importing from the aaf/omfi file, which is not very intuitive or convenient. Do we have an option at any other point in the workflow?

But, that doesn't prevent the other problem I described above.

[viaspiaggia]

Oh great and I thought I was doing well by copying instead of converting to session file format! On non-OMF files I gleefully link just to limit duplicate files on my drives, but I'll start converting from OMFs from now on. I'm guessing this older session I had set to LINK to the OMF, which I'm guessing was the source of my problem.

And I suppose converting everything to the same format when archiving makes sense, too, though that strips away some more of the original structure of the session...

Thanks!

[Postman]

And I suppose converting everything to the same format when archiving makes sense, too,

Yes you're right, that's the other way to get away from omf and mxf audio files. I forgot about that because I've chosen to convert to wavs up front (during import), for two reasons. First, I can be sure that the conversions are flawless (I'd hear any problems while working). Second, it is easier to convert 16 bit exports to 16 bit wavs to save a few megs of space.

Anyway, with luck you can restore the large omf files to their original disk/folder locations, PT will be able to relink when the session opens. It's been a while since I hit the problem, probably with PT8, so maybe this trick doesn't work anymore.

[viaspiaggia]

Yep luckily still had my live backup and it loaded fine. Saved a copy converting to specified format and got it to load!

[Brandonx1]

Why couldn't you force relink if you see the audio file you need?

[viaspiaggia]

no idea! I see the file in the browser above but it refuses to put it in the candidates panel below!

[Postman]

PT10.3.8, OSX 10.8.5. I have a couple of projects recently completed. For a few files in a couple of projects, when a session is moved to another drive, auto-relink does not work. Relink manually using name only works. Project and workspace browsers show blank unique IDs for those files. The original files in the original locations also appear with blank unique IDs.

In all cases, these files are mix and stem outputs that were created and punched in using destructive punch mode.

I recently moved from 10.3.5, OSX10.6.8, and have not found any blank IDs from those sessions.