DVD2AVIdg Version 1.3.0 with transport inside! [final]

[Guest]

Here is DVD2AVIdg/MPEG2DEC3dg Version 1.3.0 final:

http://neuron2.net/fixd2v/decodefix130.zip

Version 1.2.0 will not be formally released.

This version fixes Moitah's seeking bug and Boulder's malformed field picture stream problem, adds *.mpg to the open filter, and provides the latest MPEG2Dec3 help file. It also adds transport stream support for ATSC transport streams. It should have functionality like Nic's version (I borrowed much of his code -- thanks Nic!). There is reliable PID detection and the ability to set the PIDs through the menus, INI file, or CL.

Notes: A file is taken to be a transport stream if its extension is .ts, .tp, or .trp (this may change). PID entry is in hexadecimal.

My intent is to support additional transport formats. But if you want your favorite format supported you have to be willing to help me by pointing me to specs and providing test streams.

Have at it boys and girls!

[Guest]

Whoops. I forgot to write the PIDs into the D2V so MPEG2DEC3dg can get them. Without that only 0x11/0x14 worked. Here is beta 2, which fixes that:

http://neuron2.net/fixd2v/decodefix130beta2.zip

[Moitah]

Working good so far, thanks for the seek fix.

[Guest]

Originally posted by Moitah
Working good so far, thanks for the seek fix. Good to hear it, Moitah. Thank you for all your excellent feedback and suggestions.

[Zep]

Originally posted by neuron2
Whoops. I forgot to write the PIDs into the D2V so MPEG2DEC3dg can get them. Without that only 0x11/0x14 worked. Here is beta 2, which fixes that:

http://neuron2.net/fixd2v/decodefix130beta2.zip


no go here. Crashes or freezes when trying to read a .tp file

no preview or anything. I have to use task manager to shut it down.

PIDS are correct so that is not it.


yes I will try to make a small clip


Do you have a server i can send clips to directly?

[Guest]

Originally posted by Zep
Do you have a server i can send clips to directly? I'll PM you.

[CruNcher]

Ah btw Donald what bugs me since the first dvd2avi could you please change the preview display of Avg.Bitrate to a numerical one i dunno who can interpret this bar ;)

[Guest]

@Zep

The problem is that the stream type is not set when you drag and drop. Open through the menus. I'll fix it in the next beta.

@Cruncher

Sounds good. Put feature requests in the "Development" thread started by Cyberia. These beta threads are for FEEDBACK on the posted binaries.

THANK YOU!!!!!!!!!!!!!!

[Guest]

Beta 3 fixes drag and drop open for transport files:

http://neuron2.net/fixd2v/decodefix130beta3.zip

EDIT: Also note that PID entry is in decimal!

[Zep]

Originally posted by neuron2
Beta 3 fixes drag and drop open for transport files:

http://neuron2.net/fixd2v/decodefix130beta3.zip

EDIT:
Also note that PID entry is in decimal!


It was the PID decimal that bit me in the a$$ :D


I'm not kidding when i say i have done hundreds of .ts .tp
encodes (maybe over a thousand even) and hex PID numbers are 100%
instinct. as an example

FOX 21/24
ABC 11/14
etc...

flies out of my head.



with decimal i have to stop and think about it HAHAHA


of course now i know why 17/20 was in the PID input window
on first launch hehe


Can you make it an option for which way to use?




a huge thanks it is looking real good!

[vispgraedde]

Have a short clip here that I first do preview on. Coded # 50, Playback # 50.

Without doing anything else in between, I save project, and the Information window changes to Coded # 50, Playback # 51.

Minor issue that is just confusing.

Doing Play after this, the Coded changes to 0, and the Playback increase by one for each time I press Play.

[Guest]

@Zep

OK. I will do something about the numbering. I just thought Joe Six-Pack doesn't know what hexadecimal is!

@visp

Thanks. I'll correct that.

@all

Regarding speed:

Preview is much slower because I use Windows call for resizing. Stupid. I'll fix that.

Save Project is faster by about 13/8.

Decode in Mpeg2dec3dg is the same.

[Boulder]

Originally posted by neuron2
Boulder's malformed field picture stream problem

I can confirm this one fixed, thanks!

[Guest]

Here is beta 4 with these fixes:

http://neuron2.net/fixd2v/decodefix130beta4.zip

1. Preview speed is much faster since Windows resizing is avoided.

2. Now uses hex for PIDs.

3. Strange playback number after Play at end of stream repaired. It now replays the last GOP and gets the numbers right.

My priorities now are:

1. Speed -- Zep is complaining.

2. Upsampling issues.

3. PVA support.

[Wilbert]

http://forum.doom9.org/showthread.php?s=&postid=491183#post491183

Sorry for posting in the wrong thread :) perhaps not a bug.

[len0x]

I'm looking at the d2v project (1.3.0) created from CLI and GUI and see that iDCT_Algorithm line differs on my PC. I always get 2 (SSEMMX) from CLI and 5 (SSE2MMX) from GUI. Is CPU detection not the same for both cases?

[Dallemon]

just wanted to say that the change from 100 to 130b4 the speed has increased (approx 10 secs), except for the files have been b0rked ever since i changed from the original 1.77.3 :/ *goes hunting for possible solution*

i just tried the original 1.77.3 and the d2v works fine again :S
with 130b4 mpc would just say "cannot render the file" and if i put the d2v in an avs it just says "unrecognized error" no matter what i open it with, also the 130b4 version is 515kb where as the 1773 is 335kb

[Guest]

Here is beta 5:

http://neuron2.net/fixd2v/decodefix130beta5.zip

This one fixes a rather serious bug. The index location was getting truncated at 32 bits, even though I used 64 bit ints. It seems that if you do arithmetic on an _int64 with normal ints, it gets demoted to an int!!! So I had to put a cast in there. The effect would have been that any file bigger than about 2GB would give you grief. Now it is correct.

@Wilbert and len0x

I'll look at these issues.

@Dallemon

The D2V file format is different, so applications that used to be able to open D2Vs now no longer can do so. You'll have to serve through Avisynth or VFAPI. Post your script if you are having Avisynth problems.

[Zep]

Originally posted by neuron2

My priorities now are:

1. Speed -- Zep is complaining.



problem found


dg version version setup and d2v project on test clip

with just a 1 line script

mpeg2source("d:\336dg.d2v")

i get 41 FPS preview in VDUB (fast recompress)

Now Add SelectEven() to script to cut the 59.94 FPS
down to 29.7 and FPS tanks to 4 FPS. OUCH :)



Now for the nic/trbarry version setup and d2v project on
the same test clip of course

with just a 1 line script

mpeg2source("d:\336.d2v")

i get 41 FPS preview in VDUB (fast recompress)

Now Add SelectEven() to script to cut the 59.94 FPS
down to 29.7 and FPS tanks to 28 FPS. A FPS hit as well
but not as MASSIVE as dg run.


I feel even the 41 FPS to 28 FPS is a hit that should
not happen. SelectEven is very basic stuff and should not
give any speed hit IMHO. (at least not THIS much)


yes SelectOdd() same FPS hits :D


geez decimate works faster than SelectEven. Now that is insane! HAHA

[Guest]

That is a truly astonishing result, Mr Zep. I'm not going to believe it until I see it. :)

My first reaction is that the SelectEven() must be forcing MPEG2DEC3dg to do random access for each frame, but I can't see why because it follows Mpeg2source()! Even the hit to trbarry/Nic version is surprising. When I get home I will investigate this and get to the bottom of it. I have the capability to step through Avisynth, so it's just a matter of time until we understand this.

EDIT: Actually, thinking about it, SelectEven() will probably force both to do random access, because it will request every other frame. Now I wonder why the hit to me is worse. I bet the trbarry/Nic version will deliver incorrect frames too, due to the seeking issues there (skipping B frames). Anyway, enough speculation. Wait until I get my hands on it.

But wait, Decimate(2) will request every other frame too!!!!!

[Zep]

Originally posted by neuron2
That is a truly astonishing result, Mr Zep. I'm not going to believe it until I see it. :)


lol yes do not take my word for it. It could always be some
currupt thing on my PC


Originally posted by neuron2
My first reaction is that the SelectEven() must be forcing MPEG2DEC3dg to do random access for each frame, but I can't see why because it follows Mpeg2source()! Even the hit to trbarry/Nic version is surprising.

me too. It also means for a long time now I have been taking
a big FPS hit and didn't realize it since I never did JUST
a selecteven in a script (I always had 4 or 5 other filters too
and thought the speed hit was from them. i.e. smoothers
and scaling etc...)

So it turns out i am getting more of speed hit from Selecteven
than ALL my other filters combined. F@#$!!!


Originally posted by neuron2
When I get home I will investigate this and get to the bottom of it. I have the capability to step through Avisynth, so it's just a matter of time until we understand this.

oh if you can fix this and get selecteven to not take ANY
FPS hit, well... i will dub you a coding god :D


thanks!

[Guest]

See my edit above.

This is a good one, Zep!

I could detect that the next frame request is 2 frames later and then just go ahead and decode the in-between one and the next one, thereby avoiding random access. That would make me a god. :) I'll try it.

In fact there is probably a threshold number where it would be advisable just to decode straight and return the final one, rather than doing random access. Say maybe one GOP's worth?

Decimate(2) is faster because he doesn't always pick the same frame in the cycle, meaning that some (half) of the requests are linear.

[Zep]

Originally posted by neuron2
See my edit above.

This is a good one, Zep!

I could detect that the next frame request is 2 frames later and then just go ahead and decode the in-between one and the next one, thereby avoiding random access. That would make me a god. :) I'll try it.

In fact there is probably a threshold number where it would be advisable just to decode straight and return the final one, rather than doing random access. Say maybe one GOP's worth?

Decimate(2) is faster because he doesn't always pick the same frame in the cycle, meaning that some (half) of the requests are linear.


sounds good to me oh coding god :D


yes i just tried Decimate(2) in place of selecteven
for both versions and got 31 FPS on BOTH versions.


4 FPS to 31
and
28 FPS to 31



HOLY S@#! Decimate faster than Selecteven is truly insane IMHO


haha I'm glad we found this problem as i feel it is major stuff.
i just wish i put 2 and 2 together months ago grrrr.....

[Guest]

Thinking again, Decimate() has to get all the frames so he can do the comparisons. That is why it is so much faster, it never causes random access. It's all falling into place, son.

I'll definitely revise the code as described.

Whoulda thunk it?

[Zep]

Originally posted by neuron2
Thinking again, Decimate() has to get all the frames so he can do the comparisons. That is why it is so much faster, it never causes random access. It's all falling into place, son.

I'll definitely revise the code as described.

Whoulda thunk it?


ahhh haaa right. Yup since Decimate has to compare all the frames
random access would indeed be silly and it should just load
them sequentially. yes it is all falling into place LOL


how was this problem not seen by anyone for SOOOOOOO long?
Surely i was not the first to use SelectEven with d2v/ts files :D


(however, it took me a few months to spot it so grrrr on me too!)

[Guest]

I think it is only HD captures that would need the FPS reduction by two and that is perhaps why it hasn't turned up.

Ayway, I tested the idea and it not only works fine but required just 5 lines of code, of which 2 were braces!

You'll get it in the next beta.

[Zep]

Originally posted by neuron2
I think it is only HD captures that would need the FPS reduction by two and that is perhaps why it hasn't turned up.

Ayway, I tested the idea and it not only works fine but required just 5 lines of code, of which 2 were braces!

You'll get it in the next beta.


AWESOME oh coding god :D

[DDogg]

you think this would have effected SelectRangeEvery(1200,12) ?

[Guest]

Originally posted by DDogg
you think this would have affected SelectRangeEvery(1200,12) ? Each bunch of 12 will be decoded fast but you'll have to random access for each jump to the next 1200 point. So this fix will not affect this case, because random accessing forward 1200 frames is faster than linearly playing 1200 frames to get there. That is why I pointed out a threshold point where it become faster to random access.

EDIT: Here's the key bit:


// Decide whether to use random access or linear play to reach the
// requested frame. If the seek is just a few frames forward, it will
// be faster to play linearly to get there. This greatly speeds things up
// when a decimation like SelectEven() follows this filter.
if (frame && frame > BadStartingFrames &&
frame > prev_frame && frame < prev_frame + SEEK_THRESHOLD)
{
// use linear play
}
else
{
// use random access
}

[Dallemon]

its not the player ;)

test script 1 (using 1.3.0b5)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0dg.d2v",CPU=4,iPP=true)

test script 2 (using 1.77.3)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0.d2v",CPU=4,iPP=true)

the first script produced the same error in both VDM (1.5.10) and MPC (6.4.8.2) "MPEG2Ssource: couldn't open file"
the second scipt produced no errors in neither VDM nor MPC

[Zep]

Originally posted by neuron2

EDIT: Here's the key bit:


// Decide whether to use random access or linear play to reach the
// requested frame. If the seek is just a few frames forward, it will
// be faster to play linearly to get there. This greatly speeds things up
// when a decimation like SelectEven() follows this filter.
if (frame && frame > BadStartingFrames &&
frame > prev_frame && frame < prev_frame + SEEK_THRESHOLD)
{
// use linear play
}
else
{
// use random access
}

ahh yes but what is the SEEK_THRESHOLD? My guess depending
on your hard drive and perhaps the cache size on it, the size of a frame as well as how much pre fetch you can do to main memory while waiting for say the encoder to do 1 frame will all play a huge part
in what the SEEK_THRESHOLD should be.

are you gonna make it adjustable?



yes I'm just having fun with wishful thinking with the following :D


example:

mpeg2source("c:\test.d2v",SEEK_THRESHOLD=4)

It would be interesting to see FPS rates by adjusting the threshold
on ones system so that you know for sure when random access
is faster than linear to get to next wanted frame.




I so want the next beta LOL

[Guest]

SEEK_THRESHOLD will have a fixed value, probably in the region of 6-12.

I'll release another beta tonight. Stay up.

[vispgraedde]

Originally posted by Dallemon

the first script produced the same error in both VDM (1.5.10) and MPC (6.4.8.2) "MPEG2Ssource: couldn't open file"
the second scipt produced no errors in neither VDM nor MPC

Are you sure that avisynth is using the correct plugin for MPEG2Source?
Don't forget that you will need to put mpeg2dec3dg.dll in avisynth's plugin dir (and replace the old mpeg2dec3.dll or whatever the old one is) to open the new d2v's.

[Guest]

Here is beta 6:

http://neuron2.net/fixd2v/decodefix130beta6.zip

I wanted to get a few more things in there but I know my friend Zep is waiting anxiously for the new seeking strategy. So here it is!

This also fixes what I hope are the last 32-bit truncations of the 64-bit file position indices. If you ever see negative signs for addresses in the D2V, let me know.

EDIT: SEEK_THRESHOLD = 7 (I love prime numbers.)

[Guest]

After detailed testing I cannot identify any processing hit with SelectEven() against my beta 6. It appears that all of its effects are due to forced seeking. Do you agree, Zep?

[Zep]

Originally posted by neuron2
After detailed testing I cannot identify any processing hit with SelectEven() against my beta 6. It appears that all of its effects are due to forced seeking. Do you agree, Zep?


UPDATE

oh yeah the forced seeking was the problem.

I re ran save project and made a new d2v (just to make sure)
and i see a jump from the 4 FPS to 31 FPS now with selecteven only
(no other filters/functions) so a huge jump and you caught up to
trbarry/nic version and passed it as theirs is 28 FPS.

so I can finally dump their version for good :D


Now i do wonder why it is 31 FPS, a 10 FPS hit. Decimate()
also gets me 31 FPS and it does more. I'm still surprised
there is such a hit from 41 to 31.

thoughts on that?


anyway a huge thanks as this is now AWESOME for me and
it is getting so much better so quickly!


thanks for all the hard work DG or is that CG :)

[Guest]

Originally posted by Zep
Now i do wonder why it is 31 FPS, a 10 FPS hit. Decimate()
also gets me 31 FPS and it does more. I'm still surprised
there is such a hit from 41 to 31. So you are saying that SelectEven() causes a hit! Please describe your methodology and results for showing this. Include all scripts EXACTLY as used.

EDIT: Never mind! I know what it is. It is an illusion. Really. Think about it. Your frame rate is ~30. VirtualDub preview is not going to play it faster than that. But without the SelectEven() the fps is ~60 and that can't be sustained. Ha!

My tests use an HD file that plays at much less than 30fps. I play the AVS into BSPlayer and use the Video Info popup to monitor the rendering rate. Then you can clearly see that SelectEven() has no effect on the video rendering rate.

Now I will see if I can help out Wilbert and len0x. Thank you for bringing this interesting aspect of stream navigation to light.

[Zep]

Originally posted by neuron2
So you are saying that SelectEven() causes a hit! Please describe your methodology and results for showing this. Include all scripts EXACTLY as used.

EDIT: Never mind! I know what it is. It is an illusion. Really. Think about it. Your frame rate is ~30. VirtualDub preview is not going to play it faster than that. But without the SelectEven() the fps is ~60 and that can't be sustained. Ha!

My tests use an HD file that plays at much less than 30fps. I play the AVS into BSPlayer and use the Video Info popup to monitor the rendering rate. Then you can clearly see that SelectEven() has no effect on the video rendering rate.

Now I will see if I can help out Wilbert and len0x. Thank you for bringing this interesting aspect of stream navigation to light.

but VDub should not be throttled in preview mode. It is not
a player but and encode/edit app. grrrr... It sould preview
as fast as it can be fed. (at least there should be an option
for this if that is not the case)

ok so i will have to encode test with and without selecteven
so that preview is not in the loop in case it is throttled.

or figure out a way to trick VDub into thinking it is 60 FPS
with selectEven turned on so VDub does not try and pin it to 30 FPS.
(since I can't think of a way off the top of my head to get avisynth
to pass bogus info i guess i will have to encode. no sleep for me
yet haha)

[Guest]

Just put AssumeFPS(59.94) at the end of the script!

[Guest]

Originally posted by Dallemon
its not the player ;)

test script 1 (using 1.3.0b5)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0dg.d2v",CPU=4,iPP=true)

test script 2 (using 1.77.3)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0.d2v",CPU=4,iPP=true)

the first script produced the same error in both VDM (1.5.10) and MPC (6.4.8.2) "MPEG2Ssource: couldn't open file"
the second scipt produced no errors in neither VDM nor MPC You're not showing the complete scripts. Where are the loadplugin lines? Are you autoloading? If so, how do you ensure the right one is used? Post the actual scripts, not extracted edited ones.

[Zep]

Originally posted by neuron2
Just put AssumeFPS(59.94) at the end of the script!

i will try that next but what i did was this

same test setup as always but instead of fast recompress with preview
i did a direct stream encode which takes the data as fast as it can
be fed from avisynth and saves it to an avi.

Without selecteven 97 FPS
with selecteven 54 FPS


i will now try it with AssumeFPS(59.94) at the end of script.
will post update soon



UPDATE : did the original test with AssumeFPS(59.94) went into
the file-->file info to make sure both tests were 59.94.

Same result.

41 FPS without selecteven
31 FPS with selecteven


so both preview test and direct stream test show a speed hit when
selecteven is used.


ok now what are your thoughts? :D


just for your info the hard drive is a 160gig with 8 meg cache
at 7200rpm and 6ms seek time and it is drive D so no OS
paging to it etc... (I always boot off drive C)




UPDATE #2 I cropped 128 from all four sides to make
sure there was a speed up above 31 FPS.

preview with Selecteven on and AssumeFPS(59.94) ON 46 FPS
preview with Selecteven on and AssumeFPS(59.94) OFF 31 FPS

so yes VDub preview is throttled

[Guest]

Just for fun, see if there is a difference between

SelectEven

and

SelectEven()

You can test an old rumor for us.

[Zep]

Originally posted by neuron2
Just for fun, see if there is a difference between

SelectEven

and

SelectEven()

You can test an old rumor for us.

ok will do


and see my UPDATE above :)



UPDATE no change. i did the cropped test above.
46 FPS with and without the ()

so what was the rumor?

[Guest]

Try select100.zip from http://neuron2.net/misc/select100.zip

The rumor was that things run slower without the ().

[Zep]

Originally posted by neuron2
Try select100.zip from http://neuron2.net/misc/select100.zip



same speed

1 minute and 22 seconds (46 FPS used above crop test) both with SelectEven() and select(0)


without either

51 seconds at 74 FPS (note it pinned to 60 so i had to go back
and use AssumeFPS(120) and redo all tests so it would go above 60
on the run without either SelectEven() or select(0) )

crazy huh?



maybe it has nothing to do with your code but avisynth
does something strange.


UPDATE: tried nandub and VDM same test. Same speeds.
So whatever it is, it is on avisynth side and its ability to
frame serve.

I'm using version

AVS 2.5.5 alpha 2004-03-19 15:00
AviSynth_200304.exe

[Dallemon]

i DID post the WHOLE test script since it SHOULD be autoloading, but i'll the the script that im trying to use and it reports the same errors at mentioned before

working script

import("C:\AviSynth 2.5\scripts\restore24.avs")
import("C:\AviSynth 2.5\scripts\intellibob.avs")
loadplugin("C:\AviSynth 2.5\plugins\masktools.dll")
loadplugin("C:\AviSynth 2.5\plugins\tcombmask.dll")
loadplugin("C:\AviSynth 2.5\plugins\kerneldeint140.dll")
loadplugin("C:\AviSynth 2.5\plugins\tomsmocomp.dll")
loadplugin("C:\AviSynth 2.5\plugins\avisynth_c.dll")
loadcplugin("C:\AviSynth 2.5\plugins\smartdecimate.dll")
loadcplugin("C:\AviSynth 2.5\plugins\ibob.dll")
loadplugin("C:\AviSynth 2.5\plugins\mpeg2dec3.dll")
mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0.d2v",CPU=4,iPP=true)
assumetff()
converttoyuy2(interlaced=true)
a2=r24kernelbob()
b2=intellibob(athl=0,athc=0,mthl=0,mthc=0)
restore24(a2,b2)
vaguedenoiser(threshold=1,method=1,nsteps=8,chroma=yes)
Crop(8,2,-6,-2)
lanczos4resize(640,480)

evol malfunctioning script

import("C:\AviSynth 2.5\scripts\restore24.avs")
import("C:\AviSynth 2.5\scripts\intellibob.avs")
loadplugin("C:\AviSynth 2.5\plugins\masktools.dll")
loadplugin("C:\AviSynth 2.5\plugins\tcombmask.dll")
loadplugin("C:\AviSynth 2.5\plugins\kerneldeint140.dll")
loadplugin("C:\AviSynth 2.5\plugins\tomsmocomp.dll")
loadplugin("C:\AviSynth 2.5\plugins\avisynth_c.dll")
loadcplugin("C:\AviSynth 2.5\plugins\smartdecimate.dll")
loadcplugin("C:\AviSynth 2.5\plugins\ibob.dll")
loadplugin("C:\AviSynth 2.5\plugins\mpeg2dec3.dll")
mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0dg.d2v",CPU=4,iPP=true)
assumetff()
converttoyuy2(interlaced=true)
a2=r24kernelbob()
b2=intellibob(athl=0,athc=0,mthl=0,mthc=0)
restore24(a2,b2)
vaguedenoiser(threshold=1,method=1,nsteps=8,chroma=yes)
Crop(8,2,-6,-2)
lanczos4resize(640,480)

[vispgraedde]

Originally posted by Dallemon

evol malfunctioning script

loadplugin("C:\AviSynth 2.5\plugins\mpeg2dec3.dll")


It looks to me like you are using the old mpeg2dec3.dll when you should be using the new mpeg2dec3dg.dll

[Dallemon]

thx, it works now ^_^

edit: st00pid me for being n00bish :o

[Guest]

Originally posted by Dallemon
st00pid me for being n00bish We all suffer brain farts now and again. Please let us know of your results with this version or if you notice anything out of the ordinary.

[trbarry]

Hi -

I have not been here for awhile and it's also been many months since I've even looked at DVD2AVIx or MPEG2DECx code.

Do Donald's versions now pretty much reliably subsume the functions of mine? I previously didn't use his because of the lack of HDTV support but if the dg versions now reliably do everything then I'd like to stop worrying about mine and just vector my web page to his for those 2 prog's.

I'm in a new job and pretty busy so I don't anticipate making any changes to these in the near future anyway. Any reason not to drop support for mine?

- Tom