Page 1 of 1

Best way to convert Audio from 29.97 fps to match 23.976 vid

PostPosted: Tue Aug 02, 2022 9:22 am
by david73
Hi all-

I am looking for the best / most efficient way to convert Audio files from 29.97 fps to match 23.976 video.

I shot a 2 day short film with the camera video set to 23.976 fps.
The sound was recorded at 29.970 fps.

Any software recommendations or best practices are much appreciated.

Thanks-
David

Re: Best way to convert Audio from 29.97 fps to match 23.976

PostPosted: Sun Aug 07, 2022 7:26 am
by Marc Wielage
Fire the audio guy!

Aside from that, you could just try to sync up the audio by hand (even though the timecode numbers may not match a timecode slate) and see if it drifts. Since both the camera and sound were running at non-integer frame rates (23.98 / 29.97), I think it shouldn't drift provided they have really good internal crystal references. You'd have a bigger problem if one was at 24.00 and the other was at 29.97, that kind of thing.

If it's 29.97 drop-frame, run screaming from the room...

Re: Best way to convert Audio from 29.97 fps to match 23.976

PostPosted: Sun Aug 07, 2022 9:08 am
by Reynaud Venter
Zynaptic Time Factory (Stand-alone and macOS only)
https://www.zynaptiq.com/timefactoryii/ ... -overview/

Batch processor which supports multichannel sources and multiple rates.

Re: Best way to convert Audio from 29.97 fps to match 23.976

PostPosted: Sun Aug 07, 2022 5:27 pm
by Robert Niessner

Re: Best way to convert Audio from 29.97 fps to match 23.976

PostPosted: Tue Aug 09, 2022 8:34 pm
by mpetech
david73 wrote:Hi all-

I am looking for the best / most efficient way to convert Audio files from 29.97 fps to match 23.976 video.

I shot a 2 day short film with the camera video set to 23.976 fps.
The sound was recorded at 29.970 fps.

Any software recommendations or best practices are much appreciated.

Thanks-
David


Audio has no frame rate perse. It is sample based. Your issue is timecode.

The best way is to visually match or use audio waveform sync, restrip the TC and apply the new TC.

Re: Best way to convert Audio from 29.97 fps to match 23.976

PostPosted: Sat Aug 13, 2022 10:12 pm
by Andrew Kolakowski
Audio will be fine as it doesn't 'care' about fps. Audio is recorded in "realtime". Sync beginning and it should be fine. Possible small desync can appear due to clocking imperfection inside cameras, but if it's not too long it should be fine.

Re: Best way to convert Audio from 29.97 fps to match 23.976

PostPosted: Sat Aug 13, 2022 10:19 pm
by Andrew Kolakowski
Marc Wielage wrote:Fire the audio guy!

Aside from that, you could just try to sync up the audio by hand (even though the timecode numbers may not match a timecode slate) and see if it drifts. Since both the camera and sound were running at non-integer frame rates (23.98 / 29.97), I think it shouldn't drift provided they have really good internal crystal references. You'd have a bigger problem if one was at 24.00 and the other was at 29.97, that kind of thing.

If it's 29.97 drop-frame, run screaming from the room...


24 vs. 29.97 would still mean nothing bad for audio. In both cases recording is in realtime, so audio is "the same". You can forget about TC in this case as it's meaningless.
If you record 5min in camera A and B then fps which they were set doesn't matter. In both cases you have same length. Only differences is number of frames which you have, but actual video and audio is stil "the same" and TC has nothing to do with it. Replace TC with time (clock time) and you can't even tell (unless it's 24p vs 60p, so you can judge motion blur) which recording is from which camera.

Fractional fps only cause 'logical issue' when you think about it as 'frames per second' as then it's hard to imagine that we have eg. 29.97 frames per second. Reverse logic and say that frames are taken at 1/29.97th of a second (or more precisely 1001/30000 of a second) and suddenly this works same as any integer fps as we can "take" a frame at any time difference: 1/25, 1/30, 1001/30000 etc.

Only issue is quality of the internal clock inside camera. This is never perfect and for long recordings it will create small desync, hence multicam recordings use a single source of the clock (then it doesn't matter if quartz is not perfect as all cameras sync to it).

SMPTE TC is not well suited for fractional fps. In this case better to use frame numbers or even time with milliseconds. Then any fps works :) DF is just a bad hack which no one even bothers to use for 23.976p (this uses 24p TC and drifts from realtime), but it's used for 29.97.

Industry was brave enough to abandon interlacing for UHD format, but not brave enough to abandon fractional fps, which they should, as today they serve no role (it was needed for analog transmission). Don't know a TV which doesn't support 30p/i or 60p/i. Any legacy need originated from 30/60 UHD recording could be always slowed down as this is easy and causes no real issues. In few years fractional fps would disappear for good. Go further and stop fps madness for good introducing 1 worldwide standard. Standard can mean eg. 3 fps- for film, normal, sport. It should be designed in the way so they are easily convertible.
If people like film then use 24 as base and then make others eg. 48 and 72. These are as good numbers as 50 or 60, which have no any special meaning at all. You can also use 25, 50, 75 as 25 is as good for film as 24 (if tech is there you can keep going up by 25 increments).
TVs support (or can easily support) any of those numbers, so there is about nothing what needs to be done. Old content stays as is, new one uses new standard. Plain simple. 100x better than SMPTE crazy idea of 300fps proposal (which stalled for years) and it will never materialise. Whole fps madness cost so much problems, time, money, and conversion etc. every day. Yet SMPTE idea to solve it is 300 which is unrealistic for many years to come and comes from some short sited thinking that we need to keep using 24, 25, 30, 50, 60 values. We don't.
At least services like Netflix etc. don't care about fps and support all of them. And it works!

update: looks like SMPTE 300fps idea is abandoned for good