Is all DV "capture" the same quality?

[Razz]

Assuming that I don't drop frames, are there any differences in the video quality of the resulting AVI files created by the various DV "capture" software applications? That is, if I dump video from my DV camcorder to my PC via FireWire, does it matter which software I use or is it just a direct data dump?

I started archiving all of my old miniDV tapes by dumping them to my PC. I have the Nero6 Ultra Edition so I was using that for DV capture. But NeroVision Express 3 (NVE3) had trouble capturing some of my tapes that had garbled sections, or that had small sections of blue screen between clips. NVE3 would lose sync between audio and video, and/or fail to capture the entire tape. So I tried Windows Movie Maker 2 for capture. WMM2 had no problem capturing the same problematic tapes. I just wonder if WMM2 is capable of delivering the same quality AVI file.

Any reason why I shouldn't use WMM2 to "capture" my DV tapes?

Oddly, NVE3 doesn't have any trouble dealing with WMM2-generated AVI files, but WMM2 has trouble dealing with NVE3-generated AVI files. When I tried to auto-detect scenes in an NVE3-generated AVI file, WMM2 complained that it didn't have access to the codec used to make the AVI file. I didn't think that a codec was involved in making the AVI file (other than the one inside the camcorder).

I thought that DV "capture" (if you will) was just a straight data transfer from tape to HDD with no real conversion involved. Yet the aforementioned experiences indicate otherwise. Can anybody explain why? I'm a EE geek so you can feel to get technical on me if you want.

[adam]

It is just a straight data transfer, so no quality will not differ. But depending on what you are using to access the footage later, you may need a separate DV codec installed to decode it. There are various DV codecs on the market, each with their benefits and drawbacks.

[gadgetguy]

The quality would not be different for your "captures" but there is usually an option to capture to Type1 or Type2. People often complain of a/v synch issues when using Type2. Some software can't use Type1 and others can't use Type2 which may account for your different software packages not being able to exchange captures.

I recommend using WinDV to import your DV. It is a small application that takes very little resources and employs a buffer to guard against lost frames. Also you can choose between Type1 and Type2 for maximum compatibility.

[guns1inger]

There are two types of DV format. Type I and Type II. One has audio as a seperate track, the other has the audio interleaved throughout. It is set by the program that transfer the video to the PC. Not all software will open both types. Canopus have a free converter.

[edDV]

Assuming that I don't drop frames, are there any differences in the video quality of the resulting AVI files created by the various DV "capture" software applications? That is, if I dump video from my DV camcorder to my PC via FireWire, does it matter which software I use or is it just a direct data dump?

Its a data stream. Error checking is minimal. Single disk systems can sometimes have trouble but overall DV transfer should work on a modern desktop.

I started archiving all of my old miniDV tapes by dumping them to my PC. I have the Nero6 Ultra Edition so I was using that for DV capture. But NeroVision Express 3 (NVE3) had trouble capturing some of my tapes that had garbled sections, or that had small sections of blue screen between clips.

Garbled sections were on tape? Describe this more fully.

Best to stop capture at timecode gaps and restart for next section. Software wants only one timecode address per tape so you may need to call your second 0:00:00:01 a new tape name.

NVE3 would lose sync between audio and video, and/or fail to capture the entire tape. So I tried Windows Movie Maker 2 for capture. WMM2 had no problem capturing the same problematic tapes. I just wonder if WMM2 is capable of delivering the same quality AVI file.

hmm I haven't used Nero Video Express 3 for DV files much yet.
maybe this is related to confusion over timecode address and tape name.

WMM2 should work. Keep everything DV-AVI format. It will try to drag you into WMV. Carry a whip. Be assertive.

If it were me, I'd use WinDV for transfer before WMM2. Simple and a low resource user.

Oddly, NVE3 doesn't have any trouble dealing with WMM2-generated AVI files, but WMM2 has trouble dealing with NVE3-generated AVI files. When I tried to auto-detect scenes in an NVE3-generated AVI file, WMM2 complained that it didn't have access to the codec used to make the AVI file. I didn't think that a codec was involved in making the AVI file (other than the one inside the camcorder).

I thought that DV "capture" (if you will) was just a straight data transfer from tape to HDD with no real conversion involved. Yet the aforementioned experiences indicate otherwise. Can anybody explain why? I'm a EE geek so you can feel to get technical on me if you want.

Video is encoded to DV format in the cam. The data is streamed to a file during transfer with no conversion. Errors can occur since this isn't a file system transfer. It is a stream.

The file can be accessed by varoius programs. If you process the file in an application, it needs to be reprocessed under the active DV codec for that program. Windows has a default DV codec. Maybe Nero has a different one that it uses.

[guns1inger]

To prevent timecode gaps, lay down a continuous timecode on your tapes before recording footage on them. You can do this by simply recording with the lens cap on, or by sending a black screen up the firewire to it.

[Razz]

A belated thanks to everyone for the great advice!!!!

I think the scene-detection incompatibility that I experienced among the various AVI editors was a Type-1 vs. Type-2 thing.

In a belated answer to EdDV, one of my MiniDV tapes had a garbled section because my camcorder's head went bad in the middle of a tape, and the head had to be replaced. Unfortunately, I didn't know that it went bad until after I shot about 30 minutes of video.

[vhelp]

As much as DV is a transfer stream, it is up the the retreaving
application (app) that translates it into an AVI RIFF container
for video apps (such as vdub) to open and read as video.
.
Say you used DVIO as your dv transfer (retreaver) it
has to (on-the-fly) take that stream and put it into a container
that is readable as an AVI struture file. The dv stream is most
likly in a format that is easily translateble for AVI struture.
.
If the dv stream was just that.., a stream of data, that would
mean that it is just a bumch of numbers going somewheres. But
what would those numbers mean to a video app, if the final file
(say, AVI) is not in a struture to be read and displayed.
.
There are other forms of DV for a given task. In addition to
video DV, you have DV enclosures for disk activities (storing
and rereaving data) Somehow, I don't think that the dv stream is
an AVI stream, and has to be translated to disk I/O data struture
that the OS system can understand and work with.
.
I believe it is the retreaving software that "translates" the
stream to a given format. In the case of DV video, it is most
likely a video file translation.
.
With that in mind, then its up to the calling app to utilize
whatever (the developer of that software app) best format to use
during the IMPORTing (or, D/L) of dv stream. I think the latest
format of AVI is the OpenDML vs. the old AVI 1.0 format. Both are
good, to be quite honest with you, but I think that the current
format used during the dv IMPORT is the OpenDML one. But, I've
noticed that with this format, there are slightly different
methods used, though the final outcome is usually the same, DV
avi format.

The next link in the chain (once the dv AVI file is on your system)
is the editor software being used to read that AVI file.
.
Next, comes the Codec used during the conversion (decompression)
of the DV format AVI, which takes that AVI (YUV) and convert it
to RGB.
.
Each brand of dv codec has slight variations in the methods used
to translate/convert YUV to RGB, to be read inside your editor
app. Now, I'm not totally sure of this, but I'll comment anyways..
that there might be some software that will keep the avi's YUV
color space in YUV, and use overlay to display it. I believe that
RsDvCap does just this. If you drag in an DV avi file
that it just captured, to its window, it will display the avi file
just as you captured it, in the same YUV color space.. a perfect
match, IMO. But, if the avi looks darker, then its likely so, that
the editor (or player) converted the dv avi 's YUV to RGB.
.
Part of the reason why dv make not look so well as other dv codec
versions (there are many) is on account of the dv codec's method
used internally to decompress. Some dv codecs have better algo's
than others. But, beauty is in the eye of the beholder
.
The twist to this dv codec and best quality reproduce from it is
probably partly accounted for, during the retreaval of the dv stream
and translated into an AVI RIFF format.., then the editor used to
read this AVI RIFF format, and then the dv codec to decompress (if
the editor software app features YUV to RGB (mostly the case) or
YUV to YUV (no conversion)) during the editor viewing capability.
That is up the editor app you are using - there are many. But, the
majority are all RGB in the end, so color space conversion is
more than likely the final outcome in one's conclusion of quality.

As far as the actual dv data stream from the cam or dv device, it
is all the same, ..until your retreaving sofware app touches it.

-vhelp 3404

[edDV]

In a belated answer to EdDV, one of my MiniDV tapes had a garbled section because my camcorder's head went bad in the middle of a tape, and the head had to be replaced. Unfortunately, I didn't know that it went bad until after I shot about 30 minutes of video.

Well I can see why trasnsfer went badly.

Usually if the tape will play on the camcorder, it will make it through IEEE-1394 but there are limits to the abuse.