Type 1 DV blues

[mpwr5]

I'm trying to encode some type-1 dv files with avisynth and cce. If I use ULead's free type-1 to type-2 converter, I have no problem, but I would like to avoid the extra processing step and time time and disk space needed to convert.

I thought I had come up with a script that did the trick:

# need to use DirectShowSource, AVISource crashes
v1=DirectShowSource("d:\myclip.avi",fps=29.97)
# get rid of junk at beginning and end
v1=Trim(v1, 2297, 112353)
# throw away the interleaved audio
v1=KillAudio(v1)
# tack back the audio. This wav file was rendered
# with Vegas Video and precisely matches the frames
# specified above. CCE doesn't really need it
# but is unhappy if it's not there
a1=WAVSource("f:\myclip.wav")
v1=AudioDub(v1,a1)
return v1

CCE happily encodes this avs file--finally no crashes.

Then I combine the m2v file with the audio in a DVD image and preview it. The audio is seriously out of sync. It should have matched perfectly because it was captured with a Canopus card and them trimmed to precisely the frames listed above.

Also, the ending frame (112353) was a black screen after the credits. The capture was done with a timer, so there is some junk that follows in the source AVI file. When the encode clip is played, it ends with a few frames of this junk instead of stopping at exactly the frame I specified. I tried removing the Trim command from the script and specifying the frames in CCE, and got the same results.

It seems that when avisynth is serving a type-1 dv file, it takes the frame numbers requested as "suggestions". The documentation says the DirectShowSource files don't support seeking. There is a long pause at the beginning, presumably because it is reading and discarding the first 2997 frames. That's bearable, but I need to be able to control precisely the frames that are encoded.

Does anyone have an idea what could cause the timing to get out of whack, or perhaps a better way to serve type-1 dv with avisynth? Many thanks!

Cliff

[DJRumpy]

You need to use the AudioDub command before your TRIM command. This way, you can include the audio, with the video, and keep sync. Your script should look like this:

video=DirectShowSource("d:\myclip.avi",fps=29.97)
audio=WAVSource("f:\myclip.wav")
AudioDub(video,audio)
Trim(2297, 112353)

Ensure you have audio enabled in CCE. Set the bitrate and sample rate according to your needs. You should get an MPA, and M2V file. Feed these to your authoring software, or if your software doesn't accept individual feeds, multiplex them with TMPGenc. This script removes the need to 'edit' your audio using an outside editor. It assumes the audio is complete, as if it was just removed from your source file (i.e. FILE | SAVE WAV in VirtualDub).

This script is a bit simpler than your original script. This should serve, and encode with audio, and without any sync issues. It is not necessary to 'return' a value in your script, or to assign an input to a variable. The last command (TRIM), returns a video stream, which has been Trim'd from frame 2297, to 11235.

[mpwr5]

I dubbed the audio back in only to make CCE happy. I'm only using CCE to make an elemental stream (m2v) video only file. I combine this in the authoring tool with an ac3 file built from the wav file. It works perfectly when starting with a type-2 dv file. I have heard that CCE blows up if the input has no audio, even if it is only encoding the video, but that the audio could even be a junk file.

It seems that the problem is that CCE isn't encoding precisely the frames I specified. I specified a very specific frame as the ending frame. The encoded video ended up having a few frames that followed this frame in the source file. It happened both when I used the Trim command and when I omitted the Trim command and instead specified the frames to encode in CCE. I am guessing that the imprecision with which it is selecting the frames to encode is affecting the audio timing.

[DJRumpy]

The no-audio bug affected old versions of CCE (it may have been an AMD chipset thing. I can't remember..). Old versions also had a problem with Type-1 DV. Frameserved removes any of this from the equation. I also use the TRIM command on a regular basis, and I have never had it read in more, or less than I specified.

Verify the frame numbers using VirtualDub. The frame number is reported on the status bar of the program. Use the slider, arrow buttons, and keyframe buttons to navigate to your end frame and note the frame number to verfiy you've got the right one.

Save yourself the grief, and just let CCE process the audio with the video. You can always convert the output MPA to AC3 with any of the freeware tools out there.

[mpwr5]

Thanks very much for your advice. I'll try to let CCE do the audio. What utility would you recommend to convert mpa->ac3?

I agree with you about the Trim fxn. I've used it a lot (with type-2 dv) without a problem. As a matter of fact, I use Vdub to get the frame numbers (Vegas would work too). It complains when you load the type-1 file, but it lets you see the video and get the frame #'s.

So I'm pretty sure I have the exact frame #'s. I don't think it's a problem with Trim, because if I omit the Trim fxn in the avs file and instead specify the frames to encode right in CCE, I get identical results--it encodes a few more frames than I told it to (and maybe that messes up the audio timing).

It's almost as if Avisynth can only approximately move the the requested frames.

Another odd thing. I can use my avs file both in CCE and Vdub, with sound. With both there is a VERY long delay at the beginning before the first frame (#2297 in the original source) is served up. I think it the delay happens while it seeks to that frame. I didn't measure it with a stopwatch, but it could actually be the time it would take to go through 2297 frames at 29.97fps (about 80 sec). All in all, it seems like some strange stuff is happening with Avisynth frameserves type 1 dv.

Anyway, thanks a lot for your help. I'll feed CCE the audio and see if that works better.

[DJRumpy]

For audio conversions, I would suggest you get BeSweet, BeSweet GUI, TooLame, and SSRC. They are all freeware, and can be found in the TOOLS section. The GUI tools incorporates all of these programs into one GUI, making it a kind of 'one-stop' software package. Use the BeSweet piece to Convert to AC3. SSRC is for resampling audio (from 44.1, to 48Khz for example), and TooLame is good for MP2/MP3 encoding.

I agree on the audio delay. It does sound like it's seeking in the file to the first frame number. Is converting this file to Type-2 an option? I don't know what affect this has on a type-1 file, but you might also try re-keying the file, using the extended open options in VDub.

The only other suggestion I have, is to manually change the TRIM numbers to remove those extra frames, to see if that resolves it. I used to see issues like this when spliting mpegs with TMPGenc. It would always play the video until the next keyframe, regardless of where the CUT point was.