CCE won't decode in YUY2 format

[fmctm1sw]

I am having a lot of problems with CCE basic all of the sudden. Yesterday, I tried to convert a 90 minute source and all I got was garbled output. I can fix this only when I unchecked "try to decode in YUY2 format" and check "try to decode in RGB24 format" under the "misc" menu. I've tried feeding it with avisynth and just using the original AVI. Same thing. YUY2 is faster and I'm worried it is making a colorspace conversion that I don't want. I also cannot get it to open .vdr files from virtualdub.

[fmctm1sw]

I got this one figured out. I captured with virtualdub, which I don't normally do. I failed to crop off 8 pixels (I capture at 712x480) and gave CCE a 712x480 file to encode. It trashes it every time unless you try to decode with RGB24. Lesson learned...

[FulciLives]

I use the BTwincap driver so I also capture NTSC at 712x480

I crop it to 704x480 then add back to the sides to make it 720x480

I also use CCE along with AviSynth.

- John "FulciLives" Coleman

P.S.
If you do captures and get 29.971fps or 29.969fps etc. then CCE will also choke on that. You have to make it exactly 29.970fps ... I do it with the AviSynth command AssumeFPS(29.970, true)

[fmctm1sw]

I use the BTwincap driver so I also capture NTSC at 712x480

I crop it to 704x480 then add back to the sides to make it 720x480

I also use CCE along with AviSynth.

- John "FulciLives" Coleman

P.S.
If you do captures and get 29.971fps or 29.969fps etc. then CCE will also choke on that. You have to make it exactly 29.970fps ... I do it with the AviSynth command AssumeFPS(29.970, true)

Why do you add black to get to 720? Is that an aspect ratio thing? I havn't had any issues with audio yet, but I may just take that onboard and add the code (before I have problems).

[FulciLives]

I use the BTwincap driver so I also capture NTSC at 712x480

I crop it to 704x480 then add back to the sides to make it 720x480

I also use CCE along with AviSynth.

- John "FulciLives" Coleman

P.S.
If you do captures and get 29.971fps or 29.969fps etc. then CCE will also choke on that. You have to make it exactly 29.970fps ... I do it with the AviSynth command AssumeFPS(29.970, true)

Why do you add black to get to 720? Is that an aspect ratio thing? I havn't had any issues with audio yet, but I may just take that onboard and add the code (before I have problems).

Although I know that 704x480 is a standard NTSC DVD resolution I have never ever seen a commercial NTSC DVD use anything otherthan 720x480 nor have I have seen a commercial PAL DVD use anything but 720 again for the width.

So I just feel better using a width of 720 for my prjects. I use the AviSynth crop command to get from 712 to 704 then use the AviSynth AddBorders command to get from 704 to 720.

As for the frame rate trick ...

My capture process has changed a little bit (very little) since I got my new computer but it bascially the same.

I currently am getting good results using iuVCR and setting it up (audio sync wise) as per the help file that comes with it ... in short selecting AUDIO as the master stream (along with the other settings that are pointed out in the help file).

Now with my old computer (same BT based capture card) I tended to get 29.967fps or 29.968fps or 29.969fps and I used to feed the Avisynth AVS file through TMPGEnc Plus but JUST do the audio (not the video) and do the audio as PCM audio. I used the SSRC plug-in and it would convert the audio from whatever it was (such as 29.967fps) to 29.970fps with great results ... thanks to the AviSynth AssumeFPS(29.970, true) command. I would then convert this to AC-3 and in the end (authoring stage) match it with my MPV file from CCE.

However now with my new system my captures are on the other side if you will. Instead of being just under 29.970fps they are just slightly above it such as 29.971fps or 29.972fps

I have found that SSRC does not like this at all!

So my new workaround is to load the AviSynth AVS file NOT into TMPGEnc Plus but instead into VirtualDubMod. This of course has the aforementioned AssumeFPS(29.970, true) command in it. I then use the STREAMS function to SAVE WAV giving me a time corrected 29.970fps PCM WAV file (I always use 16-bit 48k Stereo PCM WAV as my capture audio format). However this gives me a PCM WAV file that is "slightly off" in that it is now still 16-bit Stereo but instead of 48,000 it is now something like 47,999 or 47,998 etc.

It is the correct length now but the sampling frequency is "off" so I load this PCM WAV file into Sound Forge (I suppose any decent PCM WAV audio program can do this, such as GOLDWAVE) and save it to a new 16-bit 48k Stereo PCM WAV file. This now gives me the proper frequency sampling rate without adjusting the length.

I then normalize (allways my final step with the PCM WAV file even with the "old" method) and then convert to AC-3 and again match it up with the CCE encoded video file in the final authoring stage.

I do all this so I am feeding CCE a "standard" 29.970fps video file. Since I am changing the length of the video with the AssumeFPS(29.970, ture) command I must therefore adjust the audio as well.

I have tried VirtualVCR and for a time it seemed to be working fine on my old computer but on my new computer it doesn't keep sync 100% ... it's darn close but off ... so I went back to using iuVCR (I used TheFlyDS on the old computer but it works pretty much the same as iuVCR in the sync department).

The nice thing about VirtualVCR is that it gives you a rock solid 29.970fps video file with a matching 29.970fps audio file but the sync (so close yet not perfect) annoys me so I cannot use it.

This whole issue almost made me get a Canopus ADVC-100 and the only reason why I didn't buy one (when I was considering it) was due to financial instability on my part hehehe

Then for a while I decided, after looking into the Canopus ADVC-100 (and similiar DV capture devices such as the DataVideo DAC-100) I concluded that the NTSC DV 4:1:1 color sampling made NTSC DV less than desirable depsite the fact that such a device will keep very tight audio sync with a proper rock solid 29.970fps rate.

So I stayed away from it.

But now based on the results and comments of other people and the fact that a 4:1:1 filter exists for AviSynth I am "ready" to try something like the Canopus ADVC-100 but again my financial instability is still mostly in effect so FOR NOW I am happy with my BT based capture card.

As a side note I tried the AverMedia DVD EZMaker PCI card since it uses the superior Philips chipset (slightly sharper image with less dot crawl) but wouldn't you know the card just would not cooperate with my system ... no matter what I would get frame drops (usually 4 at a time) even when testing it with a top notch DVD player as a souirce (i.e., very clean image). Why the old BT based card works fine (on the same system) I have no idea. But you know what ... even with the DVD EZMaker I would still suffer from the "issue" of having a frame rate in the capture that would be slightly off from 29.970fps so ... I see a Canopus ADVC-100 in my future at some point I think hehehe

- John "FulciLives" Coleman

[fmctm1sw]

I never really thought that much about the audio. As long as it looked like it matched up with the video, I let it go. But I've seen you post about this before, so I may look deeper into it. Looks like you do this much the way I do: Elementary streams.

[FulciLives]

Just to make it clear (in case it is not from my other post) I do get perfect A/V sync in my captures when using iuVCR and setting it up audio sync wise as per the help file within iuVCR. Only VirtualVCR gives me audio sync problems when I have tried to use the "infamous" feature it uses to sync audio dynamically. So I don't use VirtualVCR hehehe

So although the captured AVI (I use the HuffyUV codec these days) has perfect A/V sync the video and audio end up being something real close to but not exactly 29.970fps ... so ... I am NOT trying to correct sync but merely trying to get my capture from whatever frame rate it is (as of late, on my new computer, that is usually 29.971fps or 29.972fps) to the standard 29.970fps

I have decided to do this using the AviSynth AVS command AssumeFPS(29.970, true) which seems to work very well as it either slows dosn or speeds up the capture to match 29.970fps ... in other words no frames are dropped or added. This means the video length (running time) changes (even if only very slightly) so the audio must also be adjusted.

I hope this makes it more clear if it wasn't already clear before.

- John "FulciLives" Coleman

P.S.
This also works for a PAL capture since again ... when I do capture PAL video ... I never seem to get exactly 25.000fps

[fmctm1sw]

This means the video length (running time) changes (even if only very slightly) so the audio must also be adjusted.

I think that is something that has confused me for a long time. Exactly what effect does dropping frames have on audio? Does the audio end up longer or does audio get "lost" when frames get dropped? How exactly would you capture video and audio completely separate (with like different VCRs) and match up their lengths after the fact? Maybe that would help me understand it better....

[FulciLives]

This means the video length (running time) changes (even if only very slightly) so the audio must also be adjusted.

I think that is something that has confused me for a long time. Exactly what effect does dropping frames have on audio? Does the audio end up longer or does audio get "lost" when frames get dropped? How exactly would you capture video and audio completely separate (with like different VCRs) and match up their lengths after the fact? Maybe that would help me understand it better....

Let me see if I can explain any better.

When you capture with the AUDIO set as the MASTER STREAM the video is adjusted, during the capture, to match (i.e., remain in-sync) with the audio. This means that video frames are either added or dropped here or there along the way (while capturing). This is why such a capture is never exactly 29.970fps (I am of course talking NTSC here but it applies to PAL as well).

Now in all the capture I have done I have never noticed any "weirdness" when watching the video ... the added/dropped frames just are not "visible" to me. I assume this is so because the video does not need to be adjusted to any great degree and I am sure the added/dropped frames are few and far between.

Now when I use the AviSynth AVS script command AssumeFPS(29.970, true) I am changing the captured file (during the conversion to MPEG-2 DVD spec) from one frame rate (usually very close to 29.970fps but not exact) to exactly 29.970fps. Now here is the important thing. The AssumeFPS(29.970, true) command adjusts the video to 29.970fps by NOT dropping/adding frames but by changing the playback rate. It is either ever-so-slightly speeded up or slowed down to get to 29.970fps thus the final MPEG-2 DVD spec video file will either be ever-so-slightly longer or shorter in running time than the capture. Now the AssumeFPS(29.970, true) command adjusts the video length AS WELL AS the audio length but it will change the audio sampling rate from 16-bit 48,000 to 16-bit 47,999 or 48,001 etc. so that has to be adjusted back to 48,000 without changing the length back from the "corrected" length (i.e., running time).

So that is how my process is working.

Now if you feed the original capture into say TMPGEnc Plus without adjusting the framerate to exactly 29.970fps that program (TMPGEnc Plus) will either add or drop video frames while it encodes to make the final MPEG-2 DVD spec video file have exaclty a 29.970fps frame rate even if the original capture is slightly off (such as my captures which are 29.971fps or 29.972fps etc.) and the way that TMPGEnc Plus does it causes very little if any noticeable effects ... assuming the frame rate of the capture if very close to the target (which it generally is as per my examples). It somehow manages to adjust the video to make it 29.970fps while also keeping the audio unchanged (in duration) and still keeps it in-sync.

That's great if you use TMPGEnc Plus but what about using CCE or another encoder. I don't know how other encoders work but I seem to recall (a long time ago) trying to encode a capture with CCE that was not exactly 29.970fps and CCE had fits over it.

So in short I am very surprised this is not something that is more talked about.

- John "FulciLives" Coleman

[fmctm1sw]

This means the video length (running time) changes (even if only very slightly) so the audio must also be adjusted.

I think that is something that has confused me for a long time. Exactly what effect does dropping frames have on audio? Does the audio end up longer or does audio get "lost" when frames get dropped? How exactly would you capture video and audio completely separate (with like different VCRs) and match up their lengths after the fact? Maybe that would help me understand it better....

Now the AssumeFPS(29.970, true) command adjusts the video length AS WELL AS the audio length but it will change the audio sampling rate from 16-bit 48,000 to 16-bit 47,999 or 48,001 etc. so that has to be adjusted back to 48,000 without changing the length back from the "corrected" length (i.e., running time).

- John "FulciLives" Coleman

It's getting clearer. And what is used to get the audio back to 48k? SSRC?

[FulciLives]

It's getting clearer. And what is used to get the audio back to 48k? SSRC?

Well if you look at the 2nd post I made in this thread you will see that in the past I used SSRC but now I save the PCM WAV out of VirtualDubMod (after loading the AviSynth AVS script into VirtualDubMod) which gives me a "corrected-for-length" audio file but the audio file now has a "weird" sampling rate of not 48,000 as per the original capture but something more like 47,999 or 48,001 etc. so to fix it (take it back to 48,000 but leave it at the "adjusted length") I load it into Sound Forge and save it back out to a new 16-bit 48,000 PCM WAV audio file. Sound Forge is a "high-end" PCM WAV audio editing type program. I assume the same thing can be done with any similiar type prgram such as GOLDWAVE etc.

- John "FulciLives" Coleman