There appears to be an issue whereby EDL Manager 23.8.0 on MC 2.8.0 miscalculates the lengths of dissolves in the EDL.
See http://community.avid.com/forums/p/58628/328515.aspx#328515 for the original posting. I tried to reproduce on my Mac laptop, and had the same experience. 48fr dissolve in a 24p PAL project becomes a 50fr dissolve in the CMX3600 or CMX 340 EDL.
Haven't been able to check on my MC 2.7.5 or SN 1.8.3.
I feel this issue is in need of speedy escalation, though.
Remember in a SD project that START is a PAL 25fps format so the EDL reflects that. Has this ever worked any other way? In NTSC, 24fps becomes 30 to match 1 second based on the video format. If you want true 24fps counts you should use TC 24....
Michael
Hi Michael,
That was my initial thought. However, a PAL EDL is meant to be a frame-by-frame match, not a time=time match. And therefore a 48-frame transition should last 48 frames, no matter the playback speed of those frames. Unlike in NTSC, the EDL is counting time differently, but counting frames should happen identically. I cannnot think of a reason to prolong the length of a transition when the speed of both Source and Record is actually ifaster, right?
I'm pretty convinced this used to work correctly, but I cannot easily determine at this point in time. I've checked the one previous project (from SN 1.7.3 or 1.7.5) that is on my laptop here, and noticed that the same discrepancy is there between the sequence and the EDL, so probably the conform is off for those transitions (film is released, didn't notice these small differences in the conform check). Can do some research over the weekend to find older projects and EDLs from different software revisions.
*edit* tried some different transitions. Anything under 24frs stays correct, everything above gets translated.
*edit* found at least one old 24p PAL project (Meridien v12) containing a 24fr dissolve that shows up in the EDL as a 24fr dissolve, not a 25 one.
Even more serious: if I create a 48fr transition in a PAL 24p project, and choose Output-EDL and do a Get Current Sequence, the transition comes up as 60frs!!!. Until you change any parameter an update again, then it goes back to 50frs (also wrong AFAIK).
I've checked on a 25p project ; same issue.All lengths are good, but dissolve's durations are not the same if I compare an EDL made by MC 2.7.0 and the same EDL made by the "old" EDL Manager 21.5.1. (Both with CMX 3600, PAL 25). Dissolve's durations are obviously wrong in latest version of EDL Manager.(See attached .jpg)There is a contradiction beetween source's durations (which are corrects) and dissolve's durations. How can a dissolve applied on a 00:00:01:23 duration can be a 57 frames dissolve ?!...I'm curious to know how conforming machines interpret this inconsistency...Regards,Thaddée
Thanks for checking, Thaddée.
I'm curious to know how conforming machines interpret this inconsistency...
Same here.
How can a dissolve applied on a 00:00:01:23 duration can be a 57 frames dissolve ?!...
My guess is that "almost two seconds" becomes "almost 60 frames", like in NTSC. See my earlier remarks in bold. Can you try and see what happens if you change some paramters in the option window and choose Update? In my experience a 48fr dissolve from a 24p PAL project became a 60fr dissolve in the EDL the first time I bring it into EDL Manager, but reverts to 50fr (still wrong), after switching options back and forth and updating the EDL. I fear something is seriously wrong here.
Can you try and see what happens if you change some paramters in the option window and choose Update?
I can't check with a recent EDL Manager at home ; I only have 21.1.5 on my laptop. But I've made a quick test on a SD 24p PAL project created on MCA 2.6.7.
I've got a sequence with a 76 frames dissolve (I've checked the duration on the cut list). It gives with EDL M. 21.1.5 (CMX 3600) :
In this version, fx durations are the same in both output ; TC 25 or 24.
Thanks, let's hope that this will be worked out & resolved soon.
I have sent the thread into engineering test.
On behalf of Virginie Seguin, the top french edit assistant, who first observed this error, I would just like to thank you all for this thread. She is very excited that she found a real 'bug' (these simple things still keep some of us happy). We both look forward to a new version. We only use the edl manager for sending reports to SFX houses, so the issue is not a problem but it seems strange that this sort of error appears in an app that has not fundamentally changed in years. It proves that Avid do change even the little apps.
IMPORTANT BUMP:
Just did a quick test after installing MC v3.0 on one of my HP systems, and it seems this bug is still in the current release.
A quick test in a 24p PAL 35mm 3-perf project has a 48fr dissolve in MC show up as a 60fr dissolve in the EDL, EDL Manager version 24.0.
The exact same things happens in SN 1.8.3 and EDL Manager 23.8.3, as mentioned earlier.
On my v3 system, I uninstalled, EDL Managager 24.0, reinstalled 23.7.5, same thing happens. Reinstalled 23.7.2, same thing happens. All PC versions. Tried 23.7 on the MAC, same issue occurs.
Also went back to my old Compaq machine that used to run my Meridien v12, and created an EDL from the same 48fr dissolve sequence, using EDL Manager v12.0, and that works correctly, showing a 48fr dissolve in the resulting EDL.
Avid, please, this needs instant fixing.
Found an installer for Mac EDL Manager 21.8.2 (part of the AXP 4.8.4 installer), installed that on my MacBook, and found that is also behaves correctly (48fr dissolves stays 48fr in EDL). Since the MacBook has access to my Unity Lanshare partitions, that is a doable workaround for me.
Still needs fiixing, of course, but AFAIK, the fix for the EDL issue was already in the works, but the fix was not ready in time for the 3.0 release. We'll probably see an updated revision in a while.
Avid Technology, Inc. brands: Digidesign | M-Audio | Sibelius | Pinnacle Systems | Sundance Digital | Softimage
© Copyright 2000-2008 Avid Technology, Inc. All Rights Reserved — Legal Notices | Terms of Use | Privacy Policy | RSS Feeds | Site Map