Joe Marler
Forum Replies Created
-
I have two A7SIIIs, an FX6 and shot for years on a DVX-200. The A7SIII and FX6 do very well in low light if you are at the “high base” ISO, which varies with color profile. For SLog3 the switchover point is 12,800.
However most other current or recent large-sensor camera also do well in low light. The Panasonic S1H does very well, but it doesn’t have great AF, and uses the L-mount.
The problem with the A7SIII and FX6 is there is a big “ISO noise gap” from around 3200 up to the 12,800 switchover point (in SLog3). You want to avoid shooting in that range if in low light. In a bright setting it’s OK. The FX6 has built-in variable ND so it’s easy to jump to 12,800 and use the ND to balance the exposure. With the A7SIII you’d have to use an external ND.
Those behaviors are a function of sensor design. You can compare the read noise vs ISO for many cameras on this site: https://photonstophotos.net/Charts/RN_ADU.htm
Here are some simple test chart sequences where I compared the Sony A7RIII, A7SIII and FX6: https://vimeo.com/manage/videos/532676476
-
I’ve seen that happen several times on Resolve 17.x and I think also in 16.x. What if you delete all render files and re-launch Resolve? Does it happen then?
-
I have used the DVX200. It was a nice step up from smaller-sensor, fixed-lens camcorders. But despite the M4/3 sensor, it’s definitely not a low light machine.
Low light is really, really hard, and 60 fps makes that even harder because it’s only gathering half the light per frame of 30 fps. Good quality low light performance generally requires a large, new technology sensor and a fast lens. You want excellent autofocus which rules out Panasonic or any other camera not using phase-detect AF.
Achieving all those items in a camcorder-like package including motorized zoom is even more difficult because there are no inexpensive large sensor camcorders. It would be something like a Canon C70 or Sony FX6, which are both over $5,500 just for the body. The Sony 28-135 f/4 PZ lens has motorized zoom and gives a “camcorder-like feel” to a mirrorless camera or an FX6 but it’s $2,500.
I don’t think there is any fixed-lens camcorder with a 1″ sensor that can do what you want, however I haven’t investigated those lately.
The cheapest thing would be giving up the camcorder form factor and using something like a Sony A7III and a 24-105 f/4 manual zoom lens. At least that has halfway decent AF, good low light, UHD 4k/60, albeit only 8-bits per color channel.
-
I don’t see any sync problems on Catalina or Big Sur on my iMac Pro for Premiere-encoded H264 files viewed in Quicktime. I just tested a 4k/23.98 ProRes 422 file from a Sony A7RIII and Ninja V, imported to Premiere 15.1.0, exported as 4k/23.98 H264, and it played in sync on Quicktime and VLC.
If using an external monitor with audio separate from the monitor, there is a theoretical problem due to video processing delays in the monitor (esp. TV-type monitors). Sometimes this can vary randomly with scene type, as the monitor has fluctuating video processing latency. If the monitor is driven by external video hardware (Blackmagic, AJA, etc) that is another possible source. One way to test that is use local playback on an iMac or similar computer and no external or wireless audio.
If a file containing a slate clap (or hand clap) is imported to Premiere, FCP or any other NLE, the audio waveform should line up with the clap. If it lines up but there’s an audible sync problem when played back, that implies an A/V delay problem during playback. Usually that happens as video latency (IOW audio leads video). Observing whether video is late or audio is late can be a clue about possible causes. It can also be a clue to observe whether the mis-sync is constant or varies over the program.
If it appears mis-synced during local playback but in sync after upload and during streaming playback, maybe that’s because the streaming file has been re-encoded and is lower resolution? What if that re-encoded streaming file is downloaded and played back in Quicktime?
Are the problem files originally camera files with constant frame rate, or are they captured and encoded with variable frame rate?
-
There is no harm in renaming the backup drive, but the situation can become confusing if two drives with the same name appear in Finder.
There is a trick whereby you can tag one drive in Finder with an emoji character (keeping it visually distinct from a non-tagged drive with the same name), and this does not modify the drive name from the standpoint of FCP. To use emoji tags do CMD+I on the drive, place the cursor after the drive name and do CMD+CTRL+spacebar, and append an emoji character to the drive name. I haven’t tested it extensively but it seems to work, at least on Catalina 10.15.7.
If the media itself is identical and only the library (which contains the edits) differs, it doesn’t matter which data set the library connects to. The library on the backup drive could connect to the media files on the main drive. It’s a good idea to rename the library itself, e.g, MyLibrary vs MyLibraryBackup, and maintain awareness within FCP of the library name you are using. Otherwise you can end up doing work in the wrong library.
An advantage of using a “lean library” (with cache and media external) is backup. That way the library only contains the edits, is very small and can be quickly duplicated and copied in Finder. This also makes it easier to keep the library on an SSD. The library itself requires many small random IOs which can conflict with the large sequential IOs for media. The cache is also important to keep on an SSD, but it doesn’t require backup.
Or you can just relink. Normally relink isn’t that slow but if both library and media are on a single HDD and if many files are involved, it can be take a while.
-
If he’s literally dragging the library *and* all assets (IOW extra media folders besides library) to another drive, of course relink is required. The drive volume name has changed.
The scenario is confusing because it was originally described as a 100% “all internal” managed library. That is apparently not the case.
As previously explained, any change in drive volume name will cause the external media to go off line. That is regardless of whether the drive is renamed or the media is copied to another drive with a different name. It can be tested by (carefully) renaming the backup drive to the same name as source drive. Typically in that case the links will remain intact.
Obviously it’s not a good procedure to have two drives with the same name due to confusion — that is only a test.
It would be a nice enhancement if FCP allowed “patching in” a different drive volume name for cases like this. However the full pathname (inc’l volume name) is apparently stored separately for each file. If there are 5,000 media files it would require 5,000 logical read/modify/write operations to the SQLite database. If there are referential links to other SQL tables and indexes on those tables it could require vastly more physical IOs than logical IOs. Even if UI existed for that it might not execute any faster than relink.
-
When you get a red thumbnail indicating missing media, can you select that one thumbnail, do File>Relink Files>Original Media, then (without relinking) look at the bottom of that dialog. In grey letters it should show the expected pathname to the file. You can resize the window horizontally if needed to show the full pathname.
What is that pathname? You can compare it to the original pathname by opening the normal, non-backup library, in FCP right-click on the same file in the Event Browser, and pick “Reveal in Finder”. You can see the full pathname in Finder by doing View>Show Path Bar. How does the pathname of that same file differ between the backup library vs the regular library?
If you want to inspect the full pathnames of multiple files, you can drag/drop the files from Finder to a TextEdit window. It will not move any files, just display their full pathname.
-
If it lists another drive, then the media is not all internal to the library. Likely part of the media is on that drive.
When you say: “I backup on HDD drives”, does that mean setting the auto-generated FCP library backups to that drive, or is media is backed up there, or did you manually copy the FCP library there for backup?
When you say “every time I open a project on the HDD drive that has been backed up on that drive, I have to relink all media”, do you mean opening a *library* on the HDD drive?
If you have multiple versions of the library, some of which had media imported from different locations, then open an older “backup” version of the library, it won’t know about the new media locations.
However in general the location of the library *itself* doesn’t matter. If you copy a library to another drive, then open the library, any internal media will be found. If that copied library references media on other drives, those references should remain valid, provided the drive volume name has not changed.
FCP keeps a list of the high-level storage locations — the ones denoted in the library inspector>Storage Locations>Modify Settings. Those are stored within the library in the file Settings.plist. If that is deleted or one of those high-level folders or drives change, it will prompt you to update it. However that by itself will not avoid the need to relink. For external “in place” media, the full volume name + pathname for *each* file is stored in the library in binary format. If the drive name changes (as often happens with backup drives vs regular drives) it won’t find the media files without relinking.
It is easier to debug cases like this by using Final Cut Library Manager’s add-on feature to create a CSV list of all media files from each library.
-
If you open a “managed” library which supposedly has all internal media, and the media requires re-linking, it’s likely not inside the library. Media inside the library never requires re-linking.
If you click on the library in the left sidebar, then enable Inspector (CMD+4), at the bottom of that pane under “Storage Used” it will show what volumes the files are on. Unfortunately it will not show the individual pathnames to each file.
However you can right-click on individual files in the Event Browser and select “Reveal in Finder”. That will show where the file is (if linked).
If the file is a red thumbnail, you can select a *single* file, then pick Files>Relink Files>Original Media, and (before relinking) note at the bottom of the relink dialog the pathname to the file. That is where it expected the file to be. That can give a hint about why it’s looking in a certain location.
The 3rd-party utility Final Cut Library Manager has an optional feature which scans the library and creates a CSV file showing the complete pathname to each media file: https://www.arcticwhiteness.com/finalcutlibrarymanager/
All media and libraries should be kept on volumes formatted APFS or HFS+ (MacOS Extended Journaled), not ExFAT or any other format. If kept on those formats, external media files can be renamed or moved elsewhere on the volume and they will not require relinking. FCP uses “inode lookup” in that case. If the volume name is changed or the external file is moved to a different volume, relink will be required.
Keeping all media inside the library is not necessarily the best idea. It can make the library unwieldy to manage. OTOH in some archiving cases, creating a separate library using internal managed media for the project can be useful.
Here are some tutorials on FCP media management:
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
In past projects I have done #1 and #3. In general text-based translation is easiest and most common, but synchronized voice translation can be a more polished presentation. It can theoretically enable first-pass dialog editing by an English-only editor, since each language is on a separate audio track. It is also more laborious to achieve. The final result must be checked by a language specialist and (depending on the type of presentation) the edited version may be re-recorded by an age and gender-appropriate voice actor.
We had a team of translators equipped with Blue Snowball USB mics, they used Audacity to capture the files. We trained them to pause and re-start so they didn’t need a perfect 20 min take. This was Spanish-to-English voice translation of each full interview, which became a separate audio channel on the multicam, not simply translation of the final edited clips.
Due to the difficulty of the translator staying within +/- 1 or 2 sec sync, they still had to make their own transcript. Then when recording the translation, they could focus on timing and delivery. Despite the mic we had to re-do several because of background noise or echo problems. It’s more difficult than it first appears to obtain a good quality synchronized voice translation.
The translator would listen to the foreign-language dialog in one earbud, that way it didn’t leak into the English audio. We tried headphones but they preferred one ear, to better hear themselves speak.
When I got the translated audio back, it was fairly simple to drop into FCP and check the sync.
If a decision is made to later voice translate the final edited timeline to a new language while keeping the same edit, that can be difficult if going from English to Spanish. The “semantic density” is lower in Spanish to it takes more time to stay the words, and you can easily run out of space, forcing multiple re-edits. The answer is plan ahead for that and keep the project in a form that permits adjustments.
In general I think method #1 (time-stamped transcript) is the best approach and involves the least post production labor. It is tedious for a single-language editor, but it avoids the complexity of full-duration synchronized audio voice translation. The final edited timeline can still use voice translation of the selected clips.