[Dennis Couzin]

Since Dave LaRonde thinks that Michael Gissing’s information confirms his thesis, and I think the information confirms mine, there’s a big fat confusion in here.

What I mean by converting 24 fps material to 25 fps material is adding an extra frame to the original so there are now 25 frames for each second. Frame rate conversion, in my book, means conversion without changing length (running time).

When you convert 24 fps material to 30 fps material you expect the length not to change. When you convert from inches to centimeters you expect the length not to change.

“Of course you can convert from 24 fps to 25 fps. The question is whether you can stomach the result.” I meant framerate conversion, as should have been obvious from my details. Adding an extra frame every second, even with tricks, never looks good — is hard to stomach.

What Michael Gissing describes is not conversion from 24 fps to 25 fps in the above sense. To telecine “straight off 24 fps prints running at 25 fps” means that each film frame becomes two fields of video. That is no framerate conversion at all. It amounts to “declaring” the 24 fps movie 25 fps video. It accepts a 4% length reduction, just as I suggested Riana McKeith should accept.

If you brought a 24 fps film to a cine effects lab requesting conversion to a 25 fps film, and the lab handed your film back to you saying “done”, and instructing you to project it at 25 fps and be happy, you’d be happy, but there would not have been a framerate conversion.

All of this rests on my usage of the word “convert”, but maybe Dave LaRone, and maybe even Riana McKeith, mean something different by “convert”. Maybe they mean by convert what I mean by “declare”. The guy in the cine effects lab was able to “declare” your 24 fps film 25 fps by telling you how to project it. How does one go about declaring 24p digital video 25p digital video? Who knows how to go into a header, or a wrapper, and change ’24’ to ’25’? Maybe many more numbers need to be changed. Maybe it won’t play after the changes. What a nasty medium, wherein mere formalities — “declarations” — can compete with substance.

[Dennis Couzin]

Replying to Dave LaRonde.
#1, anyone watching professionally made movies on SD TV has low quality standards.
#2, are you sure that the 24 fps movies played on European TV were converted to 25 fps PAL whole? Or was the 24 fps picture “declared” 25 fps (as per my suggestion) and only the sound converted (losslessly) to 25 fps? That would have allowed simpler film transfer hardware and produced better total quality.

25 fps to 24 fps conversion is also pretty crappy, and best avoided. For example, in 2007, Fasbinder’s “Berlin Alexanderplatz” which was shot on 16 mm at 25 fps for German TV was elaborately restored for a DVD issue. They chose to not putz with the frames, but rather to “declare” it 24 fps and accept that it would run 4% longer than the original. This was a good aesthetic decision, and the flipside of my recommendation to Riana McKeith.

[Dennis Couzin]

Of course you can convert from 24 fps to 25 fps. The question is whether you can stomach the result.

The simplest way to do the conversion is to double one frame every second. The eye can catch this. Next you can try doubling one frame at not exactly one second intervals, to break the rhythm. The eye can still catch it. Next you try introducing a frame blended from two neighbor frames. This is shockingly apparent, especially in animation. Next you interpolate the whole thing: after the genuine frame 1 you create frame “1.96”, then frame “2.92”, etc. Your interpolation algorithm had better be damned good, because you’re creating 24 out of each 25 frames.

Unless the animation and the animatics have to interact, why are you planning to convert the frames of either one? Why not leave the 24 fps animation frames exactly as they are and “declare” them 25 fps. This means you speed up the animation by about 4%. The sound corresponding to the animation must be correspondingly sped up by about 4%, but this is a perfect process which does not change its pitch. The animation is now 4% shorter. I hope you have some extra material in case you have a duration requirement.
It might surprise you how insensitive viewers are to 4% speed increases, even in live action. It’s funny that this is easily verified with movie film in a variable speed projector, but difficult in our computers.

[Dennis Couzin]

David, I feared that Avid would install its own codecs which would confuse FCP, so I did it the cautious way: making a bootable partition with both FCP and Avid on it. I put them together since Avid needed FCP’s codecs to read the 10-bit uncompressed 4:2:2 QuickTimes exported by FCP.

Anyhow, field stepping in Avid found none of my sample QT clips to have their fields out of time order. It was all a false alarm.

I think there are two completely different ways to have screwed up fields. The first kind shows up as wild jittering when there is motion, especially when viewed on a CRT, but looks perfect when there is no motion. In this kind, the order of the fields comprising each frame is reversed, so, as the fields are stepped, action goes 1 step backwards, 2 steps forward, 1 step backwards, 2 steps forward, etc.
The second kind is subtler and shows up as exaggerated interlacing, the same with or without motion. In this kind, what should be the even lines are odd lines and what should be odd lines are even lines. In each frame, instead of presenting lines 1,2,3,4, etc. in correct geometrical order, it presents lines 2,1,4,3, etc.

The first kind of screw up definitely happens. Since a small error in coding could produce the second kind, I suspect it happens too.
The first kind of screw up is best examined by watching a moving subject field by field. Avid lets you do this while FCP doesn’t. It doesn’t matter whether the motion is horizontal, vertical, or at an angle, since it’s a temporal problem.
The second kind of screw up is best examined by looking at any one frame from a clip where some part of the image is perfectly still. Set the view to exactly 100% and study the pixels along a sloping edge in the image using a loupe.

The first kind of screw up is wrong “field dominance”. I don’t know if the second kind has a name.

Chris Pirazzi, who obviously understands this stuff, does not make the distinction clear in his “All About Video Fields”.

[Dennis Couzin]

If Avid can import my QuickTime file either with Upper Field First or with Lower Field First, does this mean that QuickTime files are organized as frames rather than as fields? Is the program which imports (or plays) a QuickTime file not informed by the file whether the even lines in the frame were shot before, after, or simultaneous with the odd lines of the frame? (What are headers for if not to give that kind of information?) If the field information is absent from the QuickTime file, then a QuickTime file can never be said to have reversed fields (except in the horrible case where frames have even line image in odd lines and odd line image in even lines). If the field information is present in the QuickTime file, does Avid import purposely ignore the information and require the user to input it? In that case, I haven’t really verified my QuickTime files.

[Dennis Couzin]

Andy Mees, I don’t get your LOL that I installed the Avid trial on my PC. Would you dare install it on a Mac having FCP installed? The Avid software was pretty agressive on install. Windows XP screamed and begged not to continue the install. But I can flush my PC easily after the trial. Is there no danger that installing Avid will disturb an existing happy FCP installation on a Mac?

Oh, my finding the fields out of order was a false alarm. I needed to set the field dominance in Avid before letting it import the QuickTimes. It surprises me that a QuickTime file of interlaced video isn’t organized into fields. Is it organized into frames? Does it not even specify which lines of the frame are temporally first? How can a QuickTime player do a good job of deinterlacing without that information?

[Dennis Couzin]

ra-ey Saleh, I now understand your suggestion. Under Import Settings-Current:

Field Ordering in File

Ordered for current format
Odd (Upper Field First) ordered
Even (Lower Field First) ordered

If I choose Even before I import the QuickTime file, then the field order does appear correct when I step through fields.

I think this means the QuickTime file is correct, because DV-PAL is supposed to be Lower Field First. Whew!

Incidentally, before I set the ordering to Even it was set to current project. The current project format had been set to 25i PAL. Is it reasonable that Avid interpreted this as Odd?

Sorry for the false alarm on the 8-bit QuickTimes. I will now work on viewing the 10-bit QuickTimes in Avid. It was a 10-bit uncompressed 4:2:2 QuickTime (made with FCP 5.1.2 from DV-PAL original) which I once brought to a (professional) video lab which informed me that the fields were reversed. Since I had the whole project with me the lab then recreated the problem in their FCP 6 system, declaring that it was FCP’s bug. Is this related to: https://support.apple.com/kb/TA23518?viewlocale=en_US? I’m now trying to confirm this bug. I’ve now disconfirmed it for the 8-bit uncompressed 4:2:2 QuickTime. Thanks for your help.

[Dennis Couzin]

I’ll keep the discussion going on here and also at https://forums.creativecow.net/readpost/8/1028737.

If Avid QuickTime import can’t be trusted to keep field order straight, then how can Avid be a method for checking the field order in a QuickTime file?

I did the basic experiment. Some video came out of a Sony DCR-VX2000E. It was definitely shot as DV-PAL. I captured it with FCP using the DV-PAL preset. (There is no option for field dominance in the capture settings.) I put it in the timeline and set sequence settings to DV-PAL with lower field dominance. I rerendered and exported a QuickTime using current settings. Then I set sequence settings to DV-PAL with upper field dominance. (This is the wrong setting for DV-PAL.) I rerendered and exported a QuickTime using current settings.

I imported both QuickTime files to Avid and stepped through their fields. Both showed the field reversal: 1 step backward; 2 steps forward; 1 step backward; 2 steps forward; etc.

It appears that either FCP exports DV-PAL QuickTimes incorrectly or else Avid imports DV-PAL QuickTimes incorrectly. DV-PAL is not an obscure codec. The error seems too large to be possible (unless FCP or Avid is known making for big errors)

[Dennis Couzin]

I’ll keep the discussion going on here and also at https://forums.creativecow.net/readpost/45/871653.

If Avid QuickTime import can’t be trusted to keep field order straight, then how can Avid be a method for checking the field order in a QuickTime file?

I did the basic experiment. Some video came out of a Sony DCR-VX2000E. It was definitely shot as DV-PAL. I captured it with FCP using the DV-PAL preset. (There is no option for field dominance in the capture settings.) I put it in the timeline and set sequence settings to DV-PAL with lower field dominance. I rerendered and exported a QuickTime using current settings. Then I set sequence settings to DV-PAL with upper field dominance. (This is the wrong setting for DV-PAL.) I rerendered and exported a QuickTime using current settings.

I imported both QuickTime files to Avid and stepped through their fields. Both showed the field reversal: 1 step backward; 2 steps forward; 1 step backward; 2 steps forward; etc.

It appears that either FCP exports DV-PAL QuickTimes incorrectly or else Avid imports DV-PAL QuickTimes incorrectly. DV-PAL is not an obscure codec. The error seems too large to be possible (unless FCP or Avid is known making for big errors).

[Dennis Couzin]

This strand has shifted to the Avid Editing forum https://forums.creativecow.net/readpost/45/871644
where surprising results are presented.