Mark Spano
Forum Replies Created
-
Thanks Michael. I haven’t done this in a long time as well and always remembered the software plugins to pale in comparison. Glad to hear there’s good stuff in CPU land for this.
-
The only way I’ve known this to be acceptable is by doing the pitch shift in real time using a hardware pitch shifter like the Lexicon 2400. This is a device that runs concurrently with the picture in real time and outputs a pitch-shifted signal exactly relative to the speedup or slowdown of your video. Other than that (or similar high quality hardware), I’ve never known software plugin effects to be up to the task, and always consider them to be sort of proxy previews of what it will sound like (but never final quality output).
-
Any time I’ve had this issue with AMA clips populating in the bin but not linking, I’ve had to tell MC to acknowledge all network and attached drives. Open the Console in MC and type “alldrives” and hit enter. See if those clips link after you do this.
-
Animation codec is a frame variable codec. If the video has multiple frames in a row that are the same, it will report the total frame rate as the average number of differing frames per second. That’s what animation is, if you think about it. Many animations are not a fixed amount of frames per second. This translates exactly to the video codec. You can try this – export a slug of 5 seconds out of any program to Animation codec. It will likely report a weird number for frame rate. But technically it is 23.976fps. Take a random Animation codec file and open it in Quicktime Player and watch the “Playing FPS” in the info window while playing. You’ll likely see that number go wildly up and down. Animation codec is super efficient FOR ANIMATIONS. For actual playing video, its only real use for ages was for video encoded with alpha channel information. As there is now ProRes 4×4, a real video codec with support for a real alpha channel, there is seemingly no need for Animation codec to be used for anything. Its current staying power has more to do with habits and legacy compatibility than anything else.
If you are concerned about the reported frame rate, and you know the actual fps, open the Animation codec file in Cinema Tools and “conform” the file to the frame rate you know it to be. It will likely report your correct frame rate in all those applications it wasn’t before.
-
As John says, the numbers you see in Format show you first ACTUAL resolution of your file and second DISPLAY APERTURE. It doesn’t matter what the display aperture is for most applications since the actual resolution is what counts. You can reset the aperture settings here in Quicktime Player’s Movie Properties window:
Change the setting to “Encoded Pixels” and you’ll see the full 1920×1080. It is just some metadata for Quicktime Player’s display, it will not change the actual resolution of your file. -
another for FSI. My facility here has (7) 2450s and (3) 1760s.
-
If total running time and speed are not an issue, the cleanest way would be to conform the footage in Cinema Tools to 25fps. It will play back around 4% faster, but look as good as the original.
-
It’s usually easier than all that. Launch Compressor and go here:
Choose that and then choose Reset and Cancel Jobs. Quit Compressor, wait a minute, then try your job again. Clears up 99% of my Compressor hangups…
-
[Andreas Dalsgaard] “they move progressively out of sync. About two seconds in a 30 min recording.”
Yep – I’ve seen that before in standalone non-lockable audio recorders like the Zoom. It’s recording at a slightly different speed than your camera. The audio from the Zoom is likely more accurate to actual time, but since picture rules, you need to sync that audio to the camera audio in order to get video/audio sync. The problem is not the sampling rate mismatch. A second should always be a second, right? However, if one of these recorders is slightly faster than the other, then playback at its recorded sampling rate will be out of sync with reality.
The only solution I’ve been able to use in this scenario (which does come up often) is to use a professional audio workstation software with a really good time compression/expansion plugin. Pro Tools has a good one, and Avid MC uses the same algorithm. The process is relatively simple. Place the audio and video on the timeline so that they are in sync at the start of the program. Then navigate to the end and find something visual that you can reference in the audio. Figure out the difference between the timecode where it happens in video and the timecode where it happens in audio. Apply the time compression/expansion plugin to the audio and add or subtract the found difference to the total duration. Process/render the plugin and they should now be in sync for the entire program.
The more ideal way to achieve this is to figure out the speed difference and vari-speed the audio to match. Unfortunately, tools to accomplish this are seldom found and a lot of times more hassle than just time compressing/expanding. Those plugins are good, and for a minor change like this usually needs, can sound pretty transparent.
-
This is a tough question to answer because there are many possible interpretations of what you mean. What I will do is answer one that I think you may be alluding to. To make sure that the receiving end gets the file you’re sending bit for bit, you can create your own checksum file. You use an application that can create an .md5 file (usually just a drag and drop of your file and it spits out the MD5 checksum). Then you send your video file along with the .md5 file. When the person on the other end receives your file, they can drop the .md5 on a checksum verification (usually the same program you created the MD5 with) and it will tell them that bit for bit the video file you sent matches the file you created the MD5 with.
If that isn’t what you were looking for, please clarify your question.