Bouke

What? No. Why would you even say that? Because it is true? DF is designed to make the TC drop frames in order to stay in sync with the TOD. 24 drops exactly enough to stay in sync with the TOD. 23.976 on the other hand drops the same amount, but does NOT stay in sync, making it a NDF format. Now, there is a bit in LTC that says drop/non-drop, why not use that to make a difference between 23.976 and 24? You did not really understood what I wrote, did you? Please re-read it, it's not hard.

You're missing the point. If you have a beef with a company, why not ask them for explanation? There are people working there... If it's a firmware thing, and they admit 'some' firmware had a probem, would you not like to have a copy of that mail in your pocket to show the DP that it is HIS problem, not YOURS?

Martin, Did you consider asking this at Arri? If so, what did they answer? If not, why not?

Hi Peter, Thanks! But, do NOT mistake me for someone who knows what he's talking about! I do NOT. I have (mostly) no clue about the equipment used, and if the devices / hardware were designed to send 'nice sounding' bytes, or 'as it is' bytes. What I did was just analyze what was there, and comment a bit on if it was 'good enough for rock 'n roll'. This is the part were you all (sound engineers) get in, to get to the bottom. What I've tried to do is give you some ammo for the manufacturers / DOP's Now, I'm a hacker, and I do not only hack data, I also hack people's / group minds: @ 13 febr 2017 08 AM I've overheard at Arri's HQ : ----- "Welcome to zis ARRI breakfazt zoftware developentz group meeting. Doez everyone haz a glaz of vine? Letz ztart. Who wantz to work on the new LogC codecz that will be utterly hip and fazhinobly? Please raize your hand. Neckzt, Who wantz zo work on ze 50 yearz old ZMPTE zechnologzy?" ---- Do the math! (ok, the breakfast meeting joke was not mine, bonus if you know where it came from.) Now, even with this in consideration, I find it totally understandable that a company like ARRI sets it's own params, Read, 'I find input not up to my standards, I will NOT be associated with this, as I have a reputation to maintain.' (Thus, use a Lockit or UltraSync, THEN bitch.) Summary: I'm not the one to say what is right or wrong, but I have given (a bit of) info for you all to reach out to the companies involved if you think you have a point. Bouke

What I did: I tested ONE SECOND (Sorry about the five minutes) of each file. On that second two analyzes were done: Counting bit / half bit durations, and how often each duration occurred. Thus, see how long each (half) bit duration is. Those should always be the same. Next test was to see how long an entire LTC frame was. That 'should' always be the same. Look at the image, it's a few bits from the TC stream: A bit is either short-short or long, where positive or negative makes no difference. One long one means 0, two short ones together means 1 So, you see (from left to right) half a bit, (that is probably a 1), then 0 0 1 0 0 0 I did NOT make a difference if two half bits were adjacent or not, since I don't know how the cams decode it / when they bitch, but read on, we'll get to that point. Do the math with me (it's not hard): Framerate was 23.976, recorded at 48Khz. So, a frame is 48000 / 23.976 = 2002.002 samples. Now, since samples is always a round number, the AVERAGE frame duration is 2002.002, so in practice almost all frames are 2002, and 1/500 of the frames is 2003 samples long. For the actual bit duration, that means dividing it by 80 (There are 80 bits in a LTC frame. 48000 / 23.976 / 80 = 25,02502502502503 samples for one bit. So, if a bit is one, it is low / high for 12 or 13 samples. By now you should realize that the numbers WILL vary a bit, but summed they must match. Next test is to see how long each TC frame is. (Thus, a group of 80 bits together forming one frame.) Also here, they WILL be more or less the same, but sometimes a sample longer or shorter is very normal to stay in sync. And here are the results: so3-analog tc from 633 (even though files are stamped, just for the heck of it) -- [12 465, 13 516, 25 1560, 26 26] This is a list with what kind of durations are found first number is (half) bit duration, second number is how often it occurred. -- [2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002] A (sorted) list of the duration of the found LTC frame So, this is absolute perfection! iso4-denecke sb2 jammed from 633 --[12 468, 13 520, 25 1556, 26 26] -- [2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002] again, perfect! iso5-tentacle sync jammed from 633 -- [12 819, 13 837, 25 1205, 26 43] -- [2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002] The cheapest thingy around, but I cannot say that there is ANYTHING WRONG with it. iso6-zaxcom qrx100q jammed from embedded timecode sent from 633->trx900CL->trxLA3->qrx100q set to receive tc from trx->tc analog out to 633 input -- [12 650, 13 167, 14 163, 24 498, 25 542, 26 546] -- [2001, 2001, 2001, 2001, 2001, 2001, 2001, 2001, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2003, 2003, 2003, 2003, 2003, 2003, 2003, 2003] As you can see, the bit duration drift around one sample more than 'could' have been achieved, and in the second list, not all frames have the same duration. But on total, they average out just fine, so, perhaps not utterly correct, no-one should bitch about this. iso7-zaxcom rx200 jammed from embedded timecode sent from 633->trx900CL->rx200->tc analog out to 633 input -- [11 140, 12 386, 13 278, 14 177, 23 80, 24 350, 25 595, 26 561] -- [2001, 2001, 2001, 2001, 2001, 2001, 2001, 2001, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2003, 2003, 2003, 2003, 2003, 2003, 2003, 2003] It gets worse. Here the bits jitter a bit. Finding 4 values is expected, as you have learned that (half) a bit cannot always be the same value. But here we find 8 different durations, where 4 should be expected. Half a bit is 12.5 samples, so 12 and 13 are good. But we also find 11 and 14 (23 and 26 for Zero's) BUT, if you look at the frame durations, they are only off by 1 sample. That is NOT MUCH. This 'could' be an issue if the TC reader is coded utterly correct. More on that later (If you even made it to here :-) NOTE, the lists with frame duration is SORTED, NOT in the way the durations occurred! iso8-zaxcom erx2 jammed from zaxnet 2.4gHz sent from 633->trx900CL->ERX2->tc analog out to 633 input -- [12 483, 13 495, 14 2, 24 70, 25 1405, 26 112] -- [2001, 2001, 2001, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2002, 2003, 2003] I leave it up to you to draw your own conclusions here. So, iso7-zaxcom rx200 jammed from embedded timecode sent from 633->trx900CL->rx200->tc analog out to 633 input is the worst from the set. Were 'worst' is UTTERLY OVERSTATED How long does it take for a cam to slave to incoming TC? Let's say half a second. Why? A 'decent' coded TC reader does NOT slave on one frame, as there could be a glitch. It waits untill it has seen a couple of frames, try to find 'logic' (eg, if 4 out of 5 are 'as expected', those are right and not the stray value.) Then, while it's at it, it looks at the average frame duration of each found frame. Now, for half a second, that are 24000 samples. (If the TC input AD runs at 48K, that I don't know, could be more, could be way less.) For the sake of the argument, if it runs at a lower sample rate, just double the time it takes to 'lock' Assuming that 30 FPS does not exist in our world, the most difficult to detect is between 23.976 and 24. The speed difference is 0.1 %. Thus, 48000 / 23.976 = 2002.002 samples per frame, times 12 makes 24024 samples 48000 / 24 = 2000.000 samples per frame, times 12 makes 24000 So, if sum of 12 frame durations < 24012, it's 24, otherwise it's 23.976 Even worst case, the 'bad' Zax actually HAD the frame durations in the order as shown (what was NOT the case), that would have summed up to 24016. Room to spare. For the freaks: (Read, @Klaus) It would make a nice feature to flag 24 as DROP, what it in fact is, and 23.976 as NON DROP, what it in fact is. Now for the ARRI / firmware / what goes wrong. I have no clue how it is coded, but as you can see for yourself, it is NOT hard to do it 'proper', and yes, there is a tiny bit of jitter, but the whole concept of LTC was build around making it as robust as possible on dirt cheap analogue small tracks, being able to decode at extreme speeds in analogue cirquits (where a sample rate of 192K still would not cut it), so a coder 'should' build in some fail saves, and that is very, very easy. Bouke

Martin, I think something else. If you are at another level, no problems, let's agree to disagree. Bouke

So, is there a question in here that I've missed? I totally don't get this. This is not rocket science. Either there is a HUGE mismatch between the two clocks, or something else VERY stupid is going on. Somewhere in the conversation was something about the Arri could set it's own clock to the incoming TC. That looks plain brilliant to me. (Actually, I've suggest something like this with Ambient a couple of years ago, not sure what hardware is inside the cams...) If the function is there, USE IT! (Even if it takes half an hour.) That should take care of all the problems, or either one company is to blame for fucking up. I've already offered help to analyze, but you did not use that. What exactly do you expect? Sorry to sound harsh, but if you're a pro, get to the bottom of it. Bouke

Since I'm a TC freak / nerd, I can check the Zaxcom TC if you like. Just feed your TC out to a line input, and record a couple of seconds. For my fun and research, set (if available) a pre roll. You can send the file using this: click here to upload Bouke

Trying to figure something out: I have 23.976 material with LTC recorded as sound, and a BWF from a MixPre 6 that has outputted the LTC. (Also set to 23.976, although the LTC 'seems' 24, but I take it that has to do with a bad clock of the cam.) Now, there is an offset of 28 frames between the LTC and BWF. (And by a sick joke of the TC gods the video is named '00028.mov'.) On duckducking, I've found myself and remembered I had this before, and it could be due to setting 'preroll' in the recorder. (Meaning, start recording X seconds before hitting the record button.) But that was a 'very' long time ago. Is this still a bug / featurette? (In case of the latter I would like to know in what circumstances this actually helpful.) thx, Bouke

A very quick Duck duck revealed page 26 of the manual of the Mix Pre, where it shows that you can configure the AUX input as a TC input.

Sorry, but Tourtelots statement makes no sense from an IT point of view. track names are a small part of the metadata. Metadata is a part of the file just as well as the sound data. But, all metadata is (at best, unless you have a Cantar) some 6000 bytes. Now, recording at 48Khz 24 bits, this is about (6000 / 48000 * 3 ) some 0.04 seconds of a (mono) signal. Just ONE wrong byte (at the wrong point) can make a file corrupt. Just ONE missing byte can make a file corrupt. So, it's either all or nothing.

Huh? TWO? If I'm up and running I'm lucky to have just ONE (every week). Get into welding school, better hours, better rates, better for your relation.

How are the file sizes, as expected? If not, it's back to the drawing board. If so, can you send me one? click here to upload (Don't hold your breath, if there are two seconds good, and then it becomes noise, at least one byte is missing or too much. Probably way more...) You can toy yourself with Audacity, with the 'import raw' option, and toy with the params. You probably then get 'other' parts good. But again, I'm afraid you are going to need 'better' tools, and if you have to go to a specialized company, bring very deep pockets. Then, to bitch: How come you format these drives? You have multiple, and I would say, get 500 gig drives and only format after the movie is released, still room to spare. (SSD is dirt cheap nowadays.)

If you can live with HQ downsampling and stripping the BEXT / iXML metadata, Sox can do this just as well. I've made a simple Automator app that does this. (Assuming you have Sox in your Applications folder.) Get Sox here: download SOX Then, unzip and place Sox into your applications folder. get the downconvert app here Unzip, place the app 'somewhere', and drop Wave files on it. The params as set are good for downconverting, but the app. will eat anything .wav and make it 48K (Oh, it's free, my work was just a few lines to automate, the real work is done by the nice people who make Sox.) hth, Bouke

It seems more like a clocking issue to AES sync. Meaning, the recorder did not slave its rate to the incoming signal. If that is the case, there is also a AD conversion done before the mix, that also slaves wrong, otherwise your analogue input should be clean. (Makes sense not to do the AD conversion and re-clock it for mixing.) But then you should also hear small artifacts besides the obvious (asymmetric) peaks. Having said this, this is pure a hunch. Now, my SD PIX recorder recently also had issues with recording, and those seem magically fixed by doing a firmware restore. (Not sure if that is in the menu of your recorder, but I think it can't do you any harm to update the firmware.) Oh, you might want to learn how to make a screenshot with your OS instead of your phone :-)

21 years later, it is still my weapon of choice. If it dies, I'll probably die with it, but that is total different discussion, not suitable for here.

yes :-) (and no, but I'm still using Director, that can do more than you think.)

Eeh dude! Hickory of course! (Unfinished, or if you must, Tung oil, diluted with turpentine, never with termpentine!) Geez, I thought the Pro's hung out here! Jokes aside, I do totally agree that making an appearance is important, and having the right gear sure helps in being taken seriously. That was one of the reasons (long time ago) I bought a digibeta A500. Renting when needed was definitely cheaper, but owning it made me 'the man'.

Hear hear. I once had the pleasure to sit in a Q&A with Robby Müller. (If you don't know him, look him up,) Question from the audience: "Mr. Müller, on movie X you used stock Y, why did you make that decision?" - Well, that was what the producers wife had found on leftovers under her bed. "Mr. Müller, why did you use cam X with lens Y on movie Z?" -That was what was on the set when I arrived. It's not that I was consulted... Being able to work with what was available (Including the headlights of a car when noting else available) made him one of the greatest.

Hi Vincent, IIRC, those files have a BWF timestamp, but all set to 0. (Btw, why is SD using sample 1 as 'since midnight', as the beginning should be 0 IMHO?) Should make for nice testing material. I would if i could, but my coding environment does not let me do this. I have to write my own interface. (Meaning, the button I use has 135 lines of code just to make them behave the way they do, and that is just to call an action. It sucks, but it is the way it is.) So I also cut corners, especially if it is in projects like this (That will earn me close to nothing, I expect to sell 10 copies over the next years.) The pulldowns are an example, those are easy to code since I have third party code to generate them for me. Trust me, 80 % of the work is in the interface / making it 'look' logical. Nevertheless: I don't care. Like PT is 'easy to understand'. My work is not for beginners. I totally agree that an interface should be as easy as possible, but trust me, it is very hard to make it so. Every user wants something else, and every user wants it simple. I have made stuff where an end user could set the entire interface to it's liking, but then it's 'too complicated'. (I can rant about this problem all day.) So I try to give my apps a name that describes what it does, and give buttons a name that describe what they do. Then I try to follow other conventions. (Like JKL, but then I add the 'U' key for 'play a bit', that was stolen from M100, where it was the arrow up key. That one is not to be found on laptops, and the 'U' key is at a logical place for right handed people when they use the function in a normal fashion.) Now, the original question was simple and logical. Set timestamp from recording time as BWF timestamp, as the stupid recorder does not do that itself. Made totally sense and was easy. Except that setting an offset was also logical, as setting the clock from the recorder right does not happen always. and, while I'm at it, offloading cards, as that had to be done always, why use two apps if it can be done in one? and, while I'm at it, why not add metadata like Track names? and, while I'm at adding metadata, why not add the whole shebang, since it is possible and easy? and, since the device WILL run at another speed, and (as Constantin wisely noted), the darn things will run the whole day, why not build something in to compensate for that? Then it needs to be as versatile as possible, and all recorders have different ways of file naming / storing in folders / record mono, poly or combos. Of course it needs to be able to run batches, where all clips get the same treatment. Except those who need another... (Orwell comes to mind :-) So now we have something that once was very simple, but became quite complicated very fast, all due to 'logic'. Get the point? (Like if there are two standards. Someone says, 'that's impractical, let's make something that is universal'. Then we have three standards.) You are all very lucky with the acquisition Wave 'standard' (That isn't as simple as you think, having mono/poly, the lack of acceptation of RF64 makes it ancient/outdated, let alone the lack of fader info.) ok, /rant When you all say it is ready for rock 'n roll, and I come up with a fair price. Oh, to make it worse, a few months ago I was ranting about clapperboards being obsolete, now I've found myself writing code to find a clap in a sound file, because it was the 'logical' thing to do... I really must find a Vulcan monastery...

I don't know about 'standard', but 'discrete' and 'mono' is just metadata in QT, and that is all soon to be obsolete. (In fact, it already is.) Also pan info is. Your bytes will be exactly the same no matter the settings. I would worry more about tracks vs channels. Same as Mono / Poly in the sound world, a QT sound track can be mono or poly. And there can be combo's. (Same as Zoom uses multiple 2 track files to create a 4 track.) You probably want 8 mono (single channel) tracks instead of one 8 channel track. The term 'mono' is stupid. It refers to 1 channel. But two mono tracks panned LR obiously does NOT mean 'mono' :-) (The whole naming thing is a bit of a mess...) So, either discrete or mono will probably be good, and if they don't give you specs, it's their problem. The data is there...

Thank you! But, did you already had any hands-on experience with it? (The proof is in the pudding, and I did a lot of toying around of course, but I work under lab circumstances.) I do like the drift compensation, but I'm still not sure how that is going to work out in the real world. (It will work for sure on the clip you set it, but will the drift percentage be app. the same on other days?)

Ok, the app is public now. You can find it here It does all that is promised, and a bit more. Aimed at you having to do as little work as possible, but I can imagine it will be a HUGE timesaver in post. Now, I've done my best (to my horror I now see i've been working a month on it.) to accommodate all needs, but I'm an editor and coder, not a sound guy. So, there probably are more improvements to make. Don't by shy with comments! Oh, fair warning: If you run the demo: Offloading will do no harm to your files. Altering the metadata / setting timestamps WILL! (It will add 2 seconds of silence every 25 seconds.)

This has been done before. (Mostly on music video clips.) You can use AUX tc (record the LTC on a spare track.) This is a great way to have multiple angles fall in place by itself, no need to do the entire track for just a 2 second shot. Do allow for enough preroll to give the talent time to get up to pace / in the rythm.) If you have direct out, why not generate an LTC stream and speed it up as well? (Without pitch correction, as you probably do on the sound track!) LTC was designed to be readable at very high speeds (while searching tape). At 48Khz, a 23.976 bit is about 25 samples. (48000 / 23.976 / 80 (there are 80 bits in one frame). Now, a bit needs two samples at least, so in theory you could speed it up 12 times. If you can't generate LTC yourself and you don't want to record it, get my LTCconvert demo, it comes with 10 minutes of LTC in all framerates. https://www.videotoolshed.com/product/ltc-convert-auxtc/ If you need a lot / custom start / duration, you can use my LTC generator. https://www.videotoolshed.com/product/ltc-generator/ (This thing will generate 24 hours of LTC as BWF within minutes.) I could customize it to run other speeds, but if you're handy with a HEX editor, you can easily alter the sample rate to 96000 so it runs twice as fast. Goes for the prefab files as well of course. The only tricky part is that you have to tell post to slow down the sound as well, without pitch correction, and actually use the AUX. Bouke

Hi Constantin, Please elaborate on the file names. Metadata can hold a name as well, not sure who uses that. (I personally hate it when a filename in my bin does not match the filename on disk on most scenarios)