This is a very common feature of Windows 10.

Drag the right edge of the blue box out to the right, and check "install anyway."

If the author had sought signed Microsoft installer verification, it would cost you far more than $14.

Windows completely removed the file... odd... I have to download again.

Exactly. This is the reason that you get the screen. $$

Exactly. This is the reason that you get the screen. $$

Protecting users or a pay-to-play protection racket?

Got it, thanks!

Okay now the next step. I tried a 1 minute video render from my a7siii footage. This was just 24p. This was over 12GB for the minute. Is the frame-rate automatically identified in the render?

What is the correct option to use? I am using a7siii XAVCS 10 bit 4:2:2 If I wanted to transcode ALL of my footage, how would I set my project up? I am assuming 32 bit video levels but I don't even know anymore. I was going to write up a post about this as I have been using VP since VP8 with no issue and I swear with the latest release I am suddenly lost on how to set up a project or set my renders.

Back to topic - If I want file for file the same output what are the settings to use from project setup to rendering in full or limited colors? I would have thought 32bit full levels but it does something wicked with my colors.

Then after all that is said and done, where do I set up the gofundme for the extra SSD storage I will need? :P

I don't have your camera, so others here can be of more help. I would also try Happy Otter Scripts for Vegas, there is a free trial. As far as matching properties, MediaInfo should tell you all you need to know.

https://mediaarea.net/en/MediaInfo

Just to clarify, you are asking for render settings to change 10-bit a7sIII files to MagicYUV for use in place of originals for further editing?

If so, looking at the choices, 10-bit RGB seems to be a an appropriate output choice.

hambonio, i’m waiting for my a7sIII to arrive so i’m interested in your query. Do you find the files hard to edit (10-bit 422 4K) in your computer? Can you make a comparison once transcoded to MagicYUV? Thanks

Exactly. This is the reason that you get the screen. $$

Protecting users or a pay-to-play protection racket?

Haha :)

Yes, it's apparently no longer enough to have a "regular" code signing certificate, now I'd need to use "Extended Validation" ones. Next year I'll probably need to use "Enhanced Validation" certs...

And, just now, I got an update from MagixYUV:

MagicYUV 2.3.1 has been released.

@MagicYUV - Thank you! What a Team!

It's just like buying an expensive piece of paper, cleverly disguised as a "used car warranty."

As proof, just try getting any compensation from Microsoft when one of their "signed" libraries installs nastyware on your previously healthy machine . . .

"Trust me. I paid someone to tell you I'm trustworthy."

hambonio, i’m waiting for my a7sIII to arrive so i’m interested in your query. Do you find the files hard to edit (10-bit 422 4K) in your computer? Can you make a comparison once transcoded to MagicYUV? Thanks

The 24p is not bad. 60p and 120p are a headache, and need proxies. I have not started any multi camera edits with it yet as this is where I hope/assume it will shine.

Just to clarify, you are asking for render settings to change 10-bit a7sIII files to MagicYUV for use in place of originals for further editing?

If so, looking at the choices, 10-bit RGB seems to be a an appropriate output choice.

Thanks Roger. How should my project be set up (8/32 bit with either full/video levels) and should i render the 10-bit RGB files out as full range or video levels?

How should my project be set up (8/32 bit with either full/video levels) and should i render the 10-bit RGB files out as full range or video levels?

You were asked.

As far as matching properties, MediaInfo should tell you all you need to know.

https://mediaarea.net/en/MediaInfo

We still haven't seen your exact file properties, nor an original source sample, so how would anyone possibly know? We have learned from experience long ago never to trust anecdotal reports, because they are usually wrong.

https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

We still haven't seen your exact file properties, nor an original source sample, so how would anyone possibly know? We have learned from experience long ago never to trust anecdotal reports, because they are usually wrong.

https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

Musicvid - Fair enough! Here you go.

I hope this doesn't ask too much - as I would have started my own post about this but if this all can be answered here then I will be happy - since the output of these files will be part of my problems.

Up to VP 17 (I have been using VP since 2009) I had no issues coloring and exporting my videos to look how I intended. Blacks and highlights were always exactly where I wanted them to be. With VP18 now my videos either turn out very milky, or the blacks severely crushed. I have tried changing the project settings to every limited and full range setting I can think of. I have tried every variation of my scopes settings to try and give me the best 0-100 reading for my levels.

Please humor me here and help me set each of these settings like I should for best results for my render. I understand changing the project settings to 8 bit (full or limited?) will help with editing speed, but what I am looking for are the settings I need to use when I am ready to render.

I did purchase this codec this morning - and the renders I have done from it seem to be working well as far as playback (I mean really well!) but I want to make sure it is 100% correct.

General
Complete name                            : E:\2020-10-17 Makayla and Andrew\RAW\20201017_Gimbal0345.MP4
Format                                   : XAVC
Codec ID                                 : XAVC (XAVC/mp42/iso2)
File size                                : 1.13 GiB
Duration                                 : 1 min 33 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 103 Mb/s
Encoded date                             : UTC 2020-10-17 19:49:08
Tagged date                              : UTC 2020-10-17 19:49:08

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High 4:2:2@L5.1
Format settings                          : CABAC / 2 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 2 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1 min 33 s
Bit rate mode                            : Variable
Bit rate                                 : 97.0 Mb/s
Maximum bit rate                         : 100.0 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 10 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.488
Stream size                              : 1.06 GiB (94%)
Encoded date                             : UTC 2020-10-17 19:49:08
Tagged date                              : UTC 2020-10-17 19:49:08
Color range                              : Full
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : PCM
Format settings                          : Big / Signed
Codec ID                                 : twos
Duration                                 : 1 min 33 s
Bit rate mode                            : Constant
Bit rate                                 : 1 536 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 17.1 MiB (1%)
Encoded date                             : UTC 2020-10-17 19:49:08
Tagged date                              : UTC 2020-10-17 19:49:08

Other
Type                                     : meta
Duration                                 : 1 min 33 s

Just to clarify, you are asking for render settings to change 10-bit a7sIII files to MagicYUV for use in place of originals for further editing?

If so, looking at the choices, 10-bit RGB seems to be a an appropriate output choice.

Thanks Roger. How should my project be set up (8/32 bit with either full/video levels) and should i render the 10-bit RGB files out as full range or video levels?

Happy to be corrected by others with more experience, but if you want to use the 10-bits of data you need a 32 bit project. 32 bit video is the only option, the other one engages ACES color management.

I believe the author of MagicYUV told me that for RGB there is no limited/full choice, it's full. There doesn't seem to be much of a size penalty going from 4:2:2 to RGB for MagicYUV, so it's safe to go with the top quality option.

Your project settings look fine. Scopes also fine for full range work. However the third one is messed up. You don't want to change levels from studio to computer RGB as Vegas is already doing this when in 8-bit full range (or 32-bit video levels) mode.

Just to elaborate a bit on the ranges for MagicYUV:

All 8-bit codec variants (both RGB and YUV) expect full range data, as they communicate RGB with Vegas underneath, and RGB is always expected to be full range. 8-bit YUV codec variants do RGB<->YUV conversion internally inside the codec, and the resulting encoded YUV data will have limited range, but as far as Vegas is concerned, it will only ever get full range RGB from the codec.

10-bit+ RGB codec variants expect full range RGB.

10-bit YUV codec variants expect limited range. Note this is different compared to 8-bit, the reason being that the codec communicates YUV data with Vegas (not RGB) in this case.

When a project is set to 32-bit full range mode, Vegas will do automatic full->limited conversion before sending the YUV data to the 10-bit YUV codec variants.

When a project is set to 32-bit video levels mode, Vegas should not do automatic full->limited conversion before sending the YUV data to the 10-bit YUV codec variants, however there is a bug in Vegas (confirmed by MAGIX), and currently it's still doing full->limited conversion even in 32-bit video levels mode. This will be fixed in a future release of Vegas.

Ok - can I rename my user name to MasterOfConfusion? (joking)

Lets just hope I don't get confused with all I am going to add to this post.

First off these files do seem to play like a dream - and that is why I am continuing to get the best grasp I can from this.

I have examples from 2 different cameras here - a7S II and a7s III

The first I used media info to best set up my project to what I see from my a7S II:

I set up my project to Legacy 8-Bit(video levels)

I rendered to both MagicYUV 8-bit YUV 4:2:0 and MagicYUV 8-bit RGB. The RGB render is the only render that from what I can see on enlarged scopes, has identical readout. The YUV render was a little different when I look at it and had a slight shift to magenta. This confused me a bit because the mediainfo shows as YUV so I would have assumed that would give me the best results - but is the result that gave me a difference, not the RGB.

Source a7S II footage - 30p 8-bit 4:2:0 scope

MagicYUV YUV 8-Bit 4:2:0 Scope (changes, colors seeming to slightly fall apart and slight shift to magenta visually)

MagicYUV RGB 8-Bit Scopes - 100% identical to Source

Render Settings - I used the defaults here and just changed rendering quality to Best.

The second footage I used media info to best set up my project to what I see from my a7S III:

I set up my project to 32-Bit floating point (full range) and turned off the color transform.

I rendered to both MagicYUV 10-bit YUV 4:2:2 and MagicYUV 10-bit RGB. NEITHER of these renders had completely identical readouts. The YUV render again was a little different when I look at it and had a slight shift to magenta. The RGB render gave me an ever so slight shift to blue - I have to look hard to see it but it is there.

Source a7S III footage - 60p 10-bit 4:2:2 scope

MagicYUV YUV 10-Bit 4:2:2 Scope (changes, colors seeming to slightly shift to magenta visually)

MagicYUV RGB 10-Bit Scopes - Very very very slight shift to blue.

So neither of these options gave me 100% match on my 10-bit a7S III footage.

Render Settings - I used the defaults here and just changed rendering quality to Best and range to Full.

The YUV files do seem to be more fluid and responsive on playback as far as framerates go, especially on higher 60p and 120p footage. I am just not sure which to REALLY use or if I am doing it correctly.

TIA for any more help and advice on how I am doing this. FYI - I currently have that a7S III wedding expanded to over 7TB with just 24p and 60p footage and I am not even sure if these are the files I should be using. I have not even started my 120p footage yet...

You are getting it!

You've actually made about four posts above, so I'll respond to the first bit. It will make the rest easier to understand.

RGB encoding is 4:4:4 color subsampling. It is the best mathematically possible.

YUV looks a little different on your scopes and in real-life observation can look slightly soft in the reds. Most 8-bit YUV is 4:2:0. The YUV advantage is that it is much smaller than RGB, up to 93% smaller when I last tested the Magic encoder.

So good job Sherlock!

BTW, setting Render quality to Best is not active unless you are resizing the output and / or using interlaced source.

You are getting it!

Well thanks for the encouragement - now I really don't think I am! I keep confusing myself even more. They YUV and RGB files are similar in size from my renders. In fact in some cases the RGB files are slightly smaller. They seem to trade blows clip to clip. Now I just realized that my 8 bit renders the RGB plays smoother, when I made my first statement it was from my observation of the a7s III files which most of my footage there is higher framerates.

Also the AVI output scopes don't change when I switch from video to full levels or vice versa like the source footage does.

If in the future I am mixing cameras - would I be better off just transcoding to full levels to begin with?

I know it was a long post - I spent all damn day on the thing - sorry.

I am currently running all my 8-bit footage through full level RGB now just in case this is correct and be ahead of the game for when the day comes that I can actually edit.

Here is total size difference from my 60p renders. Yes I am really that insane to be rendering all these clips while I have been sleeping in multiple formats just so when the time comes I can pick the correct source.