October 1998: Please, no more email! I know Iomega doesn't have an email tech support line, and they charge for phone calls. I know you're frustrated if you can't get your Buz to work. But please, pretty please, don't email me about it. If I can say it in the kindest possible way, I don't care. It does suck that Iomega's lame tech support can't figure out how to turn on a PC, but I can't help them or you. I'm still getting over a dozen "Help me with my Buz!" email messages a day, and I have to just toss them. If your Buz doesn't work great, then I really hope you get to the bottom of it, and I hope you find this FAQ useful. That's really the most I can do for you. Any and all buz-related email will be tossed. In fact, if you use "Buz" in the Subject, I won't even see it.

Passing the Buck
Eric S. Raymond once said that "when you lose interest in a program, your last duty is to hand it off to a competent successor." Well, it's time to find that successor for the Buz FAQ. If you're Perl-savvy, into your Buz, interested in keeping this FAQ up to date and receiving the tons of help requests and fan-mail, send me a note!

Index

1. About this page
2. Reversed field ordering, bad interlacing, and vertical "Jitter".
3. Buz and System Overclocking
4. External Zip drive does not work when connected to Buz SCSI port.
5. After installing White Pine's CuSeeMe software, Buz lost its analog video output.
6. Microsoft Netmeeting doesn't work well with Buz.
   • Pure speculation follows
   • Can I force RGB?
   • SoftCam
7. There are black stripes on the left and/or right sides of captured video.
   • Is this a problem for output to tape?
   • When is this the Wrong Thing to do?
8. Problems capturing video or still images in RGB mode
9. Dropped frames on recording or jerky playback.
10. There is no video output from the Buz analog output jack.
11. Strange bursts of video noise appear on the analog output during rendering.
12. AVI video files are limited to 1GB in VideoWave and other programs.
13. What's this I hear about a 'defective chip' or recall on the Buz?
    • Are all boards with these chips defective?
    • What are the symptoms?
    • I suspect mine's busted. Who do I call?
14. No analog video out when using Paradigm Matrix MJPEG Codec.
15. Does Buz work with Ulead's MediaStudio 5.0?
16. MediaStudio 5.0 stops capturing after 20 to 49 frames.
17. My Iomega Jaz drive seems slow -- it can't keep up with the video.
18. Connectix QuickCam and CuSee-Me conflict with Buz.
19. iVisit videoconferencing software gives errors or no color with Buz.
20. I upgraded my video card, and now I lost Buz Overlay support or other features.
21. Microsoft Internet Explorer 4.0 (IE4) conflict with Buz drivers.
22. Buz crashes when creating field-rendered AVI files from some animation software.
23. Buz output is okay on computer screen, but records poorly on VCR.
24. Microsoft Active Movie, Media Player, or 'mplayer' crashes with Buz movies.
25. Buz software conflicts with Adaptec DirectCD.

    Installation and Driver Problems

26. Hosed the drivers on a botched install?
27. Windows95 reports "Device Conflict" between the PCI Bridge and Buz devices.
28. Windows95 Device Manager lists an "Unknown Device: PCI-to-PCI Bridge"
29. Problems with video cards using S3's Virge chip
30. Problems using Buz with motherboards using the Intel 440BX chipset.
    • The 440BX Fix
31. System crashes if I change the Buz Multimedia IRQ assingment.
32. Error message: "Vertical Sync Interrupt Lost". No video captured.
33. Problems with video cards based on the S3 Virge chipset.
34. MPlayer crashes when playing Buz movies (Trident Chipset?)

    Adobe Premiere Issues

35. Rendered video (transitions, effects, filters) in Premiere degrade quality.
    • Render Everything
    • Counter-filter
    • Use the Paradigm Codec
36. Adobe Premiere v4.2 crashes after capturing video from Buz.
37. The preview window in Adobe Premiere does not work correctly.
38. Adobe Premiere 4.2 gets a fatal error on "Make Movie".
39. Does Buz work with the new Adobe Premiere 5.0?
    • Disable DirectShow!
    • Rendered output has reversed field order
    • The Preview Window doesn't work
    • The Timeline cursor does not update the Monitor window
    • Frequent crashes during Preview rendering
    • Crashes during movie rendering with Buz MJPEG output
    • The analog preview frame disappears after a few seconds
40. Adobe Premiere sometimes re-renders my entire MJPEG movie. Why?
41. Still-frame analog output vanishes five seconds after scrubbing.
42. Using Zoran's "961" drivers with Buz and Premiere 5.0

    MGI VideoWave Issues

43. What is MGI's Technical Support phone number?
44. Produced video never looks as good as my source files.
45. MGI VideoWave incorrectly estimates the production output size.
46. I can't hear my live audio during preview or recording, but it is captured OK.
47. VideoWave MPEG output files are rejected by Video CD applications
48. My good PAL video files mysteriously stopped playing correctly.

The unofficial Buz FAQ is over at http://www.trix.com/buz/faq.html . This page lists common problems users have reported, and potential fixes and workarounds for them.

If you know of common problem, a fix to a problem, or a way to make a difficult task more workable, go ahead and submit it for inclusion right here. Hopefully as Iomega becomes aware of how common some of these problems are, they will be more likely to fix them, or, in the case of the Interlacing, admit they exist.

This was perhaps the most serious bug in the first shipping (0.9.4 Beta) release of the Buz driver software. If you still experience incorrect field ordering or other interlacing artifacts at resolutions higher than 352x240, then you are probably running drivers older than Version 1.2. Double-check your version numbers.

I've pared this section of the FAQ down a bit. Now that a public fix is out, there's no need to go into as much detail on the field order problem. The full details and symptoms and examples are still available if you need them.

Most Pentium motherboards run the main system bus (CPU and DRAM) at 66 Mhz. The PCI bus runs at one half this clock rate, for a standard 33 Mhz. Some users accelerate the speed of their machines by increasing the system clock speed beyond 66 MHz to 68, 75, or even 83 MHz. On most motherboards, the PCI bus still runs at half this speed, so all the cards run faster than the normal 33 MHz. So long as the cards can handle this, it's a Good Thing. See the Overclocking Guide at Tom's Hardware Page" for more info on that.

Results with overclocking the Buz have been mixed. By own Buz works fine at 66 and 68 MHz system bus speeds (close to the standard 33 MHz PCI bus). But at a system bus speed of 75 MHz (37.5 MHz PCI), my Buz SCSI adapter crashes or resets the system. The Buz video segment works fine, even at 75 MHz. Weird.

Other users have reported in rec.video.desktop better success with overclocking, even at the 37.5 MHz PCI rate. It could be just luck-of-the-draw, or other system components. It's thought that the NS PCI-to-PCI Bridge chip is responsible for this problem, since the stand-alone Advansys SCSI cards are generally more friendly to overclocking.

One user has reported that it was necessary to turn OFF the Zip termination switch to make it work correctly with the Buz. If you have problems with the external Zip, this is worth a try, but I would recommend trying the correct arrangement (Zip Termination: ON) first.

CuSeeMe installs its own MJPEG codec, which replaces the operation of the standard Zoran/Buz codec. The result is that no MJPEG video is output to the analog video port. There is a tedious procedure to switch between installed codec files, but you're probably best off just re-installing the Buz software and using that one. (Please advise if you have a cleaner/better solution.)

Even the latest version (2.1) of Microsoft Netmeeting doesn't work well with Buz. The capture rate seems to be much slower than normal. On a fast machine, Netmeeting captures around ten frames a second for compression, using any simple video capture card (like Hauppauge's WinCast). With Buz, this capture rate can slow to two frames a second or worse. In addition, the CPU becomes heavily loaded, impacting the video receive quality as well.

Pure speculation follows

July '98: There is a new SoftCam version available (1.0.1). Luminositi worked with Iomega to improve the product. The new version should improve NetMeeting's performance significantly. Give it a try!

This is because the Buz captures the entire NTSC/PAL video area, including a portion of the screen that is not normally visible on a TV screen. Depending on the video source, up to 10% of the screen at beginning or end of each video row (scan line) may be unused. Normally, a TV or video monitor cuts off a significant portion of the top, bottom, left, and right edges, showing only the center portion of the picture.

This is normal and good, because it gives the video source some flexibility in where it starts and ends the video region; the TV hides the fringe areas. But Buz captures it all, so you see the black border areas that don't show up on TV. It's not an extra border or damaged video, you're just seeing more of the picture than you normally do.

Is this a problem for output to tape?

The black or noisy borders become a very serious problem for several video transition effects. If you pan or scroll your video segment accross the screen, the black border will become much more prominant.

To avoid the black borders in AVI and MPEG output, you must use software to crop the video segment to a "safe region" containing only the interesting video. The amount to crop will vary depending on your video source, but removing 5-10% at each side is a typical amount. You may want to compare a still scene on the Buz preview window to one on a TV screen to get an idea of how much is typically lost. Unfortunately, VideoWave SE+ has no facility to crop video segments. If that is your only video editor, you have no recourse but to tolerate the black borders.

In the original Buz driver release, RGB-15 and RGB-24 modes had significant problems, both with single-frame capture and video. On some systems, RGB video capture would incorrectly report a missing video signal, or give only black frames. Still image captures would sometimes return an old video frame.

These problems appear to have been completely fixed with Iomega's Buz Driver 1.2 release. I am pleased to report that my system now captures RGB-15 and RGB-24 formats without error, even in VideoWave.

This has several potential causes. The first (and most likely) is simply that your system can not keep up with the data rate you selected. See the Capture Rates question in the FAQ.

The Buz may also drop frames if other processes are running and interrupting the capture process. Be sure no other active Windows tasks are running during video work. One good way to do this is run the Windows program "wintop" -- part of the Windows95 distribution. This will show every task running, and which ones are using CPU time. If you notice any extra tasks using CPU time, these will interfere with capture and playback. Every non-essential task should be stopped for video work.

Some users have reported fewer dropped frames after moving the Buz Multimedia Device to its own IRQ channel. If your Buz is currently sharing its IRQ assignment with another device, see your BIOS documentation for instructions on how to control or override the assigned interrupt settings.

Of course, it's easier for Windows to stream video to hard disk if your free blocks are not fragmented. Be sure to run Windows "defrag" often to keep the free space contiguous.

During capture and playback, keep as still as possible. Do not select other windows or move the mouse cursor around. Anything that causes processor or hard disk activity can impact your throughput.

For the Buz to generate video on the analog composite or S-Video output jack, the video segment must be:

• An AVI file (not Quicktime).
• Buz MJPEG format only (not RGB, or uncompressed).
• One of the three "standard" resolutions. For NTSC these are:
  • 176 x 120 QCIF
  • 352 x 240 CIF
  • 720 x 480 FULL
  (For PAL format, these resolutions are slightly higher.)

If your video is MJPEG at one of those standard resolutions, then the Buz will generate standard NTSC or PAL video at the S-Video and Composite output jacks any time the AVI file is played back. While MGI VideoWave does not support the specific "Print to Video" function, the result is the same just by playing back any MJPEG AVI file.

If you don't see the video output, double-check your VCR or TV connections. Make sure the VCR is set to "Auxillary" input and so on.

The Buz video output is actually very good, and more stable than the computer-screen playback video! If the graphics window playback appears jerky or skipping, it's quite likely the analog output is still fine.

When the host software peforms frame-by-frame MJPEG encoding or decoding, it uses the Buz hardware to help out with the conversions. Any time the host uploads an image to the Buz, the analog video output goes nuts as the video encoders see the pixel-by-pixel local bus activity on the card. This is a function of how the Zoran chips transfer single-frame data from the host.

These flashes of video do not have a sane sync signal, and are generally confusing to an NTSC monitor or tapedeck. It's important not to leave the recorder running during any rendering, since the VCR will try to sync and fail, leaving a mess of a signal on the tape.

Unlike most Zoran-based cards, Iomega choses not to blank the video output during frame rendering. It's unknown if they consider this a bug, but it's annoying at the least.

You can create and use AVI files up to a maximum of 2GB. To get the full 2GB file length, you must set the "Audio Interleave" size to "1 frame". The default is usually "1 second". With 1-second interleave, you will only be able to edit or play the first 1 GB of the file.

Unfortunately, it appears VideoWave SE+ allows only 1-second audio interleave, so it is limited to capturing and producing 1GB AVI files. If you find a workaround for VideoWave to reach 2GB, please email.

Apparently, there is a batch of Iomega Buz cards that has a potential problem with the Philips video decoder (input) chip: SAA7111A. Chips manufactured with a date code of btD9801V1 could cause the board to fail at boot up or during initialization. If you have a defective board, Iomega will exchange it for you at no charge.

Are all boards with these chips defective?

This is perfectly normal. The Buz only generates analog video output when the Buz hardware is doing the MJPEG decoding. If you use another codec, it doesn't get a chance to decode the video.

I've only received one user report form someone using Buz with MediaStudio 5.0, and he says it does not work. It will only capture (exactly) 49 frames and then nothing more. A reboot is necessary, the problem is repeatable, and other video applications work well. See below for the fix to this problem.

July '98: Another other user has reported that MediaStudio 5.0 is working with Buz and version 1.2 drivers. However, he reports that MediaStudio suffers from the same field-reversal problems as Premiere 5.0. All rendered video has reversed fields. Hans van der Lint offers this partial workaround:

In Media studio you can specify in which field-order to render and in which field-order the imported clips are. My captured clip's are in field order "A". To avoid the problem I must specify the field-order of the rendered clip to "B". The drawback however is that the transitions look fine, but it takes hours to render an entire project (every two fields must be swapped, so the "fast-render option" won't have any effect). I admit, it's clumsy, but it works.

To fix this problem and allow MediaStudio to capture video, change the Number of Buffers in the Advanced Capture Settings from the default 522 to 32. (If you have problems with 32, try 16.) Thanks to Joshua Thompson, Theodore Cuff Jr. and Elayne Bouffler for this fix!

It turns out that any video capture program will barf on Buz with the number of buffers set this high. Ulead seems to be the only one that has it set that high by default.

The most likely cause of this is the Jaz setting "Verify writes". You can find it under My Computer / Jaz drive / Properties / Startup. You should deselect this option for the best performance.

Of course, just like any other hard disk, make sure the Jaz disk is defragmented. Iomega rates it at 3 MB/sec, which should be good for up to 100k/frame real-time video, assuming the rest of your system is up to the task.

Apparently, the QuickCam and Buz will struggle of MJPEG codec control. Larry Munson got it working under Windows98 and submits this fix (thanks!):

Edit system.ini msvideo settings to allow multiple devices....change
msvideo= to msvideo1=,msvideo2=....etc.

Example:

MSVideo.VfWWDM=vfwwdm.drv
msvideo=qccolor.drv
msvideo=h22capt.dll

Changed to:

MSVideo1.VfWWDM=vfwwdm.drv
msvideo2=qccolor.drv
msvideo3=h22capt.dll

iVisit from iXL is a downloadable videoconferencing program for Windows. It comes from the creators of CUSeeMe and looks very promising. Jason Keltz gives these tips for getting it to work with Buz (thanks!):

The trick is that you can't select "MJPEG" for the video type since the program says that there is no codec available. However, when you select RGB24 it works. The *only* problem is that when I go into it for the first time after my machine has been off, I don't get any video, but the fix for that is to change over to MJPEG, get the error, change back to RGB24 (now you get black and white video), exit the program, and re-enter to get proper colour video, but then it works fine.

Certain parts of the video card driver may have overwritten key Buz system files. If you upgrade or change your video card (or just drivers), and your Buz setup seems damaged, it's a good idea to completely uninstall the Buz software and reinstall it from CD-ROM. Then install the Buz driver update over again.

A few users have reported that installing Microsoft's IE4 has caused their Buz to stop working in VfW programs such as MediaStudio, Premiere, and Lumiere. Apparently, IE4 includes a version of ActiveMovie that interferes with the Buz drivers. The "Preview" option on the right-click AVI menu is also damaged.

So far, the workaround seems to be uninstalling ActiveMovie and installing the older software from the Buz CD-ROMs. Bill Vincent offers this procedure for removing ActiveMovie (thanks!):

Delete the following files from Win98 or Win95 with IE4:

• amovie.inf/amov4ie.inf
• amovie.ocx
• mciqtz32.dll
• actmovie.exe
• amstream.dll
• devenum.dll
• unamie.exe/unam4ie.exe
• mciqtz.drv
• vidx16.dll
• quartz.vxd
• amovie.hlp
• amovie.chm

Then run the 'amovie' file from Buz CD which installs the original version of activemovie.

Several users have reported that the Buz crashes when rendering full-resolution MJPEG video from certain animation software, such as 3D Studio Max, Lightwave, and Imagine.

Megat Hashim has found a workaround for this behavior: Before starting the rendering application, run the bundled MGI VideoWave first. Starting a new VideoWave production and minimize VideoWave. Then, run the 3D rendering application as usual. The VideoWave startup seems to suppress the Buz initialization bug. (Thanks!)

I've seen postings from Buz users that complain of what can generally be described as "strange video". The symptoms are that video captures well, and the AVI files play fine. But when the video is output, it either bad on a monitor, colors come and go, or the VCR won't sync to it. There is some question about whether the video signals being generated at the Buz outputs have some kind of level or timebase problem. Eventually, someone will the right equipment might run into this problem and shed some light on the cause of it. Until then, I have no suggestions or workarounds at this time.

This seems to vary significantly from machine to machine. Some machines have serious problems playing the Buz-generated AVI files from any stand-alone Microsoft AVI player application, such as mplayer. These use the Buz output codec to play the movie and create analog video output. On some systems, they crash during playback, or more often after playback has finished and the movie is over. On my own machine, playing a movie and then exiting 'mplayer' will cause a protection fault in some other unrelated application, which is then closed. Other users report that the entire system locks up or goes to blue-screen. Iomega, as usual, has no explanation, workaround, or bug fix.

Karel Renckens notes that uninstalling DirectCD fixed some persistant problems. Adaptec Easy CD Pro poses no problems.

In case youmissed the "Read Me First" card, the sticker you ripped to open the static bag, the notice on the CD-ROM, and warnings all over the manual, you're supposed to install the software BEFORE shutting down your machine and installing the PCI card.

If you do not, then the PC will come up and look for drivers it doesn't have yet, and probably do the Wrong Thing. No big deal, you just have to remove whatever drivers Windows95 mistakenly installed.

Shut down your machine, pull the card, boot Windows in Safe mode. Go to the device manager by right clicking on My Computer, and pick "Properties". Remove all the drivers for the unrecognized devices and anything else that looks suspect. Shut down, reboot, and install the software. Then you can install the hardware, and it should find everything alright this time.

This is actually not a problem. It's because Windows 95 really can't deal with the concept of a PCI Bridge and mistakingly reports it as a conflict. You can safely ignore it.

The PCI Bridge chip (PT80C525) allows multiple PCI features to be on the same card. Think of it as a PCI expander that lets you plug two cards into one slot. Unfortunately, Windows 95 does not have a way to represent this. It sees the PCI Bridge as being in the same place as the SCSI or Multimedia functions, and reports it as a conflict. But, there is no loss of functionality; it's just an annoying distraction in your Device Manager device display.

Supposedly, Windows 98 is a bit smarter in this regard and will not report a device conflict with PCI bridges. There is really nothing Iomega can do to "fix" Windows 95 in this regard, so we just have to tolerate it until Win98.

This is normal. Windows95 doesn't know what to do with a PCI bridge chip, and has no driver to assign to it. It will be tagged with the yellow question-mark, but it's completely benign. This is 100% normal, and will be addressed in Windows 98.

Zoran and Iomega acknowledge there are some incompatibilities and special circumstances with the S3 Virge graphics chips. See the Iomega Technical Documents for more info.

In addition, Zoran has published this note (thanks to Rob Lohman for forwarding it):

3.3.1 Overlay Problems

In Vidcap, when actual capturing is going on, the PCI bus is used both for Video and JPEG Code transfers. Sometimes the overlay display (NOT the TV monitor) may get corrupted or it may freeze. This is the result of the PCI bus being overloaded by the transfers. To minimize the bandwidth requirements for the Video transfers, try to set the computer's display to 16 bit color rather than 24 (or 32) bit, thus transferring only 2 bytes per pixel instead of 3 (or 4). For most cases, this will give smooth overlay. In Media Player, when playing a clip, the same corruption may happen. Resize the window to a smaller size until the display is smooth.

So far, we have only early reports of incompatibility with Intel's new 440BX (100 Mhz) Pentium chipset. One user reports that Iomega has confirmed the problem.

The 440BX Fix

Edit the file "H22.INI" in your Windows directory. Modify the [H22DRV] section, adding "SupportedPCIDevice6", so it looks like this:

[H22DRV]
CheckBiosForConflicts=0
SupportedPCIDevice0=80867100
SupportedPCIDevice1=80867180
SupportedPCIDevice2=80861235
SupportedPCIDevice3=80861237
SupportedPCIDevice4=80861250
SupportedPCIDevice5=80867030
SupportedPCIDevice6=80867190
NoOvlyReported=0
OverlayTestCrashed=0

Thanks Jeff!

Later news is that this fix does not fix all the problems. 440BX motherboard users have still reported severe problems with overlay and preview. Further, other video editing cards like the Bravado 2000 and Miro DC30+ also have many of the same incompatibilities with the 440BX.

Boris Epelbaum got his Buz working with an Abit BX6 motherboard by doing these things:

• Install all the latest updates from Intel at : http://developer.intel.com/design/pcisets/busmastr/ and at http://developer.intel.com/design/pcisets/drivers/inf_update.htm
• Move to Windows 98 if possible.
• Use DirectX 6.0 drivers.

If you go into the Windows Device Manager, and select Buz Multimedia/Resources, you can see the IRQ that was assigned to it. However, if you select "Manual Settings" and override the IRQ setting, the Buz will crash your system on the first attempt to capture or display video.

You must use the BIOS facilities to change the interrupt assignments at boot time, and leave the Windows setting to "automatic". If your BIOS does not give you a mechanism to manually control the PCI interrupt assignments, then you are probably out of luck. Re-ordering the PCI cards in the slots will often change the assignments and may fix some problems.

This usually indicates a problem with the Buz video interrupt. Check to make sure that it's not conflicting with another device, especially any ISA devices. Try to re-arrange your PCI cards so that it has an interrupt all to itself.

If you're still getting this error, try experimenting with your BIOS PCI settings, especially the "IRQ Activation": 'Edge' or 'Level' trigger. Some users report that the Buz only works with "Level Triggered" PCI interrupts, while my own system works best using "Edge" trigger. Just note your previous BIOS settings so you can put things back if you need to.

(Thanks Rob Lohman)

The S3 Virge video card has been problematic for several users. With this video card, capture and preview resolutions could be limited to less than full resolution at certain color depths. If you are stuck with a Virge-based video card, experiment with your color depth, trying 8-bit and 16-bit modes.

The S3 Virge chip is used on several mainstream video cards, such as the Diamond Stealth series. You may have to open your machine to check if you have a video card based on the S3 Virge chip.

(Thanks Rob Lohman)

Certain video cards seem to crash when using MPlayer to play AVI files on the Buz. One user (Vincent Sanchez) reports that this was fixed by setting Hardware Acceleration to "None" in the system Control Panel / Performance control.

Any "rendered" video in Premiere is degraded in quality from the source material. Even with no filtering, the simple act of rendering frames desaturates, brightens and sometimes even shifts the frames vertically downward a bit. The whites become a little gray, and the blacks are brightened. You can read a detailed analysis of this problem at Josha Beukema's technical Buz page.

To witness this effect, select a relatively constant-looking clip, split it in half, and dissolve it into itself. Or apply any filter with neglible effect. The video portion Premiere renders will have degraded quality compared to the unaltered frames.

Render Everything

The easiest workaround for this problem is to render the ENTIRE movie, effectively hiding the problem by applying the brightness/saturation damage equally to all video segments. This adds enormous delays, of course. MGI VideoWave renders everything all the time, which is probably why Iomega doesn't know about this problem.

Counter-filter

You can download the latest version of the Paradigm Matrix M-JPEG Codec here. Be sure to read the text about "Coexisting With Another MJPEG Codec", since that's exactly what you will have to do with Buz.

This is somehow related to the "Custom Presets" bug in Premiere. Adobe has released the "Project Window Update 4.2.1" which seems to correct this problem on most systems. You can download the update from Adobe's web page. (Use a different update to fix the Premiere LE edition.)

If you have applied this patch carefully, and you still get the same crashing after each capture, please let me know. I'm not sure this fix works for everyone, but it did seem to completely correct the problem on my machine.

This is a known problem, and not fixed by the updated DLL file from Paul Young's web page. Adobe Premiere's preview window displays no video, garbled video, or smears video all over the screen.

It's likely we won't see a fix for this until Premiere 5.0.

This seems to happen when the output size is specified as larger than the input, and uses Buz MJPEG encoding. If you load the "Literacy" project sample from the Premiere 4.2 CD-ROM and try to produce it at 720x480 MJPEG, it will cause Premiere to fail and exit. There may be more to it than this. [No known workaround.]

Yes, but it has several serious problems. I'm still looking for feedback on how common these problems are, and what other people's experiences have been with Buz and Premiere 5.0. Here is an initial listing of primarily my own results.

Disable DirectShow!

1. In the Premiere folder, open the file Prem50.ini if it exists. If the file does not exist, open any text editing program and create a new empty text file named Prem50.ini.
2. Add the following text to the file.

     [override]
     NoDirectShow=1
   

3. Save the file into the Premiere application folder and restart Premiere.

Sometimes it's possible to tease the Buz into playing correctly by quickly pausing and restarting the playback. Other times it won't budge and insists on staying backwards.

Experiments with the Paradigm Matrix MJPEG codec have failed to yeild a workable solution. While it helps to select "Reversed Fields" to compensate for the Buz bug and reduce jitter, the fields are still in the wrong chronological order after rendering. Any motion effects or animated overlays will still be "combed" or distorted, because the fields are not played in the correct sequence.

I welcome any suggestions for a workaround, as this is currently the most debilitating Buz bug in Premiere 5.0.

The Preview Window doesn't work

Note that these preview problems are specific to the Buz codec. Other AVI files (uncompressed or using another codec) will preview and scrub just fine.

Frequent crashes during Preview rendering

In order for Premiere to be "smart" about rendering only the necessary parts of your movie, the production output settings must be exactly the same as the settings for the source clips.

The most common problem is that the compression level is slightly differnt. Imagine if your source clips had a quality setting of 104k/frame, while you pick 113k/frame ("close enough") for your output in "Make Movie". Premiere would re-render every frame of your source clips. If you pick an output quality of 104k/fream instead, Premiere would only render new frames.

In Premiere, if you scrub through the timeline or pause any video preview, you correctly get the still frame both on the computer monitor and the analog video output. However, the analog video output will go blank after only five seconds of inactivity. Moving the scrub marker will refresh the display, but you can not study one still-frame for long. There is no known fix or workaround.

UPDATE: Ingo Rahn has pointed out that this is a Premiere issue common to MOST video capture cards. It could be a video screen saver of sorts. The Miro DC-series boards and FAST video boards exhibit the exacct same behavior, so it's not an Iomega Buz problem. If you wish to report it as a bug or misfeature, please direct it to Adobe. (Thanks Ingo!)

John Nevill has found that Premiere 5.0 works much better with Buz if the Zoran 961 drivers are used instead of the Iomega-supplied libraries. Here are his instructions:

Go grab the 961 drivers from the zoran site http://www.zoran.com/ftp/download/refdesigns/h33/drivers/ Copy the h22capt.dll and yuvcodec.dll into the /windows/system directory and reboot you're machine.

(These are latest version of ZORAN drivers. DO NOT try to install the full set, they dont work with BUZ - you've been warned)

Now full scrub and preview work.

Whats weird about this is the BUZ CDROM install or update patch don't install the yuvcodec.dll (its not on the CDROM), ironically the Videowave SE WILL NOT work if yuvcodec.dll is installed. Now is this a Iomege/MGI thing!

JLN

Any questions about the use of MGI VideoWave software should be directed to:

Phone:	(905) 707-3573
Fax:	(905) 707-3694
Email:	videowave@mgisoft.com

This is true. When MGI VideoWave renders every frame of your file, it does damage to the quality of the frames. Go to the "Rendering Loss Example" page for full details and a vivid illustration.

When using the MJPEG codec for output (Compressed AVI) and "Advanced Settings", VideoWave makes gross errors in the estimate of the output file size. This normally isn't a real problem, unless it estimates the output to be larger than your free disk space. I welcome any proposed workarounds you might submit.

The Iomega Buz audio is simply fed into the "Line In" connection on your audio card. Assuming your physical connections are correct (always check these first), the problem is most likely your audio mixer settings.

First, make sure you have an Audio Mixer control application running. There should be a small yellow speaker in your taskbar. If it's not present, you probably have to install it from the Win95 installation CD.

Open the control panel, which defaults to volume controls for playback. The adjustment for "Line-In" will control the real-time Buz audio during preview and capture. It's simply passed from Line In to the Soundcard's output. Make sure it's not Mute, and the volume level is reasonable. You don't need to run any software at all to hear it.

To control the audio that is recorded during capture, you must change the Recording settings by selecting "Options -> Recording" from the menu. Make sure the Line-In checkbox is selected, and then adjust the level there. This is unrelated to the pass-through audio.

MGI VideoWave adjusts the playback Line-In (pass-through) volume on startup. It does not restore the previous settings on exit.

VideoWave can not generate VideoCD-compliant MPEG streams. While the output may be at the correct bit-rate, it is not White-Book compliant because it exceeds the maximum allowed pack size of 2324 bytes. MGI technical support said it's a known problem with no workaround, and that no fix is planned. Use different software (like Xing) for White-Book MPEG encoding.

Sometimes VideoWave (and ActiveMovie) will mistakenly switch the Buz video format settings to "NTSC". This will play your existing PAL movie files incorrectly, usually resulting in only sound with no picture. Go to the "Video Format" settings. Reselect "PAL", and playback will return to normal.

(Thanks to Dave at Netcom for this tip on rec.video.desktop.)

Copyright ©1998 Steve Haehnichen