Jump to content

Bouke

Members
  • Posts

    364
  • Joined

  • Last visited

  • Days Won

    15

2 Followers

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

3,858 profile views
  1. 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.)
  2. 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.
  3. 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..)
  4. 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)
  5. 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?
  6. 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.)
  7. 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.)
  8. From hear say: https://apps.apple.com/us/app/protake-mobile-cinema-camera/id1498431506
  9. 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
  10. 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)
  11. afaik, third party recording apps are better than the one that comes with the phone.
  12. Ok, those were the days I probably worked on U-matic without any TC...
  13. 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
  14. 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.
  15. 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...
×
×
  • Create New...