Jump to content

Bouke

Members
  • Content Count

    173
  • Joined

  • Last visited

  • Days Won

    1

About Bouke

  • Rank
    Hero Member

Profile Information

  • Location
    Netherlands
  • About
    I'm a developer of software tools, both ''off the shelf' as custom work.
  • Interested in Sound for Picture
    Not Applicable

Recent Profile Visitors

1,219 profile views
  1. Yes, Avid Media Composer is not that forgiving, but I agree, it's not the end of the world.
  2. I have no clue, since I don't have access to the source code of the recorder nor Avid. Speaking of, Avid has two meanings, for some it means ProTools, for others (me) it means Media Composer. Setting framerate on your recorder affects how to interpret incoming LTC / outgoing LTC, and perhaps a stupid tiny bit of metadata in the BWF files (that can be ignored by MC if you want it.) Framerate setting 'should' not affect the timestamp of next files in a splitted set. When you say 'only exists in 25p', is that an Avid (what avid) project, or a 'I've set my recorder to 25p and then the shit hits the fan'? Keep in mind, I cannot mind-read. (But I can fix the existing files if needed.)
  3. There is really a lot wrong with the lingo used here. BWF has no timecode, it has a time stamp, a number representing samples. That can be converted to TC, but the time stamp itself has nothing to do with any video frame rate. So if there is a bug, it's due to a wrong timestamp on the spanned clips, and that MUST bite EVERY project framerate. As an example, your recorder splits every second, and you start recording at TC 00:00:01:00 The first clip (assuming you're recording @ 48K), then has a timestamp of 48001 The second clip then must have a timestamp of 96001 To see how big the offset is in your case, write down the Samples After Midnight of the first clip, and find out the amount of samples in the first clip. (Using a HEX editor, it's the value after DATA divided by the ByteDepth and Amount of Channels.) Add those, and that should be the SAM of the new clip. Now, the new clip has probably a lower SAM, hence the overlap. But, Avid does not think in video frames when it comes to syncing. Avid uses SAMPLES. (Hence way more accurate.) The fix is easy, if the first clip of a spanned set is accurate. Just autosequence the first clips, then manually butt edit the remaining, then export. (I could fix the timestamps easily by adding a small option to my BWF toolbox, but I'm swamped in porting all my stuff to 64 bits.) Bouke
  4. Well sorry, don't mistake me for a sound guy, I don't know this gear. (I'm in post / development.)
  5. I take that as a typo... Easiest workaround, do NOT record poly. Then, for the few files this will be the case: Autosequence the whole shebang in Avid. Then ffwd and see if you have spanned clips, if so, export them from Avid as Wave. (Avid will make RF64 for you, keeping the timestamp.) Make sure the linking is then done on the new files. You could (if you are lazy) do an entire day to one clip after the autosequence, and have all video link to that single file. (I know a sound guy who starts rec in the morning, stops rec while walking back to the car.) hth, Bouke
  6. Hmm. That sucks. (I don't have 50fps clips here to test, send me one if you like.) However, my tool is able to: Scan your video files for normal TC and audio TC Then scan your BWF files Then calculate the offset between BWF timestamp / LTC value / normal TC value (for clips that match the video) Then set a new timestamp on the BWF files so they match the normal video TC. That 'should' do the trick, but I'm not sure how the app interprets your normal TC. (Frames could go up to 50 (up and including 49, or be double for two frames) Please switch to 50 FPS, see if you have a clip with a start TC with a frame number higher than 24. If so, send me that clip and I'll test it. (I do know that I've build in framerates > 30, but have not tested that many cams...) To send me clips, go here: https://videotoolshed.wetransfer.com/ To toy yourself: https://www.videotoolshed.com/product/ltc-convert-auxtc/ Bouke
  7. I ment switch the project rate to 25. Now, what exactly does not work?
  8. On Avid, you normally assign the LTC to AUX1 (And you sync / subclip whatever) based on that. If it does not work in 50 (Never tried), switch to 25, sync and switch back. Does that not work for you? Bouke
  9. Last time I've checked, television in Germany is 25i (Or P in an I container.) If you do this, does your cam slave to the incoming LTC? If so, you're home free. What software? If you have an LTC in on your cam, the TC in your clips will be metadata that can be read by any NLE. Why not? Syncing in Resolve and Avid can be done on normal TC, or audio (LTC) if you have put the LTC on an audio channel. This is pretty standard, RTFM. Now, since you have an Ultrasync, Timecode Systems also has similar software to the Tentacle software, but with way more options, and if you're a novice, more complicated. (I know, since I wrote that software...) So, what exactly are you doing, and what does not work?
  10. I know for a fact that 'some' game developers use the cheapest pieces of crap cams, so you might end up putting it onto an audio channel. This is a misconception. 23.976 is a bastard format, nothing 'regular', it was never intended to be used. (Of course that has changed.) It was intended to speed up to 24 for film, to 25 for Pal, or kept the same speed but with pulldown go to NTSC, thus making this the 'Universal' recording rate if one needed to have deliverables around the world. Games don't have to deal with this, and games like high frame rates. So it's probably going to be 29.97 or plain 30 FPS. It might even be 60, but then syncing to LTC will be a bit more problematic, since a normal generator can't do this. (In theory it's no problem at all to generate 60 fps LTC though.) ASK YOUR CLIENT! Not sure what generators can do 30, but I can :-) (As well as 59.94 / 60) I have no clue what a 'MoCap' cam would be. On a 'virtual set' (Chroma key with moving cams), a decent cam will be used. But for MoCap, anything goes, as it's just reference, and it could be a 200 buck consumer cam. So, again, ask your client what will be there. (And if it makes no sense, then report back.) Bouke
  11. 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
  12. 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.
  13. 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.
  14. 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?
  15. 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.
×
×
  • Create New...