[Andrew Rendell]

FCP doesn’t export to DCP.

The subject has come up before though, so I’d recommend you go to the main forums page https://forums.creativecow.net/ and type DCP into the search panel and have a trawl through the responses there.

[Andrew Rendell]

If you have a mono track and pan it hard left or right, you get the full level on that side and nothing on the other side, but if you pan it centre you get equal levels on both sides, but 6dB lower.

With a mixer set up that way (which is normal in my experience), if you had a dual mono pair you’d get the same levels for having the tracks panned left & right as you would if they were both panned centre.

I just point this out as it sounds like you’re creating a mono track of line up tone and only putting it on one side of a stereo mix.

[Andrew Rendell]

I’m guessing that you’re in the UK as that’s a normal UK broadcast spec (it’s the 18dB digital headroom that suggests so, most of the world uses 20dB).

OK then:

“zero level” aka line up tone (the 0dBm, although that’s really a redundant term in digital audio nowadays) is at -18dBfs, i.e., 1kHz tone set to -18db in your workstation.

A PPM is like a VU meter, but with a very fast “rise” time and a slow decay, so it rides the peak levels rather than giving an average. Hardware PPMs are quite expensive but I use PPMulator+ (generally via Audio Hijack Pro on the Mac) and it does the job nicely.

https://products.zplane.de/index.php?page=ppmulator

Line up level is at 4 on the PPM and the units are 4dB apart, so PPM6 is 8dB above line up level. That’s your maximum peak level. Usually speech is best with the meters peaking roughly midway between 5 and 6 and music about half a unit or a whole unit lower, because music tends to sound subjectively louder for the same peak level and PPMs aren’t good for judging subjective loudness. (That depends somewhat on how you use EQ and compression, so do use your ears to make a judgement. Personally I like only a little compression and only use a limiter as a “legaliser” to catch any odd peaks that I’ve missed.)

Hope that helps.

[Andrew Rendell]

I don’t know but I usually give translators a low res QT with bitc, so the translations come back with a meaningful t/c ref on them.

For transcriptions, I sometimes use Cityscripts and for them I can assemble all my interviews on a timeline and export it as both a file and as an edl, and then they can translate the elapsed time into the relevant source timecodes. I think it’s their own developed software they use to do it, rather than something commercially available though.

https://www.cityscripts.co.uk/

[Andrew Rendell]

TBH, you’d be much better off converting all your material to ProRes before assembling it on a timeline. Yes, it takes time to do, but it’ll save you time later, e.g., when you come to export. Putting GOP codec material on the timeline gives you the illusion that you’re getting into the edit quicker, but it’s a false economy in terms of the amount of time you will end up spending on the project by the time you finish.

I recently picked up a project which had 4 different codecs on the timeline and had every problem you describe, plus regular crashes. Converting the media to ProRes fixed it, which took time (a couple of days doing it in batches) and in the meantime, the FCP was much more stable with the sequence settings in ProRes even with source material in other codecs.

[Andrew Rendell]

I agree with Richard, go through the manual and DO SOME TESTS as well. IMO the limiters in the EX1 will save you from clipping, but they’re too intrusive for my taste, so I’d record at levels a few dB lower than normal on those cameras to avoid them kicking in too much.

[Andrew Rendell]

I hope this doesn’t sound glib, but what you describe doesn’t normally cause an out of memory error. Out of memory is much more likely to be caused by stills than a quicktime file IME. If you have any stills, convert them to tiff and make sure they have no more than 4000 pixels along either side (if you need to work with a bigger still than that to do, for example, a big zoom, do the move in Motion and import the Motion project into FCP, not the still).

One other thing which can sometimes help is this: create a new project and a new sequence in that project (with suitable settings for your material), then open your existing sequence and copy/paste the content of your existing sequence into the new one. Render the new sequence and try exporting that.

I hope one of those helps.

[Andrew Rendell]

I’ve seen some really odd things happen when the sound clips weren’t uncompressed 48kHz 16bit files, e.g., MP3s. So my inclination is to check the file formats before going any further and if they’re not wav or aiff at 48kHz/16bit, convert them to that. 24bit is fine as well. That might not solve your problem, but it would remove a possible source of trouble/confusion before you go further.

[Andrew Rendell]

Canon DSLRs and GoPros record in a version of H264, so you’d have to convert them to something else anyway if you want to avoid the lengthy and laborious rendering that you’re putting up with now. FCP7 works acceptably with XDCAM in my experience (EX1 and EX3). So I reckon the choice is either to transcode the DSLR & GoPro footage to XDCAM and edit in XDCAM, or convert them to ProRes and use the Sony plug in to log and transfer only the sections of XDCAM that you want to use into ProRes (which would save time over transcoding everything).

TBH, for a big job I’d be transcoding everything to ProRes, but for fast turnaround I’d say do a couple of tests and if your system handles XDCAM ok (XDCAM is a GOP format so it does have processing overheads but it’s not as severe as MPEG types like H264) then go with that.

[Andrew Rendell]

You could try increasing the pixel count in photoshop and adding a little unsharp mask, but I have a feeling that the “slightly pixelated” look may be compression artefacts (IIRC those Canons use a version of h264 that’s quite heavily compressed for video), so the compromised quality is not just about pixel count. You could try making multiple gabs over a few frames to see if one is better than others (it’s conceivable that exporting from an I-frame might be slightly better than from a B- or P-frame, but I’m only speculating about that).