Call to Arms: AVTECH4

[l33tmeatwad]

While I think VapourSynth has the potential to become one of the most powerful tools available for advanced users, I think it will be too much for your average org user because they are not willing to learn, especially since what they already know (AviSynth) still works, is still being developed, and is easier. That said, I'm not opposed to it being added to an existing guide, I just feel like if the holdup is for a universal multi-OS software to use exclusively then we are waiting for the wrong thing. Personally I think BOTH should be included for an advanced guide here on the org once VapourSynth is more developed than it currently is, however for now I think we need to concentrate on getting something out there that all users can read and digest that isn't out of date and doesn't make them feel overwhelmed.

[mirkosp]

I'm okay with lmw's proposal, but can anybody handle the html side of the guide?

Also, I think the first step in making a simple and straightforward guide should be to write down a good flowchart, so we'll be able to make the pages for the "choose your own adventure"-style easy guide.

[l33tmeatwad]

I'm okay with lmw's proposal, but can anybody handle the html side of the guide?

Also, I think the first step in making a simple and straightforward guide should be to write down a good flowchart, so we'll be able to make the pages for the "choose your own adventure"-style easy guide.

If it's just basic HTML I could handle that. We should get everyone interested in contributing in a chat on IRC or Skype to discuss things sometime.

[Zarxrax]

It should just be a wiki or something.
Makes it a lot easier to keep updated too.

[l33tmeatwad]

It should just be a wiki or something.
Makes it a lot easier to keep updated too.

I agree with this, I don't know how we would go about this though.

[mirkosp]

Well, there used to be a wiki as far as I was told, but the problem there was that everybody had editing access and in the end a lot of suggestions where bad if not plainly wrong. So it should be more like a privately editable wiki, possibly with everybody getting access to the discussion section of every page so if there are mistakes or doubts, they can be covered there.
I have no clue how to go about that, though.

[Qyot27]

Considering I was around for the old AMVWiki (and contributed), yeah, in retrospect it was pretty bad (including some/most of what I put there, since it was before some of the better filters got into widespread use - on the upside, it was a major part of the reason I switched to a 'less-is-more' style approach to filtering shortly thereafter).

Honestly, I think a more useful treatment is to make a database that documents the particular issues with a series' release, with a clear indicator of region and disc production numbers and so forth. It would show whether a particular disc has pulldown flags used correctly vs. hard telecine vs. field/frame blending, etc., as well as other issues like rainbowing and dot crawl. The actual methods of performing the proper filtering to deal with these issues would be documented in a different section so it doesn't clutter up the series page, and the user would refer to it on a more theoretical level since a lot of the 'quality' filtering is overwhelmingly subjective, and isn't like the case of whether a field is matched correctly. Maybe allow for uploading override files so that problem discs have something that just works for that part - if that can be done legally, anyway.

Just giving people scripts would really just fall back into the same problem of trying to apply script A for series A to series B that probably doesn't warrant it. But documenting the actual problems on the disc is valuable in and of itself. Plus, it would serve as a better technical review of a release than what you'd get from other review sites that are more concerned with 'how does it look on a 50" HDTV situated 15 feet away from me?' type assessments than the type of technical review that's relevant to AMVs.

[BasharOfTheAges]

The elephant in the room is, as always, that most people don't want to know HOW to do this stuff - they want someone to just do the work for them, because fuck learning I want to have fun. Set it up how you want, because, really, in the end, you're going to get burned out once you let the resentment build for a few years.

[l33tmeatwad]

The elephant in the room is, as always, that most people don't want to know HOW to do this stuff - they want someone to just do the work for them, because fuck learning I want to have fun. Set it up how you want, because, really, in the end, you're going to get burned out once you let the resentment build for a few years.

While true for most, it's not true for all. Additionally, many want to learn, but the current guides are too meaty in terms of content and that overwhelms the reader and makes it harder to find particular steps they may have missed. I've had good success with the guides I wrote for the PixelBlended website because they were basic and step by step, which made for a good reference to look back on.

There isn't one best way to make a guide, but we need to strike that balance of not throwing to much at the new readers, yet providing information and links to advanced users to be able to learn more. When I say I think a wiki is a good idea, I don't mean an open one. In my opinion I think a wiki that only particular users have access to modify would be best. It doesn't need to contain everything, just what beginners need with links to the "source" and related additional information. Having one user maintain a guide over time is a bad idea as they will eventually let it get out off date. Having a small group that can maintain an easily editable guide would be best.

[Fuzzy Chickens]

Editing with AVS files has never failed me... why is this method inadvisable?