That's a good bit larger than I had imagined. Is that the actual size or were those things just rough mockups?

Hello Mike,

I don't know who would handle this type of request.

I might suggest the forum moderators at http://ediusforum.grassvalley.com/forum/index.php

Or a call to tech support at (801) 222-5204 might lead you in the right direction.

That's a good bit larger than I had imagined. Is that the actual size or were those things just rough mockups?

Exactly my first thought, too. Actually, with the unit being this huge, it's not a question how you attach it to the EX1 camera - rather how you attach the camera to this monster :)

I don't know why, instead of reading the specs carefully, I imagined it being the size of the Sony DR60 drive!

I've seen under camera cage mounts that hold firestores so I'm guessing that wouldn't be a bad option for this thing with smaller non-shoulder mounted cameras. Maybe you could also stick it on the back of one of those 3rd party shoulder mounts for the oversized handycam types too. If the image quality gains of this thing are as advertised, someone will figure out a good way to mount it to almost anything.

I can now understand why it wouldn't be a great match for say an HV20 or that sized camera.

Considering that it's a $5,000 SDI recorder, it was never a great match for a $900 non-SDI HV20.

Convergent-Design will be designing a custom bracket for the XL H1 and XL H1s to hold the Flash XDR.

The photo of the Canon XL H1s shows the Flash XDR resting on the standard bracket that comes with the XL H1s. This bracket is not custom designed for the Flash XDR. The custom bracket will probably hold the Flash XDR lower.

Yeah, on the spur of the moment I had asked Dan to hold the Flash XDR up to the XL H1 accessory bracket, and he said "what, like this?" and I snapped the photo. I didn't put a whole lot of thought into it.

Hi,

Sorry to add to this negitive point, it looks big to me as well.

Would need to use off camera somehow, sound crazy but strapped to my arm or something.

Suggestions would be great.

Mike.

The Flash XDR is relatively big, but not as big as it looks in the first photo of Chris's.

I do not know what lens Chris was using, but we have a "Wide Angle Lens" effect in that photo, in that items closer to the lens look bigger, and items farther away look smaller.

Just take a look at my hand, it looks much bigger than the Canon lens.

Of course the Flash XDR is bigger than what was originally planned, but it is not as big as it looks in the first photo.

Convergent-Design announced the nanoFlash at NAB. This unit will be much smaller and will have different capabilities.

For example, the nanoFlash will have two Compact Flash card slots instead of four which will allow the unit to be smaller.

In addition, the nanoFlash will probably not have the four additional power supplies which are required to support world class analog audio inputs.

The nanoFlash will still support audio embedded in the HD-SDI bit stream, as does the larger Flash XDR, but not XLR mic inputs with phantom power.

Mike Schell will post the actual weight and size of the Flash XDR as soon as possible.

NanoFlash - sounds so interesting, even though I already have paid the deposit for the XDR! For my needs, the 2x32GB CF cards and no additional XLR inputs would be just enough - if accompanied by a lower size and price tag...

Mike, please update us on the nanoFlash; when will it be available?

I do not know what lens Chris was using, but we have a "Wide Angle Lens" effect in that photo...The camera I used is a Canon PowerShot SD870 IS, and it is indeed a wide-angle lens (in fact it is the only PowerShot with a WA lens, which is why I bought it) and I was zoomed out to full wide for those shots. So yes it's definitely an image effect.

Dear Chris,

Thank you for confirming what I was seeing.

In the first photo, the Flash XDR looks huge!

The second photo shows the actual size much better.

Nevertheless, when you compare the second photo of Chris' (without the wide angle effect) to what was published at the very bottom of the preliminary brochure (also mounted on the XL H1), there is still a huge difference - almost double the size !!!

http://www.convergent-design.com/downloads/Flash%20XDR%20Brochure.pdf

Looks I wasn't dreaming - the device has grown during development.

Hi,

Sorry to add to this negitive point, it looks big to me as well.

Would need to use off camera somehow, sound crazy but strapped to my arm or something.

Suggestions would be great.

Mike.

Hi Mike-
We will be introducing a smaller version, called nanoFlash. This new box will be about 1/3 the size of Flash XDR and will not include analog audio I/O and only have 2 CF card slots. Also nanoFlash will have a built-in holder for Sony camcorder batteries (the 7.4V InfoLithium). I'll post more details later this week.

Nevertheless, when you compare the second photo of Chris' (without the wide angle effect) to what was published at the very bottom of the preliminary brochure (also mounted on the XL H1), there is still a huge difference - almost double the size !!!

http://www.convergent-design.com/downloads/Flash%20XDR%20Brochure.pdf

Looks I wasn't dreaming - the device has grown during development.

Hi Piotr-
Yes, Flash XDR has grown in size compared to our original estimates. The analog audio required much more space than originally planned (it's a premium quality design) and the addition of 2 more CF card slots added to the size. The weight and power consumption are still about the same as our original projections.

So, we're rushing out the nanoFlash, which fortunately uses the same technology as XDR, but without the analog audio and only 2 CF cards.

Mike,

I really wanted to get down to South Hall lower and say hello last week. I had another gentleman with your company that came by the Sony booth where I was working. I am keenly interested in this device for the F350.

Thanks for keeping DVINFO abreast of the project!

-gb-

Hi Piotr-
Yes, Flash XDR has grown in size compared to our original estimates. The analog audio required much more space than originally planned (it's a premium quality design) and the addition of 2 more CF card slots added to the size. The weight and power consumption are still about the same as our original projections.

So, we're rushing out the nanoFlash, which fortunately uses the same technology as XDR, but without the analog audio and only 2 CF cards.

Thanks Mike for this update. If I may suggest something: please prepare the nanoFlash with different battery holders (like both the 7.2 and 14.4V Sony's, with the XDCAM EX line growing!) Or at the very least, if it only can be the regular one, make the battery chargeable on the unit...

This is not to say I'm definitely giving up the XDR for the little brother, but - dependig on your pricing and time to market - will be considering either. Hopefully, my deposit would be valid for the nanoFlash, as well :)

Thanks Mike for this update. If I may suggest something: please prepare the nanoFlash with different battery holders (like both the 7.2 and 14.4V Sony's, with the XDCAM EX line growing!) Or at the very least, if it only can be the regular one, make the battery chargeable on the unit...

This is not to say I'm definitely giving up the XDR for the little brother, but - dependig on your pricing and time to market - will be considering either. Hopefully, my deposit would be valid for the nanoFlash, as well :)

Hi Piotr-
We'll try our best to support both batteries, I'll need to study the EX battery mount a bit more before making a definite commitment. The older 7.2V batteries are fairly easy to mount. The nanoFlash will operate over the same voltage range as XDR (6 to 20V), so in theory the battery should work.

Your deposit is good for either product. We'll have pricing and delivery projections on nanoFlash shortly.

Mike,

I really wanted to get down to South Hall lower and say hello last week. I had another gentleman with your company that came by the Sony booth where I was working. I am keenly interested in this device for the F350.

Thanks for keeping DVINFO abreast of the project!

-gb-

Hi Greg-
Thanks! Please send us a quick e-mail (sales@convergent-design.com) and we'll get you registered for our updates.

Dear DV Info Members-
During my long drive back from NAB, across Utah (which is quite beautiful), I thought of a second application for Flash XDR which I wanted to discuss with you.

Flash XDR has been targeted as an acquisition device, with the advantages of improved video and audio quality as well as tapeless workflow. However, XDR could offer advantages in content delivery.

After you complete a project, the video and audio could be streamed to Flash XDR (or nanoFlash) via HD-SDI or even HDMI (nanoFlash) and stored on CF cards at our highest quality (100 Mbps 4:2:2 Long-GOP) or recorded at bit-rates compatible with broadcast servers (18 Mpbs 4:2:0 Long-GOP).

We then have a couple of different delivery options. The CF cards could be overnighted to a service bureau (possibly Convergent Design) for output to an HDCAM or DVCProHD tape to be shipped to the TV station or network. For 30 second spots, the MXF file could be directly uploaded to our server for output to tape.

Alternatively, assuming the station had an XDR, the CF cards could be shipped directly to the network for upload into their server (re-encode to the desired bit-rate), instead of the HDCAM tape route. (Given the small size and light weight, you could also ship the XDR to the TV station for upload).

The ultimate delivery method would be to encode the video at the desired broadcast bit-rate (15-18 Mbps) and then upload the content via an FTP site at the TV station / network (or overnight a CF card).

I know HDCAM deck rental can be expensive and a real hassle, so I wanted to propose several other content delivery options for your consideration.

Dear Mike,

If my calculations are correct, one 32GB Compact Flash card, should hold a around 30 minutes of MPEG2 video using 4:2:2 at 100 Megabits per second.

At 50 Megabits per second, the card should hold around 60 minutes.

Since this card costs only $150, the shipping and insurance cost will be minimal.

Also, since the Flash XDR is capable of producing two originals, there is no danger of losing an important video.

Mike,

One thing got me interested - will nanoFlash only offer HDMI, not HD-SDI?

Mike,

One thing got me interested - will nanoFlash only offer HDMI, not HD-SDI?

Hi Piotr-
nanoFlash will have HDMI and HD-SDI inputs as well as HD-SDI output. We will support the same MPEG2 rates and profiles as XDR and offer ASI I/O option.

Mike:

Was good to meet you in person at NAB - wondering when you sleep, man!

Has your team been able to iron out the playback glitching anomoly yet?

As far as the size growth discussions, I don't see the current size as an issue especially when you compare the XDR to the other similar codec quality recorders (existing and future designs shown at NAB). I wished more folks had the opportunity to pick up the current XDR in their hands like those of us who attended NAB did - it really is shockingly light in weight.

Ship them ;>}

Dear John,

It was nice meeting you at NAB.

The "playback glitching anomly" was in the pre-production board with very special firmware that was created in a hurry to record a short clip, and then playback repeatedly. The problem was in the playback.

We wanted to show actual footage at the show, so we recorded a short clip at the start of each day. The glitching will not be in the production firmware (obviously).

Mike is working to create some clips which will show the differences between 25 Mb (Megabit per second) compression rate, 50 Mb, and 100MB.

I believe that you will be very pleased with the results.

Was a great pleasure meetng you as well Dan.

Can't wait to see the sample footage - especially the 100mb format.

Do you know of any new info regarding NLE support for the various formats?

And thanks again for all the help you've provided in the H1 forum.

Dear John,

Thanks for the very kind words.

I do not have any updates concerning which Non-Linear Editors will support which bit rates at this time.

Mike will be addressing that issue. As we get closer to shipping, we will have some answers from the NLE vendors.

What I can say at this time, is that there is a dramatic increase in quality, based on our testing, between a 25 Mb file and a 50 Mb file.

More results of our image testing to come.....

Was a great pleasure meetng you as well Dan.

Can't wait to see the sample footage - especially the 100mb format.

Do you know of any new info regarding NLE support for the various formats?

And thanks again for all the help you've provided in the H1 forum.

Hi John-
Thanks! Enjoyed meeting you also at NAB. It was quite a show for us and the Vidy and BE Pick Hit awards were icing on the cake!

I will be posting sample footage tomorrow. We have comparison images at uncompressed, 50 Mbps 422, DVCProHD and HDV rates. There is a very small difference between 50 Mbps and uncompressed. The 50 Mbps also clearly outperforms DVCProHD in our limited tests.

I'll try to get some 100 Mbps footage in the next few days. Our engineers are bringing up the final production board now and we hope to be writing MXF files to FAT32 partitions lalter this week.

I do think the 100 Mbps 422 Long-GOP will be the "sweet spot" for Flash XDR. I suspect that this rate will outperform even the 160 Mbps I-Frame only in most applications. Long-GOP is fundamentally a much more sophisticated compression algorithm compared to I-Frame only CODECs such as DVCProHD. By using both spatial (I-Frame) and temporal (P,B Frames) compression, Long-GOP clearly offers potentially higher overall quality. In my experience you have to increase the I-Frame bit-rate by 3 to 4X to match Long-GOP quality.

Long-GOP MPEG2 is more difficult to edit than I-Frame only, but this shortcoming is rapidly diminishing with faster multi-core processors.

It does look very likely that the low-cost 32GB Transcend CF card will support the 100 Mbps rate. I'll have more info in the coming weeks.

Well, the long awaited images comparisons are finally starting to appear. Check out the latest downloads on the Convergent Design website home page. You will find comparisons of HDV, DVCProHD and 50, 100 Mbps as well as uncompressed images. In our view the 50 Mbps MPEG2 clearly outperforms DCVProHD, while the 100 Mbps is very close to uncompressed. (If you zoom in on the text, the differences become quite apparent).

In the coming weeks we will be working on green-screen comparisons as well as video with lots of motion.

You will also see some photos from NAB and our two awards.

In our view the 50 Mbps MPEG2 clearly outperforms DCVProHD, while the 100 Mbps is very close to uncompressed.
On the file I downloaded, the comparisons appeared to be uncompressed, 25Mbs (HDV), 50Mbs long GOP, and 100Mbs I-frame only. (And no DVCProHD or 100Mbs long GOP.)

And on these images, the 50Mbs long GOP appeared superior to the 100Mbs I-frame only, though it would be interesting to see how motion would affect the comparison.

It raises an interesting thought in my mind. I've heard you say that all MPEG2 coders are not equal - an early coder and/or cheaper one would not do as good a job as a later, more sophisticated one, bitrate and other parameters being constant.

Is there an equivalent circumstance for DVCProHD (and DV for that matter)? Or does the codec itself uniquely define the compression quality?

On the file I downloaded, the comparisons appeared to be uncompressed, 25Mbs (HDV), 50Mbs long GOP, and 100Mbs I-frame only. (And no DVCProHD or 100Mbs long GOP.)

And on these images, the 50Mbs long GOP appeared superior to the 100Mbs I-frame only, though it would be interesting to see how motion would affect the comparison.

It raises an interesting thought in my mind. I've heard you say that all MPEG2 coders are not equal - an early coder and/or cheaper one would not do as good a job as a later, more sophisticated one, bitrate and other parameters being constant.

Is there an equivalent circumstance for DVCProHD (and DV for that matter)? Or does the codec itself uniquely define the compression quality?

Hi David-
There are two comparison files: CODEC comparsion and BitRate comparison. The CODEC comparison includes HDV, DVCProHD, MPEG2 50 Mbps and uncompressed images. The bit-rate comparison includes HDV, MPEG2 50 Mbps & 100 Mbps and uncompressed.

Yes, there can be considerable differences in the quality of any video encoder be it DV, DVCProHD or MPEG2. All video CODEC specifications outline the requirements for the decoder (decompression), the encoder implementation (in either hardware or software) is left up to the manufacturer.

Over time, almost all CODEC encoders have improved with advances in silicon technology and better understanding of the algorithms. We consider the Final Cut Pro implementations to some of the very best software CODECs, hence they are used to compare aganist the Sony MPEG2 hardware CODEC used in Flash XDR.

Dear David,

There are multiple image download files on the www.convergent-design.com website.

Each of these has a "Read Me" file which explains the exact process that was used to create the various images.

So, it depends on which file you downloaded.

The "Fruit Image Comparison" file contains the following examples. This is included in the "Codec Comparison Images Close-Up" download.

1. A DVCPro HD example, which is 100 Mb intraframe encoding, using a Final Cut Pro encoder,

2. An HDV example, 25 Mb 4:2:0 Long GOP,

3. A 50 MB 4:2:2 Long Gop,

4. And an uncompressed 4:2:2 example.

It is important to download and view the full fruit image to realize that the "Cropped Fruit" file is only a very small portion of the full image, zoomed in to 300%. The full image, without any zoom in, is included in the "Codec Comparison Images" download.

A close examination of the zoomed in label on the Kiwi fruit shows the differences in the codecs.

This "Cropped Fruit" set does not include a 100 Mb 4:2:2 Long GOP example at this time.


Another set of examples shows the Convergent-Design brochure. I recommend that you zoom into the logo at the bottom of the page to compare each image. These are included in the "Bit Rate Comparison Images" download.

In this set of examples, the 100 Mb 4:2:2 Long GOP image is included so that you can compare it to uncompressed.

The Read Me files are very important as these attempt to explain the exact process that was used by Mike to create these files.

We are open to suggestions, comments and opinions.

Chris,

With all due respect for Convergent Designs Flash XDR, shouldn't this thread be moved out of the news section?

Every day I click on the News Forum to see the latest news, but it's usually just another XDR post.

Hmm -- is it time to move this thread (and the other XDR FAQ thread) out of news and into Tapeless (http://www.dvinfo.net/conf/forumdisplay.php?f=60)?

Hmm -- is it time to move this thread (and the other XDR FAQ thread) out of news and into Tapeless (http://www.dvinfo.net/conf/forumdisplay.php?f=60)?

Hi Chris-
This is the right general category, but Flash XDR is not direct to disk, per se. Maybe you could re-title this section as "Direct to Disk/Flash (Tapeless) Recording Solutions".

Just my 2 cents.

Best-
Mike Schell

Mike can we get a MXF sample from the device to check if it works in certain NLE's?

Also it might be a good idea to post a sample of something in motion or highly detailed. After all this is usually where 25mbits falls apart and this will be the area where people will notice the biggest advantage to the XDR. A still life shot will usually always look pretty good at 25mbits although clearly we can see that even for still shots higher bitrates do help.

Mike can we get a MXF sample from the device to check if it works in certain NLE's?

Also it might be a good idea to post a sample of something in motion or highly detailed. After all this is usually where 25mbits falls apart and this will be the area where people will notice the biggest advantage to the XDR. A still life shot will usually always look pretty good at 25mbits although clearly we can see that even for still shots higher bitrates do help.

Hi Thomas-
Good suggestions. As soon as we have done some basic verifications of our MXF file format, we will post example files for download and test. We have the MXF code finished, but we need to complete the FAT32 code first, which is very close.

I have some blue screen images to post next week and then we will test some full-motion video (Dan Keaton suggested panning around a vase of colorful flowers).

A couple of our users have done some very interesting tests with histograms and layer overlays in Photoshop. I will ask their permission to post some of these results on our website.

Histograms that Mike noted.

Interesting in that the 50Mbps Sony/XDR 4:2:2 compares most closely to "Uncompressed" both visually when zoomed in for edges and detail and with their 2 respective histograms.

Histograms that Mike noted.

Interesting in that the 50Mbps Sony/XDR 4:2:2 compares most closely to "Uncompressed" both visually when zoomed in for edges and detail and with their 2 respective histograms.
John,

Can you explain these histograms. I can see the differences but what are they really telling us? A "HISTOGRAMS FOR DUMMIES" ...

Thanks

Stefan

Without meaning to sound like I fully understand this myself ....

In our area of interest in these single frame grabs from the 4 different formats shot:

A summary of a histogram in Photoshop is that it basically shows the distribution of all the pixels captured by the camera.

The horizontal scale goes from 0 on the left where total black is, to 255 on the right where total white is. The middle section is where the midtones of the image are displayed in the graph.

The vertical part of the graph displays how much of the image pixels are distributed in the blacks(shadow), midtones(grayscale), and highlight(whites).

So for example, if you had a shot that was totally underexposed, the histogram would graphicaly show most of the pixels distributed toward the right 0 end of the graph and very little in the middle and left 255 end of the graph.

If you had an overexposed or washed-out shot you would see most of the pixels distributed in the right end (255) of the graph.

But what is of most importance for what we are looking for in the study of the quality differences of the single frame grabs of these 4 different formats is how each format handled smoothly distributing the limited 8 bits of data in their respective historgram.

The scene shot is the same locked off shot and lighting. So what I was looking for was a comparison of the "smoothness" of the histogram - how much jagged combing or gaps there were - missing data due to the limits of 8 bit. These jagged gaps are where you get banding and aliasing - "jaggies" in edge detail that we all hate in digital video - it screams digital video. These gaps are what causes banding when we start applying effects or do some heavy compostiing. And it's why the capability to capture 10 bit formats instead of 8 bit is desireable.

In the 4 histograms provided for each of the respective formats, they all have gaps due to their 8 bit structure. But what I found interesting was how the 50Mbps Sony codec used in the XDR came closest to matching or emulating the 8 bit "Uncompressed" smoothness of pixel distribution. I think the historgrams are a statistical or numerical graphic display of what we are perceiving with review with our eyes and what we may expect when we get to review actual difficult footage with lots of movement in highly detailed subjects. I suspect that the smoother histogram of the 50mbps Sony codec recorded by the XDR is going to hold up better in these high motion/fine detail shots of flowing water or leafy trees in wind than that of the DVCProHD. I suspect that the 50mbps Sony/XDR will come closest to "Uncompressed" (hate that widely used misnomer).

I hope I made some sense and that the historgram comparisons are indeed valid.

For a much better and more in depth explanation of histograms, here is a link:

http://www.sphoto.com/techinfo/histograms/histograms.htm

The other thing to keep in mind is the wonderful trickery of motion pictures vs. still photography - quickly flashing a succession of stills in front of our peepers hides a world of ills that may exist in the individual stills.

Hi John-
Thanks for the explanation! It makes good sense to me. I think the histogram offers a more qualitative view of how compression affects the quality of the images. It certainly collaborates our earlier findings, that 50Mbps MPEG2 outperforms DVCProHD, at least on a still image.

A local EX1 user, Jim Arthurs, sent me a Photoshop file of the compressed images, as individual layers. By turning on one layer in normal mode and a second layer in difference mode, you can easily see the effects of compression. Again the results show the superior results of the 50 Mbps rate and near ideal results with 100 Mbps (you see almost no differences to the uncompressed).

A summary of a histogram in Photoshop is that it basically shows the distribution of all the pixels captured by the camera.

The horizontal scale goes from 0 on the left where total black is, to 255 on the right where total white is. ...........

In the 4 histograms provided for each of the respective formats, they all have gaps due to their 8 bit structure.
Yes, to the first bit of that, but an 8 bit structure inherently gives 2 to the power 8 levels - 256 - hence the 8 bit aspect doesn't explain the gaps.

If I import 8 bit DSLR images into Photoshop, the originals show a smooth histogram structure. Manipulating those images by such as gamma, black level or colour correction then produces histogram "gaps", as the process favours some levels over others. (Start with a 10 bit original, and this will obviously be much diminished.)
.......a Photoshop file of the compressed images, as individual layers. By turning on one layer in normal mode and a second layer in difference mode, you can easily see the effects of compression......
I'd recommend this as an excellent way of quantifying the differences, and treating Y,U,V separately can help to show what's going on. Normally the compressed signals are subtracted from the corresponding uncompressed ones, and mid grey added. Perfect compression will show up as a plain grey, the more detail that can be seen, the more errors the compression is introducing.

It can also show up compression effects due to motion, if the filmstrip feature within Photoshop is used.

David:

Please excuse my math ignorance. I surely would appreciate a little more help understanding your explanation:

"Yes, to the first bit of that, but an 8 bit structure inherently gives 2 to the power 8 levels - 256 - hence the 8 bit aspect doesn't explain the gaps."

My thoughts on thinking the gaps were due to an 8 bit photo were due to their inclusion in the standard Photoshop 24 bit histogram.

Maybe I should do some of my own screen grabs of HDV material from our Canon H1. Could it be that the gaps are created by the fact that even though the H1 is putting out a 10 bit signal from the HD-SDI, 2 of those 10 bits actually have no data reportedly?

My thoughts on thinking the gaps were due to an 8 bit photo were due to their inclusion in the standard Photoshop 24 bit histogram.
When you talk of Photoshop being 24 bit, that refers to 8 bits each for red, green and blue channels, hence each channel is 8 bits, or 256 levels. For video, it's different in so far as it is normally recorded as 3 component signals: luminance (Y), and difference signals (U and V), which show the difference between luminance and blue and red. From the three, red, green and blue can be reconstructed.

But each of Y,U,and V is recorded as an 8 bit signal, so video could also be described as 24 bit if you looked at the total.

It's conceivable that the gaps are due to a Y,U,V=>R,G,B conversion within Photoshop. It may be more valid to look directly within Photoshop at the Y,U,V histograms.

Mike,

Am I right assuming that with Flash XDR, having the 2 audio tracks embedded in the HD-SDI output from the EX1, by also using the Flash XDR's XLR audio inputs one can achieve 4 channels of audio at the ouput?

This is quite important when considering between the XDR and the nano versions, while only having a camera with 2 audio channels.

Dear Piotr,

Your question is very interesting.

Mike will be able to give you the proper answer.

But, in the meantime, I want to post the following observations for discussion purposes.

We believe that most camera audio circuits will not be as high in quality as the audio circuits in the Flash XDR.

So for the highest quality audio, one should choose the Flash XDR external audio inputs as opposed to routing the audio to the camera first.

(The audio outputs from the Flash XDR can then be routed to your cameras inputs, if you so desire.)

Few cameras support 24 bit audio, but the HD-SDI specification does include both 16 bit and 24 bit audio.

So, in use with most cameras, the embedded audio in the HD-SDI signal will normally be 16 bit.

Whenever possible, I highly recommend using 24 bit audio. 16 bit audio can give great sound, but 24 bit audio gives you the luxury of recording great audio, even if the levels are not optimum.

A 16 bit audio recording, with the audio levels set low, leaves something to be desired. But, a 24 bit audio recording, with low levels, can be optimized in post while maintaining very high quality. Recording in 16 bit audio, with the audio levels set for the expected audio level, will not be able to handle unexpectedly loud sounds.

It is possible to record in the Flash XDR at 16 bits. This would match the audio format from the camera. It would be nice if the Flash XDR combined both sources to give you four channels of embedded audio, as you suggested.

At this time, I do not know if the HD-SDI specifications allows for two channels at 16 bit and two channels at 24 bit. We will need to determine if this is the case.

Please note that if

1. You send an HD-SDI signal, without embedded audio, to the Flash XDR, and
2. You send two channels of audio to the Flash XDR via the external audio inputs, the Flash XDR HD-SDI outputs will have the audio embedded in the signal.

In other words, the Flash XDR acts as an audio embedder. I feel that this is an important feature. The same applies to the external timecode input.

I am certain that Mike will answer your original question as soon as possible.

Mike,

Am I right assuming that with Flash XDR, having the 2 audio tracks embedded in the HD-SDI output from the EX1, by also using the Flash XDR's XLR audio inputs one can achieve 4 channels of audio at the ouput?

This is quite important when considering between the XDR and the nano versions, while only having a camera with 2 audio channels.

Hi Piotr-
I just spoke to the hardware designer, who wondered when this question would arise. Yes, you can take 2 channels of embedded audio and mix with 2 channels of analog audio on the XDR. Of course this is not possible on the nanoFlash.

Dan & Mike,

Thanks for this answer, as well as the interesting considerations re 24 vs 16 bit audio.

Any news on proposed XDR mounting options with the EX1?

Hi Thomas-
Good suggestions. As soon as we have done some basic verifications of our MXF file format, we will post example files for download and test. We have the MXF code finished, but we need to complete the FAT32 code first, which is very close.

Just curious if there were any updates on the FAT32 code? The still images are fun but I am a video guy and I need to see these .mxf files work in FCP. This may be the greatest recorder in the world but it is a paper weight unless NLE's can read the video files.

David Schmerin

one thing i think that might be important to keep in mind when comparing codecs especially through histograms is that the XDR is probably the only codec that isnt scaling the input*. seems pretty likely that the differences in the histogram might be related to the fact that different pixel values are being created through the combining/filtering/averaging of surrounding pixel values. that might be all you are seeing in the histograms. of course that is a wonderful thing, since scaling introduces various kinds of artifacts and of course softening itself, but im not sure those histograms tell us much about the compression codecs and how they compare. perhaps you could throw in another codec for comparison that supports 1080p without scaling, such as 50 or 35mbps xdcam or even something more competative like hdcamsr or cineform (especially relevant if cineform ever comes out with their similar solid state recording device)?

*for reference, dvcprohd scales the image to 1280x1080 and hdv scales it to 1440x1080, whereas xdr maintains the full 1920x1080 frame