Simple cutting of lagarith/huffyuv, pcm audio files

[swiego]

I've a very simple request, hopefully someone can help!

I have about 2 TB worth of captured video that I want to prune "white space" out of... leaders, trailers, footage I won't need, etc. It's all 720x480 interlaced encoded in either lagarath or huffyuv (mostly lagarith) with included stereo (2Ch) audio at (I believe) 16/48. Most of the files are in the 50GB range--kind of big. I don't need postprocessing, anything fancy, etc. No re-encoding, no colorspace complexities, AV resyncing, etc. Just want to cut/splice out stretches of blue screen/static in order to start reducing file size a bit.

Example: 50GB file, and I want to cut out a few minutes in the middle of it that leaves me with say a 48GB file.

Can someone recommend a tool that will do this (preferably fast & free) that plays well with lagarith/huffyuv and doesn't muck up the audio or video? I've been having trouble using virtualdub to get output that's identical to the input.

[BJ_M]

VIRTUALDUB is still the best bet really .... it will not touch the quality at all in direct stream copy mode

[swiego]

Here's what makes me nervous - my original AVIs are listed in GSpot as,

OpenDML (AVI v2.0)
File Length Correct

Once I run them through VirtualDUB with Direct Stream Processing (no changes to program defaults save perhaps for adjusting the range) Gspot now reports for the container,

Multipart OpenDML AVI
(8537 frames in first part, 5390 frames follow)

What's more, if I am not changing any frame offsets, then I'm still noticing that my file size is changing - shrinking about 1% or so. This bothers me - direct stream copy of all frames within the file from source to destination should (IMO) generate a file that's almost identical. That's not the case. I've had this behavior using "Save as AVI" and "Save as old format AVI"

I'd like to understand exactly what the difference is here--why is the container changing at all? I've grown to rely on GSpot to highlight potential corruption and other problems with my files during capture, so I've been very nervous about why virtualdub is causing a change here...

[DarrellS]

I assume it is partially because you are working with lossless files. Virtualdub or any other program for that matter will handle lossless compression alot different than say DivX or XviD. It takes me 1:48 seconds to direct stream copy a 3:52 second Huffy file but if the same file were compressed to XviD, it would only take 5 seconds to direct stream copy it. That's why I normally just recode the file anyway if I'm going to be doing any editing to it. It takes almost as long to direct stream copy a huge Huffy file as it does to convert it to XviD.

Another factor. Just the act of putting the file in a different container will slightly reduce the file size and if you did any cutting at all, it will reduce the file size tremendously.

I haven't seen the multipart OpenDML that you have shown but I'm not too accustomed to working with 50GB files (I will as soon as football season gets here but they will be greatly reduced since TV resolution isn't high enough to warrant a 50GB finished file) and I don't regularly check the files that I've made in GSpot unless I'm experimenting with different codecs.

[swiego]

Hmm. This is all archival / reference material so I don't want to recode it to anything but keep it in lagarith/huffyuv. However a lot of these 50GB files have say 20GB of "noise" that I'd like to excise from the original in the interest of space and manageability.

So I guess my question is, container aside, when I use DSC of huffyuv/lagarith YUV, can I assume that the video and audio itself is completely unchanged, except for any cuts? I did some cuts and that seemed to be the case...

[DarrellS]

That's what I would assume since you aren't recoding the file but copying pieces ot it.

You could go directly to the source to get a better answer from the creator of Virtualdub.

http://forums.virtualdub.org/