Bouke

Disclaimer, I'm not a sound guy. But I do know (a little) about math and physics. A parabolic dish (with an omni in the focal point) would be my first option too. But for side, this will NOT do ANYTHING remotely related to the whole Side trick. Mind you, at small angles, sine equals tangent. (You might get away with a 'normal' local side mic, as the birds and insects at your location are probably the same as the ones next to the giraffe 300 meters from you.)

No clue what the 'lol' means. Over here, even on high end docs, there is no clap nor action. It's talking untill roll time. If there is dual system sound, there will be TC lock. Never seen a slate except on very amateur stuff where it was totally obsolete due to other mistakes. Lack of room tone, plenty though.

Hi Derek, Mind you, depending on metadata inside BWF, the filename might NOT be what the editor sees in his bin as 'clip name' I have no clue what a 'traditional' sound report is, as I have never seen one IRL (I did get some for my software development, but NEVER for my editorial work.) MS is another thing, it took me (back in the days) some education to understand it, (I still don't get how it is 'mono compatible' if the stereo part gets cancelled out, so RTW with phase correlation meters 'should' go off), but that is something someone 'should' be able to write a nice paper about, or make a 30 second video. (Longer is no longer allowed so it seems, I also produce content for the local university, and the most promising / bright smart kids don't seem to be able to concentrate more than that.) While I'm thinking of it, directors watch video. Do you all include scratch tracks on the cam? Does the director know that there might be more sound than there is picture?

As well as room tone, and please include a few words on paper / sound report / whatever on where to find what. (I've cut quite some docs, and no, I will NOT watch 60 hours of footage when I'm not getting paid for it, and the directors who view / log the material NEVER log ambience / room tone. While you're on set collecting room tone, how about telling EVERYONE to shut up for at least a whopping 4 seconds. (Trust me, I have done projects that took me an hour to find half a second of room tone to do decent dialogue cutting)

And Tarantino's take on it, (all takes, added a few (hundred) https://youtu.be/I2mzEW7ugTM?si=vq-u6IXE6Bpo4El_&t=1324

Found one: https://youtu.be/yqGBAH39ryo?si=4oeZzjqo1T0ggneu&t=120

What is unclear about that? Pic shows very well that it is Corona Era, and that vaccinations give superpowers to the arm getting the dose. Have you been living under a rock?

My bad, in my days I had wheels for close to anything, and most of it was bulky case like stuff.

How is that hard? You can buy handles at any hardware store / flightcase stuff site, and use rivets to get 'm on.

Yes, if you use it to generate new files, it will be subframe accurate, BUT ONLY as accurate as the sound track is synced, and as stated, YMMV. And, if you change the BWF timestamp to match the video TC, any half decent NLE will place it subframe accurate in synced clips / on a timeline. (BWF has no TC, but a sample count, thus can be positioned highly accurate.)

you are not missing something if you are a dslr shooter. But, 'proper' cams have genlock to overcome this issue. Then there is more math to be done. Transmitters introduce a delay. Even ProTools renders introduce a delay. (That could / should be counteracted....) Distance of mic causes a delay. Front speakers to ear (in a large theatre) can introduce a HUGE delay. Then, even the internal sound of DSLR's is often out of sync due to the cams being not made for pro video shooting. But there is one bright point (shameless self promotion follows.) If you record LTC on a sound track, and use my LTC convert software to alter the BWF timestamps to match the video TC, you are subframe accurate. (As BWF timestamps are in samples.) This of course is just as accurate as the internal sync of your DSLR.

Bullshit, 25P IS allowed in Europe. (I've send thousands of hours to European broadcasters, mind you, I work in Post, not in sound), but only in a 25I container! (What do you think, movies shot at 24 speeded up to 25 become 'interlaced' due to whatever magic?) An 'adapter' can be anything, but not a 'randomizer'. The 'random' part worries me, that makes no sense. (I can imagine an delay due to the complexity of the image, so the more complex, the more time the image takes to hit the output, but that 'should' be an easy test..)

What I dont quite get, I see audio TC's with frame numbers higher than 29 That is unsupported in LTC. So, to make that happen, the software has to calculate the found LTC to seconds and back to HH MM SS FF (I take it that's what Tentacle software does, my LTC convert certainly does this.) For that it needs the framerate of the LTC. That can be autodetected, but if that goes wrong (eg, it's very hard to distinuish 23.976 from 24), the math could be off. Are you sure the LTC is at a 'logical' rate? I would use 25 in your case. No clue why you shoot 50 unless you expect slomo on 'any' shot, or want to go to interlaced video. (shorter shutter time makes for less motion blur, more strobe like image)

Yes, don't repair a flat tire on your childs bike. Get as new one. So, you mean my income is 15.000 USD a month?

From memory, and AFAIK, PT export / render introduces a tiny bit of delay. (At least some time ago.) Could it be that the altered timestamp is to compensate for that? (That's easy to check, just import the exported file, sync on timestamp and see if there is an offset. If not, all is well.) For changing the timstamp, wave agent can do it (if it's not RF64), QTchange can do it also, and in batch / automated by using the 'save / load attributes' option. (It's not that difficult, since the files 'should' always start at a round second, so no need for adding / deducting a few samples, let the software do that math.)

Hi Ben, Not sure if that's a good idea, that would bake in metadata that could be wrong... (Setting initial levels might be a good idea and is very easy to implement.) However, I have never seen a file with fader info, so if you can provide me with one to study... That can be done already by patching, only at the moment it's not possible to omit a channel. (I will make that possible.) I'm not really looking at anything at the moment, but yes, the original request came from reality tv. (128 is a random number, with a few keystrokes it's 256 🙂 Adding video is an option I'll study, should be not too difficult. (It's using FFmpeg / FFplay under the hood.)

From hear say: https://apps.apple.com/us/app/protake-mobile-cinema-camera/id1498431506

Hi Ben, The project consisted of three parts: 'smarter' Offloading / rewrapping Zax transmitters Logging 'mute parts' (Private moments on reality shows where you don't want the talent to mute themselves) re-wrapping gazillions of recordings into one big BWF, including going over midnight. (RF64 of course), AKA 'auto sequence' The last two apps are 'nearly' done. The merge app can use the logged mute files and mute channels / recorders accordingly. For the merge app, still working on iXML, and some optical stuff, and awaiting more input. the merge app now can: Accept tons of BWF's, can be a mix of mono and poly, up to 128 channels Patch Display them in a timeline Play the whole shebang mixed (From a certain point if needed) Merge and export mono or poly ToDo is iXML (Bext chunk / timestamp IS implemented) GoTo functions for the timeline In-Out for partial export (if needed...) Sort on talent name for track ordering Save window positions on exit More based on user input My main problem now is, the client who originally requested it is not very responsive. An app like this cannot be too expensive, but will not sell that well either. And I've put quite some work in it to make it fast and versatile, but I'm not going to write yet another NLE... Nevertheless, here is the latest (untested) version: (Mac only, but I can make a Win version in a breeze.) BWFmergeBeta.dmg

QT change does exactly this, I've added this for Top Gear drone footage. (There is a youtube entry from the guy who requested it: https://www.youtube.com/watch?v=jgAP2165CMw) A sample is a frame in audio world. Movie formats also store TC as a frame number, but with more info on how to interpret it. (BWF can have the fps set, but most software lets you bypass that, video TC is more rigid in how it should be interpreted, but the essence is the same, TC is stored as 'frames after midnight' / frame number. (Where midnight is frame 0, while (at least SoundDevices) defines midnight as sample 1 instead of 0)

afaik, third party recording apps are better than the one that comes with the phone.

Ok, those were the days I probably worked on U-matic without any TC...

Yes, if you feed a 'normal' LTC signal trough audio routing. LTC is HIGH VOLTAGE, attenuation / low pass filtering and it cannot bleed more than normal cross talk, let alone that LTC is readable at -40 dB

I agree, it's a TTL signal. But, the Phil Reese site (Mentioned here before) gives info on a low pass filter to make it 'suitable' for audio tracks, taking off the sharp edges. (No one except me does that nowadays, but it's good practice.) No, it did not if you set it up correctly. Most of the time it is / was WAY TOO LOUD. Volume is not important for LTC, it's just 'on / off' for a specific period. The rounding error as mentioned only exists in digital systems, and is just a sample here and there, not really relevant for the system to work. You might want to read in on IRIG. This is Amplitude Modulation, sorta kinda you do, but it's a standard (set of standards). It's still used in aviation traffic control recordings, I have two clients using that for transcription work on communications when accidents / incidents have happened. They get 2 channel Wave files with the communication on left, Irig on right, I think to make sure no one can mess up the time stamps. (And no, it does not bleed.) Don't forget the housing / connectors, let alone marketing stuff... (Funny story, the outside sensor of my central heating broke. List price is euro 45,50. https://www.warmteservice.nl/Verwarming/Thermostaat/Buitenvoeler/Buitenvoeler-weersafhankelijke-regeling-voor-Mod-30-400/p/11850325?gclsrc=aw.ds&gclid=CjwKCAjw4P6oBhBsEiwAKYVkq6qGd6-BSr8UJhfZ8P8h2wPtLZhO_ZnMSPSKBs-5lHqilRxZozvPjBoCtKUQAvD_BwE This is a 30 cent plastic housing, a 5 cent terminal block, plus a 20 cent temperature resistor...) Then, I totally support the idea of a universal clock. Not just for syncing, TOD is always nice to have. Makes the life of editors way better. Not everyone is doing feature work... BUT, timecode is a meachanism to always be able to conform, so each frame MUST have a unique ID. Most of the time TC is written as a start frame number, with a framerate. (And that does NOT have to be the same as the video frame rate, but if it is not, it gets complicated.) To get a 'sorta kinda' UUID, add Reelname and Date (userbits). The rest is just stupid math.

Thank you. I was the one who forced Canon in giving the DSLR's 'real' timecode. (Well, just system clock emdedded as tc) Now, how can I quote from multiple posts here, I don't feel like making 20+ new ones...

ONLY if your TC is 23.976 or 29.97ND. Then you have a speed difference of 0.1 % meaning 3.6 seconds per hour. For 24, 25, 30, 50, 60 120 and drop frame rates there will be no noticeable difference. For time warping video, as mentioned a couple of times, that is VERY easy. A long take is close to never used in full, so it's very easy to cut out / slip a few frames when the angle is not used. An offset of 1 to 2 frames is often barely noticeable. (If you're in the back of a movie theater, the slow speed of sound makes that you're out of sync by 2 frames...) The main trouble is that it takes time, so a clap / flash at the end of the recording to check how many frames to add / loose would be handy.