Duplicating 249 out of every 1001 fields

[Katie Boundary]

Correct me if I'm wrong but couldn't 24 fps material be converted to 30,000/1,001 with no speed change whatsoever by duplicating 249 out of every 1001 fields, rather than slowing down by 0.1% and then duping every fourth field?

[hello_hello]

I haven't done the math but even if it was correct it'd be a convoluted telecine process that'd be harder to reverse, and I suspect unlike the traditional pulldown pattern where for every five frames there's three "clean" frames and two "dirty" frames, the percentage of dirty frames would be a lot higher. It might be do-able now, but back in the early days of NTSC I doubt the technology existed, and it's probably still not worth it to correct an undetectable speed change, especially as DVD is a previous generation format and newer formats such as Bluray support 24p.

[johnmeyer]

A 0.1% speed change is completely impossible to detect, so there is no reason to avoid it on the video side. For the audio, modern speed change algorithms can handle even 1-2% speed changes without any discernable flanging or other issues. So for the audio, 0.1% speed change would be completely impossible to detect.

I do both of these things almost every day (add pulldown and adjust audio speed while maintaining the pitch) and have done extensive tests to make sure the results are optimal. Thus, I am quite certain about both of these statements.

I'd also point out that standard 3:2 pulldown is very easy to do and generates very predictable, and very uniform results. One thing you always want to avoid when adding pulldown is an irregular pattern. All pulldown accentuates the judder inherent in low framerate video (such as 24 fps film), but when you have an irregular pattern, any occasional extra or missing field will usually stick out like a sore thumb.

[manono]

Correct me if I'm wrong but couldn't 24 fps material be converted to 30,000/1,001 with no speed change whatsoever by duplicating 249 out of every 1001 fields, rather than slowing down by 0.1% and then duping every fourth field?
Are you asking about hard-telecining it? If so, why? First, as johnmeyer mentioned, it's a complete waste of time. Second, hard-telecining is not at all encoder efficient and results in a much lower quality result for the same file size than if you had encoded it progressively to begin with. And third, you can soft-telecine it as easily as you can apply standard 3:2 pulldown.

It will change the length slightly, though, if the source is 23.976fps, and require reencoding the audio.

[Katie Boundary]

A 0.1% speed change is completely impossible to detect, so there is no reason to avoid it on the video side. For the audio, modern speed change algorithms can handle even 1-2% speed changes without any discernable flanging or other issues. So for the audio, 0.1% speed change would be completely impossible to detect.

It's not about being able to "detect" anything. It's about appeasing the obsessive-compulsive demons. The guys at Mainframe have the same demons; they convert from 25p to 29.97 by duping 199 out of every 1001 fields.

Are you asking about hard-telecining it?

No.

[Sharc]

Correct me if I'm wrong but couldn't 24 fps material be converted to 30,000/1,001 with no speed change whatsoever by duplicating 249 out of every 1001 fields, rather than slowing down by 0.1% and then duping every fourth field?
Yes, theoretically it should be working.

[manono]

The guys at Mainframe have the same demons; they convert from 25p to 29.97 by duping 199 out of every 1001 fields.
That's better than field-blending PAL to NTSC, but not nearly as good as encoding as progressive 25fps and then adding 3:2:3:2:2 pulldown. At least the hard telecine can be 'IVTC'd' back to progressive 25fps.

Are you asking about hard-telecining it?
No.
So you're planning in leaving it as separate fields? If you plan on weaving it back into frames then it's hard telecined. And encoding it as 24fps and adding soft pulldown is a much better solution. Unless I'm misunderstanding something, Always possible.

[colours]

I suspect unlike the traditional pulldown pattern where for every five frames there's three "clean" frames and two "dirty" frames, the percentage of dirty frames would be a lot higher.

The pattern of combed/clean frames would be different and have a period of 1250 frames, but the overall proportion of combed frames would remain at exactly 40% (i.e. 500 combed frames every 1250).

[Ghitulescu]

The 0.1% speed change was historically motivated.
The issue that caused this change was solved decades ago.
I still wonder why people do not abandon it and stay with 30fps, that would work also with old materials.

About duplicating frames - this is not a good method.

[filler56789]

From 4 frames (8 fields) per 1/6 second to 5 frames (10 fields) per 1/6 second:

AA, BB, CC, DD → AA, BB, BC, CD, DD

And after 199 sequences of 5 frames, there must be 1 sequence of 4 frames.

Well, at least this is the way I would do it...

I still wonder why people do not abandon it and stay with 30fps, that would work also with old materials.

The same reason why ASCII has not been incinerated yet, I presume.

[Sharc]

From 4 frames (8 fields) per 1/6 second to 5 frames (10 fields) per 1/6 second:

AA, BB, CC, DD → AA, BB, BC, CD, DD

And after 199 sequences of 5 frames, there must be 1 sequence of 4 frames.

Well, at least this is the way I would do it...

Possible, but it would break the cadence which could cause a problem for some DVD players I think, e.g. trigger these to switch (temporarily) into video deinterlace mode.

[manono]

Possible, but it would break the cadence which could cause a problem for some DVD players I think, e.g. trigger these to switch (temporarily) into video deinterlace mode.
If it's hard telecined it will have been encoded as interlaced and the vast majority of players (the flag reading ones) are just going to deinterlace the whole thing anyway.

It's only the relatively few cadence readers that will perform an on-the-fly IVTC so-to-speak and might conceivably trip over that break in the usual cadence. But I don't think they will because it usually takes even a very good DVD player (think Oppo or Denon) a few frames to adjust.

[Katie Boundary]

That's better than field-blending PAL to NTSC, but not nearly as good as encoding as progressive 25fps and then adding 3:2:3:2:2 pulldown.

In other news, 2 is more than 1 but not as much as 3.:D

So you're planning in leaving it as separate fields?

No. Why the hell would I do that?

And encoding it as 24fps and adding soft pulldown is a much better solution.

The only solution worth considering.

[Music Fan]

By the way, when movies are converted (slowed-down) from 24p to 23.976p by the studios for Blu-rays for example, is the sound slowed-down too or is another method used (resynch every x minutes) ?

[wonkey_monkey]

Most likely simply slowed down. It's such a a tiny change it doesn't warrant doing anything more complicated. You'd have to resync probably at least once a minute to avoid it drifting noticeably if you weren't going to slow it down.

[Music Fan]

Ok, but anyway something has to be done ; otherwise, for a 2 hour movie (7200 sec), one would get a 7 second delay at the end, it's quite big.
But I wonder if changing audio's duration so slightly (0,1 %) is that simple ; calculations are maybe more complex than simply doubling or halving it, as if only one frame had to be added every 1000 frames keeping the fluidity (to make a comparison with video).

[johnmeyer]

Ok, but anyway something has to be done ; otherwise, for a 2 hour movie (7200 sec), one would get a 7 second delay at the end, it's quite big.
But I wonder if changing audio's duration so slightly (0,1 %) is that simple ; calculations are maybe more complex than simply doubling or halving it, as if only one frame had to be added every 1000 frames keeping the fluidity (to make a comparison with video).Yes, it is that simple. One click. You can do it with or without pitch correction, but the change is so subtle, you'd probably never hear the pitch change.

The reason it is so simple is that audio is a completely different animal than video when it comes to changing duration. Why? Well, neglecting, for the moment, the sampling issues with digital audio, here is the big difference: film & video are a series of discrete objects; but audio is continuous. Thus, when you change playback speed of video, you end up either with repeated fields and/or frames, or you end up with lots of fields/frames that have been synthesized via blending of adjacent fields/frames, or via motion estimation. With audio, you just compress the waveform a little.

Even once you factor in the digital audio sampling issues, changing playback speed is still a trivial exercise because there are 48,000 audio samples per second, as opposed to (at most) 60 "samples" per second with video.

Thus, to a first approximation, video is discrete; audio is continuous.

[Sharc]

If it's hard telecined it will have been encoded as interlaced and the vast majority of players (the flag reading ones) are just going to deinterlace the whole thing anyway.

It's only the relatively few cadence readers that will perform an on-the-fly IVTC so-to-speak and might conceivably trip over that break in the usual cadence. But I don't think they will because it usually takes even a very good DVD player (think Oppo or Denon) a few frames to adjust.
Is it the standard rule or just good practice to set the Progressive_Frame flag to FALSE for ALL frames of a hard telecined stream?
Alternatively one could set the Progressive_Frame flag to TRUE for the "good" frames and to FALSE for the "combed" frames (e.g. HCenc has this option by selecting "auto detect" mode). Even a flag reading DVD player could then theoretically detect the cadence based on the pattern of the Progressive_Frame flag and initiate IVTC without having to analyze the frames. I have however seen a kind of strobing or flicker with adaptively changing Progressive_Frame flags (possibly also caused by the change of the chroma downsampling pattern), but I don't know whether the behavior of my player is the exception or the rule.

[Music Fan]

@ johnmeyer ;
Ok I see, but there are also samples in digital audio, it's not as continuous as analog.

[johnmeyer]

@ johnmeyer ;
Ok I see, but there are also samples in digital audio, it's not as continuous as analog.That's why I said "to a first approximation." Actually, digital audio is even closer to being continuous than just a first approximation; it's pretty much the same thing when it comes to this specific task of slightly stretching or compressing the audio. And, the modern algorithms let you keep the pitch, even with +-5% changes, without getting any noticeable flanging or other artifacts.

[Sharc]

The reason it is so simple is that audio is a completely different animal than video when it comes to changing duration. Why? Well, neglecting, for the moment, the sampling issues with digital audio, here is the big difference: film & video are a series of discrete objects; but audio is continuous. Thus, when you change playback speed of video, you end up either with repeated fields and/or frames, or you end up with lots of fields/frames that have been synthesized via blending of adjacent fields/frames, or via motion estimation. With audio, you just compress the waveform a little.

Avisynth's AssumeFPS(xx) does neither duplicate nor skip nor blend anything. It just changes the playback speed of the video as I understand it.
I can't see a principal difference between digital audio and digital video (apart from the 1 or 2 dimensions): Audio samples represent (1D) snapshots (samples) of the analogue waveform, and digital video is either derived from snapshots (=samples) taken at about 13.5 MHz of the legacy analog video signal, or snapshots of the natural (analog) world taken by the film camera at usually 24 shots (pictures) per second in 2D, or digital 2D snapshots taken by a digital video camera at the usual (standardized) framerates.
Similarly, if the frequency of the snapshots (sampling frequency) is too low, we get aliasing for audio (distortion) and video (wheels turning backwards).
As I see it, AssumeFPS() is quite comparable to stretching or squeezing the audio (with or without pitch correction).

[Music Fan]

There is though a major difference : with AssumeFPS(), you don't modify any frame, they are simply displayed longer or shorter while you can't do it with the sound when you change its speed (whatever you correct the pitch or not), new samples have to be calculated.

[wonkey_monkey]

There is though a major difference : with AssumeFPS(), you don't modify any frame, they are simply displayed longer or shorter while you can't do it with the sound when you change its speed (whatever you correct the pitch or not), new samples have to be calculated.

You can assumesamplerate to change speed and pitch (not indepedently) without resampling. Whether or not you'll get playback is a different matter, since soundcards only like certain sample rates.

[Sharc]

You can assumesamplerate to change speed and pitch (not indepedently) without resampling. Whether or not you'll get playback is a different matter, since soundcards only like certain sample rates.
Yes. Same as AssumeFPS(....,sync_audio=true)

[Music Fan]

Ok, I didn't know this, but it would be out of standards.

[StainlessS]

Ok, I didn't know this, but it would be out of standards.

ReSampleAudio()