#QuickPass Rave
34 messages in this thread
Hi All,
Not having yet joined the PAR/Targa 2000 etc. Club, I have skimmed the messages
here regarding these products with sullen disintrest.
However, now that we have upgraded our Diaquest controller to Quickpass, I am
compelled to gloat.
Our Diaquest board had seemed like a classic piece of "Hardware from the Dark
Ages". Obtuse documentation, 256 little command line utilities, 80 minutes to
put ten seconds to tape…
Quickpass ($650 ) is One of Those Upgrades that makes a person stare at the
cieling in awe and appreciation for the genius of the Technology Gods. With a
slick Windows interface, Quickpass puts video to tape 10 to 20 times faster
than an unaided VTR controller.
This is like network rendering–it totally changes ones perspective on
animation!
Not that I wouldn't rather have a "T2K" or a Personal Animation Recorder…
-Donald Newlands
For 4 times the price you could have had a PAR which would have done the
recording to video 48 times faster than QUICK PASS. But, this is not the only
value of the PAR. I have opened a whole new marketing tool of special effects
services in video processing, Non Linear editing, slo-mo, time lapsed video and
reverse. BTW: My PAR was paid for including the TBCIV in three weeks of
additional jobs I landed because of these new capabilities. It has been the
single best investment since buying my 3/4 Umatic editing equipment 6 years
ago. I have not operated my diaquest since the PAR arrived and I have not been
able to sell it even for the scrap hardware price of the cables and board.
AWww, yes, yes, but!
a) I can't spend $2500 +/- $500 until 1995 when we get a new capital budget.
b) We don't do that much video animation (yet, although we might do more with
Quick Pass).
c) Since our need is not urgent, we may as well see what happens in the
desktop/digital video world in the next six months — ultimately, we need to be
able to edit live video. Hopefully the next six months will produce as many
great products as the last six months. At Siggraph 93, there was beta Targa
2000, and another black box system (?) at Siggraph '94 there was Newtek,
Matrox, Truevision, the PAR people, and a small army of others hawking high and
low end digital video stuff. In '94 a whole magazine was launched to cover
the "Digital Video" market.
d) The difference between doing something in ten minutes versus eighty is
radical enough for me this week.
Donald
Donald,
FWIW I checked out Quick Pass some 11 months ago; when the PAR was just a glint
in the average 3DS user's eye, and was very impressed. Since then several
clients are using the DQ board with it, along with an AT-VISTA and T32's and
the former outputs better quality than the PAR, the latter IMO is a toss up,
format for format. The truth be known there is relatively little speed
difference when using both approaches and going straight from disk although
with alot of RAM the DQ can actually be fastered. Of course with the PAR you
can render directly, whereas with QP you have to render to disk first. The
biggest drawback is that unlike with the PAR you can't do multiple first
generations and the wear and tear on the deck. But the image quality is
comparable or better depending on which framebuffer you use. And if you're
outputting with the T32 your renders take 25% less time. So in spite of all the
noise you hear about the PAR, you've got every reason to be happy with your DQ
QP. 🙂
Cheers,
John (first to stir up a hornet's nest) Ellis <g>
John,
Thanks for your support! My rave was looking a little thin for awhile — it
needed some proping up!
I can see a few things that PAR might do better, but the QP does what we need.
–Donald Newlands
>>My rave was looking a little thin for awhile — it needed some proping up!
Don't worry! We all have our system at one place in the process chain. Anyone
who has a 386-33 and moves to a 486-66 is really impressed with the speed but
then someone will come along and brag about their P90. And the P90 heads will
be out done by the guys with the Onyx and workstation class software. Many of
us PAR owners are still looking for the day when we will have a fully networked
A66 and NLE with D1 decks. It never stops!
As a comparison, I just got out the calculator and figured that I did 22 years
of recording and frame grabbing with my PAR since owning it. I used to grab or
record one frame every 20 seconds. Now it's 600 frames every 20 seconds.
As far as the resolution difference is concerned, you probably won't notice
much difference between the targa+ 512 and the par 752 when recording to a 7750
in SVHS mode. There is a distinct difference, however, when recording to
betacam SP and viewing in the component mode. Resolution is not the only
factor to consider. The PAR will also have better noise figures and other
specs than the targa+ and these are also visible on a good monitor. The main
thing that is constantly badgered on the PAR is it's compression ratio of 10+
to 1. Although this seems high when compared with comparable technology, the
MAX that is bragging about a 3:1 ratio, the 10 or 12 to 1 of the PAR has only
been an issue with people I run into on this forum. It has not ever come up
with my clients.
Now here's a good offer for you: I'll sell my Diaquest DQ-50P with Action
Animator, manuals, wiring notes, and cable set for $150. The cables with BNC's
and other hardware alone is worth that much in my junk box. Let's see if I
have any takers. Note: At that price it comes with no lessons in frame by
frame, that's extra. <G>
>> I used to grab or record one frame every 20 seconds. Now it's 600 frames
every 20 seconds. <<
Uh Huh… And most animators are really concerned with how fast they can grab
frames. Heck an Indeo card can do 30 frames a second. <g> Lets talk about the
real issue. How long does it take to process a frame going from hard disk over
a network or directly to the PAR? Can you put a frame to the PAR in five
seconds, ten seconds? The average time with QP is around 2 seconds with no
compression loss. PAR times are typically 10 seconds or more and that's with
buffers maxed out! I'd be thrilled to be able to do 2 seconds a frame. And for
animators that's what counts!
John
>>I'd be thrilled to be able to do 2 seconds a frame. And for animators that's
what counts!<<
So John, Are you going to put your PAR up for sale now that you're switching
to Quick Pass? I don't see you using a PAR if it slows you down productivity
wise by a factor of 5.
Don,
>> I don't see you using a PAR if it slows you down productivity wise by a
factor of 5. <<
Me neither, however the ratio you present is inaccurate. I know I would
benefit from faster output, and the PAR is slow, just marginally faster than
my EVO. It does have other attributes which make it a useful production tool,
which I've pointed out on other occassions. But the PAR does have its
drawbacks, and I don't think it can be seriously considered better than an
AG-7750 with QP. They're different and provide different solutions. And that
IMO is what should be expressed around here, but that's probably a minority
opinion. <g>
This all does get away from the real point though, which is that "frame by
frame" is not dead, and not in the foreseeable future.
And that in part is because of products like Quick Pass which make it a very
fast medium. (I figure I can say that now because you only have a couple of
months left on your prediction. <g>)
BTW did you know that the Diskus is a "single" SCSI disk with an acquisition
rate of 6 frames a second off a network, and has real time RGB to YUV
conversion? Just $17,500 at your neighborhood Abekas dealer. <g> And you can
buy a brand new A65 for around $11,700. Still if you've already got a Beta SP
deck, QP is an attractive alternative as most of the stuff ends up on Beta
anyway. Hmmm…. Could there be a QP in your future? (Just kidding, I know how
impressed your clients are with the PAR as compared to the Abekas.)
John
Your numbers of 10 seconds vs. 2 seconds, I interpreted as a ratio of 5 was
inaccurate??? well PARdon me then. <G>
To me, Quick pass is like adding more ram to a 286 computer to get more speed.
John, listen to this, we're in the age of the pentiums,power PC's and at
least the 486-66. The age of frame by frame, a 286 level technology, is dead!
No PAR_DON me <g>, I should have explained rather than put it that
way.
You've got a PAR that's capable of outputting roughly 360 frames
an hour, and an animation that takes about 5 min a frame, so you need 6
machines to keep up and 30 machines to outpace the PAR at a ratio of 5. On the
other hand QP can output between 1500 and 2000 frames an hour which to outpace
would require more than 125 machines using your productivity analogy. Not
exactly what I'd call "dead" technology.
>> Quick pass is like adding more ram to a 286 computer to get more speed. <<
Not at all, but rather than debate it with you, I'll list Diaquest's number and
anyone who wants to check it out can call.
510-526-7167
John
>>You've got a PAR that's capable of outputting roughly 360 frames per hour..
Yes, but that's when I run the PAR in slomo. <G>
The way I figure it is that the PAR requires an additional 2 seconds to dump
the rendered frame (752×480) to the par drive during the rendering process vs.
rendering to null device only.
When I tested the same rendered animation in AT Vista mode (756×486) and it
was saved to the Dos drive it saved at 2 seconds per frame so the difference in
going to the PAR was zero seconds of added rendering (processing) time. Once
the rendering time is done I just launch the Par.exe and the output is real
time or 1800 frames per minute (30 frames per second).
I actually ran the renderings both ways and took an average for the total time
to render AND save the frame, once to the dos drive and once to the PAR.
I don't own quick Pass so I have to rely on what people have told me they get
which has been 10 frames per pass. This is a speed up of 10 times what I used
to get with my DQ422 on the AG7750. or 16 seconds per frame using a 5 second
preroll. Dividing by 10 the recording should be done, I assume, in 1.6 seconds
per frame with QP. A minute of animation (1800 frames would take 2880 seconds
or 48 minutes to record to tape.
Since my experiment showed no difference in recording the frame to the PAR vs.
recording the frame to the dos drive we can figure that the recording process
is a relation of par recording to tape vs. quickpass recording to tape or 1 min
for PAR vs. 48 minutes for QP.
In reviewing several of your arguements of last winter on the subject you were
making a comparison using IMO two invalid parameters. First, you compared the
PAR speed using a rendering resolution of 752×480 vs. a quick pass or FxF
rendering of 512×486. You used the rendering speed difference as part of the
equation. In several tests here I found all the people asked could pick out
the PAR resolution quality as superior in sharpness and video noise to the
targa+ output. It is assumed that an AT Vista or Ill Pro would be more
comparable to the quality of the PAR as opposed to the targa+. Maybe JKJ could
offer some input to this question. On this assumption I use the resolution
slow down issue as.. not valid and make my speed tests at the same resolution.
Second, You used a figure of 4-5 seconds per frame of additional processing
time ( a figure Greg P. volunteered) to convert the rendered TGA's to the PAR
using PAR's import feature. While this is an additional step in the process
and these numbers are similar to what I confirm here it is not the most
expedient way to get rendered frames to the PAR although it can be a much
safer, conservative, use of ones time assuming DOS space is available. In
actual work here I choose both ways depending on the circumstances. I realize
that the configuration you use in your network obviates the direct saving of
these frames to the PAR. This is one reason I chose not to mimick the
dedicated server approach you chose. Possibly NDUMP.exe could salvage this PAR
speed loss in your setup.
Bottom line is that QP is a much improved way of recording over FxF but still
is a far cry to the output speed of real time recording. The only way to
improve recording real time with the PAR is to go with lesser and lesser
compression or no compression such as the Abekas/Accom system network fed.
Ref. Paul Lind's setup.
Now I have to get to work.
Don:
>> You used a figure of 4-5 seconds per frame of additional processing time
>> (a figure Greg P. volunteered)
That depends quite a lot on the network speed. Those figures came from a
pretty big file moving across a network! Also, there is a big difference in
speed depending on how complicated the file is (file size is a good indication
of this.) A file with no background is a lot faster than one where you
composited on live video! Your mileage may vary. <g>
Greg Pyros
First let me say thanks for taking the time to give me a basis of
comparison.
Granted our rendering scenarios are different; having the PAR on your
rendering platform makes sense in your situation. I am re-evaluating
my setup but as I heavily rely on network rendering I'm not sure what
advantage I might have reconfiguring my system in the same way.
My new AT Vista is 720×486, my old Vista was 756×482 but it died a few
months ago and I decided to replace it with the CCIR version. FWIW.
>> Since my experiment showed no difference in recording the frame to
the PAR vs. recording the frame to the dos drive we can figure that
the recording process is a relation of par recording to tape vs.
quickpass recording to tape or 1 min for PAR vs. 48 minutes for QP.
<<
This sounds like a fair assessment. You could do better or worse with
QP depending on what kind of framebuffer, platform and output deck
you have.
>> First, you compared the PAR speed using a rendering resolution of
752×480 vs. a quick pass or FxF rendering of 512×486. You used the
rendering speed difference as part of the equation. In several tests
here I found all the people asked could pick out the PAR resolution
quality as superior in sharpness and video noise to the targa+
output. <<
That is true. In that time frame we were both outputting to SVHS and
it didn't seem to me that the quality difference between the PAR and
a Targa was significant when going to that format. You seemed to
concur with this view a few days ago. I do think that going to Beta
SP does show a significant difference in quality due to the increased
resolution of Beta. I've compared SVHS from the Targa and SVHS from
the PAR into the EVO. I can't really say one looks better than the
other though I will agree they look different. I think the Targa does
look softer but then so does the AT Vista. Kinda like Tube and CCD.
Better in this case I think is in the eye of the beholder at 400 line
res.
I'm not sure where to go from here. It appears that short of rendering
directly to the PAR, there doesn't seem to be a solution to
increasing the speed of transfer.
*** people have told me they get which has been 10 frames per pass. ***
FYI: I am getting 25 frames per pass.
John:
>> [Abekas Discus] and has real time RGB to YUV conversion?
No, not real time. An Abekas is really a UNIX workstation with a very fast
hard disk! The code they use to convert is the same code we use in our YUV
IPAS routine – it's fast, but not real-time!
Greg Pyros
Darn! I wish you had offered your DQ stuff here three weeks ago.
That sounds great, but now that I have QuickPass, my animations go to
tape SO FAST that I won't be needing another recording setup for a
few years while I'm savoring the 7.5 years I saved by buying
QuickPass on a beach someplace south of Minneapolis. (Years
saved=Life expectancy*(Quickpass/frame by frame)
Hi,
Just a note on a prob I have with mine that u may want to watch for. On some
animations I get a complete frame vert jump at every point where Quickpass
dropped the frame during the Final Pass-Frame by Frame mode. Diaquest says its
my VTR (7750), Panasonic says it is Diaquest prob!!! Typical…point the finger
and run! Needless to say I am not happy with my 6K investment in the
Diaquest/Panasonic solution. My two cents…
P.S. If u do see this problem occur please let me know.
Thanks, Bill Lundeen 310 451 1608
It could be your cabling and the way you lay your time code. While I never
used QP I have lots of experience using a DQ system and do know that it is very
very sensitive to any problems in the signal timing, genlock/sync, and the
position of the time code on the tape. There are several ways to wire the
thing so you might experiment. Things to try would be sourcing your sync from
the targa+ vs. the DQ board. Both wiring methods should be in the manual.
Usually a vertical jump in the picture is genlock related. Unfortunately the
nature of the beast is that any experiments will be very time consuming. To
clear the deck of any guilt try to do some insert edits using an edit
controller. If OK then you know the deck is working properly.
Don,
We get strange results when we run our VTR setup batch file twice. The tape
will jump, sputter and drool…
The batch file does TMODE 11, TARGEDIT (with variables to turn on genlock and
set the source to S-VHS), INIT and SONY422.
You mentioned genlock problems: could the TARGEDIT statement recommended in the
Diaquest manual be part of the cause?
Well Donald to be fair, the PAR is a very good value for the money
but if you've got a DQ with QuickPass and an AG-7750 I'd enjoy it.
Its a hot setup. If you were in a position to buy new you'd might save some
with the PAR but there are a lot of things to consider like the fact that SVHS
is typically 400 lines of resolution so the PAR is overkill unless you're going
Beta SP in which case its kinda marginal. Add to that the increased render time
for a resolution its questionable you're going to see and …
you get the point. <g> Like most things there are pro's and con's.
Usually if its a genlock problem the DQ squawks and won't let you
record. (Also lets you know on your monitor.) I haven't typically used targedit
except for adjusting phase. But you might try just using TMODE 11 6 as that
enables the TARGA input to genlock among other things and then run Sony422.
Best just to reboot, rather than reload the TSRs especially when using QP as
its operating in the less than stable Windows environment and the Diaquest
looks for an open comm port as opposed to being assigned one.
Hope this helps.
John
John,
Thanks! TMODE 11 6 is not documented in my T+ manual. We'll give it a try.
Here's the way I used to do the DQ process.
Hook up the Targa+ sync out to the reference in on the DQ board. Feed the
Black Burst out from the DQ to the video in. Run Init then TIMECODE. Hit
Record-Play and stripe your tape end to end.
For recording animation rewire as follows:
Keep the targa+ sync out hooked up to the ref in on the DQ board. Remove the
B. Burst cable from the Video in on the VCR and replace with a Video out from
the targa+. Run TMODE 11 then your DQ422 then launch 3DS and record from the
3DS software in the keyframer. If you use action animator the setup is
somewhat different. I found thet the 3DS VTR was much easier to use.
When you run Tmode followed by targedit, I believe you just overwrote the
Tmode. I thought the targedit would write a batch file that could later be run
to init the targa+ for special setups. Simpler to just run TMODE 11 or TMODE
11 6.
The trick is to get the time code striped in sync with your video tracks. The
method using DQ time code was found by me to be troublesome so I switched to
using Targa+ sync and never missed a frame after switching. Also be sure your
VCR is in the "edit" mode.
Don,
Sounds like good advice. I might your rewiring suggestion for blacking. I
haven't tried it yet, but the QP software has a "blacking" option on the menu
— I wonder how that would be different than the method suggested by Diaquest
in the manual?
I am not sure what was happening, but if we ran that BAT file twice, all hell
broke loose on our tapes. As long as we haven't done that, our system has been
fine.
–Donald
I recall having problems with many skipped frames using the wiring system in
the DQ manual which used DQ sync. Using the sync from the targa+ board solved
it. Which ever way works, I do know that the two boards MUST be genlocked to a
common sync source during the time code stripping process.
>>blacking the tape…
Don't forget the sage advice you once gave me – always FF & Rewind a new tape
before blacking. And from someone else: never use the first minute or so of
the tape.
If you really want to give away your DQ then I'll take it. I'll be out of town
for a week so just email where to send the check and I'll do it when I get
back. I hope I never have to single-frame again, but I've got a borrowed
DQ-50P now that I'd like to give back.
JKJ
You got it! see your E-mail.
Should have known, someone with an AT Vista would want it.
I have done all the cable experiments that can be done. I had a Panasonic rep
come to my loc. and verify cabling and sync. He found nothing that helped me.
The interesting thing is that the problem is evident in some anims and not
others. Diaquest said they saw this also and think it depends on the scene,
ie:colors/lighting. Sounds like doubletalk to me. Anyway thanks for the
feedback. This is one of those "guess i just have to live with it probs."
bill
Ugh!
The only problem that we have had so far (AG 7750/DQ422+), is that if we
accidentally load the control software (SONY422.EXE) twice during a session
along with other commands to initialize and setup the Targa+, we get completely
whacked out recordings. We could be seeing the same problem? I haven't
tried digitizing yet, but so far I have discovered that I don't need any of the
other command-line setup stuff with QP (except TMODE for the Targa+) and the
recordings look great and have gone without a hitch.
***load the control software (SONY422.EXE) twice during a session***
nope…not doing that.
I also have a DQ Quickpass, and I sometimes have the system drop a
frame or get out of sync. Usually, it's because some other program
(or network user) is trying to use the machine's resources at the
time that QP is laying off to tape. We have a lantastic network, and
if someone is trying to read or write a file while laying off, that
screws things up. Your problem may be slightly different, but the fix
should be similar: we let the first layoff finish, and find the first
glitch (say, frame 450 of 1500). We then start laying off at 450, and
usually the machine calculates the same QP parameters, which means
that if only one pass had gotten out of sync, it will be fixed as the
machine lays off one pass. (Hope this isn't too confusing).
As far as the overall PAR vs QP debate, there's just no contest. PAR,
MAX, Targa 2000 are all great tools for laying off stuff where
pristine quality is not an issue, but my clients, who edit using beta
SP source, would never accept the quality of the compressed image in
a "braodcast quality" edit.
That's not to say that the QP is a great product; we use it because
it's what we have, and I haven't seen a real alternative, but the
software is buggy, and doesn't include support for alpha files (8-bit
targas), looped animations, or even auto head & tails. The Mac
software is much better; the stuff in windows looks like a beta
product that was never finished.
I understand that VLAN has support for a QP-like feature, but I
haven't tried it yet.
*** if only one pass had gotten out of sync, it will be fixed as the machine
lays off one pass. (Hope this isn't too confusing). ***
Understand. I will try that to see if it will fix my case.
*** As far as the overall PAR vs QP debate, there's just no contest. ***
I agree.
*** That's not to say that the QP is a great product ***
I agree with that also
The best alternative to quickpass or single frame recording is an Abekas or
Accom digital disk recorder (no compression). They are fast, efficient, don't
drop frames, don't get worn out heads, but do cost a bit more than Diaquest's
stuff. Still, at $11k for the A65, it's not completely out of reach to those
in need of very high quality component real-time playback.
John Tissavary (LUNA cie, inc)
i have been using qp for a month now and really like the time savings it gives.
the only thing i use the par for is rotoscoping, it does a nice job there. have
fun with it , it definatly worth the money!
sherwood