Jump to content

Bouke

Members
  • Content Count

    101
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Bouke

  1. Marianna is the Avid Customer Advocate. I've altered my original post
  2. Contact Marianna if in doubt. marianna.montague@yahoo.com
  3. I'm totally supporting Constantin here. This is what YOU say, but there is NOTHING that can backup your story. IOW, it's irrelevant.
  4. 'Sync' vs 'TC jam' (since we seem to be doing bashing more than developing new ideas..)
  5. Well, I totally agree on the misleading name. But, this is about flipping one BIT (!), indicating frame length * frame rate equals one second or not. (And for the sake of the argument, I used drop/non drop to indicate just that.)
  6. So, no need to get involved. I'll read up when I have time.
  7. You are forgetting one thing: It was about making clear if a TC stream is 23.976 or 24. Measuring duration takes time to be sure. If you read the DF / NDF bit (that is in every frame), that could be a dead giveaway of what it 'should' be. (thus, instead of looking for frame duration with a 0.1% difference.) Next, if DF keeps the TC 'as good as possible' in sync with the time on the wall, thus 24, 25 and 30 also should/could be called DF. (drop nothing if not needed.) Now, please open Wave Agent (still in beta), and see that they have both 30 DF and NDF. (That makes no sense to me...)
  8. And I wrote: How many frames are dropped? 0 (aka ZERO). And that makes it in sync with TOD. Then: So, also ZERO frames dropped, but OUT of sync. (With the 'time on the wall') Hence, 24 can be seen as DF, while 23.976 can be seen as NDF. Now, I KNOW what I'm talking about. (the whole idea of a cam slaving to LTC was suggested by ME to Ambient BEFORE Arri introduced it.) Please, grasp the concept, then react.
  9. 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.
  10. 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?
  11. Martin, Did you consider asking this at Arri? If so, what did they answer? If not, why not?
  12. 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
  13. 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
  14. Martin, I think something else. If you are at another level, no problems, let's agree to disagree. Bouke
  15. 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
  16. 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
  17. 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
  18. 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.
  19. 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.
  20. 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.
  21. 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.)
  22. 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
  23. 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 :-)
  24. 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.
  25. yes :-) (and no, but I'm still using Director, that can do more than you think.)
×
×
  • Create New...