i'm receiving avi files into a final cut/quicktime environment from
a windows capture system. i have no choice in this aspect of things.
the avi files are compiled bmp image sequences from a video source
which runs at 10fps. the software capturing this video sets the file
frame rate at 10fps for this reason. the content, however, is telecine
of film from a projector. for this reason, it should match the original
film's frame rate of 24fps.

bringing the 10fps files into final cut or even the quicktime player
causes the file to be read as 10fps and the running time to be
incorrect, approximately 3 times the correct length.

to correct this situation (there appears to be no way to override the
capture software's assignment of the 10fps rate) i've found a small
utility for windows which allows the dwRate and dwScale to be
changed directly in the file without rerendering the entire file. this
results in a new frame rate of 24fps in all of the windows apps i've
tried. i also looked at the files in mpeg streamclip on the mac side
and it too sees the file as 24fps now.

the problem, however, persists in quicktime player and final cut,
both of which continue to see the files as being the original 10fps.

what can i do to get them to recognize the files as 24fps?

how do these apple apps read the frame rate differently than the
windows apps?

the files are very large, 2048x1536 uncompressed files of over
400gb so they take a long time to render and transfer. anything i
can do to get these original files to be read as 24fps without a
rerender is what i'm looking for.

thanks,
BabaG

>bringing the 10fps files into final cut or even the quicktime player
>causes the file to be read as 10fps and the running time to be
>incorrect, approximately 3 times the correct length.

What codec are you working with? Is it an image sequence that has been saved as an avi?

Here are some options to try out:

-Save it as a quicktime file, then try to telecine it to 24fps with Cinema Tools. Try it on a short clip to see if that works. (make sure you save a copy of the file before using CT)

-Alternatively, if this was an image sequence, you could you possibly re-import the image sequence and save it from either QT or After Effects and this time set frame rate to 24 fps?



www.strypesinpost.com

thanks strypes.

the files are bmp image streams being captured directly to avi files. capturing direct to avi
is a much faster process in the system being used than capturing individual frames. final
cut also has a problem loading more than about 12000 frames of this size so having it all
in a single avi file is useful as well. it loads MUCH faster.

the codec displayed by the qt player is wraw. mpeg streamclip shows the info that the stream
is a bmp stream. (it also shows the corrected 24fps frame rate.)

i'm trying to avoid a rerender of the files as they take so long given their sizes of 400+gb.
if i have to rerender i might as well try a workaround of capturing straight image sequences
instead of avi files. it's just that the avi file route is much faster and can do entire rolls from
film. the capture app has a limit of 9999 frames which means breaking up the capture,
although, final cut's issues with large image sequences make this breaking up something
i'd need to do anyway.

the best solution is to find a way of changing the file's frame rate info and not rerendering.
it works for windoze and third party apps apparently, but not for qt and fcp. i'd need to find
out how qt and final cut derive their frame rate info since the methodology seems to differ
from that used by windoze apps. if i could find out how qt and final cut derive this info, i might
be able to find a way to change it without rerendering.

thanks again,
BabaG

That is one of the most bizarre workflows I've ever heard of. It sounds like workaround piled on top of workaround piled on top of workaround, and it's not at all surprising that it isn't coming together. Why in the world is your workflow so weird? I mean, if we're talking about film here, these should be DPX sequences, and you should be using Gluetools to work with them, no?

If you're using the AVI format in any way, you will have to re-render. Absolutely no way around it. I'm with Jeff Harrell -- it sounds like somebody in your organization doesn't know how to work with Final Cut Pro. Whatever speed advantage in the prep stage will go right out the window when your AVI files slow your FCP system to a crawl. I worked with a DV short film a few years ago where they didn't change their AVI files (captured in Vegas, if I remember right). It slowed my editing down to a crawl, taking about three times as long. Not to mention that you're in HD. Plus you're almost certainly going to lose more quality than should be necessary.


www.derekmok.com

this is in a non-commercial context on converted gear. it's a home built telecine made
from a converted producers services optical printer and being used for art purposes.

over time i may try to adapt as you suggest, but for the time being, we're limited by
what we have at hand and the software (mostly free) that we can get, which is,
obviously, limited. it does not support dpx. i doubt that dpx files would get me past
final cut's import limitations, though. but, if i can figure a way to make something
work, i will.

this system does work and yields good results. the things i'm looking at here are,
ultimately, to make it efficient. the liklihood is that, over time, i'll write my own capture
app to address some of these issues. until then, though, it would be great to understand
the how and why of apple's reading of frame rates in avi files as it differs from the
approach taken by, pretty much, everybody else.

there will be a rerender as audio will be added. i'd like to avoid more than one rerender,
though, and get the image into the system as first generation, then rendering out, with
audio, to something more fcp friendly for the main work. it seems inefficient and like it
should be unnecessary to have to render a new file and format just to get things into the
system for syncing. these files are fine with the exception of frame rate. if i can solve
that, preferably without a rerender, i'll have a fairly efficient workflow from capture through
to editing.

thanks,
BabaG

> i doubt that dpx files would get me past final cut's import limitations, though.

You're not supposed to import 12,000 stills as individual still files into FCP. You make an Image Sequence in QuickTime.


www.derekmok.com

quicktime has (unless it's been solved) a color bug making for mismatched renders.
bringing the files directly through fcp avoids this issue.

edit:
to satisfy the insatiable desire for information on this topic i'll add the update that there
exists an app called 'dumpster' which will allow for the modification of moov header information.
it's been recommended that i save the avi as a ref movie and open it using dumpster. when i
do so, i do, indeed, find familiar information like frame sizes and quantities along with a host
of things as yet indecypherable to me. i have played with modifying some of the fields
presented by dumpster and have been able to modify things like frame rate and duration,
though not in a useful manner, as yet. it looks promising if i can find the patterning of how
the various fields relate to each other. if i can find the relationships, this should make the
avi files usable with just a save to ref movie, a few minor text tweaks, and no rerendering.
all of this should be doable in little to no time, as opposed to the time it would take to render
400+gb files. here's hoping someone can guide me to the relationship between moov
fields.

BabaG

ok. so, here's the solution. came from jan e. schotsman, maker of jes
deinterlacer. great utility. everyone should have it.

make a qt ref movie from the avi.
open the ref movie in dumpster.
there are four fields to edit for duration here.
there is one other for 'sampDur'.

under 'trak--->mdia--->minf--->stbl--->stts' you'll find:

sampCnt
sampDur

sampCnt is the number of frames in the file.
sampDur is fps. mine says 60, which corresponds to 10fps.

per jan's fix, i changed that to 25, which corresponds to 24fps.
you'll notice that 24fps is 10fps x 2.4 and that 25 = 60 / 2.4.

now, we use a formula:

sampCnt x sampDur

to derive a number for duration.

the file i'm looking at now has a samCnt of 17374.

17374 x 60 = 1042440
17374 x 25 = 434350

with these number, we now look for four fields containing the
original value of 1042440. they are:

'mvhd--->duration'
'trak--->duration'
'trak--->edts--->elst--->Track Dur'
'mdia--->mdhd--->duration'

each of these fields should contain the value 1042440.
change that to 434350.

make sure to click in another field after you make your last
change so the value will be retained. then save.

that's it. change five text fields and the file now opens
as a 24fps file with the correct durations. in my case, making
these five text entries (takes a minute or two), saved a three
to four hour transcode. and, i have to do this dozens of times
over saving, probably, hundreds of wasted hours.

thanks to jan!

these are simple files, in y case, picture only. i can imagine
there might be additional issues with files containing audio or
additional tracks.

BabaG

wow!
out of interest did you have a go with CinemaTools?
it will change frame rates of QuickTime files (with no rendering required) with one button.

it's the "Conform" function.
you can conform an individual clip by opening it in CT and hitting the conform button lower right of the window.
or there is a Batch Conform command in the File menu.


good luck with the project.

nick

Yeah wow, that seems a complex workaround to avoid CT.

thanks for that nick. i'd be interested in ct for something like this but, without knowing
the methodology it employs for the frame rate change, as in, does it try to transcode or
just change a numbering system, i'd be afraid to work with it. i knew all along that this
was a simple fix arising out of a simple programming oversight so it seems easy to just
address it at the file level. something as large as ct seems like overkill and, having never
used it, it seems like a minefield to me in which i could cause more trouble than i started
with. on the other hand, if it does it, great!

thanks again,
BabaG

to be accurate, it's a workaround to fix the issue. i just didn't know that ct
would fix it. still don't. it's not a workaround to avoid ct.

CT simply re-writes a part of the file header which tells it how fast to play.
probably worth a test on your end.
you can test it on a reference movie copy of the original QuickTime file if you want,
and it shouldn't effect the original

nick