Software based Time Based Correctors ?

G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

I have some old VHS tapes, I need to convert to DVDs.
Are there any Software based TBCs out there.
If yes, do I need to have the files as AVI
or can it take MPEG2

Thanks
--nw
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Norris Watkins" wrote ...
>I have some old VHS tapes, I need to convert to DVDs.
> Are there any Software based TBCs out there.

Timebase correction is pretty much a hardware function.
Not really practical to try to do in software as the damage
has already been done during capture before the software
ever gets to see it.

> If yes, do I need to have the files as AVI
> or can it take MPEG2

That card that "nappy-iou" recommended looks pretty good.
It appears to combine TBC functionality with hardware MPEG2
compression which sounds like exactly what you are seeking.
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Norris Watkins" <norris_watkins@hotmail.com> wrote in message
news:a4c8fc50.0410300934.79180258@posting.google.com...
>I have some old VHS tapes, I need to convert to DVDs.
> Are there any Software based TBCs out there.
> If yes, do I need to have the files as AVI
> or can it take MPEG2
>
> Thanks
> --nw

here's alink to a capture card wiht some TBC hardware onboard.
http://www.aver.com/products/dvm_AVerDVD_ezMakerPro.shtml

You might find others with the same.

You really need to time base correct the stream prior to capturing. A TBC
uses some memory to store frames and align sync prior to output.

I think you can pick up a used TBC for fairly cheap now.

Also. I have a Panasonic AG7750 Editing VHS deck that I have had since
about 91. Still works like a dream and has a build in TBC, which comes in
handy sometimes. I rarely capture from VHS. You may want to look for
something like that.
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Richard Crowley" <rcrowley7@xprt.net> wrote in message
news:10o7rau4ptbl14e@corp.supernews.com...
> "Norris Watkins" wrote ...
>>I have some old VHS tapes, I need to convert to DVDs.
>> Are there any Software based TBCs out there.
>
> Timebase correction is pretty much a hardware function.
> Not really practical to try to do in software as the damage
> has already been done during capture before the software
> ever gets to see it.
>
>> If yes, do I need to have the files as AVI
>> or can it take MPEG2
>
> That card that "nappy-iou" recommended looks pretty good.
> It appears to combine TBC functionality with hardware MPEG2
> compression which sounds like exactly what you are seeking.
It's not at all inconceivable though. It would have to involve the capture
application, and I'll bet that it already is.

All a TBC or Frame Synchronizer does is (most TBCs are frame
synchronizers as well these days) digitize what ever is coming in,
find the start of the frame (based on timing and sync pulses), and
stuff the lines into memory. Then it reads it back from of memory,
adds new sync (referenced to external sync if desired) and puts out
the corrected video. All it has to do in a computer is read the lines
in and put them on a hard drive. The video will come out corrected.

David
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"david.mccall" wrote ...
>
> "Richard Crowley" <rcrowley7@xprt.net> wrote in message
> news:10o7rau4ptbl14e@corp.supernews.com...
>> "Norris Watkins" wrote ...
>>>I have some old VHS tapes, I need to convert to DVDs.
>>> Are there any Software based TBCs out there.
>>
>> Timebase correction is pretty much a hardware function.
>> Not really practical to try to do in software as the damage
>> has already been done during capture before the software
>> ever gets to see it.
>>
>>> If yes, do I need to have the files as AVI
>>> or can it take MPEG2
>>
>> That card that "nappy-iou" recommended looks pretty good.
>> It appears to combine TBC functionality with hardware MPEG2
>> compression which sounds like exactly what you are seeking.
> It's not at all inconceivable though. It would have to involve the capture
> application, and I'll bet that it already is.
>
> All a TBC or Frame Synchronizer does is (most TBCs are frame
> synchronizers as well these days) digitize what ever is coming in,
> find the start of the frame (based on timing and sync pulses), and
> stuff the lines into memory. Then it reads it back from of memory,
> adds new sync (referenced to external sync if desired) and puts out
> the corrected video. All it has to do in a computer is read the lines
> in and put them on a hard drive. The video will come out corrected.

That is an oversimplification, and misses the specific function
of TBCs vs general-purpose video digitizers. Spcifically a
TBC tracks the exact position of the horizontal sync pulse of
EACH video line and adjusts the capture window to track the
timebase errors (which are seen as horizontal skewing in the
picture). General-purpose video digitizers don't necessarily
implement this function. although some seem to be better at it
than most.

I have heard that there is a plug-in for one of the freeware
applications that attempts to do line-by-line correction of
horizontal displacement. (Sort of an after-the-fact timebase
correction function). But it certainly involves a lot more
fooling around than using a conventional hardware TBC. And
of course it can only deal with the video that was captured
with the non-tracking digitizer hardware, so it doesn't have
the original sync pulses as a reference point. It has to guess
from the video whether there is a timebase error for each
specific line. Given those significant limitations, I doubt that
it is very effective.
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"david.mccall" wrote ...
> All a TBC or Frame Synchronizer does is (most TBCs are frame
> synchronizers as well these days) digitize what ever is coming in,
> find the start of the frame (based on timing and sync pulses), and
> stuff the lines into memory. Then it reads it back from of memory,
> adds new sync (referenced to external sync if desired) and puts out
> the corrected video. All it has to do in a computer is read the lines
> in and put them on a hard drive. The video will come out corrected.

Remember that there are video capture devices (such as the AverMedia
device and the Canopus ADVC-300, for example) that specifically
include TBC *hardware* functionalty. If "the video will come out
corrected" with any old video capture device as Mr. McCall suggests,
one would think that there would be no market for these devices.
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Richard Crowley" <rcrowley7@xprt.net> wrote in message
news:10o7u91p66gqm5b@corp.supernews.com...
>
>> All a TBC or Frame Synchronizer does is (most TBCs are frame
>> synchronizers as well these days) digitize what ever is coming in,
>> find the start of the frame (based on timing and sync pulses), and
>> stuff the lines into memory. Then it reads it back from of memory,
>> adds new sync (referenced to external sync if desired) and puts out
>> the corrected video. All it has to do in a computer is read the lines
>> in and put them on a hard drive. The video will come out corrected.
>
> That is an oversimplification, and misses the specific function
> of TBCs vs general-purpose video digitizers. Spcifically a
> TBC tracks the exact position of the horizontal sync pulse of
> EACH video line and adjusts the capture window to track the
> timebase errors (which are seen as horizontal skewing in the
> picture). General-purpose video digitizers don't necessarily
> implement this function. although some seem to be better at it
> than most.
>
So what did I miss???? I allready said that it locates the beginning
of each horizontal line, and stash whatever comes after that to memory.
That's about all a TBC does on the way in. In software you could look
at the pulse at the end of each line, and make sure that each line was
exactly the same length by scaleing the line to fit. I'm not at all sure
hardware TBCs can even do that. The rest of the TBC is pretty much
of no interest to video capture.

You could extrapolate line position by anaylizing adjacent lines and
frames of the video to do the correction, but I don't think TBCs ever
made it that far. They just base their capture on the incoming sync,
and base their output on either external sync source, or just on internal
sync generator. TBCs usually have a proc amp and comb filters built in,
but both could also be done in software.

David
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Richard Crowley" <rcrowley7@xprt.net> wrote in message
news:10o7uo0gpl59926@corp.supernews.com...
> "david.mccall" wrote ...
>> All a TBC or Frame Synchronizer does is (most TBCs are frame
>> synchronizers as well these days) digitize what ever is coming in,
>> find the start of the frame (based on timing and sync pulses), and
>> stuff the lines into memory. Then it reads it back from of memory,
>> adds new sync (referenced to external sync if desired) and puts out
>> the corrected video. All it has to do in a computer is read the lines
>> in and put them on a hard drive. The video will come out corrected.
>
> Remember that there are video capture devices (such as the AverMedia
> device and the Canopus ADVC-300, for example) that specifically
> include TBC *hardware* functionalty. If "the video will come out
> corrected" with any old video capture device as Mr. McCall suggests,
> one would think that there would be no market for these devices.
I don't know that there is much of a market for TBCs in non-linear suites.
I'm not suggesting that all capture devices are equal, or can all manage
to correct incoming video no matter how wide the time variations are.



David
 
G

Guest

Guest
Archived from groups: rec.video.desktop (More info?)

Here's an inexpensive harware TBC
for $200, AVT-8710:
http://www.dvwizards.com/shop/product.asp?sku=AVT5008

It works well for VHS/S-VHS/Beta.
It's in other countries, but has other
brand names (search with the specs).

Maybe a software thing could be
made, but it would be guessing
all the time, with weird side effects.


>"Norris Watkins" <norris_watkins@hotmail.com> wrote in message
>news:a4c8fc50.0410300934.79180258@posting.google.com...
>>I have some old VHS tapes, I need to convert to DVDs.
>> Are there any Software based TBCs out there.
>> If yes, do I need to have the files as AVI
>> or can it take MPEG2
>>
>> Thanks
>> --nw
>
>here's alink to a capture card wiht some TBC hardware onboard.
>http://www.aver.com/products/dvm_AVerDVD_ezMakerPro.shtml
>
>You might find others with the same.
>
>You really need to time base correct the stream prior to capturing. A TBC
>uses some memory to store frames and align sync prior to output.
>
>I think you can pick up a used TBC for fairly cheap now.
>
>Also. I have a Panasonic AG7750 Editing VHS deck that I have had since
>about 91. Still works like a dream and has a build in TBC, which comes in
>handy sometimes. I rarely capture from VHS. You may want to look for
>something like that.
>
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Richard Crowley" <rcrowley7@xprt.net> wrote in message
news:10o7u91p66gqm5b@corp.supernews.com...
>
> "david.mccall" wrote ...
> >
> > "Richard Crowley" <rcrowley7@xprt.net> wrote in message
> > news:10o7rau4ptbl14e@corp.supernews.com...
> >> "Norris Watkins" wrote ...
> >>>I have some old VHS tapes, I need to convert to DVDs.
> >>> Are there any Software based TBCs out there.
> >>
> >> Timebase correction is pretty much a hardware function.
> >> Not really practical to try to do in software as the damage
> >> has already been done during capture before the software
> >> ever gets to see it.
> >>
> >>> If yes, do I need to have the files as AVI
> >>> or can it take MPEG2
> >>
> >> That card that "nappy-iou" recommended looks pretty good.
> >> It appears to combine TBC functionality with hardware MPEG2
> >> compression which sounds like exactly what you are seeking.
> > It's not at all inconceivable though. It would have to involve the
capture
> > application, and I'll bet that it already is.
> >
> > All a TBC or Frame Synchronizer does is (most TBCs are frame
> > synchronizers as well these days) digitize what ever is coming in,
> > find the start of the frame (based on timing and sync pulses), and
> > stuff the lines into memory. Then it reads it back from of memory,
> > adds new sync (referenced to external sync if desired) and puts out
> > the corrected video. All it has to do in a computer is read the lines
> > in and put them on a hard drive. The video will come out corrected.
>
> That is an oversimplification, and misses the specific function
> of TBCs vs general-purpose video digitizers. Spcifically a
> TBC tracks the exact position of the horizontal sync pulse of
> EACH video line and adjusts the capture window to track the
> timebase errors (which are seen as horizontal skewing in the
> picture). General-purpose video digitizers don't necessarily
> implement this function. although some seem to be better at it
> than most.
>
His descripting is functionally accurate, as this is what a TBC is. A video
digitizer is also a TBC.

The basic TBC function is accomplished by digitizing the video signal and
storing it in memory. What separates the MEN from the boys is how well the
sync signals are extracted from the incoming analog video stream and how
well the "write" clock tracks the video incoming frequency rate. So for a
VHS type of player, the clock generator must correct for the head-switch
error so that there is no picture hook or bending at the top of the screen.

Thus, you have two big problems, First, the sync signals are usually
distorted and compressed by the tape recording, especially with multiple
generations of analog recording and, Second, you need to be able to store a
complete frame of the video signal in memory in exactly one frame of memory,
so as the playback frequency of the video signal drifts over time, the
"write" clock must be able to very accurately measure the incoming video
rate in the presence of noise, sync compression and tape drop-outs, head
switch tension errors and I believe the current "phase of the moon" was also
important.

Over about 20 years of designing TBC's I used many different sync extraction
methods and several different clock generators to try to find the best,
never did.

For the First digital TBC designed in 1972 I used a PLL clock design to lock
to incoming horizontal sync and incoming color burst signal as it was a
"composite" video world back then, I am very glad it is now gone.

Mike Tallent
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Mike T" <mtallent@u$-i$p.net> wrote in message
news:LyGhd.2239541$yk.364158@news.easynews.com...
> For the First digital TBC designed in 1972 I used a PLL clock design to
> lock
> to incoming horizontal sync and incoming color burst signal as it was a
> "composite" video world back then, I am very glad it is now gone.

I remember daily battles with a Phillips/Norelco
3-plumbicon color camera with a horizontal sync
circuit that had a mind of its own. Half the time it
had no concept of "genlock" and would wander
around like a feather in the breeze.
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Mike T" <mtallent@u$-i$p.net> wrote in message
news:LyGhd.2239541$yk.364158@news.easynews.com...
>
>
> His descripting is functionally accurate, as this is what a TBC is. A
> video
> digitizer is also a TBC.
>
> The basic TBC function is accomplished by digitizing the video signal and
> storing it in memory. What separates the MEN from the boys is how well
> the
> sync signals are extracted from the incoming analog video stream and how
> well the "write" clock tracks the video incoming frequency rate. So for a
> VHS type of player, the clock generator must correct for the head-switch
> error so that there is no picture hook or bending at the top of the
> screen.
>
> Thus, you have two big problems, First, the sync signals are usually
> distorted and compressed by the tape recording, especially with multiple
> generations of analog recording and, Second, you need to be able to store
> a
> complete frame of the video signal in memory in exactly one frame of
> memory,
> so as the playback frequency of the video signal drifts over time, the
> "write" clock must be able to very accurately measure the incoming video
> rate in the presence of noise, sync compression and tape drop-outs, head
> switch tension errors and I believe the current "phase of the moon" was
> also
> important.
>
> Over about 20 years of designing TBC's I used many different sync
> extraction
> methods and several different clock generators to try to find the best,
> never did.
>
> For the First digital TBC designed in 1972 I used a PLL clock design to
> lock
> to incoming horizontal sync and incoming color burst signal as it was a
> "composite" video world back then, I am very glad it is now gone.
>
> Mike Tallent
>
A good piece. Thank you. and thank you for being a part of that
first TBC. How many lines could it do? What company?

Looking back at it now, I'll bet you wished you had microprocessors
to analyze the signal, instead of just PLLs. On advantage to "capture"
alone is that you don't have to put the video back out in real time, you
just have to get it onto a hard drive. With current microprocessor
speeds, you should have a lot of advantages in terms of line to line,
field to fields, and even frame to frame comparisons, to get all of those
pixels lined up just right.

I'm not saying that they are doing a good job of it, I really don't know,
but it should be practical to capture most anything directly into the
computer without an external TBC. I have an old Matrox Digisuite
and it seems to handle everything I've thrown at it so far, but I really
haven't had to test it much. I realize that a lot of people are using
capture cards that are well under $5000, so I wouldn't be surprised
if their performance was somewhat different. However, there has
been a lot of time for improvement since this thing was designed.
A 300 mhz computer was a cooker back then.

David
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"david.mccall" <david.mccallUNDERLINE@comcast.net> wrote in message
news:wQNhd.355849$D%.318795@attbi_s51...
>
> "Mike T" <mtallent@u$-i$p.net> wrote in message
> news:LyGhd.2239541$yk.364158@news.easynews.com...
> >
> >
> > His descripting is functionally accurate, as this is what a TBC is. A
> > video
> > digitizer is also a TBC.
> >
> > The basic TBC function is accomplished by digitizing the video signal
and
> > storing it in memory. What separates the MEN from the boys is how well
> > the
> > sync signals are extracted from the incoming analog video stream and how
> > well the "write" clock tracks the video incoming frequency rate. So for
a
> > VHS type of player, the clock generator must correct for the head-switch
> > error so that there is no picture hook or bending at the top of the
> > screen.
> >
> > Thus, you have two big problems, First, the sync signals are usually
> > distorted and compressed by the tape recording, especially with multiple
> > generations of analog recording and, Second, you need to be able to
store
> > a
> > complete frame of the video signal in memory in exactly one frame of
> > memory,
> > so as the playback frequency of the video signal drifts over time, the
> > "write" clock must be able to very accurately measure the incoming video
> > rate in the presence of noise, sync compression and tape drop-outs, head
> > switch tension errors and I believe the current "phase of the moon" was
> > also
> > important.
> >
> > Over about 20 years of designing TBC's I used many different sync
> > extraction
> > methods and several different clock generators to try to find the best,
> > never did.
> >
> > For the First digital TBC designed in 1972 I used a PLL clock design to
> > lock
> > to incoming horizontal sync and incoming color burst signal as it was a
> > "composite" video world back then, I am very glad it is now gone.
> >
> > Mike Tallent
> >
> A good piece. Thank you. and thank you for being a part of that
> first TBC. How many lines could it do? What company?

The first digital TBC was introduced by Consolidated Video Systems (CVS) at
NAB 1973, it was 8 bits at 3X color or 10.7 MHz and had a correction range
of 3 horizontal lines, using 1024 BIT dynamic shift registers as the largest
RAM chip was 256 BITS and need several support chips per RAM. UGH! I was a
founder of the company and project manager on the TBC and designed the
analog parts with another designing the A/D converter and a third doing the
digital "stuff", guess we helped to put the "silicon" in Silicon Valley.
Sure was a lot of fun in those days in N. Cal.

After CVS, I did ADDA Corp and ALTA Group "stuff"

Here are a few of the patents on this stuff--
http://www.delphion.com/details?pn=US04062041__
http://www.delphion.com/details?pn=US03993982__
http://www.delphion.com/details?pn=US03900885__
http://www.delphion.com/details?pn=US03860952__

In case you want to know more ;-)

>
> Looking back at it now, I'll bet you wished you had microprocessors
> to analyze the signal, instead of just PLLs. On advantage to "capture"
> alone is that you don't have to put the video back out in real time, you
> just have to get it onto a hard drive. With current microprocessor
> speeds, you should have a lot of advantages in terms of line to line,
> field to fields, and even frame to frame comparisons, to get all of those
> pixels lined up just right.

I don't think today the computers are fast enough to do much analysis on the
video signal in real time, and to store the video into memory you STILL have
to know WHERE the video line starts and if you do that correctly the TBC
function is complete.

To store the complete sync pulse into memory in order to analyze it would be
a waste of dynamic range and you still have to "DC" restore the sync pulse
to set it at the proper video level into the A/D converter and if you can do
a proper DC restoration on the incoming video, then you also "know" where
the video line starts so you would also know how to perform the complete TBC
function.

So software is not a solution for this "hardware" problem, at least not yet
:)

Mike T

>
> I'm not saying that they are doing a good job of it, I really don't know,
> but it should be practical to capture most anything directly into the
> computer without an external TBC. I have an old Matrox Digisuite
> and it seems to handle everything I've thrown at it so far, but I really
> haven't had to test it much. I realize that a lot of people are using
> capture cards that are well under $5000, so I wouldn't be surprised
> if their performance was somewhat different. However, there has
> been a lot of time for improvement since this thing was designed.
> A 300 mhz computer was a cooker back then.
>
> David
>
>
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

Mike T wrote:
> Sure was a lot of fun in those days in N. Cal.
>
> After CVS, I did ADDA Corp and ALTA Group "stuff"

I used to have a dual ADDA TBC. That thing was so coooooool.

E
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

> Mike T wrote:
>> Sure was a lot of fun in those days in N. Cal.
>>
>> After CVS, I did ADDA Corp and ALTA Group "stuff"
>
I think a 16 line CVS may have been my first, and I owned
a Pyxis for many years.

David
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Seattle Eric" <noone@erehwon.gov> wrote in message
news:4188368c$0$11701$8b463f8a@news.nationwide.net...
> Mike T wrote:
> > Sure was a lot of fun in those days in N. Cal.
> >
> > After CVS, I did ADDA Corp and ALTA Group "stuff"
>
> I used to have a dual ADDA TBC. That thing was so coooooool.
>
> E
>

The ADDA AC-20 was the first dual channel TBC with special video effects, it
seemed like a good idea with all the A-B roll editing going on at that time.

Got spare parts and manuals for most of these products if anyone needs one
repaired today ;-)

Mike Tallent
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

I'm still using a Pyxis, a Pyxis-E in my dub rooms, and my Centaurus is the
main still store in my production truck.

Steve



"david.mccall" <david.mccallUNDERLINE@comcast.net> wrote in message
news:nqYhd.561889$8_6.68770@attbi_s04...
>
> > Mike T wrote:
> >> Sure was a lot of fun in those days in N. Cal.
> >>
> >> After CVS, I did ADDA Corp and ALTA Group "stuff"
> >
> I think a 16 line CVS may have been my first, and I owned
> a Pyxis for many years.
>
> David
>
>
 
G

Guest

Guest
Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (More info?)

"Steve Guidry" <steveguidrynospam@earthlink.net> wrote in message
news:s_5id.2472$O11.2054@newsread3.news.pas.earthlink.net...
> I'm still using a Pyxis, a Pyxis-E in my dub rooms, and my Centaurus is
> the
> main still store in my production truck.
>
> Steve
>
I donated my Pyxis E to the local access channel.
It sat on the shelf for a year or so then tried to use it.
They plugged it in and it smoked. So they never got to use it.

David