Constantin Posted December 5, 2013 Report Share Posted December 5, 2013 Yes, thank you, Frank, very informative Quote Link to comment Share on other sites More sharing options...
macrecorder Posted December 6, 2013 Report Share Posted December 6, 2013 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). Quote Link to comment Share on other sites More sharing options...
John Blankenship Posted December 6, 2013 Report Share Posted December 6, 2013 ... Which is where we came in on this discussion before the needless diversions and dismissive hysterics. ... Why are you trying to hard to keep them going with comments such as this? Quote Link to comment Share on other sites More sharing options...
old school Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
John Blankenship Posted December 6, 2013 Report Share Posted December 6, 2013 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 Quote Link to comment Share on other sites More sharing options...
Marc Wielage Posted December 6, 2013 Report Share Posted December 6, 2013 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: 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. Quote Link to comment Share on other sites More sharing options...
pindrop Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
macrecorder Posted December 6, 2013 Report Share Posted December 6, 2013 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??? Quote Link to comment Share on other sites More sharing options...
Constantin Posted December 6, 2013 Report Share Posted December 6, 2013 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 Quote Link to comment Share on other sites More sharing options...
Constantin Posted December 6, 2013 Report Share Posted December 6, 2013 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 Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted December 6, 2013 Report Share Posted December 6, 2013 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 Quote Link to comment Share on other sites More sharing options...
pindrop Posted December 6, 2013 Report Share Posted December 6, 2013 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...... Quote Link to comment Share on other sites More sharing options...
pindrop Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
studiomprd Posted December 6, 2013 Report Share Posted December 6, 2013 " the pops that are, like in the Nagra days, on each individual audio file . " 2-pop's are different than the beeps (often two) that we put at the end of a take, to signal that we are about to cut... we call those tail tones,never "pop's"... Quote Link to comment Share on other sites More sharing options...
Jeff Wexler Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
cmgoodin Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
patrickveigel Posted December 6, 2013 Report Share Posted December 6, 2013 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à. Quote Link to comment Share on other sites More sharing options...
takev Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
John Blankenship Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
Constantin Posted December 6, 2013 Report Share Posted December 6, 2013 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? Quote Link to comment Share on other sites More sharing options...
Constantin Posted December 6, 2013 Report Share Posted December 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
John Blankenship Posted December 6, 2013 Report Share Posted December 6, 2013 Of course, pre-record requires a buffer. Quote Link to comment Share on other sites More sharing options...
Constantin Posted December 7, 2013 Report Share Posted December 7, 2013 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. Quote Link to comment Share on other sites More sharing options...
pindrop Posted December 7, 2013 Report Share Posted December 7, 2013 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.... Quote Link to comment Share on other sites More sharing options...
Marc Wielage Posted December 7, 2013 Report Share Posted December 7, 2013 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.