Announcement

Collapse
No announcement yet.

"Generic" 1394 DV audio drift with MS DV driver and MSP6

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

  • "Generic" 1394 DV audio drift with MS DV driver and MSP6

    jeff b,

    You're much further up the learning curve than I but what audio format is your DV capturing? I'm using win2000 but I set it up dual boot -- PITA under win9x, relatively painless under w2k, but the Pyro has been my only w2k PnP failure. Audio capture isn't working at all right now under w2k as I'm missing the Camcorder entry under the sound card drivers in device manager. I had trouble with it when I did a test install but got it to work. No that I've installed on on my "real" system I haven't yet blundered onto the trick that worked the first time.

    Anyway, under VS4 the only dv template is PCM 48000 Hz 16-bit stereo, under MSPro6 there are two 32000 Hz and 48000 Hz. All my DV caps so far have shown 32000 Hz audio under media player properties. Perhaps the problem is in some kind of rate conversion in MSPro6. Does your project audio settings match what your camcoder is actually putting out (Not that I know how to tell at the moment?).

    My camcorder is a Sony D8 model TR7000 (bottom of the line). My test clips so far have not has a lot of dialog where I'd notice less than a major problem with audio sync.

    I believe I'm using the MS drivers under both w2k and w9x.

    --wally.

  • #2
    Hi Wally,
    I've found that it makes no difference whether I use 32khz or 48khz in the clips. Mention was made in a thread in another forum that this problem doesn't occur in VideoStudio, but I haven't had a chance to see if that's the case.

    I used clips that, at the 18 minute mark, I did a lot of finger snapping and other abrupt sounds that would clearly show the drift.

    Comment


    • #3
      Hi, Jeff!

      The latest version of files I know of:
      qdv.dll - 6.2.10.1 - it is included in Pinnacle Systems Studio DV update 1.04

      qcap.dll - 6.1.5.319 - MS Q243174 update.

      DGCom
      DGCom

      Comment


      • #4
        "Generic" 1394 DV audio drift with MS DV driver and MSP6

        I've found that if I capture a DV clip to the max filesize, then import that clip into MSP6 and create a new file from the tail end of the source clip, the audio will be out of sync with the video on the new clip. This problem has been detailed in other forums, and it took a while to duplicate the problem, since it requires capturing a 20 minute clip that, during the end of the clip has audio that will clearly show the problem.

        I'm using SIIG 1394 and MSP6 with latest MS DV drivers I can find.

        There's no real workaround that I can find for this, other than capturing short, as the problem won't occur when creating new files out to the max filesize (4gig) with short source clips. It only happens if the capture source file is long, and you use the tail end of the source clip where the driver bug becomes evident.

        This looks to me like there's some lingering rate difference between how DV is captured, and how it is copied or rendered. I notice that my qcap.dll is dated 7/14/99 and my qdv.dll is dated 10/1/99. The qdv.dll from 7/14/99 will cause a new file creation in MSP6 to have a frame rate problem, causing a duplication of frame 998 at frame 999, and every 1000 frames thereafter. This was resolved with the qdv.dll dated 10/1/99, but I see that qcap.dll is still 7/14/99, so I'm tending to believe that this may be the source of the problem.

        Comment


        • #5
          Hi Dmitri!

          I was wondering if you had encountered this audio drift problem, too? Also, I seem to remember a post from you somewhere, mentioning something about missing audio samples for every frame in captured DV using MS codecs...? I would expect that if captured files have missing audio samples, then ultimately this would get re-rendered with the audio 're-packed' without the same missing spots, and thus create the out of sync audio. This is just speculation on my part, but it would make sense to me if this was the case.

          Comment


          • #6
            Hi!

            Those missing samples occurs if you work with DV AVI type 1 in MSPro 6 AND getting audio clicks...

            I didn't got time yet to test long clip. But I will.

            But eventualy, those two problems could have the same roots...

            Dmitry
            DGCom

            Comment


            • #7
              I discovered this morning that the source clip (although it plays fine in Mediaplayer, and can be sent back out to the camcorder without a problem) displays the out of sync audio the minute it is imported onto the timeline in MSP6 VEditor. Marking a point in the video track where I make a finger snap, and then looking at the waveform on the audio track, it can be seen that the audio lags by about 8 frames once you get out to the 18 minute range.

              Very strange....

              Comment


              • #8
                Playing with MSPro6 some last night I noticed that when you load a clip into the timeline it appears to create a seperate wave and AVI file in the preview directory. Both files play fine with media player and the AVI file appears to have audio in it as well! Perhaps there is a bug in this "spliting" that acounts for the 8 frame delay.

                This sure is a weird problem!

                I sure feel stupid about my audio capture problems. Seems DV capture doesn't pay audio while capturing but since I had the camcorder hooked to the VCR and monitor I heard audio during capture when I did the test installs. The second time the VCR was off -- hence no audio during capture but the data is there in the DV file on playback.

                --wally.

                Comment


                • #9
                  I'm guessing here and wiriting before I've had a chnace to really work out in a practical example.. but might this sort of effect have something to do with locked versus unlocked audio in prosumer DV camcorders

                  A locked audio device will always have precise number of samples per frame of footage an unlocked device will average the given rate over a range of frames there no guarantee each frame will correspond to exactly that number of samples.

                  It could be that MSPro is conforming the audio track to exactly the stated number of samples per frame (a la locked audio) hence the drift over a long period of frames?

                  Steven C

                  Comment


                  • #10
                    chances are (i read up quite a bit on this a few days ago) is that you are capturing at 30 fps instead of 29.97 which would cause the frame repeat.

                    Comment


                    • #11
                      unlocked audio doesn't match up constantly but it still stays within (i read this a while ago so i'm guessing) 1/3 of a frame. the analogy on the page i read it from likened locked audio to a person (video) walking a dog (audio) on a short chain leash, the dog is always right there, the same distance from the person walking it. unlocked audio is like using one of those retractable leashes. the dog is free to wander but it has to stay close and eventually the dog and owner end up in the same place.

                      i hope i didn't lose anyone there

                      Comment


                      • #12
                        Having thouht about practical implications then yep thats my final thought on unlocked audio too 8-) However I had another look at the unlocked/locked info (probably same site as I remember that dog analogy ) the chap on there mentions a similar sort of prob with the canon cam's 48KHz mode not being exactly 48KHz but 48.09Khz and the Sony being 48.01

                        The knock on effect of this for a computer editing package that assumes 48KHz bang on is to end up with a file where the audio drifts minutely out of sync (until of course you reach 18mins or so where the cummulative effect can add up to several frames in case of the canon they were refering to and approx 1hour in for the sony).

                        I don't think that this would be a issue with analog capture given audio and vid are treated as separate entities captured seperately and combined together in the AVI, but with DV where the stream is data-transferred from the cam direct then it could be an issue (I'd need to refresh my understanding of the new type 1 avis when it comes to handling DV data but I get the feeling they would be more prone to this than the VfW type 2 files - which is why the effect may be more noticeable in packages that handle type 1 ie MSPro6)

                        Steven C

                        Comment

                        Working...
                        X