Bouke
Members-
Posts
364 -
Joined
-
Last visited
-
Days Won
15
Content Type
Forums
Gallery
Store
Everything posted by Bouke
-
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.
-
Sony FX3 with timecode-cable: delay of 2-3 frames
Bouke replied to Sound's topic in Cameras... love them, hate them
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..) -
Sony FX3 with timecode-cable: delay of 2-3 frames
Bouke replied to Sound's topic in Cameras... love them, hate them
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.
-
Please, don't make this kind of stupid remarks
-
Well, I did some research years ago. A GPS receiver is dirt cheap, and coding for it is incredibly easy. (Just connect to it, and data comes in in human readable form.) But, the clocks from satellites do NOT run at the wall time on earth. They have an offset, that is increased every such time (I forgot...) So, to get the real time, you need to know the offset. But that is only broadcasted every hour or so. Then, it might take a long time for the unit to find a satellite, that is not nice for run & gun work.
-
Working on a set of tools: Tool to merge BWF files into one long poly or mono file. Tool to log mute moments Tool to extremely fast offload Zaxcom MARF cards (Copy only the 'new' data, instead of the full card.) the Merge tool does something like 'autosequence', but with patch. The mute tool is a simple util that works with the merge tool, it will mute specific moments of specific tracks in the timeline I could use some input on how to improve it. Background: Client is shooting real life soap (or alike) with a gazillion of Zaxcom transmitters that also record. They want to use the data from the transmitter rather than the wireless (RF faults etc.) And he does not want 'private' moments to go to Post, nor does he wants talent to mute their transmitters. If you like, toy with the stuff below. (And give feedback, either here or in PM) Test set.zip BWFmergeBeta.dmg MuteLogger.dmg Test set.zip
-
Here is proof of concept: ZaxTrimBeta.dmg This is Mac only for now, but I can make it Win also. (And Unix, but that will take a bit longer...) It wil copy MARF / Zax 'trimmed', so as small as needed. ZaxConvert 'should' still be able to work on the smaller / trimmed files. Fair warning, it WILL overwrite existing files, so choose your output wisely!
-
(my guess is that the Zax stuff is not so sophisticated, it just allocates space so no other app can interferere with it, Nothing wrong with that, but easy to parse. What I've done is not even remotely hacking, it's just extracting data, to feed ZaxConvert to it's expectations (for as far as I know, I just have one channel on one clip of one recorder, but I bet a box of beer this will work in any case.))
-
Nope, I'm on a fairly old Intel I5... But, for the stuff I do and the support I can give given the money, I don't want to have too much hassle... For the trimmed stuff, see the attachment. No clue what metadata there is to loose, as there is hardly any. (And I think the metadata is not in the .zax files, but in the .zzz file.) LAV__YEL.zip This should unzip to just a small .zax file, and a .zzz file, that 'should' work fine in ZaxConvert, give you the same as the 4 gigs you've posted..
-
Definitely something like that. I took your sample file, deleted the empty .zax files, trimmed the non empty (removing all trailing zeros), and ended up with a 344 KB file, that was still fully functional. This 344 KB became 2,4 MB when converted to BWF. That's 7 times bigger. So 'some' data compression is applied... (No clue if it's destructive or not, but I don't care, as long as it sounds good : -) But, this knowledge makes that I could create something that could backup cards fast, and save storage. (But that's only good as backup 'in case of emergency', as the MARF stuff can't be played / used. However, ZaxConvert is able to create BWF's if needed.) I don't think it will be significant faster than using the ZaxConvert, unless you offload to a very slow disk. (I guess the disk to oflload to is WAY faster than the cards.) I'm not going to pursue the Wine option, too much hassle. (I get a 'wrong CPU type' error.) More later.
-
No clue how to accomplish that. Wine / WineBottler chokes on it. Yes, that won't be hard to make. No clue, the interface comes back with the settings as I've left them... Those are simple CSV files, not hard to work on from Python, but I have no clue who uses them for what. (I'm a coder, used to be an editor, but never had to work with sound reports...) But, can we motivate Zaxcom to update the CLI version, and port it to Mac? (64 bits of course...)
-
Thanks. (Zipping zeros is always fun : - ) Looks simple enough, but yes, no fun reverse engineering. And no 'real' need, ZaxConvert GUI accepts multiple inputs, cards need to be offloaded anyways for backup. The command line util is simple enough for me to write an gui, but why would it be better than the Zac gui itself? It cannot send data to StdOut or alike for me to process further... So what's there to automate further? And, it's Win only, while I think most people here are on Mac.