[Ariane Fisher]

@Andreas, I found an interesting quirk in the calculations for one file – and managed to crash the script several times. I’m good at that. 🙂

One of the files is a NDF NTSC30 file from a 5D. It shows 00:00:14:08 duration in QT (on the desktop). When you move the slider to the end,the last frame is 00:00:14:07. The calculations in Sometimes used 14:07. Sometimes came up with the exact same answer as QT in the Mediainfo file. I understand mathematically how Sometimes came up with the answer it did. Is the discrepancy between 14:08 and 14:07 a result of the frame duration of the last frame? I can send you the file if you can tell me how to get it to you. I doubt uploading it to Cow would do any good as it will most likely get transcoded and we need to examine the 14 second, 252 MB file.

Part of me wonders if it matters, as long as QT knows what it’s referencing, and I understand the math, I should be able to reverse engineer it.

@Matt, is there some way I can connect with your offline to further discuss your workflow? I have a feeling that would be taking this thread in a completely new, interesting, and completely un-FCP like direction.

[Ariane Fisher]

Andreas, thank you so much. I downloaded the app but it’s crashing without opening. Here’s a screenshot of the problem report:

I must look like a real genius now. 🙂 If I upload a sample here, won’t it get transcoded? Can I be really 1990’s and email you a short clip? Oh wait, we didn’t even have that capability in the 90s.

[Ariane Fisher]

To my surprise, beer really did help. I was still slightly off on some calculations, but figured I’d post my results for your amusement:

Here are my calculations for duration:
Sample 1 is NTSC 24fps (23.976 fps). The clip was 00:00:46:12 seconds duration. Using the formula listed above:
((46*24)+12)*1000/23976=46.547 seconds
mediainfo read 46.549 seconds

sample 2 is NTSC 30fps (29.97). the clip was 00:00:27;11.
((27*30)+11)*100/2997=27.394
mediainfo got 27.413

sample 3 is NTSC 30fps (29.97). the clip was 00:00:33;21.
((33*30)+21)*100/2997=33.734
mediainfo got 27.749

sample 4 is NTSC 30fps (29.97). the clip was 00:00:14:08.
((14*30)+8)*100/2997=14.281
mediainfo got 14.250

sample 5 is NTSC FALSE 30fps, meaning 30 (however you wish me to say it). the clip was 00:00:10:04.
((10*30)+4)/30=10.133
mediainfo got 10.133

Needless to say I liked the last one the best. Samples 1, 4, and 5 are non-drop-frame; although I wouldn’t think that would affect duration calculation. Any thoughts on what could have caused my slight error?

[Ariane Fisher]

I would try it and see if your situation improves. I’ve heard that letting the software infer can sometimes lead to errors. I don’t generally use mpegstreamclip for those purposes, so I haven’t seen it there myself. I did read about something similar on the planet5D forums though.

[Ariane Fisher]

What? You guys can’t read my mind about the true 24 vs. NTSC thing? I knew what I meant. 🙂

Andreas, thank you so much for explaining the discrepancy in the results between desktop and online.

[Andreas Kiel] “In this case 1000 is the internal frame duration of this special example QT movie. The values used apply to any QT file created with FCP — except the frame number.
For 29.97 the frame duration will be 100 and timebase is 2997, for PAL and other non NTSC movies frame duration is always 100 and timebase is 100*FPS – with FCP QT movies.”

Would it be possible for you to elaborate on this? I’ve never heard the term “internal frame duration”. At a quick glance, it seems that this is a factor used to reconcile the 23.976 vs. 30 math. So, you’re using 1000 to get the 23.976 into an integer. With 29.97, you use 100 to make it an integer. If the media is true 24 or 30, no multiplier would be needed, as it’s already an integer. The discrepancy between desktop and online versions appears because they are not including the factor of 1/1.001, but simply truncating the result to 23.976. Did I summarize this correctly?

I will perform extensive calculations and testing of our online media over the next few days, so If you don’t hear from me, I either figured it out for all the crazy iterations for which I need it OR my brain exploded from overuse of algebra, division, or whatever operations these are.

By the way, I can’t thank you guys enough. Please let me know, if/when you’re ever in Chicago. I owe you all several beers. We can then discuss imaginary numbers, pi, and logarithmic functions in proper fashion.

[Ariane Fisher]

Try on eBay. You might be able to get a student version of FCS2, which I wouldn’t ordinarily recommend, but in your case it makes sense.

[Ariane Fisher]

Ok, Rafael. You win. Hyperbole always gets me in the end. 🙂

[Ariane Fisher]

Doug, first of all, I’m female, although do still enjoy a hearty oatmeal stout. 🙂

Second of all, I completely and wholeheartedly, agree: measurement in milliseconds is a Quicktime contrivance. It doesn’t exist anywhere within FCP nor the real world. It does, however, exist in the mediainfo file of uploaded Quicktime files. For whatever reason, Quicktime defaults to measurement in ms, not frames. I need to manipulate this data with java script, which does need frames. Well, actually java can handle ms, but I need frames back out. Now that I know the math behind the conversion factor, I think I’m good. Although that may be a premature assumption. I still need to calculate all this in cases of DF as well. But at least now I know where to find the information. Thanks again.

[Ariane Fisher]

Holy crap on a stick, Keith! You did it! Excuse my phraseology and extreme beer consumption! That’s all I was looking for. I knew it was simple. Thank you!!!! That is extremely handy as well, because I quickly realized that i had let my developer membership lapse and didn’t feel like paying $99 for a simple question. Any idea why the mediainfo QT metadata would show 20.288 rather than 20.27? Or am I pushing my luck? You saved me soooo much reading through the copious pages of developers manuals I downloaded tonight. I’ll probably read them anyway though.

I’ll let you know if I get the audio sync issue sorted as well. That should be worth a few virtual beers.

[Ariane Fisher]

I could be wrong, but I believe mpegstreamclip defaults to 23.98, instead of 23.976 as the frame rate. This causes sync issues. If you manually type in the frame rate, this issue will correct itself.