Bouke

From my (limited) point of view: (Disclaimer, although I did work on 'Avatar' and 'the Junglebook', and have sold TC related stuff to the major game developers, I never ever have been on set, and never saw the actual footage as it was Hollywood 'need to know' base, and I never left my (Dutch) office.) Cameras are only used to check the integrity of the MoCap data. So, video was there as 'video assist', not shooting. Now, a MoCap system is a (bunch of) computers that gather data, nothing more. The video is used as bg, to overlay a quick and dirty rendered animation from the gathered data as soon as possible after a take, to see if the system has worked flawless, and / or a new take is needed. (Perhaps nowadays it can be done in RT, so just a bit of video delay is needed.) If it's not RT, the Mocap system and the cams need common TC to avoid manual syncing. On 'the Jungle book, 3 cams were around the set, and were rendered into a HD quad, I forgot what was in the fourth box... They had an Avid on set for reviewing, and a rough first cut. I am totally clueless what audio does on a Mocap set, other than catching directors shouting and/or scratch dialogue. I very much doubt any sound will make it into the final mix. The set looked like a sports hall, a tremendous amount of lines on the floor representing the virtual world, so the talent (dancers / athletes / acrobats / animals, everything that can do pretty moves) would know where to walk, duck, jump etc. Nothing looked as if sound was important. Problems that might arise (one of the reasons I was hired), video might go trough lots of processing and get a delay, while the MoCap system does not, so you might need to compensate for those offsets. So if you want to be prepared, bring some audio delay boxes that won't destroy a TC signal. (I would think any half decent piece of crap will do.) my 2 cents, hth, Bouke

How about a teamviewer session, or another form of remote control / view of two machines, and a simple text editor with page up/down or alike? No clue if something like this exists, but autocue software is also freely available. I could make something custom, but that seem total overkill.

Well, the drive IS in fact brand new, and brand. (Sandisk) The device prefers to do it's own formatting, but I can try a low level format. However, when I connect the caddy over USB3 to my PC, read/write speeds are good, so I don't think it's the drive nor the drive connectors to the caddy. But it can't hurt to try though.

My trusty Pix is not so trusty anymore. Recently it craps out on recording after a minute or so, with a 'media too slow' warning. Also, sometimes it fails to mount the drive and a re-insertion is needed. That makes me believe the only thing wrong is the e-satap connection. Is it possible to clean those connectors?

There won't be any gaps in the sound! But, if the Tascam files are importing NOT as being spanned, the TC on the butt-edits might skip or double a frame. This will NOT have any impact on the actual sound, and syncing will be painless. If the cams don't shoot very long takes there will be no noticable drift, since all TC's come from the same clock. (No matter how inaccurate / unlocked that clock may be.) Downside, you'll loose one track on the Tascam. Next, I would NEVER use HDMI on a pro shoot where my recording signal depends on such crappy connectors.

https://www.videotoolshed.com/product/transcriber/ Runs both on Win and Mac, reads all forms of TC, (Including the obscure IRIG). To create Mp3 for transcription: https://www.videotoolshed.com/product/make-transcriber-files/ (Shameless self promotion) Bouke

I would not over complicate things. Why not distribute the LTC to the Tascam as well, sacrificing a channel. Set it up to split fairly often, and have post using a couple of files. Perhaps at the breakpoint the TC will shift a frame, but the edit will still be seamless of course. Should be the easiest way, and still frame accurate. Plan B is to rent another recorder for the day. You still need either a lot of cabling or 5 transmitters and a distribution amp. (And a laptop with software to test each cam / recorder.)

Nice!

The madness is even bigger than I thought. Both F4 and F8 run at the same time with the same TC. If the bug occurs, it occurs on clips recorded at (app.) the same time. (Maybe a few seconds difference between starts) AFAIK, only a TC cable between them, and I don't think metadata is piped inbetween the SMPTE. (But I have not listened to it, as recorders are on the other side of the world, perhaps they detect each other and switch to another protocol?) Then there is more. Sometimes, the NOTE is written as NOTE=SPEED=25.000ND This could be a user setting, but I very much doubt that, since in the iXML the <NOTE> entry is a more logical one. Then, most recorders I've seen write a char before a bext entry, and they brand it. So, Zaxcom writes 'zSPEED=' Sounddevices writes 'sSpeed=' Nagra writes 'nSPEED=' (And my work writes 'vSpeed=' of couse...) But Zoom seems to do it random. Not a problem, but, (and that is strange,) sometimes does NOT write a char before a bext entry. Questions, questions.... (But my preliminary conclusion is that these devices are not very strong in the metadata department.) Well, I HATE Facebook.... Bouke

Hi all, Got clips from both a Zoom F8 and F4. Sometimes, the last char of the date in the bext chunk is written as 00x (thus, sometimes the last character of the date is missing.) This does not happen on all clips, but it does occur on both recorders. Is this a known issue? (I've contacted Zoom support in the past, but never received an anser.) Any more gotcha's? Bouke

+ 1 I think this will make some difference. But, of course it's nice to see a hardware TC display running, but decoding will be in sofware. Would it not be an idea to test that? (I'm happy to test for you here if you send me some testclips.)

Yeah, that was why DF was invented :-) (But that does not exists in 23.976, and it's beyond me why there is no DF flavour of that.) Nowdays, a Mac 'learns from it's mistakes'. It checks network time every now and then, compares that with previous checks and calculates its average offset, and compensates for that to make it fairly stable, so it's not that much of an issue anymore. (But no, it's obviously not genlock stable.)

Well, I'm in Post, and I never use any 'pads'... (Even my laptop is crippling me, having just one screen and no full blown keyboard...) I occasionally help out at events (light, mics, couple of big screens, OSD countdown clocks, video playback and a cam, that kind of work. I was amazed to see that the sound / light guys bring about 12 laptops. (Granted, mission critical systems like PowerPoint (that is also used for video playback) are double.) No Ipad to be seen there, and the laptops are all Windows.

Assuming you are referring to my LTC reader / converter, indeed no iOS, but both Win and Mac. (As it also does Midi, it is used a lot to slave other equipment, (video) display in post, laser shows and pyrotech stuff. (That always scares the hell out of me, since that comes with a lot of responsibility.))

Strange that this did not come up: https://www.videotoolshed.com/handcrafted-timecode-tools/ltc-midi-readerconverter/ (Working on an update now, latest version is a bit CPU hungry, should be fixed by tomorrow) What is the problem of syncing to network time every 10 minutes? That should take care of the problems.

Life as you know it will cease to exist, but no worries, the devices will fall back to their internal clock and you will be in sync for at least 16 hours. After that, you might be experiencing a frame offset, but since Post is no longer alive, nothing to worry about.

Robin Williams was bi-polar (Manic depressed.) The medicine for that is Lithium. A lot of bi-polar people kill themselves, and helium is a poplar way to go, he used that as well. But, now I get the original meaning of the post, so, my apologies, and ignore my remarks please.

Eer, does the @ means that I have to comment on how tricky this part is? (Well, it is NOT RT, it has to be compensated with the launch date of the satellite, but then you have to know that, and there is the tricky part, let alone the subscription you need on having an accurate bird database. So, when we get 5G +, there will be 20.000 of them... (But, I'm sure there will be lots of nerd fun to do then, to generate a stupid horrible sounding totally outdated blockwave.)

What exactly are you trying to say here? I find this a bit offensive. Robin Williams did lithium & helium Perhaps I'm missing the joke, so do explain!

OB vans normally don't boldly go where no OB van has gone before...

Mind you, a LOT of cams already have GPS build in. (They write location metadata in the clips.) So, for some reason (And probably the speed of / reliability of reception) the GPS clock is not used. I disagree on 'not being compatible', if all devices write their own time based on GPS, it must be compatible. But, as stated before, it is 'not' that obvious, as GPS is ahead of the 'normal' time by18 seconds today. NTP could be an option, since internet is available almost anywhere nowadays. But as stated before, it is not 'that' hard to do it the 'traditional' way. Only if all devices would run on the same clock it could be easier / less wires / equipment, but I predict a gazillion screw-ups before we get there. (Remember the early days of Plural Eyes where people thought 'everything would sync up automagically.)

No need to do anything if there is no TC sync. Everything will run in the same speed, as the setup of your audio recorder only has to do with the time stamping. Now, if they are going to change the speed of the video, Patrick is your man.

Thank you for paying attention to my class. As stated, if you have a recorder that is 'smart', you won't. My (shameless promoted) BWF toolbox WILL be a solid workaround if your recorder is not so smart. More important, I would be afraid of timing issues if you can't delay other channels that end up in the mix. The half frame delay is not that big of an issue if everything is delayed the same way.

The idea is not new. I have toyed with this at least 6 years ago. It is really easy: A GPS receiver is dirt cheap (2 bucks or alike) Then, you read out the info (Could be over USB), you have NOTHING to code, all the data just rolls out! (Time, location coordinates, even altitude!) There are a few major problems: Often you don't have a satellite 'in sight', or you have to wait until the unit finds it. So, be prepared to curse every now and then. Next is, the atom clocks on board the satellites are NOT accurate. Well, they are HIGHLY accurate, but they run at another time / speed than earth clocks. (Due to the fact that the earth does NOT go around the sun exactly 360 days a year.) To compensate, you have to code. The satellites broadcast their time of launch / offset every 24 hours or so. This is (well, it was for me) hard to tackle. You need to figure out what satellite you have, and where it is in it's own clock. Then, the cheap devices are connecting as plain old N 8 1 XXbaud devices. No way to tell the delay between data received and serial out. (That should be the least of the worries though...) But yes, the general idea is solid :-) (And i think a small Arduinio board will do the trick just fine.)

This I call 'effort'. In your case all params where perfect, but that is not always the case, and then it's more like 4 hours for a shooting day. Mind you, on 'normal' broadcast jobs, a day of shooting 'should' be edited in half a day, so more than a few minutes of sycning is highly irritating. (Let alone you did not have subclips after Plural Eyes, but a sequence. LTC and Avid (or my software) would have done this faster AND with creating (sub) clips.) And I don't eat the TC boxes being big. If you could get production audio to the cam, you could get TC to the cam. Same transmitters / wires. And you bet you are right that I have personal issues with Plural Eyes. (I know the developer, we have had extensive conversations.) It just does not work well in a lot of cases, but people seem to rely on it. Then I'm the one who has the problems and explaining to do that even the 'try really hard' method came up with close to nothing after 400 euro's of studio time. I can't sell that. Period.