===

The PAR has nothing to do with how the video is supposed to be displayed. For example a captured AVI of 720x480 is supposed to be displayed in a 4:3 frame. An AVI of 720x576 is also supposed to be displayed in a 4:3 frame, not a 5:4 frame.

===

Of course, the PAR has nothing to do with how it is to be displayed, as I was saying if you read it carefully. The display is determined by the DAR. They are independent values. At one time the only display ratio for a DVD was 4:3, but now 16:9 is also allowed for a DVD and the DAR determines which it is. There are plenty of 16:9 DVDs which display full screen.

The image examples show what might show up on an old TV which has a 4:3 screen. Modern TVs have 16:9 or even wider so a 4:3 image on a modern TV would be pillar boxed. This is why letterboxing is wrong for a video processed by MMS with PAR 3:2 but DAR 4:3. It should be just passed through with no modifications and the DAR metadata should be set to 4:3 with no letter boxing.

MMS should NOT EVER change the PAR using the DAR, especially when the DAR is a standard size. The DAR should only affect the metadata. That is what is the big problem in MMS. In the case of AVI it should just ignore the DAR because AVI does not have metadata for storing it.

When you have frames with PAR 3:2 and you specify PAR 4:3 the result is just letterboxed which still has a image that is too wide. Setting 4:3 should just compress the output horizontally while keeping the vertical at 480 to have a realistic picture. But for editing a picture and inserting it back you want to maintain the original PAR which could be done by a checkbox to decouple the PAR and DAR, or by specifying 3:2 aspect ratio. It could be a box marked "set realistic aspect ratio" or some sort of thing. There could also be a warning that the video aspect ratio does not match the frame size. Another alternative is to have the frame size modified by default to match the video aspect ratio, but allow the user to reset it and have it saved for the video project. This is what used to happen at one time.

It was Idiotic to letter box a 4:3 video frame when exporting a picture, because the result is entirely wrong with somewhat wide fat people and reduced vertical resolution.

Incidentally I have 3 copies of this movie. Two are identical. So I have two movies from different transfer and different sources. They both have a bar on the horizontal edges, so the 4:3 aspect is still a mystery. One has VHS bars on the top and bottom, but the other has apparently cropped them off.

--> Export of Analogue-sourced AVIs only at 23.98, not 23.976 as set in the Export dialogue.

This is not true. The drop list setting is rounded off from 23.976. But the true rate is specificed in the metadata as two integer numbers. The standard rate for 23.976 is actually 24000/1001, but MMS sets it to 24976/1000. Whether that is only a symptom or the cause of the mismatch between the original and the exported video file is unknown. I think it is the source because VirtualDub reports a different time for the exported movie compared to the the original, but the same number of frames. Actually some of the drop downs display 23.976 and other 23.98 and the box displaying the value likewise varies.

When you have an America blu-ray the frame rate is 24000/1001 as reported by my metadata display app. Windows only displays the decimal equivalent rounded off. Similarly American DVDs run at 30000/1000 fps. This was originally due to the method of inserting color into the b&W image, but has continued to be used.

See: en.wikipedia.org/wiki/NTSC

Also:

video.stackexchange.com/questions/20523/ffmpeg-whats-the-difference-between-nn000-1000-fps-and-nn000-1001-fps

The programs (apps) simplify the numbers for the average person can understand them, instead of the exact information which may confuse them.

@clement5

Setting 4:3 should just compress the output horizontally while keeping the vertical at 480 to have a realistic picture.

Never! should a program automatically squash a too-wide video into the selected frame size. You can use your TV remote to expand/fill/stretch, or Size Position Rotation to distort your video to make it fit to the frame size of the screen, but automatically doing it would be heresy. Precisely why your 3:2 AVI file of the sailors is letterboxed in a 4:3 frame. Stretching it to fit would distort the video. If you want a 3:2 video to fill a 4:3 screen, you have the Section, Camera Zoomshot or SPR effects to achieve that.

Export of Analogue-sourced AVIs only at 23.98, not 23.976 as set in the Export dialogue.

This is not true.

Yes, you are right. Magix showed 23.98 in the Export box but it did export as 23.976, as evidenced by MediaInfo. I'm going to mention that to Magix too.

The standard rate for 23.976 is actually 24000/1001, but MMS sets it to 24976/1000.

I assume you mean 23976/1000 for Magix.

Similarly American DVDs run at 30000/1000 fps. 

No, 30000/1001, 29.97.

MMS should NOT EVER change the PAR using the DAR, especially when the DAR is a standard size. The DAR should only affect the metadata. 

Of course it has to. If a video has a DAR of 4:3 but is only 720x480, of course any NLE must display it at 720x540, otherwise the video would be distorted. The program uses the metadata to work out how to display it.

That is what is the big problem in MMS. In the case of AVI it should just ignore the DAR because AVI does not have metadata for storing it.

That's precisely what it does do. The user has to manually set the DAR in Object Properties. My gripe is that in versions before MEP 2021, Magix assumed an AVI had a DAR of 4:3 and displayed it as such, saving the need to manually set it.

Anyway, I said enough. It is clear that we have differing views on how the program behaves with PARs that are different to the DAR. Notwithstanding the bugs I've already mentioned, I find it's behaviour entirely logical.

In a nutshell, if your video's DAR is not the same as your movie setting, you will either have to accept bars or crop it (or stretch/distort it in your player/TV).

@clement5, @AAProds

Hi JohnC, Al

. . . . Of course, the PAR has nothing to do with how it is to be displayed . . . .

The PAR is important, it is calculated from the SAR and DAR by the player, or software, decoder to apply the correct amount of stretch or compression to the pixels before preparation for 'transmission' through the RF or HDMI outputs or to the screen display.

Have you read this Wiki article, it demonstrates what a 'pigs ear' the old analog TV standards have made to the video standards we use today. and how the complications they introduce for digital video.

John EB

@johnebaker

John, which of your players/TVs don't play this correctly? 😉

https://drive.google.com/file/d/104-8P0npodNURwL39fWmGmqHBu5rS9-a/view?usp=sharing

Ex-analogue AVIs are a different kettle of fish. I get them into 768x576/720x540 ASAP.

@AAProds

Hi Al

Interesting vidoe file format, was this orginally recorded using a 'Panavision' camera?

In the 6 programs I have that can play the video file, they all display the video in 16:9 AR, using the DAR value to adjust the SAR value to give a PAR of 4:10. Have not tested the file directly (USB stick) on a TV yet.

Interesting points with respect ot DAR obedience:

• Windows file explorer uses the SAR to determine 'frame size' of the icon, while using the DAR to get the actual preview image to display the image correctly.
  
   
• AVIDemux ignores the DAR, on import it shows the preview image using the SAR
  
   
• Sound Forge Audio Studio also ignores the DAR and shows the SAR image,
  
  
  Sound Forge Pro shows the DAR image. however using the Copy frame option and pasting it into an image editor gives you the SAR image.

If only all programs followed the rules consistently, life would be much simpler. 😉

John EB

----Have you read this Wiki article, it demonstrates what a 'pigs ear' the old analog TV standards have made to the -video standards we use today. and how the complications they introduce for digital video.-

I just came across it, but had read another article which mistakenly said that SAR and DAR were the same thing. It called the SAR the simple aspect ratio. The "Pixel Aspect Ratio" article makes more sense. While it gives the mathematical relationship between PAR, SAR, and DAR, it does not say what actual quantities stored as the metadata. The frame size is always stored which gives the SAR, but AVI does not store the PAR, or SAR. Looking at an MP4 from a VHS tape I found that the PAR is stored. In a VOB it stores the PAR and the "frame aspect ratio" which is the DAR. So it looks like the PAR may be stored in most formats, but it is possible that some may store the DAR and not the PAR.

MMS does store them, but when creating a half frame 4k SBS 3D MP4 it used to store.

<mpeg7:Pixel aspectRatio="1.000" bitsPer="8" />
 <mpeg7:Frame aspectRatio="1.778" height="2160" width="3840" rate="24.000" structure="progressive" />

Now it stores Pixel aspectratio=.5. For a while it could make a full frame SBS, but I just discovered now it reverts to half frame, YIKES.

For a while when making a full frame it 16:9 it would have aspect DAR 32:9. Then it switched to having DAR 16:9. That was most annoying because sView looks a the DAR or PAR. With the old format sView would display an mp4 full width sbs with suffix -LR, but with the changed DAR I had to use -HRQ even though I could verify that it really was FW SBS. At least they would put the 3D metadata clue into the files. Why do they have to remove features. For a while it would create 3D FW HD, but only HW 4k. The it could be kludged to create FW 4k, but they took that away, and then to create FW HD or 4k you just had to specify doing it, which was nice, but now they again did a promiscuous change. YEUCH. I do have a workaround to output it as AVI and then use PowerDirector to create the output, but I find setting up the menus to be a chore compared to MMS.

My metadata parser only shows frame size and DAR in the easy to read default. But there are other formats I can show which reveal the PAR and SAR in detail. I was confused by the HTML format which is not complete. I think that the PAR or DAR being specified is an ideal clue for the 3D format HW or FW in an MP4. The jungle just gets denser, not clearer.

I have already spent too much time digging into the horse manure.

@johnebaker

Interesting vidoe file format, was this orginally recorded using a 'Panavision' camera?

John, made it in Magix from a 1920x1080 video from my phone.

It was made from a 720x480 4:3 DVD which was apparently lifted from a VHS tape likely of a broadcast, but may have been a dub from a 16mm film. As to the specs for the original film it is "The Leathernecks have Landed" which can be researched on IMDB.

The original DVD version had black bars on either side. The original DVD VOBS were detelecined. Then using Virtual Dub the video was centered, increased by 16pixels vertically, and horizontally. Then VD Deshaker was used to reduce the frame shaking. Finally the black bars were restored slightly wider. Then the video was cropped back by 8 px on each side to get back to the original 720x480. MMS was not used to create Test 1, just Avisynth and VD.

Test 2 and 3 along with the clips were all created by MMS.

Since Panavision was created in 1954 and the movie is from 1935 I don't think that company had anything to do with it.

Note: most dehaking apps or plugins crop the video after they are finished. Deshaker for VD has a variety of options, so it is possible to create a passible copy of a film without cropping off details. The increasing of the frame size and extrapolating (smeared), allows deshaker room to move the frames. Then the final cropping gives back the original images, but with some fuzzing at the edges most of which can be cropped off. Deshaker has a method of using nearby frames to fill in the edges, but with motion, the artifacts are not good.

An AI dehaker might work, but my experience with Topaz AI trial was not good. It filled in ambiguous details with fanciful details that were sometimes plausible, but then sometimes not. 2 shots from different angles would give different made up details that do not match.

This is more detail than you needed, as the important detail is the comparisons of the various problems in MMS.

John C