Thanks for your reply. The Lagarith codec was set to RGB which has always worked in the past. However, I rendered the video out of Vegas 8 using DNxHR which worked well.

Glad to hear DNxHR (did you mean DNXHD?) works in Pro 8.

Unfortunately, that version only uses 32 bit QuickTime for all .mov files.

Time permitting, I'll run some tests on my copy of VP8.

Yeah, that is too bad it's only 32 bit, but since VP8 is also only 32 bit, at least it gets the job done. I'll have to check out the UT codec too. It was really strange how this all happened... it was so unexpected. To fix it, I uninstalled all versions of Vegas (15 trial, 13, and 8) and re-installed VP8, but it didn't help... uninstalled VLC Media player, Ashampoo Burning Studio, GoPro software, anything recently installed that could have messed with codecs. Un/re-installed Lagarith, tried an older version of it, nothing worked. I blame VLC player, but I have no proof it was the culprit. All I know for sure is this didn't happen before in VP8. Why it only affects VP8 and not 13 though is really strange. Anyway, it's nice to have a good workaround. :-)

...In Vegas 13, the issue doesn't occur, however, because of the bug with reading the correct frame position of .m2t files,...

Can you give us any more information on this bug? I haven't seen any issue with my HDV .m2t files.

Can you give us any more information on this bug? I haven't seen any issue with my HDV .m2t files.

Hi Nick, the files are 1440 x 1080 .m2t 29.97 interlaced footage (upper field first) captured in 2008, and added to a 23.976p timeline (not ideal, I know, but necessary in this case). The video/audio in many places has been sped up by 115 to 125%, and perhaps this triggers the discrepancy between Vegas 8.0c 32 bit and all later 64 bit versions of Vegas. In 64 bit versions of Vegas, the video/audio incorrectly shifts by about 2 frames (as if you had "slipped" the contents of the clips without actually moving them). The edit was originally done in VP 8 32 bit, so I don't know if that makes a difference, but this bug has existed since VP 8.1 64 bit, and I reported it both to Sony (years ago) and to Magix in 2016, but it was never addressed. Now needing to re-edit portions of the original project, this bug requires cracking open VP8 to make sure the original edit is preserved. :-)

Interestingly, I just discovered the bug actually occurred the very day I installed a trial version of Vegas Pro 15! So it's most likely the VP15 trial destroyed Lagarith in VP8, but left it usable in VP13. Very strange since VP8 was working perfect for rendering Lagarith files back in 2016 on the same PC and OS. It appears the VP15 install also messed with Vegas 13's help software, imposing the Magix copyright where Sony used to be (even after uninstalling VP15).

Though any of my Magix Vegas installs (vs. 14, 15, and 16) have not "messed with" Help in earlier versions, occasional issues have indeed been reported (e.g. here). The workaround is to use C:\Program Files (x86)\Sony\Shared Plug-Ins\Help Files\vegas130.chm instead of online Help. Create a shortcut.

Thanks, Vkmast, for your reply. Deleting all Magix and Vegas / Vegas Pro folders I could find leftover after the uninstall corrected the Help file redirect in VP13. Sadly, the Lagarith "x16 instead of x24" bug remains in VP8.

I think it's a Lagarith bug, of the many I've seen. Lagarith's quirkiness in other applications is well-reported.

16 bits is an illogical outcome since it is indivisible by 3 (RGB), And RGBA would only give 4 bits per channel (MS-DOS, anyone)?

I abandoned Lagarith for intermediates long ago, and my new go-to losslessiest (how's that for an unword) encoder is MAGIC YUV. I was blown away by the absence of any noticeable chroma subsampling errors as reported by Belle-Nuit. That's significant, because 8 bit 422 Magic YUV appears to beat Sony 10 bit in that department. Wow. And still a huge compression advantage over 8 bit 444 (avi).

Don't get me wrong; the suggestions above are still good ones, and wouldn't show up in a 2nd generation probably.

Thinking of staging a MAGIC / SONY shootout, should anyone else share an interest in such esoterica.

Thanks Musicvid for that helpful info. Magic YUV sounds like an incredible codec. I'm going to try out the older version 1.2 right now.

Not sure how v2.0 is, but I find v1.2 to be rather confusing in its interface. I tested it in Vegas 8 (since I need VP8 to render these old .m2t files) and unless "Accepted Colorspace" is set to "All Supported" and "Mode (conversion)" is set to "Compress as-is (No conversion)" the codec will refuse to render. The worst of it is, I have no idea what the final output is supposed to be (since the source is a 1440x1080 4:2:0 HDV file inside a 1920x1080 project). Looking at the log files, it **seems** the codec is selecting 1920x1080 4:2:2 ?? However, I want to render my video out as 8 bit RGB, but setting RGB in the "Accepted Colorspace" tab just causes Vegas to give the error, "The selected codec does not support the current render settings". It should be able to take in anything and spit out RGB or 4:4:4 like Lagarith or DNxHR... perhaps I don't know what settings to use to achieve this.

Yes, 1440x1080 is anamorphic 1920x1080.

I've got some old HDV to play with and ill give you the settings later this week. I bet Nick does this too.

Thanks Musicvid. This project actually contains mixed media (including some 1920x1080 HD clips), though, which is why I'm not rendering it out as 1440x1080p with a 1.333 PAR. I'm just trying to figure out how to output RGB from MagicYUV regardless of input. Not sure if that's possible.

As I said, Magic YUV 8 bit appears to be every bit the equal of RGB wrt chroma subsampling, so why clobber yourself with larger RGB file sizes for zero added value?

Unequivocally, you do not want to render 1440x1080 1.333 PAR.

That is your HDV acquisition and storage format, not a delivery format.

TS, MTS, M2T, M2TS are all transport streams, not program streams. Day and night, and plenty of mumbo-jumbo to confuse you with.

HD delivery format is 1920x1080p 1.0 PAR, 16:9, and you should not be concerning yourself with anything else. I really do not know any other way to say this.

What are you planning on using your lossless AVI digital intermediates for?

Thanks again for your reply, Musicvid. The files are pre-rendered sections of a larger film. They need to be lossless since they will be re-rendered in the final master. I just finished running some extensive testing. Here are the results. MagicYUV was rendered using the only usable setting I could find: (All Supported, Compress As-is, Full Range YUV [otherwise Vegas decodes it as Computer RGB]):

For a 00:01:18 test region (under 8x Zoom)

• Lagarith RGB > 74.479 MB > Visually Lossless
• MagicYUV > 51.066 MB > Visually Lossless, Slight Red Push & Blue Reduction
• DNxHR 444 RGB > 75.266 MB > Visually Lossless
• Cineform RGB 444 Filmscan 1 > 55.053 MB> Visually Lossless, but wavelet compression produces some artifacts which differ from Lagarith or DNxHR
• Cineform RGB 444 Filmscan 2 > 86.367 MB> Visually Lossless, artifacts much closer to DNxHR

So my conclusion is if one is looking for a visually lossless codec with a smaller file size and no red push, look at Cineform RGB 444 Filmscan 1 (settings higher than that have diminishing returns).

But for me on this specific project, the best alternative to Lagarith is DNxHR (best balance of quality to file-size). However, this only applies to VP8 where Lagarith is currently unusable. For mastering out of VP13, I will continue to use Lagarith as it's not limited by a 32 bit wrapper like the VFW version of DNxHR.

EDIT: DNxHR repeatedly glitched while rendering sections with the "Flash" transition in VP8. I instead used Cineform RGB 444 Filmscan 2 for my render.

Lagarith's VP8 demise and VP13 resilience seemingly will remain a mystery, however. :-)

By the way, to get Cineform to render in Vegas if you have the now-discontinued GoPro Studio installed (2.5.3.4) follow these steps: https://gopro.com/help/articles/solutions_troubleshooting/Unable-to-Encode-into-the-GoPro-Cineform-Coded-with-3rd-Party-Applications

Did you conduct objectified Belle-Nuit->SSIM analysis, or are these subjective observations? "Color cast" is always quantifiable, a simple thing to check with the eyedropper.

You can see the color shift both visually and with Vegas' scopes (RGB parade). The footage tested on was rich with warm tones so it was more obvious. This shift likely wouldn't be as noticeable on a neutral image. Moreover, the test was with v1.2, so this issue may have been corrected in v.2.0+.

I haven't experienced that; can you show us steps to to replicate?

Using an HDV 60i .M2T file with plenty of warm tones as source, render to 24p Magic YUV (older version 1.2) using the settings mentioned above (All Supported, Compress As-is, Full Range YUV). All settings are default except Full Range YUV. Not sure if the source format makes the difference here. Ran tests originally in VP13. I haven't tested this in the newest version of MagicYUV. By the way, I wound up using Cineform RGB 444 Filmscan 2 to render out of VP8 instead of DNxHR, as DNxHR was glitching anywhere there was a "Flash" transition. This was likely due to its 32 bit wrapper or perhaps some incompatibilities with the older VP8.

HDV is not fullrange YUV, nor is your destination. You are no doubt CLIPPING the output, which shows up first as overstated primary colors!

Back up a step, learn to use the video histogram first, then use the correct levels filter if indicated (your footage is legal YUV, not illegal Fullrange.)

Start here

https://www.vegascreativesoftware.info/us/forum/vegas-pro-faqs-and-troubleshooting-guides--104787/

And here

https://www.vegascreativesoftware.info/us/forum/faq-why-does-my-rendered-video-look-bad-troubleshooting-quality--103361/

Vegas preview is static RGB. That means it will always look flatter than the rendered video in a player.

Mathematically, there are 31 ways to get it wrong, and one way to get it correct. When you're up to speed on the fundamentals, see here for a peek at what everyone gets wrong the first 31 times. It's NOT logical, so park your prefrontal cortex before embarking, and prepare for a couple of giggles.

https://www.vegascreativesoftware.info/us/forum/pc-to-tv-levels-a-comedy-of-errors--107325/

There are some other links in my signature you might find entertaining, if a little academic.

BTW, I ran the comparison between RGB 444 (avi) and Magic YUV again, and there are no chroma deviations, save for the legacy one-bit data shift. Don't ask.

Finally, here is a serviceable RGB/YUV stepwedge you are free to use for tweaking your levels and monitors, which is equally important.

Legal YUV range equates to 16-235. As you've already seen from the link just up, rendering fullrange yuv is a crapshoot.

My MAGIC YUV/RGB shootout may come as early as this weekend, stay tuned.

And a belated welcome to the forums! Your potential here is not unnoticed.

Thanks so much, Musicvid, for the helpful links and the welcome. Perhaps it's a misnomer, but unchecking the "Fullrange YUV" flag and leaving the other settings at default causes Vegas to display the rendered MagicYUV video as 0-255 instead of the usual 16-235. Leaving the flag on will cause the rendered file to display the same as the source file in Vegas (16-235) (with a slight added red push). If it doesn't exhibit this behavior for you, that's great. Maybe it just doesn't like my source footage, or maybe v1.2 is buggy. I'm sure MagicYUV is good, however, I personally prefer a codec with a more straightforward UI. If I have 4:2:0 footage mixed with 4:4:4 or RGB footage and want to explicitly output RGB or 4:4:4 YUV regardless of input, the codec shouldn't squawk with "The selected codec does not support the current render settings". :-)