My guess is that scopes2.jpg (the first image that shows when you click on the pictures) is the nano. It has a wider vectorscope trace which I think is a result of having more chroma info.

I'm not sure why you say except for 422 the pictures should be identical? They use different data rates as well, so the images should be somewhat different, hence there should be minor variations in the scopes as well.

What on earth does this have to do with the new firmware? Why didn't you just include it in the thread that refuses to die ("Noise comparison: 35/4:2:0 vs. 180/4:2:2"); you know, the one where no one is willing to make the only realistic evaluation, where both codecs are compared to an uncompressed frame?

Why are you surprised that there is a difference between the two codecs? And if you felt they should be the same, why did you bother getting a nano in the first place?

Who cares which scope picture is which, and why didn't you include a picture of each of the frames you captured, which would at least make it a reasonable question? All the scope pictures tell us is that the frames aren't the same, not which one is more accurate.

Billy

You made it very clear, in both the current manual and your original online post; I just managed to miss it, and my nano is out in the field, running production firmware.

This is great news, at least for me, as having a handful of configuration settings on a single card is just what I need.

I took a quick look on amazon, and there are a number of San Disk Ultra (and Ultra II) cards in small sizes that are under $25; some are under $15. There's even a 2GB Extreme III for under $30. When I get the nano back in my hands, and load the beta firmware, I'll see if I can "qualify" some, at least to my satisfaction (though one anecdotal experience does not make for an unqualified recommendation). If you happen to have some small CF cards lying around the shop, and some free time one day, you might consider some testing... :)

Billy

ps Is UDMA a nano requirement, even for a custom-configuration-only CF card? If so, it'll make it easier for me to rule out a bunch of small capacity CF cards when I go hunting.

I am with Olof. Vectorscope shows more color spatter. It should be noted that there is probably a filter on the blacks "in camera" as there is on many CMOS chipped cameras. We don't know how it is implemented so I would suggest if this is going to turn into a debate on Piotr's scope images and the way his camera spits out data that this be spun out into a new thread so this thread stays as a reporting of issues with the firmware in question.

Dear Billy,

Yes, as far as I know, UDMA is a requirement, even for Config files.

But, there are some relatively low cost UDMA cards.

Please note that they do not have to be fast UDMA cards, just UDMA.

(I have not asked this specific question to our engineers. I do feel that our whole system is built around using UDMA cards, and I just doubt that we used something different for our Config files.

I like being able to keep a Config directory or folder on a computer with a backup of all of my config files.

Billy is the first person to make me laugh out loud at this website. thank you
"thread that refuses to die" HAHA

It's funny how some (most ?) people will deny hard facts in order to rationalize their investment. You have no idea how many of them PM'ed me with exactly the same observations as mine in the "thread that refuses to die" !

I stated it many times the nanoFlash is a great device, and I'm using it every day - yet, it doesn't mean it's forbidden to speak about its shortcomings. Or simply wonder about some of its features, not even calling them "shortcomings".

But enough's been said; I guess I owe an answer to those who tried to guess which scopes belong to the nanoFlash: it indeed is the "scopes2.jpg" picture, so Peter Moretti had it right.

As you say, Peter, "it has a wider vectorscope trace which [...] is a result of having more chroma info". What caught my attention though is that - at the same time - it seems to have less black information (when I compare my other clips, the nanoFlash versions have consistently narrower histogram than their EX counterparts).

Can anybody explain why the nanoFlash would change levels?

Dear Piotr,

Please post the original frames. We need these to evaluate the scopes.

Dear Dan,

As I said in my previous post: when I compare my other clips, the nanoFlash versions have consistently narrower histogram than their EX counterparts. Aso, the same can be seen with other nanoFlash formats (like 100 Mbps L-GoP), and with the previous nF firmware.

So there is no point in posting any particular pair of stills (obviously, people on this forum have had enough of them :)). If however my observation is something new to you, and you cannot re-create it yourself - please let me know, and I'll send you a couple of samples with an email.

Thanks,

Piotr

OK, here is the most neutral comparison:

The difference is extremely subtle, but still the nano histogram is narrower (at both ends - not just blacks)...

It's interesting to see how the single dot in the center of the nano's vectorscope, gets replaced by a circular array of dots for the EX. This might be the reason for "more information" at left side of the EX histogram - if it's indeed, that the "extra information" would probably be just the EX's lower color resolution garbage.

Dear Friends,

Disclaimer: While I understand a Vectorscope and Histogram, I do not consider myself an expert in using these tools.

With that said, it appears to me that the Vectorscope tells the story.

In Image 3 (nanoFlash), the scopes for the nanoFlash, take a close look at the blacks (center bullseye).
Note that these is only one dot in the nanoFlash image.

Compare this to Image 4 (EX), there is not just one center dot, but quite a few in the center (black) area.

In my opinon, the nanoFlash recording is cleaner and this is easily seen in the Vectorscope.

Besides the blacks, the cyan area of the EX has extra dots that are not present in the nanoFlash image.
And note that some are outside the box.

The histogram for the EX will be "Wider" using Priotr's term, for the EX.
The Vectorscope shows why: there is more noise in the EX 35 Mbps (or at least it is less precise).


My comments are not to trash the EX, but to explain why there is a difference in the histogram,
in other words, to answer Piotr questions.

I welcome comments and suggestions from those that are experts in reading these tools.

Dear Dan,

As I already stated in my last post, this is what I'm thinking as well.

Thank you for inviting me to post some screen grabs; while I was reluctant at the beginning (for obvious reasons :)), this led me to the idea of shooting the EX1's own bars. Their scopes, and as you point out - particularly the vectorscope, says a lot.

Since I'm not an expert in interpreting all the intricacies scopes show, I'd once again like to invite those more knowledgeable than myself, to chime in and discuss the matter further.

I'd say it's not more noise (in the common meaning of the term), but certainly less precision of the EX 4:2:0 picture when compared to the nanoFlash'es 4:2:2.

To Chris: if you think this subject deserves it, please take out posts starting with #34 from the Beta firmware discussion thread and create a separate one. Thank you.

Piotr

Dear Piotr,

After I posted my reply, I re-read your original post and noted that you came to a similar conclusion.

Dear Dan,

Yes - this is the only explanation that comes to my mind.

This can be further illustrated with the examples below: on the right, you can see a blown-up detail from the EX. At 4:2:0 color resolution, you can see black stripes across the solid red color - they may be accounted for by the extra content at the very left end of the histogram.

The left-hand side pics show the same frame from the nano; no black stripes, less black garbage in the histogram, richer vectorscope trace...

I believe the six vectorscope dots around the center are caused by bleeding between the luma and chroma values along the horizontal edge where the vertical color bars meet the grey horizontal stripe. This is causing values that are "mostly white." That is, they have almost equal R, G and B vlaues but do also contain small amounts of color information from the color bars.

Such values would show as being slightly off center in the direction of the "polluting color" on the vectorscope's graticle. And that's exactly what we see.

If you blowup by a considerable amount the border between the horizontal line and the color bars, you can actaully see this "bleeding" with your naked eye.

I HTH and believe it's accurate. ;).

Yes Peter - the vertical color resolution is so much better with 4:2:2 than it is with 4:2:0, isn't it. It can be seen at the border between the horizontal line and the color bars; it's also apparent in my red flower blow-up.

How nice it would be if the same was possible in the other direction - but there is only one way to get it all: 4:4:4 :(

Actually, 4:2:2 and 4:2:0 theoretically have the same vertical resolution. It's the horizontal resolution that's different.

But when you throw in macro blocking, bit rate and how the codec works, there can be a difference in vertical resolution as well. So the horizontal banding you're seeing is not really the direct result of 4:2:0 but a more complex combination of factors.

Dear Friends,

I received an email concerning these comparisons:

He points out that "the difference between the SxS and the NANO files, is not due to the difference on the recorded signal, but on how is displayed."

"The difference is dues to a property of the QT files called APERTURE ( Properties > Presentation).

The aperture of the NANO files is "CLASSIC", while the aperture of the SxS files is PRODUCTION.

QT has four different aperture options.

The same clip displayed with different "apertures" will show some differences on the screen (QT Player, FC) and on the VideoScope."

Dan,

I respectfully disagree w/ that explanation. The aperture size in QT has to do with subtle differences between SD and DV frame sizes and pixel aspect ratio. It would not cause the horizontal banding that I described above.

A difference in QT Aperture can cause a difference in adding or removing black from the the borders of the entire frame, but I really don't think that's happening in this case.

HTH, and that I'm giving you the correct info.. (I obviously believe that I am.)

I beg to disagree - just take a look at diagrams on Page 3 here:

http://dougkerr.net/pumpkin/articles/Subsampling.pdf

But I guess we mean the same thing - just a matter of nomenclature; better vertical resolution = more horizontal lines.

Dear Peter,

I tried hard, in posting the information, to convey the information provided to me.

I am not knowledgeable about Aperature settings.

And I do not understand how this information can be determined from the images Piotr posted.

But, the information came from a trusted source, but his posts, for some reason were not getting through.

Also, I am certain that the originator of the comments was not referring to your post. His email arrived in my inbox at 2 pm EST today, before your first post in this thread.

I am trying to learn about "Aperature" settings as used in this context.

Dear Friends,

I am wondering if the "Aperature" has application here in this discussion or not.

I believe that Piotr uses Sony Vegas Pro 10.

If "Aperature" is a Apple Quicktime or Final Cut Pro control only, and if it does not apply to the way that Sony Vegas Pro 10 displays the files, then we should discount the "Aperature" discussion.

I believe we do mean the same thing. But, FWIW, the "correct" terminology is 1/2 horizontal resolution. You can see in the diagram that you referenced a "H: 1/2" next to 4:2:2.

An Aperture setting is usually set during creating the QT wrapped file. Now if the NLE or player actually uses this setting depends on the program. Some also let you override what's set in the file. Often times slight issues in aspect ratio or garbage lines on the top and bottom of the frame are caused by an incorrect Aperture setting. So extra black info in a histogram can be the result of such garbage, but that's not what's going on here.

I have no doubt whatsoever that the nano writes the correct Aperture setting. And just because the EX uses "Production" instead of "Classic" does not mean that there is any type of mismatch. Often times different Aperture settings will yield the identical result.

Exactly, Peter:

4:4:4 ----> H:1/1, V:1/1

4:2:2 ----> H:1/2, V:1/1
4:2:0 ----> H:1/2, V:1/2

- which means the vertical resolution is exactly 2x higher in 4:2:2 than it's in 4:2:0. Both 422 and 420 have horizontal resolution 2x lower than the full 4:4:4 sampling (and this is probably what you meant).

422 has DOUBLE COLOR VERTICAL RESOLUTION than 420.
Just have a look to a 2x2 pixels block as 4.2.0, and to the same 2x2 block as 4.2.2.
rafael

Peter,
The miss match is HUGE.
You simply can not cut between a picture with an aperture and the same picture with a different aperture.
The picture JUMP as when you were cutting between signal out of sync.
They have different sizes on screen.
This may be something originally designed for DV, but affects every single standard, format, size,..
Just open any QT file and switch between the different aperture options.
rafael

Dear Dan,

Just to return to this thread main subject: what do you think is causing this slight audio delay in the present Beta?

FYI, it used to be even longer with previous firmware releases (I don't know about the 1.6.29, as I skipped it).

Thanks,

Piotr

Dear Priotr,

How does the audio line up to a loud clap, one near the lens and near the mic?

4 milliseconds = 1/250th of a second.

May I assume that you are recording in MXF, and using an EX1, using embedded audio in HD-SDI?

I assume that you are using I-Frame Only at 220 Mbps.

Dear Dan,

All your assumptions above are correct.

I'm not sure I understood your question, but I'll try to be more specific:

- the slight delay of nanoFlash clip (both audio and video) in relation to the EX1 internally recorded one is natural. However, I'm talking about the audio lagging behind the video inside the nano clip - i.e. after having aligned the nF and EX video with a single frame accuracy (using TC), the nF-recorded audio is still those 4 ms behind the EX-recorded audio.

As I said - not a big deal, but out of technical curiosity - what might be causing it? Both audio and video are fed to the nanoFlash simultaneously, through SDI...As is the TC, by which the video can be synchronized perfectly in Vegas Pro - but not the audio?

To synchronize the audio perfectly, I must ungroup it from the video, turn frame quantization off, and slide the audio by exactly 4 ms.

Believe me, 4 ms can be important with the kind of recordings I do. I produced a live classic guitar performance recently: - and on those close-ups of the guitarist fingers, even 1 ms audio/video lag is visible!

Thanks

Piotr

Oops - I didn't realize inserting a link to Vimeo clip will open the player; this was NOT my intention as there are no close-ups I mentioned in this particular clip, which is just a sample of the DVD I made later :) But you can take my word for it - with fast passages watched on a really big screen, every string pulling must be perfectly synchronized with the sound of the string, or a person with a good ear for music will notice. I remember that while editing this video, I had to adjust the audio by milliseconds quite often...

Yes we agree :). And you are right concerning the comparison to 4:2:0 in terms of vertical resolution. So what I wrote about 4:2:0 not being responsible for the horizontal banding is incorrect. I knew that 4:2:0 halves the resolution in both directions, but had in my mind that 4:2:2 halves the horizontal resolution (compared to 4:4:4).

So your explanation of the horizontal banding being caused by less vertical resolution in 4:2:0 is correct. ;)


P.S. Are you sure the audio issue you're having might not be caused by mic placement? I'm sure you know that a mic placed farther away from a subject will cause delay, due to the fact that the sound traveling to the mic travels more slowly than the light traveling to the sensor. I believe the rule of thumb is that a mic 20' away from the subject will cause a one frame audio delay.

Peter,

Of course I'm aware of the light vs. sound speed difference, but this is not the case here - I was comparing the nano recording with the EX own recording, done simultaneously, with a single microphone, and with the nano fed from the EX1 through HD-SDI.

The above is an explanation of my "4 ms audio lag in the current Beta", and NOT how I recorded the live event I mentioned later on :)

Gottcha. I thought that was the case, but just thought I'd ask ;).

Is that Wawel?

Thanks Rafael - your posts arrive with considerable delay, which is a great pity :(

You're probably reading this "in real time", so you're aware that some people (like Luben) also suggested the Aperture setting difference being the reason, but that has been ruled out later on the basis that my examples come from MXF files and Vegas Pro, the environment which doesn't use the Aperture parameter at all.

Nevertheless, the question remains open to Dan on why CD have chosen to encode with Aperture set to "Classic" setting while most camcorders record with Aperture set to "Production". If there are no special reasons for this, perhaps the nanoFlash could also use the latter, if only for compatibility reasons?


Piotr

That's right, Adam. BTW, this particular event took place at the Batory Courtyard - a place never available to the public before.

Keep in mind that you're talking about chroma subsampling here, not luminance. While I'm not trying to dismiss the degradation that happens with chroma subsampling, it's a far cry from what most people think of as 1/2 the resolution.

Billy

Thank you very much for enlightening me, Mr. Steinberg. It would have never occurred to me!

Do you have an easy means to check the sync right out of the camera's HD-SDI spigot (or HDMI spigot if that's what you use)?

The reason I ask is that the path the video/audio takes to the internal recorder is very different from the path it takes getting out of the camera. Just because the internal recorder is dead on sync while the nano recording is slightly out doesn't mean the delay is being introduced by the nano. It doesn't mean it's not the fault of the nano, particularly if early versions of the nano firmware were enough out of sync that it was obvious it wasn't the camera, but now that you're talking about minuscule sync errors, before you spend a huge amount of time determining if the nano is out of sync, you might want to check if the feed from your camera is out of sync.

Just a thought.

Billy

Right.
Luma is full resolution, whatever the format, from DV up.
rafael