Announcement

Collapse
No announcement yet.

Why is preview with MSP6.5 so slow?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    A little progress...

    The green and red horizontal lines should be visible for the duration of the clips.
    I'll be honest and admit that I've never paid any attention to these two colored lines before. Now that I'm looking a bit more closely, I notice that there are many clips in my projects where the line representing the audio is not colored. I realize that the line won't be colored where there are transitions and volume changes, but I also notice the colored line is missing in parts of clips where there shouldn't be any rendering taking place. It's no wonder I haven't been happy with the time it takes for the previews. These clips have all been trimmed, but that shouldn't make any difference. It'll take some more investigating to find out what's affecting the audio in these particular clips. Thanks for pointing this out Jerry.

    Wally, I could find no reference at all to the file (RenderAudio) you had trouble with, so I guess that's good. Thanks for the suggestion though.
    Last edited by Patrick; 10 April 2002, 01:55.

    Comment


    • #17
      Don't know if this has any bearing, but does it make any difference if the audio is 12 or 16 bit? I'm not in a position to test ATM, so only a thought...

      Comment


      • #18
        All DV video is captured to 16-bit even if the DV camcorder was set to record in 12-bit.

        The capture software writes the 16-bit file@32kHz when capturing from a DV tape recorded in 12-bit mode.

        Personally, I avoid setting a DV camcorder to 12-bit mode whenever possible. Sometimes it is not possible to avoid it. The Sony DCR-VX1000 only records in the 12-bit mode, for example.

        When I must use a DV tape recorded in 12-bit mode, I prefer to use the older Canopus DV Raptor "Raptor Video" for capture... and even then I'm not greatly enthused because the audio *does* require re-rendering in MediaStudio Pro 6.5.

        (And it's PCM audio.)

        I much prefer to use OHCI and DV tapes recorded in 16-bit mode whenever possible.

        On my machines, problems occur when I attempt to use OHCI boards and Ulead software to capture from DV tapes recorded in 12-bit mode.

        This is strictly on my machines and I have never been able to solve the mystery.

        Example: With DV tapes recorded in 12-bit mode, I use the 16-bit, 32kHz project template and whenever I render out a 3D transition with video captured from such material, the audio drops out entirely for the duration of the transition.

        (I have noted others do not experience that problem with 12-bit material and OHCI.)

        Whenever possible... record in 16-bit mode.

        Jerry Jones

        Comment


        • #19
          The plot thickens...

          Rob, your suggestion inspired me to check a few things out because several of my projects have been produced using footage transferred from other digital camcorders to my own. Some of this video may have been originally shot using 12 bit audio whereas I always use 16 bit. I haven't found anything concrete yet, however...

          I've discovered that there must be something other than Project Settings that determines whether or not audio (and/or maybe video) requires rendering before previewing. There is a project I'm currently working on that for some reason requires all audio to be rendered. If I drop a new clip onto the time line, there is no colored line displayed for the audio, thus it requires rendering. If I then try the same clip in a new project, with exactly the same Project Settings, the clips will preview immediately with NO rendering. I've checked and double checked. I can't find anything to explain this. What the heck is going on here?

          Is there a bug in the Ulead software or am I overlooking something?
          Last edited by Patrick; 10 April 2002, 22:37.

          Comment


          • #20
            Is the project an old MSP6 project? Maybe something goes funny when loading an old project file into MSP 6.5? How about if you import (insert project file in menu) the old project into a new project?

            Just a thought....

            Rob.

            Comment


            • #21
              More questions...

              Rob, you may have something there! Yes, this started out as a project that I was capturing and editing using MSP6.0. I then updated to 6.5, so I now have a bunch of clips captured with 6.0 and a bunch captured with 6.5. Theoretically this shouldn't make any difference, but there really does seem to be something odd going on here. It would take many, many inches of forum space to explain all the different experiments I've tried, but suffice to say that there appears to be a bug in the way MSP deals with audio. MSP seems to arbitrarily decide to render the audio in situations where it makes no sense at all.

              Here's a question for anyone familiar with MSP. Let's say you have a one minute clip on the timeline where absolutely nothing has been done to it except for a one second fade up and a one second fade down in the audio. If the Project Settings match the clip, what now needs to be rendered, two seconds of audio or one minute of audio?

              Comment


              • #22
                There's really no "bug" in MediaStudio where audio is concerned... at least not on my systems.

                On my OHCI system, the red and green horizontal lines appear every time I drop a DV clip into the time line because the project properties precisely match the attributes of the video.

                When one adjusts the audio levels, then one is essentially altering the entire clip (even if volume is changed for only a segment of the clip).

                In my experience, there's no "arbitrary" decision by MediaStudio to render audio/video.

                In fact, it's quite predictable, i.e. any time a filter is applied or any time a title or transition is applied.

                Comment


                • #23
                  I would also mention that on my Canopus system, there is a *required* entry in the Ulead32.ini that undoubtedly makes it necessary for audio to be re-rendered.

                  It's "renderaudio=1"

                  As I recall, MediaStudio Pro 6.0's help files specifically mentioned that as necessary for the Canopus DV Raptor.

                  I suspect the reason it is no longer mentioned is the entry is automatically inserted when the Canopus "Smart Play" timeline playback plug-in is installed in MediaStudio Pro 6.5.

                  Comment


                  • #24
                    the only thing predicable is unpredictability...

                    From Jerry:

                    When one adjusts the audio levels, then one is essentially altering the entire clip (even if volume is changed for only a segment of the clip).

                    In my experience, there's no "arbitrary" decision by MediaStudio to render audio/video.
                    Well Jerry, you may not call that "arbitrary", but it seems like a silly waste of time to me. Would any of us be happy with this program if the video portion of the clips were treated in the same manner (example- if we added a one second dissolve we'd have to render the entire clip)? I think not. Of course, one way around this particular audio rendering problem is to ensure that all audio fades occur during a video transition. That way only small segments of the clip need to rendered. Perhaps Ulead can fix this in MSP7.0.

                    In regards to the project I referred to earlier that I started while using MSP6.0, when I add a clip to it that I've captured using 6.5, no red line representing the audio appears. All audio needs to be rendered. This is with a clip that has had nothing done to it and whose properties match the Project Settings exactly. This is not "predicable". Well, unfortunately I guess it is for me by now.

                    I love using MSP and I'm not trying to criticize it just for the fun of it, but there seems to be something odd happening here and I'm just trying to get to the bottom of it. If it turns out it's something I'm doing wrong, fine, I'll admit it, but right now it appears that there's a glitch in the program.
                    Last edited by Patrick; 12 April 2002, 14:52.

                    Comment


                    • #25
                      Success...

                      Ok, I finally resolved the problem. That doesn't mean I solved the problem, but at least I've been able to eliminate all the senseless audio rendering.

                      I dragged all the clips from the open project off of the timeline into the Storyboard in Media Library. This allowed me to save all the trim settings for every clip. I then dragged all these clips back onto the timeline in a new project. Although there were many clips that had no alterations to the audio, these clips still required rendering until I removed all volume changes of any type from every clip. This took awhile as I had many, many volume "ramps" at the beginning and/or end of about a hundred clips. To do this I had to shorten each clip by clicking the cursor on the edge of the clip on the timeline and dragging it, and then I had to drag the edge of the clip back to where it originally was. This effectively removed all the ramps. If anyone knows an easier way of eliminating all volume changes to multiple clips, I'd love to hear about it!

                      Anyways, once I did all this, every clip on the timeline now displays both a red and a green line above it. This of course means that nothing has to be rendered until after I alter something. There is no way it was ever going to work properly earlier. I believe Rob was correct in his statement that something might have gone funny using an old project in MSP6.5 which was started in MSP6.0. (Thanks Rob!) By the way, I tried Rob's suggestion of importing the old project into a new one, but unfortunately that didn't work. All the clips still required the audio to render.

                      One would think that there shouldn't have been a problem like this with an upgrade, but you never know...

                      Comment

                      Working...
                      X