Exactly why I wanted to split the guide to begin with. So I can just do the easy stuff for everybody first, then later get to the advanced guide.

That said, there also is the small amount (higher than what you'd think, possibly) of people that WANT to learn how to do all the advanced stuff. The problem is that such a guide does not exist at all.

If you don't want to go advanced then you shouldn't have to, but you shouldn't even try to kinda sorta pick some things here and there, it's just more confusing than it would be good. That's why, in those cases, it's best to stick to the simple way.

mirko, I'm not saying you are limited to little drop downs XD. Each one of those items you mentioned can easily have their own page as long as they relate together smoothly.From what it sounds like, I could easily make a subsection called Advanced Preparation & Cleaning, and you can put all your stuff under that heading. Because the end result is still going to be the same: an .avs script or .avi file, right? Then Basic users can simply skip that whole section if they already have footage that seems good enough for them. ofc, you'd have to give me a list of all your pages with heading subheadings/sub-subheadings etc first... which is what you should do before even writing the guide in the first place. Once you do that, everything is 9001 times easier for everyone. Unfortunately, it's also the most difficult part. It should take a while. But if you do it first, you'll know exactly what you are dealing with so you can write pages at your leisure later on.

1. Menu Headings/SubHeadings/Sub-SubHeadings (Make Alpha-Numeric)2. Page Titles3. Page SubHeadings/Sub-SubHeadings4. input/output of each section-necessary steps to be added next-formatting to be figured out later

Well, I probably should have been more clear about what I meant by dropdowns earlier. My intention is to add advanced information in a dropdown(s) at the end of each section wherever possible. That way, the most crucial info is right on the surface for Basic and Advanced users alike, while still maintaining connection to advanced techniques, as well as flowing into the rest of AMVGuide for covering all those non-technical aspects of AMVing as well. I may have to toy with the idea of multiple dropdowns like on the Site Info. Page (That's a fair amount of info. in a small space!). But if it's not possible, I'm certainly open to making as many pages as necessary. But I need a rough outline of your plan first. Just do it at your leisure... you have all the time in the world -owait2012nowai

Just saying, there really needs to be some segmentation on "basics of ripping", "manual field matching of multiple framerate content in the same frame", and all the crap in between. Too many idiots trying to do complicated things, and too many nubs being frightened by the intermediate stuff so ignoring the basics. Also add a damn checkbox to the forum for new threads for "YES I HAVE READ THE GUIDE" and link to it. Also, a section dedicated to encoding and advanced ripping techniques.

You might notice there hasn't been much progress report (nothing in fact) yet.Fact is, a short while after I got this posted, development for vapoursynth started, and contrary to what I thought, it's going by quite fast. I believe in a few months time it will be fine to adopt, actually, so I wish to hold off the guide to until vapoursynth is completely up and running on all OSes. It currently is in a mostly usable state on Windows (though it still needs a buncha improvements), but for the other OSes it's left to building from source.Fact is that avisynth was the main reason for the avtechs so far to be windows only, but with vapoursynth we'd finally be able to have a multi-os guide, so os x and linux users would greatly benefit from a new guide as well. So rather than write a v4 now and then get to a v5 then, I'll just hold off for vapoursynth to fully be around.OTOH I'm not sure what this would mean for users that would want to use fake avi and such for editing. It's a bit early to know, but I believe saving lossless clips would be obligatory...EDIT: Just as I say that, r12 introduces vsfs. Peeps gonna be happy.

I wonder... Well, I got the dvd/bd ripping written already. But then already from the next step avisynth's involved until the footage is loaded in the NLE.Basically the only other thing I could write about would perhaps be the final encoding. I guess I can do that.

No, see, that IS the problem with the guide. Most of the concepts and explanations need to be done step by step along with the scripts, if at all. People are ENTIRELY skipping the theory guides currently, plus they sound more complicated than they should, yet aren't quite as comprehensive.

For instance, avtech3 still does not mention colormatrix, which is important. It's not even that hard, and you don't even have to get into details. People don't need to know what are the white points and primaries. They just need to know that BDs are Rec. 709, DVDs are Rec. 601, and in playback anything up to 1024x600 is considered Rec. 601, whereas anything beyond is considered Rec. 709 and thus they need to convert the matrix when they're upscaling/downscaling through that resolution. Which isn't hard at all to do.

So yes, I believe simple explanation snippets along with the code, step by step in the guide, will be much less overwhelming and easier to understand.

I think the point of a guide should be to make sure people actually understand what they're doing. IMO it is useless to talk about frameserving in a basics guide as that requires in-depth knowledge of video theory, which most readers do not actually have. What happens is you end up with a bunch of people with no clue copypasting bad scripts and not understanding what is happening or why. Better to keep theory out of it for people who don't want to spend the time on it, and just cover what they REALLY need to know. Frameserving in general I think is an advanced topic already.

mirkosp wrote:so I wish to hold off the guide to until vapoursynth is completely up and running on all OSes. It currently is in a mostly usable state on Windows (though it still needs a buncha improvements), but for the other OSes it's left to building from source.

And with the way these things usually go, that'll probably be the way it stays. /cynical

The most you may need to do for Mac users is step them through installing homebrew, since its probably inevitable for it to get a formula at some point (considering AvxSynth already has one, but there's no reason to use that for anything but academic curiosity...you're still better off just using AviSynth 2.6 under Wine). There's probably zero need to worry about Linux users, since A) the source distros likely already have it available in the user areas or will in short order (there's already an AUR for Arch users), and B) the INSTALL file that comes with the source code covers how to build it.

Waiting on Ubuntu probably means waiting on Debian, and if not, who knows how long that'll take considering how long it took for MediaInfo to finally get into Universe (it didn't get in there until Precise, aka 12.04, aka the current release that only came out six months ago - prior to that you had to use the project's official PPA). There's no way it'll be in the repos for 12.10 (13.04 *might* be a possibility but still pretty damn unlikely), since the distro itself is only now wanting to shift its main version of Python to 3.x. The alternate solution is to wait on a PPA - unlikely, IMO - or for there to be a ruleset added to the source so that using apt's automatic dependency resolution+build system is possible (discounting that they could just go ahead and use the instructions in INSTALL).

I wouldn't wait on Fedora, either, for largely the same reason: the INSTALL instructions are probably enough, or someone will come up with a user-submitted or quasi-unofficial repository like the situation that darwinx has been in for the last few releases.

Other than that, there's just too much variety in package management solutions and software provided by them to wait on the distros themselves having it available through their official repositories. There's a certain point where the operating principle for Linux is that for most of them, the user should be assumed to know how to deal with installation from source, or to know how to find the unofficial repositories themselves and use those - any more than that and you aren't teaching them anything about VapourSynth, you're teaching them how to use their own operating system. The big distros are often notoriously sluggish on getting this stuff included or up-to-date (hell, getting up-to-date versions of mplayer[2] or ffmpeg/libav or x264 is already typically left to the user compiling them on their own because the official maintainers can't be arsed to do it, or only do it every six months unless there's a security issue).

Which also brings up the point that even if VapourSynth gets in, you still have to deal with all the other software not necessarily being up-to-date, again throwing it back to the users having to build everything again. So I'd just ignore the point on getting it installed and have it laid out for usage. Installation instructions can be added later, or you could link to established guides elsewhere about doing it, if it was really necessary.

All of this ignoring the part where there's been this disconnect between AviSynth scripting and CLI use for a long time, for insanely dumb reasons. Comparatively speaking, AviSynth syntax (or Python syntax) is a lot more complex than the build process or general CLI use. Having to open the Terminal or Command Prompt to do some preparation shouldn't be treated as a deterrent. After all, if the requisite steps are all right there and only need to be copy-pasted, it's the user's own fault for being lazy (or stubborn) if they don't want to follow them. There's only so much hand-holding you can do.

Qyot27 wrote:(considering AvxSynth already has one, but there's no reason to use that for anything but academic curiosity...you're still better off just using AviSynth 2.6 under Wine)

Now I kind of have to eat my words, even if the external filter situation hasn't changed much. While it hasn't been finalized yet, there is a rewrite of the AviSynth parser in libavformat which would allow ffmpeg to use AvxSynth to open .avs scripts directly on Linux, as well as a patch for mplayer2 to accomplish the same thing through mpdemux.

Of course, from personal testing, the ffmpeg patch applies cleanly and builds without errors, but trying to actually use a script causes a segfault. You can, however, tell that it is doing what it's supposed to, because it can probe the .avs format, just not continue beyond that. That'll end up getting sorted out, though.

The mplayer2 patch, on the other hand, does work. And this means you don't have to do any piping, and you can actually seek forward and backward in a script. And it supports taking/playing audio, which (along with the inability to pipe in y4m format) was one of the deficiencies of the avxFrameServer application. This does also allow for the use of mplayer2's vo-lavc branch to do transcoding from scripts.

mirkosp wrote:No, see, that IS the problem with the guide. Most of the concepts and explanations need to be done step by step along with the scripts, if at all. People are ENTIRELY skipping the theory guides currently, plus they sound more complicated than they should, yet aren't quite as comprehensive.

For instance, avtech3 still does not mention colormatrix, which is important. It's not even that hard, and you don't even have to get into details. People don't need to know what are the white points and primaries. They just need to know that BDs are Rec. 709, DVDs are Rec. 601, and in playback anything up to 1024x600 is considered Rec. 601, whereas anything beyond is considered Rec. 709 and thus they need to convert the matrix when they're upscaling/downscaling through that resolution. Which isn't hard at all to do.

So yes, I believe simple explanation snippets along with the code, step by step in the guide, will be much less overwhelming and easier to understand.

I agree, having been working with editors on Skype a lot, they are way less willing to learn conceptual stuff and are very intimidated by the current "book" that is the AV guide here on the org. Most everyone wants to know how to do something when they need to do it and want basics instructions. I like the idea of basic and advanced guides as well, I've found that some will just ignore guides altogether if they are too advanced and will continue doing things the wrong way...

Mister Hatt wrote:I think the point of a guide should be to make sure people actually understand what they're doing. IMO it is useless to talk about frameserving in a basics guide as that requires in-depth knowledge of video theory, which most readers do not actually have. What happens is you end up with a bunch of people with no clue copypasting bad scripts and not understanding what is happening or why. Better to keep theory out of it for people who don't want to spend the time on it, and just cover what they REALLY need to know. Frameserving in general I think is an advanced topic already.

While I agree it would be BETTER and EASIER for everyone if they actually learned stuff in depth, but not every editor wants to learn how to become an advanced "encoder" who knows tons of stuff about AviSynth and all the settings in x264. Editors are quite honest about this and are very willing to say they don't care, haha...

I think this is a project that needs to be visited sooner rather than later. I understand the idea of picking one standard, but the slow development of VapourSynth really points to it being years before this is updated if we wait on that. I really think users would benefit greatly from a guide that is a bit easier to find what they need and is up to date.