Field Recorder Workflow problem

[jakylluk]

Been watching and reading a lot about the field recorder workflow from AAFs supplied by media composer but can't seem to replicate what seems so easy and painless in any of the guides I've seen.

I am working as an assistant sound editor on an upcoming documentary series. I have an AAF of a finished edit which has been cut with the audio that is attached to the video clip which appears to be a mix from the sound recordist, however, it retains the same name as the video clip eg 'EE080' and is in the BWF format. The editor has not synced the iso BWAV sound rushes to the clips so they are not embedded in the aaf.

I have a network drive of all the audio rushes which contain the isolated tracks from the shoot, TC information matches the video clip however the naming convention is completely different, the location bwavs have all been named appropriately relating to what they were recording at the time ie. Markinterview1 Mark interview2 etc.

I have had no luck in matching the clips by match criteria, I have done it by timecode only which eventually gave me the right clip sandwiched in between all the other expanded tracks it gave me which went over maximum amount of voices and were full of clips that had no relation to the take I was after.

I have read about people usingf EdiLoad and other 3rd party applications but from what I've seen of the field recorder guide tracks workflow if I can get it to work it would be fine!

Essentially my problem is that there doesn't seem to be anything other than timecode information that the reference audio and the field recorder audio have in common.


Any help or pointers would be much appreciated!

Thanks!

[Frank Kruse]

Your analysis of the problem is correct:

They edited with the camera-audio so the only data that relates to the original BWAVs is the TC (which will have duplicated al most on every day of the shoot).

Your only option is EdiLoad's reference track conform option. But that will only work if you find some kind of common text pattern that the picture EDL and BWAV meta-data have in common. Something like slate nr. scene/take etc. If the picture EDL only references the file ID (Alexa file name etc.) you won't be able to conform anything correctly.

If the latter is the case the next painless workflow is to manually sync up the BWAVs to picture in the NLE which won't be easy either if there are no references to the original files. But way easier than doing it in Protools by hand.

Try to get picture EDL from your editor check if there are any usable infos in the "from clip name" field and then if they match the scene take numbers of your BWAVs. If yes you have a good chance. If not you could manually batch-alter the source reel names of the video EDL to match the TAPE meta-data of the BWAVs to something that works. But if it was a pro-sumer recorder there might not be ANY usable info besides the filename and TC.

I'd get a picture EDL first and take it from there.

Frank.

[jakylluk]

Thanks for your quick response Frank, I've looked at the metadata for the video clips and the iso BWAVS and it looks like there isn't anything else that they share in common other than TC.

I will try Ediloads workflow and see if that is the way forward.

Thanks again much appreciated.

J

[Frank Kruse]

Originally Posted by jakylluk

Thanks for your quick response Frank, I've looked at the metadata for the video clips and the iso BWAVS and it looks like there isn't anything else that they share in common other than TC.

I will try Ediloads workflow and see if that is the way forward.

Thanks again much appreciated.

J

You need to look at the clip name info in the NLE too. Those could be scene/take names that only live inside the NLE and not the files themselves. They will show up in an EDL hence my suggestion to ask for one. But maybe you've looked at that already.

If there positively is no info you can trace/match there will be no way for a machine to do the conforming. You'll (or an assistant) have to do it fully manually.

If there was no system established during the shoot I think it will be unlikely you find a solution that works automatically.

F.

[jakylluk]

The clip name information in the NLE (MC) is the same as the raw file from the camera but with the extension of .new as it has been transcoded which is very much common practice.

To give you a specific example. I have a piece to camera which has the audio clip from the camera called EE080. The sound roll and tape metadata for this clip are all the same as the clip name. I have manually found the correct BWAV recording that corresponds to it which is called MIKEINT002. There is nothing in the metadata of this wav that relates to the clip in the edit except date and timecode.

Watching the Ediload guide it seems that it relies heavily on metadata being matched between the camera clip and the location audio clip (things like sound roll name etc) but in a working practical situation that isn't going to happen, I don't even know how you would ensure that? Especially for documentary work where so much is on the fly grab it while you can footage.

This is my first time dealing with this kind of issue and before I can say it is a problem that was created on shoot/during edit by not naming properly/ not syncing rushes, I'd like to know I've done my homework first!

Your help so far has been much appreciated Frank!

[Frank Kruse]

EdiLoad works with the info that comes across from the *picture*-EDL and then created dummy audio clips that contain the metadata from the picture EDL. You can manipulate that before the session is created. Check out the video ion their website to see what it does.

In your case the most likely db-field that you could use is a combination of creation date (shoot date & TC) But since they consolidated the audio in the AVID (hence the .new names) that might not work anymore.

From what you wrote I'd try to match the date and TC assuming that video clips carry that info somewhere so you can build a new field inside EdiLoad from that info.

Good luck.

P.S.: have you actually tried the shoot date and TC combo in PT's match criteria?

[jakylluk]

I have tried those match criteria functions and it doesn't work with most clips which makes me think it may have somehing to do with copies of files changing metadata.

I have my session set to copy all files to session so it will actually be creating new files for anything I add. For a test I just took one of my dialog tracks in PT and exported an aaf of it and when I look at the data within it any date related information like shoot date etc has all been changed to today. The original TC information has been retained though.

[Frank Kruse]

You need to work in referenced mode for this workflow. And you need to use non-embedded AAFs just as a side note. Otherwise as you noticed the creation date will constantly change. Embedded AAFs might also strip meta-data depending on the MC used.

That said the "shoot date" meta-data is usually a permanent info embedded inside the BWAVs that should not change when you copy the files.

Hard to diagnose from far away anyway...

[philper]

This is why I try so hard to sell doco filmmakers on syncing up (and cutting with) the mix file from a double-system recorder for all their sync footage instead of just jumping in with the camera ref audio. Even if that audio is relatively hifi (like from a good camera hop) it still is only 2 tr, and they invariably end up where the OP is now--the only way back to MT iso audio will be very laborious. So they are stuck with a ref mix track, probably mono and from a less than great wireless that no one was monitoring while shooting. At least this OP has TC ref in the metadata of both audio and video files, many docs are shot on cameras that do not allow jam-sync between audio TC and camera TC, so the only common factor is the ref audio track (if there is one)--so it could be worse!

[smurfyou]

Originally Posted by philper

This is why I try so hard to sell doco filmmakers on syncing up (and cutting with) the mix file from a double-system recorder for all their sync footage instead of just jumping in with the camera ref audio. Even if that audio is relatively hifi (like from a good camera hop) it still is only 2 tr, and they invariably end up where the OP is now--the only way back to MT iso audio will be very laborious. So they are stuck with a ref mix track, probably mono and from a less than great wireless that no one was monitoring while shooting. At least this OP has TC ref in the metadata of both audio and video files, many docs are shot on cameras that do not allow jam-sync between audio TC and camera TC, so the only common factor is the ref audio track (if there is one)--so it could be worse!

+1

Camera ref is for dailies. They might not want to do it right and sync up front until they find out it will take twice as long and much more $$ to fix it later.