16mm double head to video

Serena wrote on 11/13/2009, 8:54 PM
I'm transferring 16mm film shot at 18fps in 1977 to DVD and have had the visuals transferred to MiniDV PAL. I understand that the film is run at 16.8fps for this. The film has two sync audio tracks (on separate 16mm sprocketed tape) and my plan is to lay all this onto timelines (Vegas) and do all the usual post work. The visual and audio tracks have matching head & tail sync marks, so it seemed a simple matter to align these (contracting the video track to match and restore the original speed). But there is a snag and maybe others know the answer. Aligning the tracks by sync marks (video and track #1 is all I've tried) doesn't get things in sync and if I manually match the start and end of the film (10 minutes) the centre is out by 2.5 seconds. There is a non-linearity that I don't understand. The audio tracks were transferred to digital 48KHz 24 bit by me. This "double heading" process always works well when the visuals begin as video, but then each begins life at the correct frame rate. I've tried leaving the video track "as is" and stretching the audio to match, but same result. Be nice not to have to go in and recut the whole thing; the only available material is the the final film cut. I have set "smart resample" for the video (playback speed 1.0705).

Comments

xberk wrote on 11/13/2009, 9:16 PM
I never heard of any live sound in 16mm shot at 18fps. This normally was 24fps. I don't get how they shot at 18fps for "lip sync" ? Sound projectors run at 24fps. Any chance this was shot on Super 8 which used 18fps?

Paul B .. PCI Express Video Card: EVGA VCX 10G-P5-3885-KL GeForce RTX 3080 XC3 ULTRA ,,  Intel Core i9-11900K Desktop Processor ,,  MSI Z590-A PRO Desktop Motherboard LGA-1200 ,, 64GB (2X32GB) XPG GAMMIX D45 DDR4 3200MHz 288-Pin SDRAM PC4-25600 Memory .. Seasonic Power Supply SSR-1000FX Focus Plus 1000W ,, Arctic Liquid Freezer II – 360MM .. Fractal Design case ,, Samsung Solid State Drive MZ-V8P1T0B/AM 980 PRO 1TB PCI Express 4 NVMe M.2 ,, Wundiws 10 .. Vegas Pro 19 Edit

Serena wrote on 11/13/2009, 9:53 PM
You can shoot sound film at any speed if you're not looking to commercial release. Nearly all sub-standard projectors run at governed 18 and 24 fps, and special 35mm projectors can be run over a range of speeds. Sound only requires that the film be projected at the intended speed. Most amateurs shot at 18fps to reduce costs. It is difficult to mistake 8mm film for 16mm when you have it in your hand.
Former user wrote on 11/13/2009, 10:00 PM
Film stretches and shrinks. Also depending upon how it was transferred to tape, the speed may vary on both the film and the soundtrack.

Dave T2
johnmeyer wrote on 11/13/2009, 10:35 PM
I am just at this moment trying to re-sync the audio on a videotape transfer from a tape done in 1971. The sync was good at the head/tail, but not in the middle.

I'm not dealing with the original master, but with a 2nd or 3rd generation dub. Somewhere the audio and video got separated and put back together, and at the "splice" bad things happened. By successive approximations (going to the 1/2 point, then the 1/4 point, then the 1/8 point) I was able to find the splice where things went out of sync.

So, the first thing I would look for is a bad splice, especially since the audio and video in your situation are apparently on separate physical stock. I'll bet that you'll find some blank or duplicate audio somewhere on the timeline. It is a pain to have to visually look for these short gaps. Sound Forge has a detect silence function that sort of works for this sort of thing, and you might want to try that.

Serena wrote on 11/14/2009, 12:10 AM
Hi John,
Wish it was that easy. In this case it is the original material and I've checked it all on the flatbed; had to fix all the tape splices before it went to transfer. On the flatbed everything is in sync and because the audio was cut very simply in general the sound splices match the splices in the visual (at least that gives me many findable sync points). You are the very person who I hoped would tell me how simple the problem is to fix! The error in sync is roughly proportional (I haven't tabulated the error) to time from the start/end , which I don't understand at all. I see no way to make that happen in the transfer to video, so thought it must have something to do with the way Vegas does stretch/compress. But why would anyone choose to make that process non-linear?

edit: just to be clear: by adjusting the video play speed the audio can be brought into both head and tail sync, but the error get progressively larger with time from those points.
farss wrote on 11/14/2009, 12:29 AM
John's suggestion is the only way I can imagine this happening. I've created this scenario when I had to cut a second out of vision (bumped camera) but keep all the audio.

If what John is saying what happened then running the sound and vision at the correct speed should cause you to be able to sync the head or the tail but not both. Playing it out with the head synced sould then mean it'd stay in sync until the cut and then jump out. You could get the opposite by syncing the tail.

I'm thinking this though some more and maybe you're right.

If I were to change the speed of an entire program so that two sync points well inside the program aligned them I've got the actual speed wrong. What you need to do is trim what you're speed changing so you're changing the speed of only the potion between the sync points. Hope that makes sense.

Bob.
Chienworks wrote on 11/14/2009, 3:06 AM
If you can't find a discontinuity to fix, you can start adjusting manually. Find a sync point in the middle and Split the audio at that point. Ctrl-drag the two new event ends to the video sync point. You have now restored sync at the 1/2 point without losing it at the ends. If it still drifts noticeably at the 1/4 and 3/4 points then repeat the procedure there, where the error should be proportionately less. Then go for 1/8, 3/8, 5/8, and 7/8 points. Continue refining until there's no noticeable drift.

If you've got more time to play with you should search for the points of maximum drift rather than simply halving each section.

You may eventually come upon a point where the error suddenly increases instead of getting smaller. If you do then you've narrowed down where the original discontinuity happened. If you can locate this spot then i would suggest you restore the original unsplit audio and start over using this point instead of the 1/2 point. Of course, you may discover that the discontinuity is in the video rather than the audio. If this is the case then use the original unsplit audio and do the splitting and adjusting with the video track instead.

Personally, i would disable video resampling. Resampling will introduce blurred or doubled images where it has to combine adjacent frames. I find this more annoying than the cadence issues you'll get without resampling.
Serena wrote on 11/14/2009, 4:14 AM
Thanks Guys. Obviously I haven't made the situation clear. The film and audio tracks (all on separate sprocketed material -- as in the old days) are all in sync. No gaps, no discontinuities, no errors. All as should be. All three have been run in locked sync on my Intercine 35/16 flatbed editor and everything on the film side of things is fine. Absolutely no problems before we transfer to video. The transferred video looks good (well, as good as SD can) and the digitised audio tracks are all fine. The trouble arrives when all three are dropped onto Vegas tracks. Hopefully now my statement of the problem is clearer.
Just to reiterate:
material shot and double head recorded at 18fps.
video transfer was done at (I understand) 16.8 fps (to avoid rolling bars), so I have a 10 minute clip (the whole film).
To match the audio the video must be run faster than transferred, so in Vegas make playing speed 1.073 (about). Audio syncs at head and tail, but progressively in error as approach half way (from both directions). This indicates that the time compression applied by Vegas is not uniform, although I find that hard to believe. Other explanations and fixes welcome. Re-cutting to restore sync is a last resort but if I must I will. I think I mentioned that in the original post.
farss wrote on 11/14/2009, 4:38 AM
Can I suggest two things:

1) Ignore what I said before, it makes no sense now I think about it.
2) Try retiming and pitch shifting the audio to match the vision. I know this will make the movie a bit slower than it should be but:
a) It's already had some pulldown applied to get it into 25fps.
b) I think it's possible Vegas is doing something funky but the only way to be sure without building a test case is to try the other approach. 9.0c should handle the pitch shift.

Bob.
RalphM wrote on 11/14/2009, 5:46 AM
For the original equipment that was used to produce the visual and audio 16mm films - would they have been gear driven off the same mechanical system or shot on two separate machines? Point being, is it possible that you have a visual film that has a speed variance?
Chienworks wrote on 11/14/2009, 6:35 AM
I'm sure Ralph has it right. The projectionist would have occasionally adjusted the speed on either machine during the showing to manually keep them in sync. I know, i've been one of those projectionists a few times, and it's not fun!
johnmeyer wrote on 11/14/2009, 8:34 AM
video transfer was done at (I understand) 16.8 fps (to avoid rolling bars), so I have a 10 minute clip (the whole film).OK, I'm understanding something that I did "get" before, namely: YOU didn't actually do the film transfer or, perhaps, the audio transfer.

This is probably where the problem lies.

First question: What is the audio sampling rate?

Second question: what was the video transfer process? Was it done with a film scanner (e.g., Rank Cintel), or was it done with some sort of projector to video camera technique?

Actually, as I am writing this, I'm thinking that perhaps those two questions may not lead to the problem and the ultimate fix. Perhaps the more important question is this: What are you using for your project properties in Vegas? If the film was really transferred at 16.8 fps, then you should set the project properties to 16.8 fps, and field order should be set to progressive. In addition, you should right-click on the video (film) event, and check that it's fps properties exactly match the rate at which the film was transferred. While I wouldn't expect a sawtooth drift (where sync drifts off in one direction, and then comes back), I do remember back when I first started with Vegas trying to fix some audio problems, and nothing would stay in sync. I'm pretty sure that the reason I haven't had this problem in years is that I got "religion" about always matching the project properties to the media.

Now, if the media is reporting to Vegas properties that are wrong (Vegas just gets this information from the media header) then you have to patch the media. For AVI, there is an old hack called AVI Frame Rate Changer. This is the readme file:

AVI Frame Rate Changer [freeware]
(c) Alexander Milukov, AM Software 2001
-------------------------------------------

AviFrate allows you to change the
frame rate of an existing AVI file.
Also it does change FourCC and other
important things.

Just press the browse button and open an
AVI file, then edit the values. Or you
can pass the filename in the command line.

------------------------------------------
The same feature, among many others,
available in AVIedit (c) AM Software.

Visit us at http://www.am-softhome.com
http://www.am-soft.ru

Author's e-mail:
alexander@am-soft.ru
milukov_a@mtu-net.ru
mil_alex@usa.net

Hope that helps!

P.S. The advice given earlier about disabling resample is a good one. I always edit with that turned off. If the video requires pulldown, I do that with a separate application. Vegas' blending algorithms are completely wrong for film to video transfer. For odd frame rates (i.e., anything other than 24p) I have to create my own pulldown algorithms. These are all variations on the usual 3:2 (where every alternating frame of film gets placed on one frame of video, plus the top (or bottom) field of the next frame. This process of field duplication can be extended to any arbitrary pattern and can eventually produce any pulldown pattern you can think of.

Here's an AVISynth script showing some of the more common pulldoan patterns I use:

AVISource("E:\frameserver.avi")
AssumeFrameBased


# Pulldown for 24 fps
#separatefields()
# SelectEvery(8, 0,1, 2,3,2, 5,4, 7,6,7)

# Pulldown for 18 fps using repeats normal-repeat-normal-weave-normal
#separatefields()
#selectevery(6, 0,1, 0,1, 2,3, 2,5, 4,5)


# Pulldown for 18 fps using all weaves normal-weave-normal-weave-normal (I like this the best)
#separatefields()
#selectEvery(6, 0,1, 0,3, 2,3, 2,5, 4,5)

# Pulldown for 18 fps using a technique in the Doom forums (seems to produce same as above)
#changefps(59.94)
#separatefields().selectevery(4,0,3)
#separatefields().selectevery(4,1,2)

#Pulldown for 16 fps using all weaves
separatefields()
SelectEvery(16, 0,1, 0,3, 2,3, 2,5, 4,5, 4,7, 6,7, 6,9, 8,9, 8,11, 10,11, 10,13, 12,13, 12,15, 14,15)

weave()
AssumeFPS(29.97, true)

farss wrote on 11/14/2009, 1:01 PM
John,
Serena is working in PAL i.e. 25fps. The film was run at 16.8fps into 25fps not 18 into 24fps.


I was at an auction yesterday and could have bought an Ikegami telecine and 16mm audio follower for scrap metal prices. Only thing stopping me was space to store the units, a big truck and a very strong back.

Not to get OT but I was left breathless by the price a very early Neve mixer went for. Despite the dirt, grot and bird droppings on this mixer it fetched $15,5000. Part of the appeal I was told was this was a very early serial number unit that was built by hand by The Man himself.

The only double head systems I've worked with the audio tape and the film was run from one motor, lots of shafts and bevel gears. Speed might not have been accurate to atomic time but very, very unlikely the system could loose sync. I'm not 100% certain about telecines and audio followers. The units are not mechanically locked, I suspect they were servo or syncronous motors though.


Bob.
Serena wrote on 11/14/2009, 1:59 PM
Morning again, so have just caught up with posts.
Ralph, no speed variation. Standard cine double system -- you remember Pilotone?
Kelly, yes I've done that too. But again see my check on flatbed.
John, no I had the transfer done by one of those film to DVD businesses who use a cheaper process and output a 50i (PAL) video. A film scan costs rather more (0.66c/foot) but has obvious advantages. Yes, I tried disabling resampling and got the same result and project properties are set to 50i 48KHz. After breakfast I'll properly read your advice and look into its ramifications. Also I'll get more quantitative about the variation of the sync error, for that may be instructive. This job is but one of several more of similar nature, so I'm spending a bit of time on it. I expected it to be a "no brainer", and I suspect the cost of my recutting or of film scanning will make it unattractive.
Bob, yes, finding room for these bargains is a great problem.
Serena wrote on 11/14/2009, 6:08 PM
To satisfy my curiosity I plotted the sync error against running time of the clip. Some of the sound cuts are not easily picked, but accepting those variations (including a 0.36sec tail sync error not adjusted) the error curve is parabolic. I doubt that you want to know, but the fitted curve is:
sound sync error= 3E-05t.t - 0.0184t + 0.821
where t is the time (secs) from start, the max error being 2.2 seconds lag at 50% of clip (300 seconds).

I think there is something funny (unexpected) about the way Vegas handles changes in clip playing time. However I'll have to plot the error for the clip at normal speed before I can be sure of that.

Serena wrote on 11/14/2009, 7:33 PM
As I expected, at normal playing speed (video clip) the sound falls behind linearly with time. The problem is in Vegas.
johnmeyer wrote on 11/14/2009, 8:18 PM
Bob, thanks for the reminder that she, like you, is in down-under PAL land. That means my pulldown scripts are useless.

Serena, what version of Vegas are you using? I sure haven't experienced any of this in Vegas 7.0d or 8.0c, but I never upgraded to 9.x, in part because of all sorts of reports that the underlying timecode stuff may have been messed up (you'll see a few posts back in the spring in the scripting forum).

So, the first thing would be to move it back to 8.0c or 7.0d.

The next thing I would suggest is to forget about doing ANY stretching or fooling around in Vegas. I sort of suggested this in a previous post, but let me make the suggestion more concrete: I would use AVIFrameRate to change the header of the video AVI file (do this on a copy) so that it matches EXACTLY the rate of your audio. You can put any number you want into the header of an AVI file, and your computer programs (including Vegas) will dutifully play back the frames at a faster or slower rate. I do this all the time with AVIs I get from captured film because who the heck knows (for silent film) what fps the film camera was running at? Most of my stuff is either really old (from the 1920s) or is from home cameras. The point is that changing this header is exactly like changing the speed control on a film projector (for those projectors that had such a control): the number of frames displayed is exactly the same, but each frame is simply displayed for a little longer or shorter amount of time.

This is a totally harmless exercise, and take about five seconds (or however long it takes to type two numbers).

Doing it this way, you don't have to rely on Vegas to do ANYTHING.

Here's the link to the page that has the utility:

AM Software AVIFrate

If I understand your situation, the audio was recorded such that it should sync perfectly if your video can be made to play at 18 fps instead of 16.8 fps. So, in this utility, open the AVI file that contains the film video, and enter 1 for scale and 18 for rate. Click on Apply. The patch happens instantly. Then, set the fps in the Vegas project properties to 18 fps (this was what I was trying to get you to change). Put the modified video and the original audio on the timeline. They should now line up to exactly the same length.

Turn off re-sample for the video.

This pretty much takes Vegas out of the loop.

I'd still be interested in what version of Vegas is giving you this problem. Like I said, I've done a lot of things that seem like they are identical to what you are describing and never seen Vegas behave like this.




Serena wrote on 11/14/2009, 9:59 PM
Thanks John, I'll get onto AVIsynth and implement your advice. I'm using Vegas 9c but yesterday did try v8 to see if it did the same thing. Bit of a day off today!
Apit, the audio is uncompressed.
johnmeyer wrote on 11/15/2009, 12:22 AM
No, you don't need to do anything with AVISynth. I was suggesting using AVIFrate, a very simple one-trick-pony utility.

The fact that you are using Vegas 9.0c is VERY interesting. I'll look forward to hearing if you get the same results (and same problem) with 8.0c.
Serena wrote on 11/15/2009, 1:33 AM
Thanks again John. I'll get it right yet! Ah, I wasn't clear: 8c gave the same result.
Serena wrote on 11/15/2009, 3:40 AM
Actually I did download AVIRate (not AVISynth) and it seems not to work under Windows 7; does under Vista. The result is very encouraging. I think I need to use a fractional frame rate to get the correct result, which doesn't seem to be permitted. The avi I need to modify is recognised by AVIRate as 25fps, so to achieve the running time matching the audio I need to change that to 27.182fps. I tried 27 and the result is quite close. That the correct projection speed of the film was 18fps is, I think, lost through the transfer process. Will do more tomorrow. Thanks John, you've provided the solution.
LarryP wrote on 11/15/2009, 7:58 AM
I did notice that if you have SF10 installed the élastique time stretch plug in "time stretch ratio" can be automated with an envelope.

Being a plug in getting the correct effect could be challenging.

Larry
johnmeyer wrote on 11/15/2009, 8:16 AM
result is very encouraging. I think I need to use a fractional frame rate to get the correct result, which doesn't seem to be permitted. Being a hack, AVIFrate is not very intuitive. However, you can get pretty much ANY framerate you want. The key is the "scale" setting. I told you to set it to [edit] one, but in fact you can use anything you want. It is actually the denominator and the Rate is the numerator in a fraction that determines the actual frame rate. So, for example, if you lived up over (is that the opposite of "down under"?) and needed to get 29.97, you would enter 1001 for Scale and 30000 for Rate. This gives you the exact definition of how the "29.97" rate is derived (1000/1001 * 30).

I am not exactly clear as to what frame rate you need, or I'd offer the numbers needed to achieve it. However, to get fractional results, just multiply the frame rate by 1000, enter that for rate, and then put 1000 into the "scale" entry. Thus, to get 16.8 (your original frame rate), you'd enter 1000 for Scale and 16800 for Rate.

Hope that helps.
farss wrote on 11/15/2009, 12:51 PM
I'm not convinced that changing the playback speed f the AVI is such a wise move. Vegas will still have to conform it to 50i, that means either it'll interpolate (if enabled) or add some form of pulldown.
That might have been OK however the footage was already messed with in the telecine process. A second generation of the frames being futzed with is probably not going to help the images at all.
Given that the speed change required is only 7% I'd be changing the audio's speed. With the new pitch shift algorithm in V9.0c this might have less impact on the quality of the final product.

I also thought about the telecine process that might have been used. The cheapo telecines that I used to use all used variable speed motors. Nothing crystal locked about them at all. I more than once adjusted the speed during a transfer. Even without me nudging the pot this system would have had a lot of drift.
I know Serena says the offset between sound and vision of the original was linear however it's pretty hard to tell this without precise measurement. My quick tests with Vegas were unable to reproduce a condition in which Vegas would "squeeze" playback rate rather than do a linear change. I'm really leaning towards the problem being with the telecine process and not Vegas.

Bob.