@Kwag,

Here the instructions SansGrip gave me to Crop using FitCD.
I created a avs script with no filters as input to VDub->video->add->
null transform->OK->cropping. Then I following the steps below.
It gets tricky when top-bottom and/or left-right borders are different.
The advantage of doing it this way is faster encodes. Albeit FitCD
can give the crop settings, it would be nice to make this a more
user friendly process


-black prince

I generally only need to adjust the audio length if I'm converting a PAL movie into NTSC. To do this I use AssumeFPS(23.976), which means the video now runs about 4% longer and I need to "time stretch" the audio an equal amount for it to remain in sync.

Edit: Oops, forgot to say how I do it. I either use a utility called WLA (available from Doom9's download page, I think) or I use WaveLab. The latter is easier since I just enter the new running time instead of having to calculate the new total-samples value.

A quick clarification to what I wrote: when I say "uncheck anamorphic", I mean "uncheck destination anamorphic", not source.

Also I've since stopped putting AddBorders in my Avisynth script. I now set TMPGEnc's arrange method to "center" and it adds whatever borders are necessary.

@All,

It turns out that LanczosResize(496,352,0,8,720,464) in this
format will crop and resize. LanczosResize(496,352) and
Crop(0,8,720,464) is the same thing. There is debate as to whether
a resize should include a crop command. Having a separate crop
command before resize will speedup the encode process.
Choosing LanczosResize in FitCD will give you the both

-black prince

@SansGrip,

I wanted to add some more ideas to enhance documentation.
I'd like dividing each step into separate How to Guides. This makes
it easier to update or add more information to each step.

For example:

1) Ripping DVD

2) Converting VOB to .d2v

3) Converting Audio

4) Cropping and Resizing

5) Predicting File Size

6) Encoding

7) Multiplexing

8 ) Authoring and Burning


-black prince

That's a good idea. Of course, all of these guides can be written right now, except number 5 .

Here's what I do:
1) Ripping DVD with smartripper

2) Converting VOB to .d2v with dvd2avi

3) Converting Audio with headache

4) Cropping and Resizing with fitcd

5) Encoding with tmpg and kwag's templates

6) Multiplexing with tmpg

7) Burning with nero

I didn't add Predicting File Size because I haven't tried it yet,but I plan on trying it soon. Most of the time my movies fits on a cd so I burn it, and if it's over I adjust so the movie will fit. But this is the way I do it.

@SansGrip,

The manual prediction method is available. It's need to include a section
for CQ prediction, where Kwag takes the current CQ and adds the new
CQ then divides by 2 for the corrected new CQ. CQ_VBR is what he
has available.

-black prince

@SansGrip,

Here's the manual file prediction guide:

http://www.kvcd.net/forum/viewtopic.php?t=2102

-black prince

What is the advantage of doing it this way? Does it help speed up the encode process? Between this and doing a Crop() separate from the LanczosResize() I might finally get my encodes down to a more sane amount of time

The advantage of letting TMPGEnc add the borders, for me, is that if I change my mind about what resolution to encode at there's fewer things to change in the script .

I'm not sure how it affects encode time. Probably not a lot.

I think with exception of FitCD, file size prediction and kwag templates, we can refer to Doom9 guides, they're very detailed and reliable. No need to reinvent the wheel

@acidfire,

Some of us use DVD Decrypter instead of Smartripper. Some use
BeSweet instead of Headac3he. Some multiplex with bbMPEG instead
of Tmpgenc and some use VCDEasy instead of Nero. Maybe these
steps should be without specific software so more than one way
can be described in the explaination of How To step.

@GFR

Maybe we should recreate all the steps, since some of Doom9's
guides have not been updated and are not specific to KVCD settings.
I never thought anyone would write an automated program like
acp, because we were using DVD2SVCD. Now it makes sense
because we can make changes to this program when new developments
arise more quickly and the same would be true for our own guides.
Also, putting updated dates on a step, let's everyone know the latest
changes for that step.

For example:

4) Cropping and Resize

5) File Prediction (updated: 01/07/03)

Step 4) has no changes, but step 5) was changed on 01/07/03.


-black prince

@ black prince,
Yes I understand what you are saying , but SansGrip wanted to know how everyone makes their kvcd. And in his first post he had his method and the software he used. So that is why I added the software I used. But I do agree with you when you say we should not limit it to certain software. I'm not sure if it would be hard or not but maybe we can have each step then inside each step can be different software and how to use each software . But first we should get the basic steps down and go from there.

@acidfire,

acidfire wrote:
Yep! your right. I was thinking ahead about designing a guide that new
visitors and experienced users could refer to for starting with KVCD.
I'm sure the steps within steps can describe other methods to accomplish
the same outcome. Guides change and with this forum where change is
rapid we need a source to keep up to date. My hope is that only stable
processes will be posted for update and only certain forum members will
be able to make updates.

-black prince

I follow the steps and software suggestions put forward by Kwag and SansGrip. I simply don't have the time to do the extensive amount of testing that they've done, so if they say something works I tend to believe it and use it. This was especially true of bbMPEG. I loathed trying to use that software first time I tried, because it never worked. I asked Kwag what was wrong and he whipped up a screenshot of his settings and I haven't had a problem since!

To the point: KVCD has become much more than just a TMPGEnc template, it is a whole process from the ripping through to the burning. While I agree several software solutions will do the job, for any guides that are created for this site I think as much detail as possible should be included _based on the software being used by the authors_. Hence, if Kwag/SansGrip use HeadAc3he over BeSweet, for example, then document the process for HeadAc3he! Trying to document the process for multiple apps is very time-consuming, and will lead to either no guides getting completed or 'rush-jobs' that forget a few critical steps causing a flood of new posts here in the forums. If others want to contribute process documents for alternate software, by all means, but overall there should be a "Complete Guide to KVCD" which documents a single path from start to finish.

(NOTE: I mention Kwag/SansGrip above without any intention of slighting anyone else that has contributed significantly to the KVCD process).

@ black prince,
Sounds Great! I don't know much about making guides but maybe SansGrip, Kwag, and you can get someothers to help with making guides. And maybe assign certen sections to one perston. It might make it easier for all involved in making the guides. Example:One person workes on just audio or if you can get enough people say one person just dose heada3he in the audio section. And that person keeps their section updated. Hope this help or gives you some ideas!

This would be my preference not because kwag and myself use it, but because it's better .

I agree. I think the first step is to get the "most common case" documented, whether that be HeadAC3he or BeSweet, acp or DVD2SVCD, a calculator or KVCD Predictor, etc.. This was one of the reasons I started the thread.

KVCD is by nature open source, and the best thing about open source is that anyone can contribute. I think it would be a very good idea if we set up some "teams" to document certain aspects of the process, then a few individuals could go through the results and edit and integrate into a whole. I suggest a few individuals because I find things tend to be more consistent that way.

Personally I much prefer coding and testing to writing documentation (as you can tell from my readmes ), and I think am more useful to the cause in that role, but would be more than willing to help out with the final integration.

An additional thought struck me while playing with the 3-disc version of Minority Report: a useful section of the documentation would deal specifically with AC3 audio from AVI sources:

1) Use VirtualDub to extract
2) Use BeSplit to repair the resulting file
3) Use BeSplit to join separate AC3 files if necessary

Then one could refer to the generic HeadAC3he guide for actually encoding the AC3.

@All,

Here's a link to Divx Guides, that has a structure we could discuss.

http://www.everwicked.com/modules.ph...des&file=index

The guide uses links within the guide for steps needed to create
the Divx video. I'm interested in the structure and how easy it
would be to follow along. You may have a better one or want
to comment on this one

-black prince