nanoFlash Known Issues
 

Here's our latest list of known nanoFlash issues we are trying to resolve:

1) A/V Sync issues with some Tape-Based Cameras, especially with Panansonic VariCam. The sync seems to get off during tape shuttle operations. We are testing a potential fix today.

2) SanDisk Extreme III cards limited to 140 Mbps. We had orginally speced this card for 160 Mbps, but found some performance issues. The next firmware release will improve the Compact Flash card write performance by 15 to 40% depending on the card. So, the Extreme III will then be approved for 160 Mbps.

3) SDI output does not power-up when coming out of power-save mode. The only remedy is to power-cycle the nanoFlash. The short-term solution is to disable power-save if you need to monitor the SDI-Out. This will be fixed on the next release.

4) Problem locking to some SD-SDI sources, such as the IOHD. We are investigating this issue today and expect a fix shortly.

5) I-Frame only does not work in Vegas. We have files into Vegas engineers for testing.

6) Long-GOP above 50 Mbps is not recommended for Avid. However, all I-Frame-only files (up to 220 Mbps) work great in Avid. We have files into Avid engineers for testing.

7) Time-Lapse mode can produce very short files, espcecially for time intervals > 1 frame every 5 seconds. This will be improved on the next release.

We welcome any additonal comments or bugs we may have missed. Note that most of these issues also apply to the Flash XDR, which will also be corrected.

Best-

Hi Michael,
I see that you are checking the ioHD issue.
I think there is a Gamma discrepancy between the MPGs and the MOV files.
Captured the same stuff (Prores p720 from the ioHD) the MPG file looks much darker than the MOV.
IMO the MOV is correct.
I haven't made further tests.
Thanks for taking care of so many things.
Best,
rafael

Hi Rafael-
On the Gamma discrepancy issue, was the video captured via HD-SDI out of the nanoFlash into an IOHD? Is the bit-rate the same for the MOV and MPG file formats?

I though the essence (MPEG2 data) was the same for MPG, MOV and MXF. But we could have made a mistake in programming the Sony MPEG2 encoder in MPG format.

Thanks-

Sounds like the usual QT nonsense between Apple/PC.

MOV files have a flag that works with the PC platform (gamma 2.2), but not going to MAC (1.8).

Odd Apple makes this work OK on the PC.

There are two grades of Extreme III cards. Which are you referring to? I have the two of the initial run, before the "30 MB" series was produced. The early versions seem to top out at write speeds of about 12 MB/sec, although I can make an exact measurement if you need it. If you are optimizing write block size for particular cards, I would not be opposed to manually specifying the card model. You could also include a speedtest that is run when the card is inserted.

Dear Gints,

We are referring to the current SanDisk Extreme III cards.

These have 30 MB/s on the front of the card.

I was not aware that SanDisk originaly made a lower performace card with the same name.

Hi Glints-
Good question. I was referring to the newer "30 MB" model. The older Extreme III cards were much slower.

There is a basic speed test in the latest version of the nano/XDR firmware. Basically, you can test any card by setting the bitrate to the highest level (220 Mbps I-Frame). Then insert the card and hit record. If the card is not fast enough to keep up, the firmware will automatically drop back to the next slower rate. Note that this may take a few interations, as the bit-rate will drop from 220 -> 160 -> 140 -> 100 -> 50 as necessary. Also note that video recorded at too high a bit-rate will not be usable.

Higher write performance will be included in the next firmware release (scheduled for the end of this month).

Best-

I have 4 of these and used each of them many times, 99% of the time at 100Mbps without any issue. Have not needed to go higher as yet.

Hi Rafael-
We found the problem in standard def with the IOHD. It was a mistake in our code and will be fixed in the next firmware release (due in about 2 weeks).

Best-

Mike, I think it's pretty timely that you're posting this. I need to record some SD material from a component video source today. I was planning on using my AJA IO (Not the IO HD) to connect to my component video source, and then use my XDR to record the SD-SDI output signal of the AJA IO.

Do you know if the problem you are referring to above affects the AJA IO, or only the IOhd. Also, I'm working with an XDR, not a Nano if that makes any difference.

Hi Aaron-
If you are not using embedded audio, then you should be OK. But we have not tested with the IOHD, so cannot confirm with 100% confidence. I would highly recommend that you test as early as possible (so you have time for plan "B", if necessary).

This should be fixed for almost all SD sources in the next update.

Sorry for any problems this may cause.

Best-

Dear Mike,

Just to be clear, Aaron is using an AJA IO, not an IO HD.

In either case, Aaron is testing his setup tonight.

David, it's not clear if you are reporting success with the older Extreme III's (late 2007, early 2008) or the newer 30 MB Extreme IIIs.

Here is a speed comparison table for the Nikon D3. The write block size may have something to do with higher RAW performance, but we can't tell. I'm not sure how well this table applies to the Nanoflash, so it would be could if CD would create a similar table.

Rob Galbraith DPI: Nikon D3

I did test it right this moment. My analog SD source connected to the AJA IO does work as expected, the AJA IO recognizes the signal it seems. However, the XDR is not able to see the SDI signal.

When connecting the SDI to the XDR, the XDR shows NO SRC. The XDR also is very sluggish to respond to any button pressing while the AJA IO is connected via SDI.

Hopefully, your fix for the IOHD also fixes my problem I see here. Every once in a while, I need to record an analog component SD source. I'll continue to use the AJA IO with a MacBook Pro and FCP. It's a workable solution, if not a finicky one. I was hoping the XDR could do this and save me the headache of dealing with a laptop to capture with.

Hi Glints-
Great suggestion! I'll speak to our engineers next week about developing a simple program to check the write/read performance of a CF card. I can envision a couple of different techniques.

We'll need to requalify almost all CF cards after we release our new write algorithm later this month. All the cards we have tested have shown some improvement ranging from 10 to 40%.

Best-