[quote="r6d2"]@Kwag,

Uh... Do you happen to have an image to check this? (lazy moron again) 8).
What do you mean by "Image" :?:12. Audio: 112 kbps Joint stereo for 2 channel input; 128 Dual channel for 5 channel input.

Still a no no :?:
I use 112Kbps almost exclusively, leaving more bitrate for videoBut Kwag... 0 (Auto) is TMPGEnc default! (At least on my Plus 2.5 version) Or you mean "standard" defaults of VCD 40/SVCD 112?
TMPGEnc shouldn't be set to "0" :!: At least that's not the default in my PLUS version :!: Not for MPEG-1. And for the low bitrates we use here ,it's better to use 8 bits of precision, instead of 9 or 10..

-kwag

If you don't want to use 'dual channel', please use at least 'stereo' instead of 'joint stereo'. The current MP2 encoders are not very good at joint stereo, you'll get glitches and distortion in the audio track very easily.

@Kwag,

A mean a ISO image, a short clip encoded at 10 kbps to check my DVD player and not do it myself :lol:
OK, great tip.
You're right, if you load a template it would to be zero. But look at the help file:

It is not the default, but the recommended setting (my fault). So it seems it can handle it sort of dinamically... Maybe sometimes it needs more than what the standard says... Any thoughts on this?

@Boulder,

So I guess that joint stereo is a No no No :!:
:lol:

Thank you guys, I am encoding right now Friends Season 1, 3 episodes per CD with KVCDx3, with all this suggestions of yours.

I did some LBR tests but I was dissapointed. My encodes were by far worse than Kwag's KVCD test disc with the Seinfeld scene. I was aiming at that... 6 episodes per CD, but I guess I did was not able to tweak it right.
Regards,

About Motion Estimation... This method produce larger video files, and I don't to be sure it's have higher quality... How you compare results from HighPrecision and MotionEstimate? Frame-per-frame or common look on tv-set? If f-per-f - what method do you use?
Thanks in advance :)

Hi GetUp,

Motion Estimation produces better quality and less artifacts. At least on all the latest tests I've done with the current script and AviSynth 2.52. You can clearly see less artifacts around moving objects, and even though the CQ is slightly lower than with "High quality", the results are better :)

-kwag

I understand that so far as we are concerned in this case, the advantage of SVCD over VCD is PBC. You can have seamless chapters instead of tracks.

[quote="r6d2"]You have seamless chapters with VCDs too :!:
You don't need to do tracks/chapter. Use ChapterXtractor to read your .IFO, and Cut&Paste the information into VCDEasy. It will create chapter entry points on your single MPEG file.

-kwag

Then that leaves us just with selectable subs and multiple audio tracks, which we rather not use anyway in KVCD :?:

That's right :D
There are very few players that can handle selectable subs on SVCDs. So that only leaves selectable audio channels on a SVCD as an option :mrgreen:

-kwag

But you can still encode as a KVCD and after that mux as SVCD with 2 audio tracks! :wink:

[quote="kwag"]At least in my player (Philco), chapters get completely messed up if I do a SVCD with more than 90 min (there's a warning about that when VCDEasy is generating the image). Chapters work fine in VCDs over 90mins.

Kwag,

is it the same for scripts without the dynamic filtering?

I don't know, because I'm not using any other (non-adaptive) script from now on :mrgreen:

-kwag

Well, I did a small test and it looks like the motion estimate search produces better quality despite the fact that CQ has to be reduced slightly. I don't use the adaptive filtering because of the damn permanent subtitles in the TV broadcasts here :evil:

Are the permanent subs on a black bar below the picture, or are they right on top of the picture :?:

-kwag

They are practically always on top of the picture. We are supposed to switch to digital broadcasts in a couple of years and then you're supposed to be able to switch the subs off and change their appearance. At the moment the transmissions are 4:3 so there are no borders (unless the source was specifically made widescreen format). And even if there are borders, a part of the subs is always on top of the picture :roll:

I've tested a lot and here I've a link to compare the CQ and CQ_VBR at a resolution of 352x(240)288 PAL.

TEST: CQ vs. CQ_VBR

If the results aren't good for you download the pics and use the zoom function and you will see CQ is better in every resolution.

Who ever did those tests, probably didn't consider many factors.
We've already proved here that CQ_VBR is better than CQ for resolutions of 352x240(288).
That is, when comparing both CQ and CQ_VBR targets to be the same size.
Those screeen shots don't mention the process, and there is not enough data.
In this threads, we did provide all the data and procedures ;)

-kwag

I don't know clearly what you say, but I've tested a lot of resolutions with CQ and CQ_VBR and in my results you can see the difference. First I've tested a resolution of 480x576, but the artefacts in this Video with CQ_VBR were very high.
And then I've tested VCD resolution. And I don't know why but you can see that there are more blocks with CQ_VBR because this mode has too little weak in high action scenes.
Can't you that the pics on the left side are very shaper than the right?

Then read this thread from top to bottom again :mrgreen: Of course :!:
That's clearly stated in this thread, that above 352x240(288), CQ is better than CQ_VBR.Yes, I can see it, and as I said before, the screenshots don't prove anything, because there's no detailed data as to how those samples were encoded.
Again, read this thread from top to bottom, and you'll see the FACTS :!:

-kwag

This point is also known and was already discussed on the forum. CQ_VBR is not good for hig action scene BUT it is far better in VCD res than CQ for evry other scene (I am talking about MPEG1 as I never do MPEG2).

So the choice as to be done according to the "actioness" of the movie.

I know that it was discuss. But did you see the pic's above?
They say another and there are more blocks at a resolution of 352x288 with CQ_VBR.

CQ vs. CQ_VBR

I did see the pics. Please re-read my previous post, and maybe look at OUR PICS in this thread, which contain HOW the samples were done WITH data to prove the points.

-kwag

And I would add something : I do not use CQ_VBR for VCD resolution because someone (even if he was kwag) told me to do like this . I use it because I tested it and compared to CQ. And I trust the one and only tool I ever use : my eyes.

Do not follow foreign advices, test it by yourself and take the one you prefer.

I use MPEG1 where others prefer MPEG2.
I do not use the MA script when others say it rocks.
I never encode the audio in dual chanel mode.
And I use tmpgenc for muxing.

You aren't a number, you are a free man :-).

What do you think I've made with this screens and you have to admit that the CQ pic's are sharper and less of blocks then CQ_VBR.


I know! :lol: :D :wink:

I didn't notice these snapshots were yours.

So we are still at the point we were in my first post : the choice must be done according to what is in the movie.

And I agree with you that in the present case, CQ is better than CQ_VBR.

Well CQ or CQ_VBR......

in these samples above I see a total horizontal distortion/frequency cutting! Thats the one which would make me think about it, the CQ or CQ_VBR is not the problem in these pics.
It seems like a very overdone cutting using DCTFilter or the right colums of the DCT matrix.


Inc.

pfew.. another long thread.

Listen, I remember following this very long thread (when it was short, way
back when SansGrip was adding his research knowledge etc to it)
and even then, it was considered long. Anways..

I remember following it while at work (every day) and it was fun and very
interesting indeed. This was the kind of thread/topic etc that I always looked
forward to while at work. Anyways..

I think what was kwag was saying is that you need to first read through the whole
thread (not just the tail end) because you miss so many key points, of which
led many of those that did the painstaking research (and testers) a great
deal of time and effert to conclude to. And, many of those key points were at the
beginning and then some. There are many key factors that led one here, to there
and so on and so forth.

So, w/ the above in mind, all those sample pics that you see (afer reading) should
be followed (to the letter) those settings used in TMPG (that includes the proper
bitrate settings, and those w/in the scope of the CQ vs. CQ_VBR analysis) and the
various Filters that were used during the testing (and debating) plus the various
.AVS scripts that were used, and the source type (Resident Evel, for instance)
(yes, like I said, I read it) and some ofthe tools used to compare the pics as
well as the encodes etc :P

.. .. .. getting some coffee .. .. ..

-vhelp

Sorry, I had technicle issues w/ my pc..

As I was saying..

I remember those that contributed, rendalunit, jorel, maudib, jellygoose, kwag
el_mero_zooter, black prince, GFR and others.. the list goes on.

Check page 8, for intance. And, notice the CQ vs. CQVBR pics.

Did you use the same source files as those in the test threads here ?
Did you use the same .AVS scripts; filters; settings; bitrates etc etc etc ?
Again, all within the same params as those in the thread, and matching the
same sources etc etc.

Course, TMPG has evolved since that time, two years ago. So, the CQ/CQVBR mode
may have improved. Which in actuallity, my cause your argument to become
null'n void :P

That's about it,
-vhelp