Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Johnny B]

When slowing down PAL content (25->24 FPS) only video is slowed but audio is not e.g. it is stretched. What am I doing wrong?
Following wiki I imported the test file into MC database, manually changed FPS from 25 to 23,97. Now when I start playback, refresh rate does automatically change to 24 Hz (using internal, in madVR it is disabled), video is played slower (e.g. 24 FPS instead of 25) BUT the audio stays at the same pitch, however I want (and expect) it to be slowed down accordingly (gramophone effect).
Basically what I need is the ReClock's "PAL SpeedDown" checkbox functionality (see attached picture) which works with other players as expected.

[Johnny B]

bump
I mean am I right assuming audio SHOULD be pitched down, right? As it is mentioned in wiki here:
http://wiki.jriver.com/index.php/VideoClock

..."This feature is also useful for PAL content that was originally shot at 23.97 fps and is recorded on disc or media at 25 fps. If played back at on a display set to 25 or 50 Hz, the movie would be slightly shorter and the audio pitch would be slightly higher. When playing these 25 fps files with the display rate set at 24 Hz, the movie will be played at the correct rate and the audio at the correct pitch. This requires the fps setting for these files to be changed to 23.97 fps."

I did however it does not work that way.

[Hendrik]

Your post seems quite confusing, you seem to swap the meaning of "timestretching" in the post a few times, sometimes meaning "change pitch" and sometimes "do not change pitch", or your definition of "original pitch" is weird, either one of those.
I think its a bad term to use generally, as noone is going to know what it really means anyway.

I'm also not convinced that its a good idea to change the default behavior from what it is today.

[Johnny B]

I don't think he does - although it might be confusing to some it actually makes perfect sense to me.
And as to "noone is going to know"; the term "timestretching / time stretch" is a regular known phrase in audio world describing the process which simply means "same pitch but different length" (like speeding up / slowing down the tempo of a song preserving the pitch / key) and the other term is "pitchshifting / pitch shift" which always changes the pitch either preserving the same length (simply transposition / key change) or slowing it down (turntable effect e.g. lower pitch AND longer time)

[Johnny B]

I'm also not convinced that its a good idea to change the default behavior from what it is today.

Do you realize that the way it is now MC behaves differently from how it is described in jwiki?

[Hendrik]

And as to "noone is going to know"; the term "timestretching / time stretch" is a regular known phrase in audio world describing the process which simply means "same pitch but different length" (like speeding up / slowing down the tempo of a song preserving the pitch / key) and the other term is "pitchshifting / pitch shift" which always changes the pitch either preserving the same length (simply transposition / key change) or slowing it down (turntable effect e.g. lower pitch AND longer time)

You should be able to understand what the options do without being an expert in the audio world, or having to look them up.
Even more-so because its a video option.

[6233638]

Removed original post for clarity.

Timestretching adjusts the speed while preserving pitch.

When films or US television shows are released in PAL territories, they were sped up from 24 FPS to 25 FPS, typically without any timestretching applied.
This means that the audio on the DVD is higher pitch than the original.
To fix this, you need to play back the 25 FPS DVD at 24 FPS without time stretching, since that will restore the original pitch.
If you play back 25 FPS at 24 FPS with time stretching, it preserves the high pitched result, instead of correcting the pitch.
 
 
It is a similar situation with Blu-rays released in NTSC regions. Film is shot at 24 FPS.
In PAL regions Blu-rays are often released at the native 24 FPS.
In NTSC regions they are slowed down to 23.976 FPS.
 
When slowing them down to 23.976 FPS there is typically no timestretching applied.
So if you speed them up to 24 FPS with timestretching, you are preserving the pitch on the disc, only it is the wrong pitch.
 
 
 
However there is some content which should use timestretching.
Anything filmed natively in the PAL format e.g. European TV shows shot at 25 FPS should use timestretching when played at 24 FPS.
If you did not use timestretching they would be pitched down which sounds very wrong.
 
That's why you need to be able to tag files in a way which enables/disables timestretching, because there is no way to automatically determine which would be most appropriate.
 
 
Timestretching should not be the default, since I would assume that most people are using VideoClock with films - where you are dealing with 23→24 FPS or 25→24 FPS conversions.
The only content that timestretching should be used with, is something shot natively in the PAL format, which generally only applies to television shows/documentaries. Or the rare films which were sped up to 25 FPS with timestretching.
 
 
Ideally there would be a user preference to set the default behavior for VideoClock (timestretching on/off) with a manual override of the default available via tagging - whether that is specifying that timestretching should be on or off for that file.
If it's a preference, then people can decide whether they want to disable timestretching, or use the current behavior (which is to use timestretching on every file) though I would suggest that timestretching should be optional, with rate adjustments rather than tempo adjustments being the default.

[JimH]

Expect no change.

[Johnny B]

Expect no change.

Again, do you realize that the way it is now MC behaves differently from how it is described in jwiki? So who is wrong - MC or jwiki?

And does it mean is is impossible to play 25 FPS file (which WAS originally 24 FPS) in its correct pitch e.g. pitched down using VideoClock in MC now and even in future?

[glynor]

So who is wrong - MC or jwiki?

Always the wiki, as I think most would assume to be obvious.

The wiki is user-contributed.  If you write up a simple edit to what the Wiki's text should say and post it here, I'll fix the wiki later.

[Johnny B]

Always the wiki, as I think most would assume to be obvious.

Why obvious? I mean whoever wrote that article was describing the behaviour in MC and not just fantasizing - this is definitely what I would assume to be obvious. It surely is possible that some behaviour in MC might get changed (unintentionally) and nobody would spot it, which in this case could very much be the case as most people here (incl. creators) are in America and are not affected by this European PAL issue.

[glynor]

Because the object of the wiki is to describe the application. If the two don't agree, then obviously the wiki is incorrect because it has failed at its reason for being.

[Johnny B]

Because the object of the wiki is to describe the application. If the two don't agree, then obviously the wiki is incorrect because it has failed at its reason for being.

My point is that at the time of writing the article it most probably WAS actually describing the application but since then something happened in MC (unintentioanally) which only now makes jwiki irrelevant (and in my opinion MC wrong, logically)

[glynor]

My point is that at the time of writing the article it most probably WAS actually describing the application but since then something happened in MC (unintentioanally) which only now makes jwiki irrelevant (and in my opinion MC wrong, logically)

Exceedingly unlikely*, and ultimately irrelevant.

If the Wiki and MC are in conflict, the raison d'ętre of the wiki is to describe MC.  Therefore, the wiki is wrong.

* That article was written by NickF (a user, not a JRiver employee) in 2012. I'm sure he just made a mistake or didn't fully understand how it worked.

[glynor]

I should note, I was only commenting on the repeated use of the error on the wiki as some kind of "evidence", which to me is absurd. Its like if Wikipedia and Reality were in conflict, arguing that reality should change to match the Wikipedia entry.  Perhaps that would be better, but that's irrelevant.

If you want to go back and install builds from March 2012 and test them and see if NickF was actually right way back then, and figure out when the change was made to change it, then great.  But, barring that, the most likely explanation is that NickF was wrong when he wrote the entry. Of course, even if that were the case, who's to say it wasn't changed on purpose because someone else came along in 2014 with a convincing argument of why it should be the opposite way?

I could not care less about how MC handles PAL content, so I'm making no comments on any changes here pro or anti, and my comments should not be construed to mean anything in that vein.

[Johnny B]

...Its like if Wikipedia and Reality were in conflict, arguing that reality should change to match the Wikipedia entry.

Come on, comparing reality to software application which is going through constant changes / updates (which DO lead to unintentional functionality changes - see fixes) is not fair...

Anyway, so to make some conclusions:
jwiki's article about VideoClock is wrong since it was written, and it is and will be impossible to use VideoClock the way ReClock's checkbox "PAL SpeedDown" functions, correct?
Pitty...

[glynor]

jwiki's article about VideoClock is wrong since it was written, and it is and will be impossible to use VideoClock the way ReClock's checkbox "PAL SpeedDown" functions, correct?

That seems to be what you said from the outset, and 6233638 seems to agree (though I admit, my eyes glazed over in his explanation).

I have no PAL content, so I don't know, and can't test.

As I said, if you write me an edit for the Wiki that properly describes what it does, I'll alter the wiki to properly reflect reality. I can't speak to what it should do or shouldn't do. It does what it does, unless Hendrik is convinced to change it. He sounds unconvinced, and he lives in PAL-land, so it seems like it might not be that big of a deal.

[Johnny B]

He sounds unconvinced, and he lives in PAL-land, so it seems like it might not be that big of a deal.

Oh trust me it IS a big deal! Because apart from music content and original European TV shows ALL the other video stuff (almost all movies and all American shows) released in Europe are played at wrong (higher) pitch!
And the point is not to flip the behaviour from one to another but to allow both options.

[thecrow]

I have to say that being a european this is a big deal and the way MC behaves is wrong.
I am also surprised by the attitude from the MC staff regarding this.

[glynor]

To be clear, I'm not JRiver staff.  Just a guy.

[glynor]

I'm also confused. It seems like there are two options for what is "right" and there is no way to automatically select the proper answer. If I understand correctly, what MC does now is "right" for modern, mostly-HD content.  It is wrong for older, mostly-SD content.  Is this correct?

EDIT: Hendrik, can you comment on what the wiki should say?

[6233638]

I'm also confused. It seems like there are two options for what is "right" and there is no way to automatically select the proper answer. If I understand correctly, what MC does now is "right" for modern, mostly-HD content.  It is wrong for older, mostly-SD content.  Is this correct?

Well it mostly shouldn't apply to HD content.
Most HD content is either released at 23/24 FPS or 50 FPS if it's natively shot at that rate and all of those are fine with TimeStretching.

Technically though, it would apply to Blu-ray releases in NTSC regions since they are often released at 23.976 FPS rather than the original 24.
However this is such a small change that it doesn't really matter whether it is a tempo or rate adjustment applied.
 
That said, I do have a handful of films which were released as 1080i50 rather than 1080p24.
That was back before they figured out they could just release 24 FPS films on Blu-ray in PAL regions without any problems.
I guess they still release 23.976 in NTSC regions out of habit, and because it's such a small change that it doesn't really matter. (23.976 is used to "fit" into the old 59.94Hz NTSC standard using a 3:2 cadence)
Those 1080i50 discs deinterlace to 1080p25 and need pitched down to sound correct (no timestretching) since they are hollywood films that originated at 24 FPS.

I could be mistaken, but I don't think Hendrik watches much SD content at all, which is why it's not a concern for him.
Jim is in the USA and probably doesn't import any media, so it won't be a concern for him either.
Anyone in PAL/SECAM territories (most of the world) still watching DVDs is affected by this however.
 
A 4% change in pitch (25 FPS→24 FPS) is a big change that is easily noticed.
Some people are bothered by it all the time, but others may actually not be bothered by it until they are watching a film and a song they know plays on the soundtrack. Then it's blatantly obvious that it sounds very wrong.
 
Since MC includes both tempo and rate controls, a "simple fix" would be a universal preference below the enable/disable VideoClock option which enables/disables TimeStretching with VideoClock.
Really though, an ideal solution would let you tag the files in a way which forces TimeStretching on/off for that specific file, with the default state honoring the aforementioned preference.

[Johnny B]

It seems like there are two options for what is "right" and there is no way to automatically select the proper answer.

Correct

If I understand correctly, what MC does now is "right" for modern, mostly-HD content.  It is wrong for older, mostly-SD content.  Is this correct?

Not exactly. Basically only DVDs released in / for Europe are affected however it applies to latest movies / American TV shows too.
For Americans the audio processing does not need to be used (almost) at all in most cases as NTSC DVDs support (are released) 23,97 and 29,97 FPS - in such case MC simply changes display refresh rate to 24 / 30 (60) Hz and does very little audio processing (e.g. not noticeable) . However PAL DVDs support only 25 FPS, therefore in order to put the originally 24 FPS content on 25 FPS medium the movie / show is played "faster" when using refresh rate 50 Hz (25 frames per second instead of 24) which not only makes the video content shorter (faster) BUT audio higher (pitch shifted up). What MC does if refresh rate is changed to 24 Hz is it plays the video at correct speed (24 FPS) however audio is still pitch shifted (e.g. only stretched)

[Fangio]

NickF was wrong when he wrote the entry

Unlikely

[Fangio]

I have to say that being a european this is a big deal

+1

[glynor]

Unlikely

What evidence do you have to support that?

I knew NickF quite well.  He was a super-nice and smart guy, but (like me) absolutely not infallible.  He edited a TON of content on the Wiki.  I've fixed a TON of other mistakes.

So... What evidence do you have?  Do you know that the versions of MC out back then worked differently? And when it changed? If so, that would be useful information.  Otherwise, it is all silly nonsense.

EDIT: I don't mean to be a jerk. I know you were friends, and I also know Nick was a super-smart guy. But, there have been a ton of other little mistakes like that I've edited in his old articles. I'm sure there are a ton of little mistakes in my articles.

Again, it is irrelevant what the wiki says, unless someone can say for sure that it worked differently in an older version and it was changed in build 19.0.xxx.  Otherwise, we can't look back to see why it was changed.  Because, from the description here, to work "right" you'd need a setting you can flip on and off to handle different types of video.  If that existed before, the whole system didn't mysteriously vanish.  Best case, it used to be optimized for Standard Def content and is now optimized for High-Def content.  But, if so, that was done for a reason (a fairly obvious one, I'd say).

I'd like Hendrik to comment on why he feels it isn't worth changing (or that he will change it), and on the exact mechanism used, so I can fix the wiki.  That would be useful.

[glynor]

FYI, 23.976 is 24fps.

Until relatively recently, there was no such thing as "true" 24fps.  Film cameras all were 23.976 for ancient esoteric reasons.  Digital cameras now do sometimes shoot at "true" 24fps.  About as often, they list it as 24fps (or 24p) and actually shoot at 23.976.

In any case, thanks for the description, 6233638.  That's basically what I thought this was about, but I wasn't 100% sure.

[Fangio]

What evidence do you have to support that?

I knew NickF quite well.  He was a super-nice and smart guy, but (like me) absolutely not infallible.  He edited a TON of content on the Wiki.  I've fixed a TON of other mistakes.

So... What evidence do you have?  Do you know that the versions of MC out back then worked differently? And when it changed? If so, that would be useful information.  Otherwise, it is all silly nonsense.

I don't, unfortunately. I can't dig back that far, and I just haven't the time to do the research anyway. Apologies for the blunt response, it was kneejerk. I knew Nick for 25 years and sorely miss our regular meets.

[glynor]

Apologies for the blunt response, it was kneejerk. I knew Nick for 25 years and sorely miss our regular meets.

No worries.

I never knew him in person, which makes me sad. He is still sorely missed.

[6233638]

I really don't think arguing over the accuracy of the wiki is helpful.
Whether it was wrong to begin with, or MC has since been changed and no longer matches the wiki really doesn't affect the underlying issue.

FYI, 23.976 is 24fps.

My Blu-rays from NTSC regions are mostly 23.976 FPS
My European Blu-rays are frequently 24.000 FPS

Until relatively recently, there was no such thing as "true" 24fps.  Film cameras all were 23.976 for ancient esoteric reasons.  Digital cameras now do sometimes shoot at "true" 24fps.  About as often, they list it as 24fps (or 24p) and actually shoot at 23.976.

You know, I'm not actually sure what film cameras were natively shooting. I had been under the impression that it was true 24.000 FPS
Of course it really just depends on the speed of the shutter in use.
I would think that 24 FPS would be a lot easier to build than 23.976 but I don't have a source that is definitive one way or the other.

23.976 primarily exists for compatibility with NTSC televisions.
NTSC televisions traditionally operated at a rate defined as "60/1.001" which is approximately 59.94Hz
 
If you slow down film from 24 FPS to 23.976 FPS and repeat every fourth field an extra time, you end up with a 3:2 cadence which fits perfectly into this 59.94Hz refresh rate.
23.976 × 5 = 119.88
119.88 ÷ 2 = 59.94
 
This means that NTSC DVDs would judder due to the uneven frame presentation.
However now that our displays support 23.976Hz refresh rates, this process can be reversed. The duplicate fields are dropped to give us a 2:2 cadence rather than 3:2, which deinterlaces to a perfect 23.976 FPS.
 
If you were to store 24.000 FPS on the disc, that would not "fit into" the legacy 59.94Hz refresh rate, which is why all the discs released in NTSC regions are 23.976 FPS.
In PAL regions there is no 59.94Hz legacy format. PAL was traditionally 50.00Hz (hence the speed-up from 24 FPS to 25 FPS)
Since they are not concerned about legacy support, the discs are encoded with true 24.000 FPS content - the original speed of the film.
 
Of course some releases may have a single encode that is used worldwide so Blu-rays sold in PAL regions may include 23.976 FPS content, but a large number (perhaps the majority) of my European discs are 24.000 FPS native.

[glynor]

My Blu-rays from NTSC regions are mostly 23.976 FPS
My European Blu-rays are frequently 24.000 FPS
You know, I'm not actually sure what film cameras were natively shooting. I had been under the impression that it was true 24.000 FPS

It isn't useful for these purposes to get into.  I can point you to some resources that explain some of the history, if you're curious.

Suffice to say, that what you get on the BluRay has only the most tenuous connection to how it was originally shot. Most footage has gone through at least one, and usually two or more, framerate conversions before it makes it to the BluRay master phase.

[dean70]

To be clear, I'm not JRiver staff.  Just a guy.

Your definitely a steakholder 

[JimH]

Your definitely a steakholder 

Genius.

[thecrow]

You know, I'm not actually sure what film cameras were natively shooting. I had been under the impression that it was true 24.000 FPS
Of course it really just depends on the speed of the shutter in use.
I would think that 24 FPS would be a lot easier to build than 23.976 but I don't have a source that is definitive one way or the other.

Yes true film cameras run at 24fps.
Modern digital cameras are switchable.
But since the invention of video the work flow for a movie involves both true 24fps and 23.976fps.
For the past 30 years I've worked for large music recording studios in London, UK and been involved in recording orchestral scores for many Hollywood movies. We always record to picture running at 23.976 even though it was shot at 24, which means when the score is mixed in the final dub it is actually running slightly fast compared with the recording and so is not at the true pitch of the orchestra. Unless your hearing can distinguish perfect pitch nobody else ever notices.

On the other hand the 24 to 25 conversion is very noticeable.

[JimH]

For the past 30 years I've worked for large music recording studios in London, UK and been involved in recording orchestral scores for many Hollywood movies.

Is it this studio?

[metac]

+1 for having the option (preferably default) to slowdown.

I read the wiki ages ago and thought great, PAL Slowdown. This seems to be confirmed by Matt

VideoClock works with EVR and madVR, and handles PAL slowdown.

You should use VideoClock instead of ReClock in my opinion.

[thecrow]

Is it this studio?

Close, but it is actually

[JimH]

Ooh!

Thanks for the picture.

[glynor]

Yes true film cameras run at 24fps.

Interesting.  I've never shot film, and certainly not in the "old days", but most film cameras I've looked at had adjustable shutter angles and rotation speeds (like the ubiquitous Arriflex camera line).  In fact, an ARRI I looked at a few years back at NABShow (I met Jim at the show) allowed you to adjust both mid-shot.  Of course, none of them actually record audio at all, so it is of somewhat esoteric relevance.

Every "24fps" professional timeline I've seen in Final Cut or Media Composer was actually 23.976, though, was my main point. In the industry, 24p was used synonymously for 23.976fps (except when talking to the encoding nerds). I do know that lots of current productions are making very heavy use of footage from DSLRs and stuff now, which actually shoot "real" 24fps, and if you don't set up your timeline correctly, it makes the audio engineers' heads explode. That stuff shifts so rapidly, though, and the cameras were changing in revolutionary fashion when I last paid attention, so it is probably all different now (and almost all of my knowledge is TV/web based anyway, not film).

Cool picture, by the way.  Thanks!

[glynor]

In any case, that's all a sideshow diversion.

The nuts-and-bolts of this is that for (mostly) standard-def, DVD content of content produced at 24p (regardless of the variety), if you play a PAL conversion, those are formatted at 25p because PAL is wacky, and that makes everything "speed up".  That's the same thing that would happen if you play the disc on a regular run-of-the-mill set-top DVD Player.

But, if you lie to MC, and set the FPS at 24fps manually, you can make MC play the video back at "native" 24p speeds, but the audio stays whacked in pitch but not "duration".  Do I have this right?

[Johnny B]

bump

[glynor]

Do I have this right?

[6233638]

Do I have this right?

I haven't tested it, but my understanding was that Media Center uses the [FPS] field to determine what refresh rate a video should be played back at, since MC's Display Mode Switcher makes the change before video playback starts, rather than it affecting any other aspect of video playback.
 
So if you have a 25 FPS video and want it to play at 24Hz, you'd change the FPS field to "24".
It would still be treated as a 25 FPS file by the video renderer which gets that information from the file/splitter rather than the [FPS] field, and it would then be slowed down to 24 FPS by VideoClock to match the 24Hz refresh rate.
 
I don't like this as a "solution" because it means that the FPS field is wrong and all my movies would read "24 FPS" instead of being able to separate them based on what framerate they are. (and I have some views which do just that)
 
I haven't found that to be a problem though, as madVR's Display Mode Switcher has a lot of special-case handling which MC's switcher does not, since it is the video renderer.
If you have a 1080i50 file for example, that can be deinterlaced to 25 or 50 FPS depending on whether it is film-type or video-type content.
Since madVR is the video renderer, it knows whether the video/film mode is being used and can play 25 FPS material at 24Hz, with 50 FPS material outputting 50Hz. Even if I toggle between film/video mode during playback, madVR will still switch the refresh rate between 24/50Hz.
Since Media Center changes the refresh rate before playback has started, it would use 50Hz for all PAL files, unless you edited the FPS tag to read "24".
 
 
But none of that changes the fact that VideoClock is using Tempo for adjustments, when Rate adjustments would generally be more appropriate for PAL film content.
Just as MC cannot automatically determine whether it needs to switch to 24/50Hz, it would not be able to determine whether Rate or Tempo adjustments should be used for a file.
 
The problem is that there are so many different types of PAL content.
The only real solution would be a combination of a setting to specify whether VideoClock uses Tempo/Rate adjustments by default when playing PAL files, while also allowing that to be overridden by a custom tag.
 
You can have a 25 FPS file which is:

• PAL-native material
• NTSC-sourced material with pitch-correction applied to the audio
• NTSC-sourced material without pitch-correction applied to the audio

1 & 2 should use Tempo adjustments for VideoClock
3 should use Rate adjustments for VideoClock
 
1 is the default for PAL television shows
3 is generally the default for film releases - but sometimes it's 2
 
 
So in my case, I would want the default to use Rate adjustment for PAL content, since most of the PAL content I own is film releases.
But I'd want to manually tag PAL television shows to use Tempo adjustments, as well as any film releases which did have pitch-correction applied.

[Johnny B]

All right, so basically we agreed the change is appropriate as the need for it had been discussed and explained here thoroughly.
Now the question is what are the developers going to do about it?

[Johnny B]

bump

[flac.rules]

I have to agree with Johnny, no one setting is always right, but defaulting to changing the pitch is much more often right than not doing it, ideally it should be user-selectable.

[6233638]

I have to agree with Johnny, no one setting is always right, but defaulting to changing the pitch is much more often right than not doing it, ideally it should be user-selectable.

I really think it would have to be something that a file can be tagged with, rather than a selectable preference.
A selectable default, sure, but as we've discussed: no one setting can be applied across all content.

[squeedle]

After reading the wiki about reclock, and then the seemingly current wiki about videoclock, I was excited that MC would automatically "slow down" 25fps content and pitch the audio down 4%.

However, as the above thread implies, this is not what it's doing. It is slowing things down but NOT pitching the audio down, as it should.

The DSP "tempo & pitch" options page lists 1) tempo, 2) pitch, and 3) rate. What we'd like is for MC to simply use RATE when it plays back 25fps content at ~24fps.

Possible? Please? PLEASE? No more high pitched audio on PAL sources? PLEASE???