Jump to content
JonG

Zaxcom ERX as Camera Hops - New Problem

Recommended Posts

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

 

Share this post


Link to post
Share on other sites
30 minutes ago, Bouke said:

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

 

Bourke, I think it's pretty simple. Arri had apparently set their incoming signal requirements higher than SMPTE, and apparently higher than anyone else's camera. Probably to an unneeded level. I don't think anyone needs sync more accurate than 1/20 of a frame, or whatever all the other cameras have. Someone can weigh in on that level of sync. 

Thank you, Martin

Share this post


Link to post
Share on other sites

Martin,
I think something else.

If you are at another level, no problems, let's agree to disagree.

 

Bouke

 

Share this post


Link to post
Share on other sites
47 minutes ago, Bouke said:

Martin,
I think something else.

If you are at another level, no problems, let's agree to disagree.

 

Bouke

 

Bouke, I think this is lost in translation. I don't even know what were not agreeing on. Sorry.

Thank you, Martin

Share this post


Link to post
Share on other sites

Thanks Bouke for your willingness to look into this at any level. i am sending you files right now and also wanted to share here. I have encountered several of these timecode situations and frankly it makes me nuts. These high dollar cameras seem to give us the most strugles - not just with timecode, but with audio connections too as we are all well aware. just had my first experience with a sony venice yesterday. still had that new camera smell. i was filled with anxieties prior to shoot 1) crazy 5 pin connector and 2) bnc tc yay but not entirely confident it would work properly until i had a chance to test in person. i built a custom 5 pin cable the day prior for my rx200. good news is everything worked perfect. they even had an a-box adapter but i elected to skip it just to avoid xlr's protruding out the side of the camera body. tc was perfect. audio was perfect. but WHY we have to deal with this stress so much on these high dollar cameras will always be a mystery to me. i relate to a lot of the points discussed here particularly the alexa mini. not all DP owner op's update firmware and i too am guilty. heck the old macbook air i am using to type this is running os 10.8.5. it is great that there is an update for the alexas but not so great for us when certain DP's choose not to update, which i understand the hesitation too for all the various reasonson up to no time to do it.  DP's and AC's who understand we are pro's and the tc we send is great despite warnings, i highly appreciate them. it's the DP's who look to me like i am somehow compromising the whole shoot because there is a flashing warning sign... so, as much as i love zaxcom tc when it works, sadly, i know i have to have multiple levels of tc from other manufacturers for every possible camera scenario and their relative firmware states. reds, alexas, sonys, atamos monitor recorders etc - not only do i have to have countless seemingly never ending connection options for audio signals, i must do the same for tc as well - despite well established industry timecode standards. i still carry a -10 padded red one cable in my kit. never touched. the moment i remove it from my kit someone will show up with a red one i just know it!

 

sorry had to get that out

 

here is what i sent to Bouke. by no means am i a scientist. and i have been told by someone once before my audio hygiene needs improvement (constantly workingon improving that) so my pics arent the greatest.  at least they detail my efforts. my wife is in market research so i am always fascinated and willing to participate. market research proves that market research works! in the end, i know this may not give us answers to what we are discussing but i feel there is something for me personally to learn in what Bouke is willing to examine. maybe it could be helpful to others here even in the slightest. Thank you Bouke for your suggestion to evaluate some files

 

6 files - bwf wavs with timecode stamps recorded for 5 min (probably overkill)

recorded on my sound devices 633 iso tracks as follows:

 

iso3-analog tc from 633 (even though files are stamped, just for the heck of it)
iso4-denecke sb2 jammed from 633
iso5-tentacle sync jammed from 633
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
iso7-zaxcom rx200 jammed from embedded timecode sent from 633->trx900CL->rx200->tc analog out to 633 input
iso8-zaxcom erx2 jammed from zaxnet 2.4gHz sent from 633->trx900CL->ERX2->tc analog out to 633 input

 

20190309_114239.jpg

20190309_114109.jpg

Share this post


Link to post
Share on other sites

I thought the erx tc issue with arri is the high jitter rate on all zaxcom timecode and the new arri firmware relaxed its criteria for stable timecode..?

Share this post


Link to post
Share on other sites
1 hour ago, r.paterson said:

I thought the erx tc issue with arri is the high jitter rate on all zaxcom timecode and the new arri firmware relaxed its criteria for stable timecode..?

R.patterson, Hi. I understand you are probaly referring to a technical description when you talk about the "jitter rate", but all I use is Zaxcom and I never get a call saying my files are not in sync. If it works on all the other cameras, then Arri is just being to picky, that's the word I'll use. If Jack is still single at 98 years old, I think Jack is being to picky about finding a wife. 

 

Thanks, Martin

Share this post


Link to post
Share on other sites
17 hours ago, osa said:

6 files - bwf wavs with timecode stamps recorded for 5 min (probably overkill)

recorded on my sound devices 633 iso tracks as follows:

 

iso3-analog tc from 633 (even though files are stamped, just for the heck of it)
iso4-denecke sb2 jammed from 633
iso5-tentacle sync jammed from 633
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
iso7-zaxcom rx200 jammed from embedded timecode sent from 633->trx900CL->rx200->tc analog out to 633 input
iso8-zaxcom erx2 jammed from zaxnet 2.4gHz sent from 633->trx900CL->ERX2->tc analog out to 633 input 

 

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:

image.png

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

 

 

Share this post


Link to post
Share on other sites
17 hours ago, r.paterson said:

I thought the erx tc issue with arri is the high jitter rate on all zaxcom timecode and the new arri firmware relaxed its criteria for stable timecode..?

Hi all, I talked to the DP this morning, DOP for the blokes out there, and we talked some more about him having TC  warning issues on the Alexa mini last week in Miami, he says it was definitely not a Zaxcom erx, he knows what they looked like, he described it as small like a cigarette lighter,  I am guessing tentacle sync? So anyway, here attached is a picture of the firmware version that is a problem.

 

Thank you, Martin

20190310_101636.jpg

Share this post


Link to post
Share on other sites

Bouke, great work on that!

 

Just a hypothetical (as I don't know if this is true or not) but since Zaxcom operate at 32khz for their audio converters, it would be easy to assume that their timecode circuits also work at 32khz and the mismatch and rounding errors that would happen from being decoded by a rate 1.5X faster (at 48K) you would see those additional half bit durations of 11 and 14 even if everything averages out in the end

Share this post


Link to post
Share on other sites

Hi Peter,

1 hour ago, Shastapete said:

Bouke, great work on that!

 

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

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Wow that is a lot of great info to digest thx bouke for sharing.

 

If i understand martin correctly it sounds like his dp had previous problems on arri fw 5.4x which was supposidly full of fixes for these tc woes and NOT w zaxcom devices attached. If you do a search outside jw there is a flood of tc problems with semmingly every device at one point or another incl direct tc from 633 jam issues. now I can't proclaim what firmware they were using and even if they had correctly troubleshot so who knows. I dont feel any more or less confident i just know i always have to have backup plans for backup plans

Share this post


Link to post
Share on other sites
5 hours ago, osa said:

Wow that is a lot of great info to digest thx bouke for sharing.

 

If i understand martin correctly it sounds like his dp had previous problems on arri fw 5.4x which was supposidly full of fixes for these tc woes and NOT w zaxcom devices attached. If you do a search outside jw there is a flood of tc problems with semmingly every device at one point or another incl direct tc from 633 jam issues. now I can't proclaim what firmware they were using and even if they had correctly troubleshot so who knows. I dont feel any more or less confident i just know i always have to have backup plans for backup plans

Osa, This question hit me later. If any brand, whatever brand, is not "good" enough for the Alexa Mini, does that mean, since it works fine on the Amira, that Arri decided sub par time code was acceptable for the Amira, but not acceptable for the Alexa Mini? I showed the D.P. a picture of the tentacle sync, and he said that was the one that was giving warning readings for him last week.

 

Thanks, Martin

Share this post


Link to post
Share on other sites
On 3/11/2019 at 2:28 AM, MartinTheMixer said:

does that mean, since it works fine on the Amira, that Arri decided sub par time code was acceptable for the Amira, but not acceptable for the Alexa Mini? I

 

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

Share this post


Link to post
Share on other sites
4 minutes ago, Bouke said:

 

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

Bouke, Hi. My take on all this. If Zaxcom time code is good enough for all the other camera's, then it should be good enough for all of Arri's cameras. Since the Tentacle sync, something I don't own,  also had problems on that same type camera, Alexa Mini, then it is a camera problem, and I am not a camera repair technician. I can't imagine what Arri could say to me that could possibly improve the my set life, or the set life of any mixer, as it pertains to Arri dysfunctional time code issues. I like those camera's. If I make a movie tomorrow,  I'm shooting it on an Arri. 

Thank you, Martin

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites
On 3/10/2019 at 6:35 AM, Bouke said:

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.

What? No. Why would you even say that?

 

 

The whole Arri/Zax problem is pretty simple. Zaxcom timecode is within SMPTE specs and can feed an Arri camera fine and provide adequate sync. However, firmware dependent, the camera will display an error message. This is because the camera also has a feature which allows you to tune the camera's internal clock to the incoming TC stream, similar to how genlock works. (Remember sync boxes that had TC and genlock?) This requires a much more stable clock than that specified by SMPTE. Since there is jitter in Zaxcom's TC, it is not stable enough for the camera to tune it's clock to. This is what produces the error message, ableit Arri worded the alert incorrectly.

Share this post


Link to post
Share on other sites
6 hours ago, Bouke said:

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?

 

 

2 hours ago, Patrick Farrell said:

What? No. Why would you even say that?

 

 

The whole Arri/Zax problem is pretty simple. Zaxcom timecode is within SMPTE specs and can feed an Arri camera fine and provide adequate sync. However, firmware dependent, the camera will display an error message. This is because the camera also has a feature which allows you to tune the camera's internal clock to the incoming TC stream, similar to how genlock works. (Remember sync boxes that had TC and genlock?) This requires a much more stable clock than that specified by SMPTE. Since there is jitter in Zaxcom's TC, it is not stable enough for the camera to tune it's clock to. This is what produces the error message, ableit Arri worded the alert incorrectly.

Hey guys, as for Bouke, I don't have a beef with that company, if they want to show goofy warnings for Zaxcom, and at least on that day, on that camera, goofy warnings for tentacle sync, who am I to say anything to them. If they were not aware, that would be a different matter.

As far as the D.P goes, the one time I have had this problem, he was the one telling me he was aware, and when he had the problem, it was tentacle sync, not Zaxcom. 

 

If I want to show him all is fine, he can look at the slate, which is in sync. 

 

As for Patrick, a shorter response, the tentacle sync showed the same problem, at least on that one day with that one camera with that one Tentacle sync box. 

Thanks guys, Martin

 

P.S. Bouke, thanks for all your time you took to provide us with all the info. M.W.

 

 

Share this post


Link to post
Share on other sites
2 hours ago, Patrick Farrell said:

What? No. Why would you even say that?

 

 

The whole Arri/Zax problem is pretty simple. Zaxcom timecode is within SMPTE specs and can feed an Arri camera fine and provide adequate sync. However, firmware dependent, the camera will display an error message. This is because the camera also has a feature which allows you to tune the camera's internal clock to the incoming TC stream, similar to how genlock works. (Remember sync boxes that had TC and genlock?) This requires a much more stable clock than that specified by SMPTE. Since there is jitter in Zaxcom's TC, it is not stable enough for the camera to tune it's clock to. This is what produces the error message, ableit Arri worded the alert incorrectly.

This

 

Share this post


Link to post
Share on other sites

At last year's NAB I sought out and spoke with a couple of ARRI Alexa-Mini engineers.  They said their cameras are designed and tested with Ambient time code generators and they never tested them with any others.  I suggested that it would be a really good idea to test their cameras with a variety of available time code boxes since that's how they'll be used in the field.  I don't know if they have acted on that advice.

 

They made the point that both the Amira and Mini use the same firmware and circuits.  I find that comment particularly interesting as I've not had any problems jamming to an Amira but have encountered issues with several Minis -- feeding them via time code devices from more than one manufacturer.  Sometimes they don't jam at all and one Mini took more than five minutes each time to accept a jam from a Denecke box.  The AC told me that was normal for this particular camera. 

 

What the ARRI engineers didn't mention was that, while the Amira has a standard sync input, the Mini derives its sync from the time code signal -- something the SMPTE spec was never designed for.

 

A person who should know, told me that the latest Mini firmware has alleviated the problems, but I haven't confirmed that myself.

Share this post


Link to post
Share on other sites
5 hours ago, Patrick Farrell said:
On 3/10/2019 at 11:35 AM, Bouke said:

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.

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?

 

5 hours ago, Patrick Farrell said:

Since there is jitter in Zaxcom's TC, it is not stable enough for the camera to tune it's clock to.

 

You did not really understood what I wrote, did you? Please re-read it, it's not hard.

 

Share this post


Link to post
Share on other sites
14 hours ago, Bouke said:

 

 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.

 

 

No frame values are dropped in either 24 fps or 23.976.  Both of them are NON DROP frame rates and are labeled accordingly.  The difference between them comes down to speed, not skipped frame numbers.  

Share this post


Link to post
Share on other sites
11 minutes ago, Wandering Ear said:

No frame values are dropped in either 24 fps or 23.976.

 

And I wrote:

14 hours ago, Bouke said:

24 drops exactly enough to stay in sync with the TOD.

 

How many frames are dropped? 0 (aka ZERO). And that makes it in sync with TOD.

Then:

14 hours ago, Bouke said:

23.976 on the other hand drops the same amount

 

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.

 

 

 

Share this post


Link to post
Share on other sites

I understand the concept, but 24 FPS staying in sync with the wall clock does not make it DROP FRAME.  DROP FRAME timecode drops the first two TC numbers every minute except in multiple of 10 minutes. 24 FPS stays in sync but does not skip any values.  That makes it NON DROP regardless of whether it stays in sync with the wall clock.  You state yourself that 0 frames are dropped at 24, so why do you insist on calling it DROP FRAME when nothing is DROPPED? 

I understand that you are a very knowledgeable person, I am not making a personal attack on you, but I do disagree with you on this point.

Share this post


Link to post
Share on other sites

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...)

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...