#PAR errors
35 messages in this thread
Hello – I've been experiencing similar problems to those described by
others here on the forum and wanted to post what I've found, so far.
When I render out of 3DS striaght to the PAR I do not have any
problems (other than getting my gamma where I want it). When I render
from other software and then copy to the PAR, either from the command
prompt or from within the PAR interface, each individual file looks
fine and can be displayed correctly, but upon playback the image
breaks up into green checks and static (including audio static even
tho I'm going video-only into my TV monitor). If I pause or stop, the
image suspends as broken up. When I advance 1 frame or go back one,
the image returns to clarity. Returning to the frame I paused on, it
looks fine, now. When I take the *exact same* images into 3DS (via
Video Post) and re-render them to the PAR directly, I can play them
back smoothly with no problem. Now, the images are not rendered with
fields, but when I load them into 3DS I re-render without fields, so
that should not make any difference. Of these 3rd party images, some
have been taken into Photoshop and tweaked and resaved and some have
not, but they behave the same way. I was initially concerned that I
have a hardware problem developing with my 3-week old board, but
clearly it's a software problem with the DOS copy function in the PAR
driver set – a problem that does not exist in the 3DS driver. I have
posted this on the DPS BBS, as well, FWIW. Hopefully this tidbit of
info will help DPS and, at their behest, Gus fix the problem, toot
sweet. 8)
David Taffet
P.S. Otherwise, working with the PAR and the TBCIV is extremely easy, fast
and… FUN! Video capture is WAY cool with this setup. Jeez!
Ok, first of all, there is no such thing as a PAR driver for 3D
Studio. There is no difference whatsoever saving a Targa file from 3D
Studio or from the command prompt. All 3D Studio does is to create a
targa file on what it thinks is a DOS drive. The same is the case
when you simply COPY it from the command prompt.
What causes an animation to go berserk as you describe is lack of
throughput from your PAR disk. If your PAR disk can pump 3 megabytes
a second and 30 frames worth of video is more than that, the PAR
hardware will get lost. That's what the Block Limit is all about.
Run PARTEST and check what's the throughput of your PAR system. It
will give you a number between 2 and 3.5 megabytes/second. Divide
that by 30 (frames). Let's assume you had an even 3meg/sec. That
gives 3,145,738 / 30 = 104,857. That means your frame size limit is
104,857 bytes. Each PAR block is 512 bytes long. If we divide the
frame limit by the block size we get the block limit. That is,
104,857 / 512 = 205. In this scenario, if you have the block limit
set to anything greater than 205 it will blow up just like you
described.
Also note that the throughput decreases as you move into the disk.
That is, if you have a lot of stuff on your PAR disk, the block limit
will reduce for the animations at the end (closer to the center of
the disk). That's why PARTEST gives you a throughput check for the
entire media. Check what you got at the beginning of the disk and
than check what is like at the end. If you plan on creating humongous
animations or if you are about to create one on a disk rather full,
you should calculate a new block limit accordingly.
Home work: Go and check what's you block limit is set for. Run PARTEST
and let me know what's the throughput of your PAR disk (beginning of
the disk and end).
Gus,
I ran the Partest and the "DMA" test bargraph shows >3.6 in all areas.
I did the math as you demonstrated and found that my block limit should be
about 235 (being conservative). I've been using 240 and I only have
intermittent problems — most of the time everthing plays fine but sometimes
after a "join" or "duplicate" or an optimize, the .ani's go bad on me.
Also, wouldn't it be a good idea to have the software automatically set the
block limit maximum — after a partest? Or at least warn the user not to exceed
a particular limit?
Alec Jason
Make sure your drive isn't getting hot. I had similar problems after a
Micropolis drive got hot. The problem didn't go away after cooling the same
drive. I had to replace it.
Ed,
PMJI, << Make sure your drive isn't getting hot. I had similar
problems after a Micropolis drive got hot. The problem didn't go away
after cooling the same drive. I had to replace it. >>
Just out of curiosity I don't have a PAR yet and I have heard about a few drive
overheating problems on the forum. If this would happen to me would the drive
be *replaced* for free under the warranty or would *I* have to buy a new one?
Thanks,
Mark Yankee
Ed,
My drive does not get hot. I have an 8 inch fan blowing directly on it so it
has never been hot.
Thanks,
Alec Jason
Regarding the hot drive thing: In my case this is not the issue. In one
session, without turning off my CPU or dumping ice water in it, I can copy
files to the PAR, have them play like crap, then render the same ones to the
PAR and have them play fine, whether I delete the first try or not (i.e.
whether the second anim is closer to the disk interior or not).
David Taffet
The only difference between rendering from 3ds and copying from dos is if you
use the PAR pxp to control the block limit in 3ds. If the block limit in the
PXP is different from the block limit that you have set in dos, you will get
different results, otherwise everything is exactly the same.
Brick
Make sure Brick gets this message. I can't do much about PARTEST.EXE
nor PAR.EXE. I also think it would be a good idea to have PARTEST
providing the block limit. I don't use the PAR program much. In fact,
I don't think I use it at all. I'm not familiar with the join,
duplicate, nor optimize options. I can't tell if the problem is due
to your block limit or because of some flaw in either of the
functions above.
BTW: 3.6M = 245
i.e. 3.6M = 3,774,873 bytes / 30 / 512 = 245
1 meg = 2 ^ 20 = 1024 kbytes = 1,048,576 bytes
1 kb = 2 ^ 10 = 1024 bytes
Gus,
I _do_ realize that you're not PAR tech support but . . .
I was going to back up my PAR drive files to DAT tape but the .ani
files (and the .tga's) all show up as ".tga" files when I do a dir on
the PAR drive! When I'm running the PAR software, all the files show
up as .ani's or tga's and work fine (for the moment) but in dos all
.ani's are shown as .tga's of 1.08 megs.
Que pasa?
Alec Jason
From the DOS prompt, type "PARDRV /?". It will give you a list of command line
options. Two of them set the output mode. A "/P" set to PAR mode (.ANI and
.STL). A "/T" sets to Targa mode (.TGA). You need to set to PAR mode in order
to backup the files in their original format (otherwise you get just a single
Targa frame).
Gus,
I used the "/p" switch with Pardrv but now what? The files are still in tga
format. Do I have to export them back to tga's on a dos disk and then re-import
them?
Thanks,
Alec Jason
If you run PARDRV -p and you do a DIR of the PAR drive, the files should (has
to) be *.ANI and *.STL. Use -v (verbose) to see what the settings are.
For information sake, the files within the PAR are always in PAR
format. That is, they are always *.ANI and *.STL. When you set the
driver to Targa mode (using the -t option), the driver just responds
to queries telling DOS the files are *.TGA. They only get converted
when you read them out. That means, when you copy a file out of the
PAR to a local disk, the driver will do the conversion in memory
(that's the reason for that huge buffer) and give you a Targa file
instead.
So, if the driver is set to Targa mode and I do a dir, I get:
——————————————
[C:\]>dir e:
Volume in drive E is DPS_PAR-S0
Directory of e:\*.*
CACTUS TGA 1082898 10-11-94 3:13a
PAIN0000 TGA 1082898 12:00a
CHEVY TGA 1082898 10-13-94 11:13a
SPMTE1 TGA 1082898 10-17-94 12:36a
TEST TGA 1082898 10-17-94 12:38a
5,414,490 bytes in 5 file(s) 5,570,560 bytes allocated
456,720,384 bytes free
——————————————
now I type:
——————————————
[C:\]>pardrv -p -v
Digital Processing Systems
Personal Animation Recorder Driver V 1.6 (486) – NTSC System
Program Produced for DPS by Pyros Partnership, Inc
(c) Copyright 1993, 1994 Gus J Grubba – All Rights Reserved
– Animation mode engaged
– Chroma filtering disabled
– Noise filtering enabled
– Output mode is PAR format <*********** this is what I just set
– Blah, Blah, Blah…
Resident driver updated.
——————————————
Now I do a dir again:
——————————————
[C:\]>dir e:
Volume in drive E is DPS_PAR-S0
Directory of e:\*.*
CACTUS ANI 205824 10-11-94 3:13a
PAIN0000 ANI 35950592 12:00a
CHEVY ANI 518656 10-13-94 11:13a
SPMTE1 ANI 503296 10-17-94 12:36a
TEST ANI 1005568 10-17-94 12:38a
38,183,936 bytes in 5 file(s) 38,273,024 bytes allocated
456,720,384 bytes free
Ahhhh . . . it's a "-p", not a "/p" !
I've got everything working now. Thanks VERY much for your detailed help.
Alec Jason
Alec
I'm just posting this here 'cause it was the last PAR thread I saw.
I'm getting corrupt .tga files on the server when netrendering if: the PAR
(which is on the server) has been running previously. Note that they are
corrupt Before (and After) going to the PAR. If I reboot to unload the Par
software, there is no problem. I didn't change anything (except /B:1800 instead
of 1500) when I went from 1.09 to 1.30. I can duplicate this at anytime, but I
obviously don't care to keep experimenting.
What, pray tell, have I missed or done incorrectly? Must be a conflict
somewhere…
Thanks JB
Lantastic 6.0 2 p-90's 2-66's
James,
Boy, that's a new problem. Never heard of that one before.
I did send my PAR board back to DPS but the tech called me and said the board
is working fine. As I described the details of the problem, he asked me to
check the rev date on a chip on the Micropolis drive. He then told me that the
problem was being caused by the drive — and further that DPS had sent an
engineer down to Micropolis to prove to them that some of their drives were not
operating properly. I wasn't happy to hear this because, as I told him, I knew
that when I called Micropolis and told them about the problem they would say
they never heard of it and that it must be the PAR board's problem. I even
asked him for the name of someone at Micropolis who knew about the situation.
I then called Micropolis and actually spoke to the right guy. He, of course,
told me the exact OPPOSITE: that the problem was the PAR board and that the DPS
engineer who had been sent there was fully aware that there was no problem at
all with the drive's functioning!
So here I was, once again, lost in that area between light and shadow, between
truth and superstition, between tech support and tech support: in the PC ZONE
where no one really know what's going on; where everyone can blame anyone else
for anything.
The Micropolis guy was nice enough to offer a replacement drive just for heck
of it and I've installed it and everything seems to work fine — for now. I
asked him to please call DPS and get this thing settled.
I dunno . . . I just work here.
Alec Jason
This is to everyone..
" I also think it would be a good idea to have PARTEST providing
the block limit"
The reason that we don't have any software setting the block limit
automatically is because there are several reasons not to.
1. It says EVERYWHERE in the manual to use 240.
2. I often save animations that I know I am going to use in compositing or
rotoscoping at very high block values, this helps hold the integrity of the
image. For instance if you KNOW that you are going to use the animation only
for rotoscoping or compositing, then use a higher block value. The image will
not be playable, but you will get better quality when pulling the frames back
into 3ds.
3. There really is no way to get the highest performance from a program like
Partest. In short.. it lies and can only be used as a guide. So setting the
block transfer rates would be marginally accurate. You could test the drive
completely which would take several hours, but isn't it just easier to set the
block limit to 240?
Brick
Thanks again, Brick for more tips.
I like the tip for rotoscoping. To clarify this, when you say you set the BLF
"higher" I assume you mean 255. Or do you mean even higher? I was under the
impression that the upper limit was 255 even though the software settings go
over 500.
So taking your advice I should use 255 BLF and the highest QF possible when
recording frames from video. Also turn down the saturation to achieve higher
QF's. I understand that this roto.ani may not play but will do for 3DS texture
maps.
" I was under the impression that the upper limit was 255"
It is. The extra few blocks help a little. If you want to be really tricky you
could store the images as stills. Stills do not adhere to the 255 block limit.
Brick
>> If you want to be really tricky you could store the images as stills <<
I was thinking about doing this a few days ago. Is there a limit to the number
of stills that can be stored in a directory (excepting the natural storage
limit of the drive)?
— James — MAP —
" Is there a limit to the number of stills that can be stored in a directory
(excepting the natural storage limit of the drive)?"
Yes, it 'was' around 3000 frames.. I will look into this. This limit was
scheduled to be removed some time ago.
Brick
The limit is 2048 files per directory, that is, the PAR directory slot has 2048
entries and there are 256 slots for directories (500k files limit).
Thanks Brick and Gus,
2048 is sufficient for my needs. Time for me to start building some IFL files
. . .
— James — MAP —
Brick,
I am also having problems with the par and corrupt TGA files. Except my par is
on a workstation. Even TGA files I convert from Par native ANI files give this
error. The common Link seems to be Lantastic. I hope someone Knows a Work
around I have to deliver an animation to Autodesk U. today.
help………………Kevin
Have you ever checked the integrity of your lantastic network? Network
corruption of large files is a common problem..
Brick
Gus,
Great! I appreciated the tip on how to calculate the block limit. I
just recently lost almost half of the frames on a large animation
after an optimize operation. After reading your message to David and
the description of his problem, I realize it had to do with the block
limit as my PAR drive was almost full. The long animation was
re-written where I assume to be the the tracks close to the center of
the disk using an improper block limit. After adjusting my settings,
everything seems to be back to normal.
Once again, I am convinced that the support offered here is absolutely
priceless. I am constantly blown away!
Thank you and thanks to all of the people in this forum who take their time to
offer help.
-Hugo
Gus – I will check what you suggest and get back to you. I clearly
don't know how the programming was done, HOWEVER, I'm talking about a
30 frame animation where each frame is about 700K on a DOS drive. I
have 99% of my PAR drive empty and have optimized it till my brains
fell out. The same 30 frames play fine when rendered from 3D and play
like crap when copies from the command prompt or the PAR interface.
This device is NOT loaded down. I do my animation in my free time,
after work and between the rest of my life and my wife's life and
simply have not had the time, in 3 weeks, to fill this thing up or
get close to the interior of the drive. There's one other animation
on there and it's also 30 frames. If my comments sounded like a
criticism of your programming, that wasn't the intention (even if it
was the result). I'm really just reporting what I have found and can
consistently reproduce and want to not be there. If there's *really*
no difference *at all* in the way files get to the PAR from within
3DS or outside, then this is very mysterious, indeed!
David (I'll get back to you) Taffet
I should know better than to cry "bug"… In my own defense,
inconsistent results helped lead me astray. It does say in one
sentence on page 40 of the documentation that an animation will break
up if the block limit is set too high, but it didn't stick in my
mind. Also, when I was rendering from 3DS, I was still using the same
very high block limit as when copying from DOS. Somehow, for some
reason, that works basically fine; the only symptom being that the
first 3 frames of the animation repeated when ever it replayed. I had
come to those settings when capturing from videotape. Replaying of
those captures worked just great. No problems at all.
Specific findings:
PARTEST's DMA test indicate thruput of 3.75 – 4.0 across the board
total disk size 975.1 MB
free space 914.8 MB
Based on your calculations my maximum block limit is 256.
Animation size/# of frames = 93.5 KB (the animation in question)
I had my block limit set to 350 (I know, I know… now)
Q factor set to 20
These last two were left over after testing the video capture function. The
sequence I captured played back clean as the original, after I had arrived at
these settings. I did not try to refine them further after getting output that
satisfied me. I guess I assumed that animation recording was less demanding and
that if capturing worked at that setting, so would the other.
So why could I render from 3DS at these settings and have good output?
Pardon me for seeming agitated in my first message. I was, of course,
but can see it was my own problem. Had I looked further earlier I
probably would not have even posted the message.
This is weird. If your driver does 3.75M/sec, it should handle even
the maximum block limit allowed. 3.75 yields a block limit of 256 as
you noticed. Also note that the maximum block limit is 255! There is
no reason to set it to anything higher than that as it is ignored.
Just leave it at 255. Also note that, unless you have a special
reason, you should always leave the Q Factor at its max which is 23.
The driver will automatically reduce it if a frame compresses to
something greater than the block limit (going back up with frames that
allow better compression). The Q Factor should only be changed when
doing real time recording with the TBC.
My original alteration of the Q factor was when I was real time recording. It's
good to know that 255 is the limit, since the software lets you set it WAY
above that. I'm also glad you said "this is weird". At least I'm not *totally*
off my nut. Regardless, however, your pointing out that my block limit was too
high got me to put it where it works for copying my non-3DS files and I guess
that's the most important thing.
Thanks for the feedback. If anything strikes you as a possible explaination,
let me know if there are any test you want me to run to test the theory….
David Taffet
Hi David,
I'm just jumping in with a question, how did you manage to capture
video at Bl350, Q20. I never can get better than 250/14.
THANX
Theo
Theo – I was testing the capture function and was not happy with
psychedelic-looking artifacts I was getting, so I started fiddling with my
block limit and q factors. I was intending to make large adjustments and then
refine them, but I guess I got so excited by getting a good capture I never did
refine them. As to how I got a capture at that setting, I don't know. I just
did. Maybe my thruput of 3.75 or better is what allows it. I also have the
2210, rather than the 2217. I don't know if that has anything to do with it or
not.
DT
Thanx David,
I tried out your settings, but i could only capture 120 frames and then
i had to drop the Q-factor back to 14, which worked ok for the 3600 frames.
Maybe your a lucky guy !
CIAO FOR NOW
THEO
>>Maybe your a lucky guy<<
Well, that's what my wife tells me <g>
I grabbed a solid minute of video at those settings. Looked great.
DT
David,
You're even more lucky than i thought if you can combine a wife
with this kind of work.
Theo