Jump to content

Conformed original BWAVs are out of sync by up to a frame compared to the AAF


Matthias Richter

Recommended Posts

  • Replies 216
  • Created
  • Last Reply

Top Posters In This Topic

Excellent post, Frank, very clear. Personally I would like to hand files over to you and your colleagues which don't have this problem now we know what it is. Which is where we came in on this discussion before the needless diversions and dismissive hysterics. If post is frame based for the foreseeable future then it would benefit recorder manufacturers to acknowledge this and design accordingly, imho (as at least two have done).

Link to comment
Share on other sites

Excellent post, Frank, very clear. Personally I would like to hand files over to you and your colleagues which don't have this problem now we know what it is. Which is where we came in on this discussion before the needless diversions and dismissive hysterics. If post is frame based for the foreseeable future then it would benefit recorder manufacturers to acknowledge this and design accordingly, imho (as at least two have done).

Yes, thank you Frank for making this effort and recapping the problem such as it is... I hope your concern gets both the recorder manufacturers and Avid to correct this "flaw". We all want to hand over usable files and most of us do at the end of 99% of our work days. On a scale of 1 to 10, this is a 1 at best on the road blocks we face in media creation. Is the problem real? Yes. So are many other flaws in the gear we use. Real life/Set life is a work around until they get corrected or the flow changes. 

CrewC

PS. one mans dismissive hysterics is an other mans truth.

Link to comment
Share on other sites

Yes, thank you Frank for making this effort and recapping the problem such as it is... I hope your concern gets both the recorder manufacturers and Avid to correct this "flaw". We all want to hand over usable files and most of us do at the end of 99% of our work days. On a scale of 1 to 10, this is a 1 at best on the road blocks we face in media creation. Is the problem real? Yes. So are many other flaws in the gear we use. Real file/Set life is a work around until they get corrected or the flow changes. 

CrewC

PS. one mans dismissive hysterics is an other mans truth.

 

+1

Link to comment
Share on other sites

When Marc said "solid-state monitors" what he really meant was "digital monitors."  Solid state monitors have been around displaying analog signals for a long time without a delay.  Digital processing necessitates the delay.  I know Marc knows the difference but I wanted to make sure anyone looking in wasn't mislead by an inadvertent slip of the keyboard."

 

Well, I didn't want to list LCD, Plasma, OLED, light valve, laser, and DLP projectors. I was trying to differentiate them from CRT tube monitors, which had no delay (or a delay under a couple of milliseconds, which doesn't matter). The solid-state display devices do have delays.

 

 

So OK. Lets assume the assistant editor has hand-synced all of that (which he usually won't because he doesn't have the time and also seems no reason why he shouldn't sync the dailies to a wrong TC and it's all done in a Telecine shop that uses an InDAW that does it all by numbers anyway.)

 

Traditional telecine dailies are gone for the most part, at least in America. It's all non-linear now, and it took InDAW with it. All of Hollywood used non-Aaton systems like Fostex DVD-RAM players for telecine in the 1990s -- I don't know of a single post house that had the Aaton inDaw (Matchframe in Burbank had one, but they've been bankrupt for four years), though a handful had the Aaton timecode edge system (including one room at Complete Post, where I worked). Everything is now synced with time-lines, very similar to non-linear editing. It's fast and trivial to slip a dialogue track one frame here or there as needed, and you can literally get to the next take in less than 1 second. 

 

Here's a shot from MTI Film's Cortext Dailies, which is one non-linear dailies product often used to sync dailies and create viewable files for screening and for editing:

 

MTISoundSync_zps5df990bb.jpg

 

Systems like this even have a "clap finder" feature where you just park on the video frame where the sticks close, and the system will automatically find something that sounds like a clapstick. Granted, it can get confused, plus there are issues with multiple cameras and multiple slates, but those are easily rectified. With an experienced operator, they can blow through hours of footage in a fraction of the time it used to take in linear film dailies. This will sync to the sub-frame level, but as far as I know, I don't think Avid or FCP can output an OMF for the post sound department that will reflect less than a frame.

 

I think if this is a post sound argument against Avid because Media Composer can only shift sound in 1 frame increments, then the answer is to complain to Avid:

 

Avid Corporation

65-75 Network Drive,
Burlington, MA 01803
USA
(978) 640-6789
 
Support:
(800) 800-2843
(978) 275-2476
 
On my last feature for which I worked as post supervisor, our dialogue editor told me it took him three days to sync up all our multitracks to the conformed original, and that was in addition to spending about 10 days cleaning up the dialogue, making tweaks, and then another two weeks for SFX (which he also did for us). Not an arduous project, not difficult. We did the final mix in 5 days on a medium-size stage at Anarchy Post in Burbank. Our sound supervisor said the biggest problem was OMF issues from Final Cut Pro 7, and that Avid was actually better from his perspective. From a budget and schedule point of view, we came out exactly where we expected and not a penny over, and the producer and director loved the final mix. 
 
To me, it often seems like the clients who complain the most about stuff like sound sync are those who are 1) neophytes in the process, or 2) impatient and lack understanding about the traditions of film in general. There's an argument like this going on right now on the Red User group, where one guy is questioning why they need a mixer or sound recorder at all, and why all multitrack dialogue can't just be done in the camera to avoid the need for sound syncing entirely. 
Link to comment
Share on other sites

An attempt at a (mildly partisan sorry in advance :)) summary of where we've got to with this -

 

a) Frank works out what has been causing a puzzling, but common sync. problem in post down the line, thanks Frank

 

b. Only happens with some recorders not others.

 

c) Disseminate the information and discuss it with colleagues on a forum.

 

d) Spreads to another forum as awareness of workflow discrepancy which can lead to a fair bit of extra work down the line for post grows.

 

e) Discuss it's level of importance and who could be responsible for fixing it.
quote Frank "When listening to the conformed tracks against the AAF there are random sync inaccuracies from bang-on to light phasing to terrible echo."
However quite a few dismiss this as a minor, with effectively 'Well we've always done it like this and it's been dealt with by post in hundreds of films worth billions of dollars"

 

f) more or less conclude that the real culprit cannot be brought to account

The 'fixes' -

 

1) Avid fix it - conclusion not going to happen

 

2) A recorder manufacturer looks to modifying it's workflow mechanics but is reluctant to try to fix it because it turns out it's a lot of work, (but might have fixed it if it was easier) and not convinced they should have to do all the work to fix Avid's problem anyway.

Also possible translation fix from one format to another might be possible.

 

3) Third party utility could maybe fix it?

 

4) Just ignore it and have all the hard working people in post do the work of fixing it as they always have.

 

 

Notes:

 

i) Recorder manufacturers surprisingly mostly absent from discussion?

 

ii) Style of discussion takes up almost as much time as discussing the issue itself. Quite common on forums, as things get a little heated and people are a little careless about their style (including me!). Could possibly be some kind of cultural thing as well on an international forum?

Can be amusing anyway?

 

iii) Frank says "But AFAIk things are moving behind the curtains" what could this mean?

 

iv) Some discrepancy between scale of production and resources available to deal with this kind of issue ie. big films no problem, plenty of resources to throw at it, smaller productions not so much. (thanks to Macrecorder for this)

 

iiv) No talk about whether a group such as ours, and such as it is, could have any persuasive power in a situation like this.
 

Link to comment
Share on other sites

Thanks, pin. Yes, I think it is not an issue on big Hollywood films and budgets, as Marc expains. But I think the issue is more pressing for lower budget, small staffed operations. However, let's see what happens 'from behind the curtains' - who can be behind those curtains? Avid, Zaxcom, or the big tooth fairy???

Link to comment
Share on other sites

iiv) No talk about whether a group such as ours, and such as it is, could have any persuasive power in a situation like this.

Seriously? This is the single most important place for all things location sound. ... I think. What do you think why so many manufacturers (in many cases represented by their top guys) participate here? They come here for our opinions. Just look at the active IDX thread. Most have their own forum, which will be another important source for them, but no group is as diverse and opinionated as this.

But: we only have influence, if any, on the audio manufacturers, but none on the camera manufacturers and hardly any on the NLE guys

Link to comment
Share on other sites

Thanks, pin. Yes, I think it is not an issue on big Hollywood films and budgets, as Marc expains. But I think the issue is more pressing for lower budget, small staffed operations. However, let's see what happens 'from behind the curtains' - who can be behind those curtains? Avid, Zaxcom, or the big tooth fairy???

Well, if you read through the corresponding DUC thread, Frank (I think) mentions that Zaxcom may be working on something. Don't know his source.

Funny, how on the DUC thread, they got through this topic in 23 posts. This is post #135

Link to comment
Share on other sites

Well, we got to post #135 for a few reasons, including worries by Zax recorder owners that they were about to be unfairly on the hot seat for this issue, and because we as location soundies are often blamed (often in absentia) for all sync issues on a project whether we had anything to do with them or not.  We may not have as much traction with Avid as the posties of big projects do, but I bet they have heard plenty about the issue in play here by now.  That's good.  I've learned a lot from this discussion and the one on the same topic on the DUC.  Thanks

 

philp

Link to comment
Share on other sites

Well, if you read through the corresponding DUC thread, Frank (I think) mentions that Zaxcom may be working on something. Don't know his source.

Funny, how on the DUC thread, they got through this topic in 23 posts. This is post #135

Yes we're a diverse, difficult, and argumentative lot...... :)

Link to comment
Share on other sites

Well, we got to post #135 for a few reasons, including worries by Zax recorder owners that they were about to be unfairly on the hot seat for this issue, and because we as location soundies are often blamed (often in absentia) for all sync issues on a project whether we had anything to do with them or not.  We may not have as much traction with Avid as the posties of big projects do, but I bet they have heard plenty about the issue in play here by now.  That's good.  I've learned a lot from this discussion and the one on the same topic on the DUC.  Thanks

 

philp

This IMHO is a very, very, good point.

Link to comment
Share on other sites

Philip said:"Well, we got to post #135 for a few reasons, including worries by Zax recorder owners that they were about to be unfairly on the hot seat for this issue, and because we as location soundies are often blamed (often in absentia) for all sync issues on a project whether we had anything to do with them or not."

 

I will add to this by saying I think the reason this thread took the turns that it did came from several of the statements (and I won't try and collect them all and list them here with their authors) that took the form of inciting FEAR in our production sound community. Fear that this problem, identified quite thoroughly by Frank's (quoted) original post, could cost some of us our jobs (specifically, those using recorders from Zaxcom). The people who interpreted this as a real threat (and I believe that it probably was only a few) feared that their decision to use a Deva, Nomad or MAXX, could be a fatal decision. Once the people in post get together and tell a producer or production manager that they are having to do so much more work when the mixer used a Zaxcom recorder, some of our sound mixers may have felt they are doomed. 

 

This is not the way this issue should have been discussed but I realize, as do many others here, it is the nature of forums like this (and thank you, Constantin for "This is the single most important place for all things location sound") for things to sometimes go off the rails.

 

The hope is that this amazingly long thread settles down, the fears subside, and we get on with our working lives, solving the problems that we can solve, talking about the ones we hope to solve, and start enjoying our lives again. 

Link to comment
Share on other sites

There's all kinds of problems with the Time Code in BWF Files.  Most of them lead back to a few problems that are endemic with the design of the standard.

 

The EBU in their construction of the standard had a failure to consider non-integer frame rates.  They  chose to store the "Time Stamp" in BWF files using a unit of measurement (samples since midnight) that is not a finite unit of time.   A "sample" can be any length and you must know the precise sample rate of the recorder when the file was created as well as the frame rate to translate Hours Minutes; Seconds and Frames to Samples since midnight and vice-versa.  However the Metadata spec for BWF files does not include the frame rate.  Also to accommodate non-integer frame rates of NTSC 29.97 and 23.976 many tweaked the sample rate to slow down the playback.  Now the calculation of the Start time code stamp is wrong.  So the time stamp of the start plus the running time code when playing the file must always be CALCULATED using computer floating point arithmetic and not a simple counter that is just counting pulses which was the original way SMPTE time code worked.  There are always algorithmic errors and floating point rounding errors that accumulate whenever this calculation of translating samples since midnight to time occurs especially at non-integer rates.   Had the EBU just stored the Timecode Stamp as a UNIT of TIME,  like Seconds since midnight to 5 decimal places,  we wouldn't have as many errors or difficulties in storing this time stamp.  Cameras should start frames at calculated frame starts but I bet many don't ..   So absolute sample accurate sync using Time Code which is only stored to the nearest frame is just not possible.  To avoid a lot of these errors and calculation problems Sound Devices used their pre-record buffer to backfill the start to the nearest second of the TC clock.  They also continue recording until the next second transition after you hit the stop button so each file starts and stops on an even second transition which should always make it better to verify you got the math correct when applying the frame rate calculation  for the time stamps.

Link to comment
Share on other sites

  To avoid a lot of these errors and calculation problems Sound Devices used their pre-record buffer to backfill the start to the nearest second of the TC clock.  They also continue recording until the next second transition after you hit the stop button so each file starts and stops on an even second transition which should always make it better to verify you got the math correct when applying the frame rate calculation  for the time stamps.

et voilà.

Link to comment
Share on other sites

To avoid a lot of these errors and calculation problems Sound Devices used their pre-record buffer to backfill the start to the nearest second of the TC clock.  They also continue recording until the next second transition after you hit the stop button so each file starts and stops on an even second transition which should always make it better to verify you got the math correct when applying the frame rate calculation  for the time stamps.

That is funny, I was working on the exact same implementation; a pre record buffer that jumps to seconds during idle, and stopping on a second as well.

 

However the pre-record buffer is running at the word clock speed, so I still need to do the calculations for non integer frame rates and pull downed sample rates. I don't use floating point calculations, I do them in integer that way it remains accurate, but it is a bit more difficult.

Link to comment
Share on other sites

Oh, please, Pin, drop the Drama Queen crap!

 

...and quit misquoting and mis-characterizing other people's positions.  That reflects very poorly on you.

 

Just when this thread was settling down to actually discussing time code improvement, you do your best to stir up contentious rhetoric again.

 

I had hoped we'd moved beyond that.

Link to comment
Share on other sites

That is funny, I was working on the exact same implementation; a pre record buffer that jumps to seconds during idle, and stopping on a second as well. However the pre-record buffer is running at the word clock speed, so I still need to do the calculations for non integer frame rates and pull downed sample rates. I don't use floating point calculations, I do them in integer that way it remains accurate, but it is a bit more difficult.
Takev, I have to admit my mind is stretched to the uhm, frame's edge understanding this, but is the buffer even necessary? As was said before, any audio before the first frame of picture isn't really needed, so you might as well start recording at the next 00 second after recording has started. That may not help with your calculations, but may make it easier?
Link to comment
Share on other sites

Well, we got to post #135 for a few reasons, including worries by Zax recorder owners that they were about to be unfairly on the hot seat for this issue, and because we as location soundies are often blamed (often in absentia) for all sync issues on a project whether we had anything to do with them or not. We may not have as much traction with Avid as the posties of big projects do, but I bet they have heard plenty about the issue in play here by now. That's good. I've learned a lot from this discussion and the one on the same topic on the DUC. Thanks

philp

I really agree with this, too.

I wasn't trying to imply anything by comparing number of posts. It meant as a somewhat humorous comment - nevermind, please.

Link to comment
Share on other sites

Of course, pre-record requires a buffer.

Of course, I meant foregoing the pre-record function, too, at least to use it as a solution for the frane-edge thing. It sounded like Sound Devices use a pre-record buffer for this purpose even if the pre-record function has been turned off by the user.

But the pre-record buffer may not be the complicated part anyway.

Link to comment
Share on other sites

Oh, please, Pin, drop the Drama Queen crap!

 

...and quit misquoting and mis-characterizing other people's positions.  That reflects very poorly on you.

 

Just when this thread was settling down to actually discussing time code improvement, you do your best to stir up contentious rhetoric again.

 

I had hoped we'd moved beyond that.

Yes actually so did I, but someone couldn't resist some rather silly remarks and as before I couldn't resist responding to it, but it was probably a little over the top? :) ..... so as if by magic......

 

But talking of keeping rigidly to the topic under discussion I expect you remember your own news bulletin spoof early on in the thread which was flippant but I thought quite amusing, carefully, and inventively written, a bit more than just a snipe. Anyway I started to write a little drama spoof about a recorder manufacturer and demands made on his poor put upon programmer trying to keep up, but decided it was probably also a little over the top and maybe too close to the bone, so at least you're spared that as well, you'll just have to imagine it.... :)

Link to comment
Share on other sites

Well, we got to post #135 for a few reasons, including worries by Zax recorder owners that they were about to be unfairly on the hot seat for this issue, and because we as location soundies are often blamed (often in absentia) for all sync issues on a project whether we had anything to do with them or not. 

 

When I worked on dailies projects for Technicolor, sometimes my bosses were quick to say, "ah, there's a sync problem, therefore the sound is bad." I generally would say, "well, it's either a camera problem or a sound problem -- it could go either way." Once in a blue moon, it was our problem and we had a bad reference. 

 

The rare times we had real sound problems were when the sound mixer rolled at 25fps on a 23.98 (or 29.97) job, which required jumping through hoops to get that to sync in telecine. Another bad one is confusing drop and non-drop frame code, which was a nightmare in the standard-def days. One of the biggest shows we ever worked on (one that ran 7 seasons) had a case where the 1st unit shot 30fps ND code, while the 2nd unit shot 29.97ND code. We did not complain or comment -- we just fixed it and rolled with the punches. Nobody noticed, nobody cared. 

 

To me, post's main job is to solve problems and keep the show going and not bother producers or crew about non-serious problems. At best, the 30/29 problem cited above caused us 5 minutes of grief a day -- "oh, no! This is slipping out of sync! Oh, wait -- let me flip this switch. All fixed now." Not a big deal.

 

There are far too many crybabies in post these days, and many of them are editors unaccustomed to film and longstanding traditions. They expect things to automatically work and be easily solved. Experienced editors, post supervisors, D.I.T.'s, and post producers know it's an arduous road and you just gotta roll your sleeves up, dive in, solve the problem, and move on. The neophyte idiots are the ones who whine and complain and want to yell at the crew for problems they can easily solve. 

 

Courtney above is 100% right (as usual) that sample-accurate timecode is never going to be 100% perfect. When you have a solid genlock reference, then you have timecode where it has a relation to the leading edge of picture, and then you have a fighting chance of it being so fractionally close that for all intents and purposes it's perfect.

 

We've known there were jitter issues with Zaxcom timecode, resulting in the SYNC ERROR display on Denecke slates, so that's another potential problem. In the real world, I honestly think it's close enough for jazz and post can (and should) just work around it. In a perfect world, I wish the timecode output had less jitter and did start the recordings on a :00 frame, but I don't think it's absolutely mandatory.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...