Premiere CS3 settings for lossless recompiling

[Kereellis]

Follow-up question from:
http://www.digitalfaq.com/forum/show...vice-2020.html

Quote:

Originally Posted by admin

Capture it twice!
Once with DNR turned on, for the video.
Once with DNR turned off, for the audio.

Overlay them in an editor (I use Adobe Premiere for this, when AVI) to sync within a half-frame radius.

(sidenote: It's not the DNR adding a buzz, it's the JVC itself. Luckily I have a backup VCR for the audio capture ).

However for the next step, I would have to know what project settings to use in Adobe Premiere Pro CS3 in order to preserve all data of my YUY2 Pal captures upon recompiling the video and audio (with that of the separate capture). I've tried this before with huffyuv, but I'd still need to edit beyond synchronizing, so I prefer to avoid compression for now (even though it's supposed to be losless).

This is how I inferred the settings would need to be selected thus far:
New project-> custom settings-> General
Editing mode: desktop (I guess, the others were all options for DV)
Timebase: 25 FPS
720 x 576
Pixel aspect ratio: Square pixels (?)
Fields: Upper field first
Title safe area: I have no clue, so I left these at their default settings
Action safe area: See previous.

Audio: Al that's relevant here is whether I can downsample from 48khz to 44,1 khz in high quality, but I could also do this in a later phase.

Videorendering->
Maximum bit depth: check/uncheck?
File format: There are three options
VFW
Uncompressed 8-bit 4:2:2
Uncompressed 10-bit 4:2:2

I'd assume I need one of the latter two options, but I don't know which one corresponds to the bitdepth of the original capture. I thought YUY2 was 16-bit actually.

Optimize stills: check/uncheck?

(I know I could always try huffyuv instead of Adobe's uncompressed settings, but I still haven't succeeded in conducting a screenshot-based test that proves color information isn't changed slightly upon compression to this format. All I have is the theoretical assumption, but screens prove otherwise. Therefore I would like to avoid huffyuv-compression till the final stage).

[admin]

I generally select DV NTSC or DV PAL for most of my projects. It's mostly just a preset name -- it's not actually using an DV codecs to render or encode.

You don't want square pixels for anything that goes on a DVD, no.

Field order depends on your source input. Most things are top-field first, with DV always being bottom-field first.

I generally ignore the title safe settings anyway, but the defaults are fine. This just affects the preview dotted lines, that show you want won't be seen due to overscan. In other words, what is "safely" inside the viewing area on any TV set.

Of course, the only way to select the video renderer options is to not select DV. Selecting desktop opens up these options.

Are you trying to edit in Premiere, and the export without re-encoding?

I'm not sure I really understand the question entirely.

[Kereellis]

I'd like to mux seperate video and audio streams (from the two different caps as you suggested), without the yuy2 captures being compressed, which probably comes down to 'without being compressed to a different format'.

So, the question would be, what settings meet this purpose?
Also, what's the problem with square pixels?
I thought that in order to maintain the resolution of the capture the pixels needed a 1:1 ratio. I'm not burning to dvd at this point. I'd just compress to mpeg2 for that purpose later, if I need to.

[admin]

I'm afraid I don't have an answer for this. I never use Premiere, and export without re-encoding, either as uncompressed/lossless, or through AME (Adobe Media Encoder) to On2 VP6 FLV, H.264 MP4, or MPEG-2. You're probably best left to experiment. I'll do the same, but you'll surely get to that before I can.

If you find an answer, please do come back and post it!

I would suggest trying it without changing the pixel ratio of the source. I'm pretty sure that changing the pixel type would force a re-encode. Maybe not so certain to bet my life on it, but I'd be willing to wager a few bucks on it! (I'm a gambler, what can I say?)

Another option is to use Premiere ONLY to adjust the audio. Then use VirtualDub to adjust the video. You can "stream copy" in VirtualDub -- not re-compression required. It really depends on how complex the project is.

In all honestly, you'd be hard-pressed to see any quality loss from an uncompressed/lossless re-encode export from Premiere. But I can understand the desire to not compressed. I'm just not sure if you can do it easily, with Premiere as the only tool.

As much as I hate not having the answer, or referring you to another site, you will find more "hardcore" Premiere users at WrigleyVideo.com's forums, as well as the Adobe.com forums. I did a quick check there, however, and didn't see much. You may want to start a new topic, and see if anybody replies.

And again, share you findings here, if you would!

[Kereellis]

Ah well, if there's no answer, then I assume it's just not possible to output stream copy or YUY2 in Premiere (which would be pretty lame for such an expensive software suite if you ask me though..). However it's already quite a pain having to mux video and audio rips, and even more so in vdub as I've noticed, so I'll probably resort to Premiere + huffyuv compression then (but grudgingly!).

I'm still left wondering what to do about the PAR settings in Premiere though. I do all my captures in 720x576, which isn't 4:3 per default, and I assume the pixel ratio of these caps is square, since overriding the default aspect ratio in MPC results in a stretched horizontal dimension compared to the original. Does this mean that if I normally play back my captures on pc, I'm actually watching a slightly elongated version of the original material?

Would it in that case be better to archive my captures as is or should I change the PAR somewhere in the compression procedure for a more correct AR on playback? I'm hesitative about it since I expect changing the PAR to somewhat blur the image like MMC, and then I might as well stretch the original video upon playback if I need to.

Also, why is it that neither of my capture devices (neither the easycap nor the ATI) support 768x576 if that matches the default ratio for PAL? Do they already capture non-square in the right PAR or am I right in assuming they just capture square pixels in the wrong aspect ratio?

Finally are there any misunderstandings that show from my reasoning? I actually never got into the whole PAR subject before this, and it's hard to find some clear answers about PAL VHS sources and capturing regarding the matter, so I'm mostly left guessing.

[admin]

Since this is getting into a new topic, I've moved the aspect ratio conversation to http://www.digitalfaq.com/forum/show...28.html?t=2128

Continue there, for the AR.

[Kereellis]

Done so.

As for the export settings output, some experimenting revealed the following:

Settings
filetype: avi
compression: uncompressed
color depth: millions of colors+
bit depth: maximum

resulted in : 36-bit RGB

Settings
filetype: avi
compression: uncompressed
color depth: millions of colors (without plus)
bit depth: maximum

resulted in: 24-bit RGB

At an eyelevel inspection all conversions are the same. Then I went on to do my screenshot pixel comparison thing again. I made a png-screenshot of a particular frame in all conversions and the original. Selected the same random pixel in all three screenshots with the eyedropper tool in Corel Photopaint and noted down the RGB-values.

The results for this pixel were as follows:

36-bit RGB:
R:98,G:83,B:91

24-bit RGB:
R:98,G:83,B:91

original (YUY2):
R:97,G:84,B:90

It seems safe to infer from this and other tests I conducted (which have shown that either all or no colored pixels in a particular screen match colors with their counterpart in another conversion of the file -although admittedly that's no guarantee for other frames-) that 24-bit and 36-bit both yield the same 'losless' result for YUY2 conversion (except 24-bit comes at a much lower filesize of course). However since there's still a slight inaccuracy in color reproduction (or in color encoding) compared to the original, and RGB takes up more space, there's little use in resorting to these settings for me instead of directly applying huffyuv. I guess I have to throw in the towel here and admit my loss to Premiere.

By the way, this same pixel was rendered as follows after conversion to huffyuv in Premiere:
huffyuv: 97,84,91

Just my findings again. I still have no explanation as to why the heck these color values would differ from the original in losless conversions. There's simply no pattern to be discovered in it so far (for example, in a few of these tests conducted on a particular clip, reconversion to YUY2 of the clip would restore the original colors in two out of three screens, but in the third the colors would slightly differ from both the huffyuv and the original YUY2 versions). Anyway, since the colors differ only so marginally between conversions I guess I just have to accept it as a fact of life. Because of my obsessivity with this issue I've already wasted way too much time on studying pixels instead of rescuing analogue material, which was what I believe once had set out to do ,_,\

[admin]

Although I usually completely shun the attitude of "good enough", there does come a point in time where an obsessive quest for perfection does have to be mitigated and ended with this advice: "It's good enough." After many hours of searching for the best method, I think you've now arrived at that point.

I do this, too. Many of us do. It's not just you.

Although it may be interesting to discover the variations in values -- something that I just really can't explain either -- it may not affect the end-product. That's when "good enough" kicks in.

It may require the knowledge of a video/broadcast engineer, the people that create this stuff, and not us end-users. If you ever do find the answer, please post it here for all to read.

You're also correct when it comes to bit depth. Although it looks good on paper, and becomes the bragging points for tech geeks and company marketing departments, it doesn't often have a lot of real-world meaning. I run into this with scanning, DSLR RAW images, video codecs, etc. --- there is a "good enough" with bit depth, too!