No 4 gig limit on w2k

[Serengeti]

Well, the 4 gig file limit is due to the filesystem being 32bit, and unless Win2k is using a new file system, the limit should still be 4Gb.

There are other considerations, besides Win98SE and Win2k, however. Both Linux and BeOS are making attempts at becoming usable platforms for editing DV. I don't know much about Linux, but read this topic thread: Free BeOS 5 in 5 Days!

Theres more info about editing on BeOS there. BeOS does support the Pyro, BTW.

[wkulecz]

Supposedly under win2000 and Directshow capture with Media Studio Pro6 the 4GB limint is a thing of the past if you capture to an NTFS formated drive.

I'm about the convert my FastTrack66. I post a definitive answer in a day or two if no one else does.

--wally.

[Walrus]

The rumours are true. Under any capture app that supports OpenDML (like MSPRO 6 or Virtualdub) with a NTFS partition, you can breeze past the 4gb limit. (note this is also true under NT 4 or any version that has NTFS support). Also, you can exceed 4 gb by capturing in sgements with programs like AVI_IO or virtualdub on either NTFS or FAT32 under Win9x or WinNT or Win2K.

[ScottV]

No 4 gig limit on w2k

I read somewhere that there is no 4-gig limit for captured video when using Windows 2000.

Can somebody confirm that this is indeed the case.

Also, some people were having audio sync problems with DV capture (and frame drops !!). Have these problems been resolved yet.

I ask because I plan to go fully digital soon with Pyro DV, PanaDVin and MSP 6.0. I know I have to use either Win98se or Win2K. Are there any other considerations?

Thanks.

[Serengeti]

How does it do this? It would have been my assumption that it would do what AVI_IO does and create a sequential file order, like sequential Targas. How does it allow for this? Would this method affect normal usage of the file, say copying it across a network, or backing it up to a tape drive?

[Walrus]

From what I understand OpenDML is an extension to the existing RIFF format that is the basis for the .wav and .avi formats. What in does is it breaks up the file into regions, each described by it's own unique header, which allows an avi-like format, but with more capacity since you have many regions each capable of holding several hundred megs of data. The down-side is that the files can only be handled with programs that are designed to use OpenDML files. Right now only Virtualdub and MSPro 6 come to mind of the compatible programs.

[ScottV]

Thanks guys. Sounds like it's brand new territory and I should steer clear for a while (let the experts try it first).

I already have a registered version of AVI-IO. Can I use this to capture DV? Does DV capture just use a codec like analog capturing or does it work completely differently?

Sorry but I don't know an awful lot about DV yet, just that I want it

[Serengeti]

Well, Walrus, Im certainly going to read up on OpenDML tonight, but it sounds like it makes multiple files as either sequentials ... or maybe analogous to how RAID hard drives work, distributing the data evenly through multiple files.

None the less, one way to circumvent the entire issue is to use an operating system that has a filesystem larger than 32bit, like BeOS, which is free as of later today

[Serengeti]

Well, this document regarding OpenDML http://www.matrox.com/videoweb/press/papers/odmlff2.pdf only talks about overcoming the RIFF AVI chunk limitation of 1Gb, not the 4Gb limitation of the filesystem. It MENTIONS the FS limitation, but suggests no solution. It's possible that this doc is out of date (1997).

I also searched Microsoft - No help there (they must be too busy licking Jacksons' boots!).

And any other searches I made came up with crazy Russian websites (Look at my CRRRAAZZZY passport!! - Futurama)

No doubt is the solution to the 4Gb limitation available through OpenDML, I just wish it was easier to find references to it. Anyone know sites that I can read up on it?

[Walrus]

ScottV:
I think AVI_IO in theory can capture DV video... if there is a VFW capture driver for it. From what I understand, very few if any have VFW drivers.
Serengeti:
OpenDML captures into a single file, but the file is logically broken up into many pieces. This is somewhat how a hard drive can be split into many logical partitions, but it is still a single hard drive. Fortunatly, Virtualdub treats the file as a single entity, and abstracts away the sub-regions. (I assume MSPro6 does the same). The reason this is done is so that none of the sub-regions exceeds the 32-bit address limitations.
As for the 4gb limit, if you capture to OpenDML .avis, then all you need to do is make sure the FS can handle file sizes > 4 GB. NTFS will do this. (I forget it's max file size, but it's VERY high) NTFS is only available in NT (aka W2K). One other FS that NT can handle that in theory could handle > 4 gb file sizes is HPFS (OS/2's file system), but W2K can only support the partitions read-only, and NT 4 can only support the partitions if you hack in the NT 3.51 driver, and even then the driver will only recognize HPFS partitions up to 4 gb. (note: HPFS can have bigger partition sizes, but the hacked driver would ignore it)

[Serengeti]

Well, as I've eluded to, there is one other Filesystem that allows for files larger than 4Gb.

The BeOS File System is 64bit, allowing for files up to 18 Petabtes in size (18 million Gb).

I don't know how NTFS (a 32bit filesystem) handles files over 4gb. I'd be interested to know, though, so if you have any links for me, I'd love for you to post them

[Walrus]

Serengeti:
Actually, there are tons of other file systems that also work. (most modern Unix or Linux variants support > 4 gb files) NTFS and somewhat HPFS are the only ones in the Windows-OS/2 world I know of (HPFS was developed by Microsoft in the 80s when IBM & Microsoft co-developed OS/2, and Microsoft used the code to form the basis of NTFS. In fact, the two file systems are VERY simular)
As for NTFS, I'm not totally sure how it handles using 32-bit pointers (if it in fact does) to address > 4 gb files, but it definatly can do it. (I've created > 4 gb files before in NT with NTFS) There are really two ways of doing this that I can think of. Either don't use a 32-bit value for the file size, (16-bit DOS used 32 bit pointers here and there) or logically link files together logically in the FS driver, and report the file size as a 64-bit value. I can't tell you wish method was used (though I would guess the former), or if some other method was used. (you could align to clusters like FAT does and thereby make file sizes max out at 4 billion * cluster size.. which would max files out at 2 terabytes in size since I think I remember that HPFS & NTFS have a set cluster size of 512 bytes)

[dgcom]

Hi!

NTFS is based on 64-bit pointers. In fact, NT has functions to work with 64-bit integers for a long time now...

As far as cluster size - you can select 512-4096 clusters when formatting...

DGCom