Slow!

Splitting is very slow for me as well (> 1 hour, removing 10 mins at the beginning and 5 mins at the end of a 50 min recording, on a i7 920, 6GB RAM, RAID1, Windows 7 64bit).

My recordings are .ts, MPEG-2 straight from DVBViewer.

Have you tried recent Video Splitter 2.3 beta. This should solve the problem.

Yes, I agree.   

The new versions are very fast.  I'm editing large-ish (1+ GB) videos using a laptop (Dell Inspiron 1525, 3 GB, Vista) and this machine is nowhere near as powerful as your machine, and SolveigMM Video Splitter 2.2 and 2.3 is really fast.

Moose

Splitting is very slow for me as well (> 1 hour, removing 10 mins at the beginning and 5 mins at the end of a 50 min recording, on a i7 920, 6GB RAM, RAID1, Windows 7 64bit).

My recordings are .ts, MPEG-2 straight from DVBViewer.

Have you tried recent Video Splitter 2.3 beta. This should solve the problem.

Splitting is very slow for me as well (> 1 hour, removing 10 mins at the beginning and 5 mins at the end of a 50 min recording, on a i7 920, 6GB RAM, RAID1, Windows 7 64bit).

My recordings are .ts, MPEG-2 straight from DVBViewer.

Hello Odyssey,

The only way to fix the problem is to replicate it with "problem" file. If you upload us such a file it would be very helpfull. PLease let me know if you can do that and I'mm send you to PM ftp details.

Any update on this?  I'm currently splitting a 500Mb chunk out of a 1.5Gb MPG2 file (using 2.2.905.18), and although it seems to be working, it is very slow, and has taken over an hour so far to get to ~75%.

Following on from the guess about it being an issue with large indexes, I can upload the generated index somewhere if that would help?

As I said above, I think the slowness bug is related to use of the index file. When I decline to use an index, the "Save Media File" command works quite fast.

BUT there is a different bug when the index file is not used. Last night I started with a 30-minute MPG video. I marked about 4 sections of commercials (maybe 10 minutes) to be removed. I saved the Media file. It grew from 30 to 36 minutes. None of the commercials was removed. One six-minute section (with both keep and throw away parts) was repeated.

Hi freshbits,
Thank you for info. Unfurtunately we have not managed to replicate the bug so far, but will try to.
Thanks for the help!

And one more test:

I cancelled so that there would be NO index. I CUT three sections. I saved the media file. Again, it only took 3 minutes.

One more interesting thing: The resulting file is LARGER (2,755,253 KB) than the original (2,343,336 KB). My video player says it is 1:14 long (instead of 1:00).

I made different tests, based on my own guess.

First, I made a 1-hour clip (2.4 GB). (This time I made it CBR, not VBR, but I don't think that is the problem.)

I cut three commercials out, and saved the media file. It was taking "forever," so I cancelled.

I reopened the file, using the same index file. I made NO cuts, just saved the media file. It took "forever."

I reopened the file, but forced Splitter to re-index. I made NO cuts and saved the media file. Again, "forever."

I then deleted the index file and reopened the MPEG. As it started to re-index, I cancelled. The index file disappeared. THEN I saved the media file (NO cuts).

This time it only took only 3 minutes to save all 2.4 GB!

I think, therefore, that the slowness is related to the index.

Another thing: Scanning through the file (right-arrow key) takes longer and longer - slows down - as you go further along in the video. Perhaps there's a memory leak -- or possibly the algorithm for scanning starts at the beginning every time.

I think there's a problem with the index.

that is quier as the file length should no influence to the trimming process speed.
Anyway we we walked half of a way

Can you make some more tests?
Please prepare 100 mb 300 mb 900 mb, 2GB files and try to trim them.
let us know which of them will be edited slow.
Thnk you for your help, we appretiate that!

It did not take long for me either.

I think the problem is when editing large files - one or two hours - with large indexes.

My editing folder is c:\MyVideos

The computer is an AMD Athlon 64 X2 Dual Core Processor 6000+ 3.01 GHz, 3.0 GB RAM

OS Name   Microsoft Windows XP Professional
Version   5.1.2600 Service Pack 3 Build 2600
OS Manufacturer   Microsoft Corporation
System Name   BLACKBEAR
System Manufacturer   HP-Pavilion
System Model   GN551AA-ABA m8200n
System Type   X86-based PC
Processor   x86 Family 15 Model 67 Stepping 3 AuthenticAMD ~3013 Mhz
BIOS Version/Date   Phoenix Technologies, LTD 5.16, 8/14/2007
SMBIOS Version   2.4
Windows Directory   C:\WINDOWS
System Directory   C:\WINDOWS\system32
Boot Device   \Device\HarddiskVolume1
Locale   United States
Hardware Abstraction Layer   Version = "5.1.2600.5512 (xpsp.080413-2111)"
User Name   BLACKBEAR\Michael
Time Zone   Central Standard Time
Total Physical Memory   3,072.00 MB
Available Physical Memory   2.21 GB
Total Virtual Memory   2.00 GB
Available Virtual Memory   1.96 GB
Page File Space   4.84 GB
Page File   C:\pagefile.sys

well the problem is not replicated as well so far.

e.g I just try to save a fragment  from 00:00:25:93 to   00:01:38:35 keep.
It is trimmed fairy fast. Could you try to trim same fragment from file freshbits-sample-2-min.mpg and let me know if it will process slow.

Also please enumerate your CP configuration. Where your files are located, may me it is a removable HDD or something like that?

ok, thanks a lot.
We will let you know the results as soon as they arise.

I am now uploading a 2-minute clip (80,412,672 bytes). I made the file tonight. It is typical output from the Hauppage and has not been modified in any way. It will take at least another 2 hours for the upload to complete.

Hi Freshbits ,
I suppose 100MB would be quite enought.