I just reported a nasty bug that makes Adobe MEdia Encoder totally useless. It cannot even read the pixel aspect ratio of a ProRes file. It really sucks bigtime.

If I import a PAL ProRes file (obviously with non-square pixels), AME THINKS that the file has square pixels. It wants to add black bars on both sides of the footage, or it wants to make me crop the top and bottom of the image. That is all the options this program gives, there is no option for overriding the pixel aspect ratio of the original file.

I know the file is definetly not with square pixels. Premiere reads it correctly, Final Cut reads it correctly, my DVD Authoring program reads it correctly. AME is the only program that goes "Oh... oh... SQUARE!" Incredible. Why on earth are there no options for setting the correct pixel aspect ratio? LEt me freakin override the ****** software that cannot read the pixel aspect ratio automatically!

But sadly that doesen´t fix the bug for importing it directly to Media Encoder. I´m trying to streamline my work, I have several hundred clips each week that I need to convert. Making Premiere Projects for each clip just to make the Media Encoder to understand that the file doesen´t have square pixels somehow doesen´t feel like a perfect solution.

I´m not sure what to do, perhaps I will stick/switch to Compressor in my macs so I won´t have to create tons of Premiere projects for nothing. Thats a bit sad, since I really prefer the layout on Adobe Media Encoder. It is much faster and more intuitive to work with setting up the batch lists. But if it cannot ingest the footage properly...

Hopefully Adobe will fix this in some update, now they should know about the bug anyway.

It is very weird that both Final Cut and Premiere reads the aspect ratio correctly, the Media Encoder is the only program that thinks that the pixels are square.

Well I would if Adobe had a codec as good as ProRes to use. Sadly they don´t, so I need my macs to be able to use ProRes. No other codec gives the same level of quality, and at full HD resolutions (1280x720 and 1920x1080) as well as PAL resolution.

You have another, and I would say better, option: Avid QuickTime Codecs 2.0. You want to use the DNxHD codecs included in the package. DNxHD and ProRes are pretty similar, with the former being generally regarded as having a higher level of quality. What's nice about the Avid codecs, as well, is that they can be used for both read AND write on Macs AND PCs--the same cannot be said for ProRes, which limits PCs to playback only.

And you can always go uncompressed, if needed--though the file sizes can be a bit unwieldly.

Uncompressed really takes up a lot of drivespace. The reason I didn´t go the Avid-way is the following: The way I understand it you cannot capture directly to the codec, you´d need to capture first to uncompressed and then make the DNxHD files. Definetly a bottleneck.

Adobe doesn't need a codec as good as ProRes because Adobe edits everything natively. There's no need to use such a codec. You ingest the media directly, edit that, send it to AE without rendering, bring back to Premiere without rendering, and even send it off to Encore without rendering, keeping everything native, using only the original media for final transcoding. You just can't get any higher quality that that.

A card is not a solution. A card is merely a way to get the signal to the computer. Then you need a codec, be it DV, DVCProHD or ProRes.

A card is not a codec. And the scenario I wanted to bring attention to was the fact that Adobe Media Encoder cannot read the pixel aspec ratio of a ProRes file correctly. Premiere does, Media Encoder doesen´t.

I already know what codec to use, and that is ProRes. Wich has lead me to from Premiere to Final Cut, like it or not. Actually I don´t like it all that much. I like the user interface of Premiere more. I´m hoping the next Final Cut version will be better (as well as the next Compressor). Oh, and PCs are cheap as hell when compared to the price of a MacPro.

But I need the best results, and in a good workflow, so I need ProRes.

You just DON'T get it do ya pal. The reason FCP uses prorezz is because it can't edit the footage that was shot right out of the camera. Adobe can...so can Edius there are plenty of good codecs out there (there's a few great free avid codecs that are 10 bit and are aroubd the same size as pro-rezz)

Why not just edit with whatever codec the camera shot instead of wasting time going to another codec anyway.

The whole point of CS4 is being able to edit the footage your camera shot without having to makwe new files and lose a generation. Why is that so hard to understand for FCP people?

You just DONT get it, do ya pal? The footage is shot by professionals in a studio using cameras that will never ever record anything on tape. You know why? Because the tapeformats are more compressed and takes time to log and transfer. I just get the files directly to my drive arrays and get much better image quality.

You might want to try working with something that isn´t shot with a tiny handheld AVCHD camera compressed to ****. I couldn´t care less if I am able to edit the files directly, they are so compressed I wouldn´t touch them with a ten foot pole.

Please tell me what the hell kind of codec you are talking about that are "around the same size" as ProRes. also let me know why on earth the size of the files would be so interesting. I´m more interested in the image quality and in good workflows, as in being able to RECORD directly to the codec.

This thread was never a question about codecs, it was a question about the Media Encoder not being able to read the aspect ratio of files correctly. Have you even read the thread or are you just banging your head in the wall because someone is using Final Cut? Get over it already.

Apparently you guys have no idea what you are talking about regarding codecs, why on earth have you made this into a pissing contest?

If there are no known PAR bugs in AME I am really glad I reported this as a bug, it means I actually found a new bug. If I import the file to Premiere the PAR is indeed seen as PAL nonsquare, but if I import the same file to AME it treats the file exactly as if it is 720x576 with square pixels. That is: adding black bars on both sides, unless I change to square pixels in the settings or crop the image top and bottom.

I have never (and will never) understand why on earth someone would want to record something to AVCHD and compress the footage a lot. I think the original footage should have as little compression as possible, both HDV and AVCHD are very compressed, with AVCHD being the worst of them. Sure they can be edited, but they won´t stand for colorcorrections and advanced editing like champs.

"BTW I'm not being a smartass when I say that Premiere is made and advertised to edit the media natively. It is an advantage to not have to make new files just to edit."

Of course it is, I totally agree with you. However the footage I have doesen´t have any "native" cameraformat. It is recorded directly to ProRes files, so there is no need to make new files.

Adobe did change the PAR values for CS4. Read the above. DO you think that might be it? Can you explain what's wrong with the pic, is it stretched horizontal or vertical. Your files are fullscreen right?

"Adobe did change the PAR values for CS4. Read the above. DO you think that might be it?"

I don´t think so. These files were created by me 2 days ago, exported from Final Cut to new ProRes files.

"Can you explain what's wrong with the pic, is it stretched horizontal or vertical. Your files are fullscreen right"

They are PAL sized for 4:3, not 16:9. Weird thing is, if I load the file to GSpot for codec examination it tells me that they are MOV files, but nothing else?I just thought I would have a non-partial examinator of the file.

If I load it to the inspector in Compressor it tells me the PAR is PAL CCIR 601, with encoded bounds 720x576 and display bounds 768x576 (I´m guessing it is to show how the file is to be displayed by computers in order to show a corrected aspect ratio).

If I load it to Premiere, it tells me the PAR is 1.094

If I load it to Final Cut, it tells me tha PAR is PAL CCIR 601

If I load it to Adobe Media Encoder it doesen´t tell me anything about the PAR, but it treats the file just as if it would be encoded with square pixels (wanting to add black bars on both sides if encoded to DV, for example). If I choose to encode it to PAL DV, then go to the settings, if I view the SOURCE tab I see the image with correct aspect ratio, as it should be. If I switch to the tab with OUTPUT tab AME wants to squeeze the image horisontally and add black bars on both sides of the image. This would be correct if the file would have been encoded with square pixels.

I think a lot of the frustration and anger expressed in this thread is due to a simple misunderstanding. I suspect that the OP is mistaking Avid DNxHD for some flavor of AVCHD. The two are not related at all.

It seems that things have calmed down - kudos to the involved parties.

Wearing my Community Expert hat:

How thick are the black bars on the sides? If they are thin, then I think the different PAR calculations between apps is the problem. I don't use FCP, but I suspect it creates PAL 4:3 (non-square) with a 1.066 PAR and Adobe now uses a PAR of 1.094.

If the black bars are thick, then there is a mismatch in settings and interpretations. I did some Googling, and it seems that both FCP and Quicktime Pro have several settings that seem to be similar or that have logical names, but are not, in fact, the correct settings. In that case, I recommend that you retrace your steps through all the FCP and ProRes capture and export settings, just to be sure you're getting what you expect out of FCP. I also recommend that you go through the Video tab of the AME settings to make sure everything there is what you expect.

You've said at least twice that Premiere is seeing the PAR correctly. If you try to export from Premiere, does the AME interface from inside Pr show you the proper PAR?

A card is not a solution. A card is merely a way to get the signal to the computer. Then you need a codec, be it DV, DVCProHD or ProRes.

Fine. The AJA card uses the V210 codec, which is a 10-bit 4:2:2 Uncompressed Component YCbCr format, taken directly from the SDI inputs on their card. Premiere doesn't do Uncompressed so well on it's own, so it uses third-party cards to add that functionality.

Actually I don´t like it all that much. I like the user interface of Premiere more

Which is why I suggested an all Adobe workflow. An AJA or BlackMagic card will allow that while keeping the quality you desire.

"I suspect that the OP is mistaking Avid DNxHD for some flavor of AVCHD."

No, not at all. I have no idea why everyone suddenly started talking about codecs and suggesting a all-Adobe workflow and suggesting other codecs.

"How thick are the black bars on the sides?"

Not superthin.

"I don't use FCP, but I suspect it creates PAL 4:3 (non-square) with a 1.066 PAR and Adobe now uses a PAR of 1.094."

Yet, Premiere CS4 still reads the PAR correctly as nonsquare pixels. If Adobe would make Media Encoder read PAR the same way as Premiere, the problem would be solved. Or if they would give me the option to override PAR and squeeze/stretch the image any way I wanted to.

"...you retrace your steps through all the FCP and ProRes capture and export settings"

Premiere has had nothing to do in either capturing or exporting these files. I don´t think there is anything wrong with the PAR of the file since Premiere, Final Cut and Compressor reads the PAR correctly. My first thought was that there is something wrong with the files, but since I cannot get any other software than AME to reproduce the incorrect PAR I believe that AME is the bad guy here.

"You've said at least twice that Premiere is seeing the PAR correctly. If you try to export from Premiere, does the AME interface from inside Pr show you the proper PAR?"

Yes, I did it to show that the PAR of the file is not incorrect. If the PAR of the file was square then Premiere too should read the file as square pixels.

If I create a Premiere Project with the file, and then import that project/sequence to AME, then AME reads the PAR correctly. I guess it reads the PAR of the sequence in this case.

"Fine. The AJA card uses the V210 codec, which is a 10-bit 4:2:2 Uncompressed"

Uncompressed is not an option, since it eats up way too much space on the hard drives.

"Which is why I suggested an all Adobe workflow. An AJA or BlackMagic card will allow that while keeping the quality you desire."

How would a all Adobe workflow give me a way of capturing and encoding files with ProRes quality, without going for uncompressed?

Can I capture to DNxHD with Premiere through a uncompressed SDI connection? I didn´t think that was possible.

I don´t want to go uncompressed, I only have some 40TB drive space and I need a format with top quality that I can deliver on hard drive to my clients. They don´t have the arrays top play/use uncompressed HD, and I don´t have enough drive space.

I don´t think there is anything wrong with the PAR of the file since Premiere, Final Cut and Compressor reads the PAR correctly. My first thought was that there is something wrong with the files, but since I cannot get any other software than AME to reproduce the incorrect PAR I believe that AME is the bad guy here.

I can't get the AME to misbehave like that here. I'm using NTSC footage and an all-Windows, all-Adobe workflow. I only mention that so that you have a data point to reference. Pr CS4 has had multiple issues with .mov files and Quicktime in general, so it's quite possible that PAR interpretation in the AME when using .mov files, QT, FCP and ProRes is smurfed.

How would a all Adobe workflow give me a way of capturing and encoding files with ProRes quality, without going for uncompressed

Can I capture to DNxHD with Premiere through a uncompressed SDI connection? I didn´t think that was possible.

Only if your current setup allows you to capture with Premiere to a codec other than uncompressed. Apparently you can already do that with FCP. You should test the Pr workflow before you install DNxHD.

I don´t want to go uncompressed, I only have some 40TB drive space and I need a format with top quality that I can deliver on hard drive to my clients. They don´t have the arrays top play/use uncompressed HD, and I don´t have enough drive space.

Did you say 40 Terabytes? As in forty-thousand Gigabytes? And you still don't have enough drive space? Wow.

"Pr CS4 has had multiple issues with .mov files and Quicktime in general, so it's quite possible that PAR interpretation in the AME when using .mov files, QT, FCP and ProRes is smurfed."

That is probably the case.

"Did you say 40 Terabytes? As in forty-thousand Gigabytes? And you still don't have enough drive space?"

Yep! It is somewhere between 40-50TB. What can I say, my facility moves a lot of film.

I also keep everything as a backup for 14 days, so if anything goes wrong with the films I provide to my clients I can make new versions. Sometimes some of the clients doesen´t come to pick up their films for a few weeks, so I need space for my backupfiles.

Yeah I found this out too, really annoying and not fixed even in the latest updates.

The way I got around this (sort-of) was in FCP begin the sequence (we're talking DV PAL 16:9 here) with a 1-frame solid colour video generator in the top layer. With opacity at 0% it just sits there BUT since it is inheretly a square pixel format, Media Encoder now seems to read the entire FCP exported sequence as square pixel format. You can check the difference in quicktime info with in the size settings now showing 720x576 (1024x576) rather than 720x576 (768x576).

The final flash encode isn't completely in a perfect 16:9 aspect ratio (it has thin bars at the top) but it's very close and can be cropped by resizing the frame height and checking the output window.

I'm getting a similar weirdness with a PAL DV QT exported from FCP. Adobe Media Encoder 4.0.0.374 tells me it is 786x576. That's right. 786, not 768. Weird. So when I downrez to 4:3 ratio for web delivery, instead of a setting like 256x192, it puts it at 262x192!!! If I set it manually, it has black letterboxing. Annoying as hell from a best practice standpoint regarding the ratios.

I never had this issue with FLV export from PAL DV QTs from FCP before Media Encoder. The old Flash 8 exporter worked. Not sure if it's QT or AME.

Also discovered that the easiest thing right now, aside from Exporting via Compressor as a H264 with an extension of .f4v instead (which reads fine by Flash) and loosing a little bit of convenience (though saving on another conversion) is to set the FCP timeline to Square pixels. So I did that.

And I also changed the codec from DV to ProRes and changed the 720x576 pixel ratio to PAL sq (and it correctly jumped to 768x576),

BUT

when I exported as a QT and dump in the CS4 Media Encoder, it still didn't resize correctly. Media Encoder is still incorrectly reading it as 720x576!!! wtf?

So it looks like I may have to Export through compressor after all. This is getting ridiculous.

Of course you prefer FCP, so do I and everyone I know. The only reason I wanted to use the Adobe Media encoder instead of Compressor was the fact that I wanted to create AVI files, and Compressor won´t do it.

I found a solution: Don´t use any Adobe products at all. They don´t give a **** about this bug. I use Mpeg Streamclip for the creation of my AVI files now, and it reads the pixel aspect ratio correctly, as does any other software I throw these files at. Except Adobe Media Encoder.

The fact is still that all other software understands that the PAR is supposed to be nonsquare. AME doesen´t. Bad explanations will never change this.

And it is still a fact that Premiere reads the PAR correctly, but AME doesen´t. So your BBC explanation just went down the drain, if this would be the case then all Adobe software would read the PAR the same way.

The fact is still that all other software understands that the PAR is supposed to be nonsquare. AME doesen´t. Bad explanations will never change this.

And it is still a fact that Premiere reads the PAR correctly, but AME doesen´t. So your BBC explanation just went down the drain, if this would be the case then all Adobe software would read the PAR the same way.

I didn't re-read this thread from the beginning and I should have. Sorry. I misinterpreted your most recent posts.

But as I said before, I can't get the AME to misbehave this way.

Have you narrowed it down to only files created with the ProRes codec? Or did I miss still more info from earlier in the thread?

I have no idea, since all the compression I wanted to use AME for was the convertion from SD-PAL ProRes to SD-PAL AVI. All the other convertions and compressions we do over here, I use Compressor. Perhaps it is a bug that is specific to how AME reads the PAR on ProRes files. I could email you a short clip (just a few frames) if you want to test it.

I reported this to Adobe, but I haven´t even gotten any reply from them. So they don´t care.

By the way, I can really recommend Mpeg Streamclip if someone has problems with PAR on AME. Mpeg Streamclip is free and reads the PAR correctly.