As noted, I make too many AMVs. Or, more accurately, I have made too many AMVs, such that I still average over 1 VPM over the total length of my career despite being nearly retired for large parts of 2006 and nearly all of '07, '08, and '09. The normal reaction is to look at that back catalog and say, wow, there's probably a lot of crap in there. Yes. There definitely is, almost certainly more than even I'm willing to admit. But that's kind of the point.
I have an overdue reverence for Robert Rodriguez, mostly because he has a knack for making cool movies, but also because he spends his commentary tracks not talking about his artistic vision, but about production tricks and how he's made his DIY ideals into an actual production process. The commentary track to El Mariachi is a bible for anyone who thinks they don't have the resources to do what they want to creatively, and towards the end of the opening credits, Rodriguez comments that he had a great advantage by making movies on home video before going to film school, let alone actually filming anything. His quote: "I believe every filmmaker has about thirty bad movies in them, so it's better to shoot on video and get them all out of the way, so that you don't shoot them on film and waste all your money."
The point is not, oh, go make 30 crappy videos (or 30 crappy 80-minute video movies) and magically become better, but that practice is a very real part of becoming better at any craft. You get better at making movies by, surprise, making movies, and you get better at making AMVs by making AMVs. You need to have the technical basics as well, and you need to have an idea of what's worked in the past, too, but Rodriguez still went to film school despite all those video movies he made in high school; they may only take you so far, but the guides and watching previous videos shouldn't be just skipped. If you want to make better AMVs, you need to make AMVs.
This is where the Tube comes in, obviously. You can dump whatever the hell you want on it, and if THEY think it sucks, no harm, no foul, delete and learn from it. The next part should also be obvious: this is why MEPs are bad.
MEPs are bad because they take nearly as long to produce as AMVs, but are not AMVs and do not teach you how to make AMVs. What MEPs teach you is how to make 30-60 seconds of sparkly crap. If you want to know why the well is running dry on the .org, look no further than the MEP forum, and how many thoroughly needless projects are underway. If you want to know why your work sucks now, look at your prod history and see how many MEPs are up at the top. MEPs are nice for building community and making something that everyone can feel good about for 30 seconds before going on to the next one. They suck balls, though, at making better AMV editors.
Your frame of reference as an editor is not infinite. You have to train yourself to focus and concentrate on long projects, especially to see the video as a coherent whole where the end follows up logically from the middle from the beginning, and where the beginning sets up how the video flows in the middle and how it concludes. In a MEP track, everything is compressed, and it becomes more difficult to maintain the focus on building a full video -- especially when it's so easy to drop the project and say "screw it, I'll just do a track for Project Timewaster instead".
It also doesn't help that MEPs are easier to come up with than AMVs. For a MEP, usually someone else has picked the music, and maybe the anime depending on the project, and all you have to do is come up with some bare-bones editing concept. You don't need to watch anime and listen to music extensively, which is required for doing regular AMVs. Rather simply put, MEPs mess up your focus frame and let your source concept synthesis abilities atrophy. They don't make you better, and may actually make you worse. Stop joining MEPs, and stop starting new ones.
Yes, I've done them as well, but in my archives, two of the three that I've been involved with fit this pattern. I got to pick all my own tracks for all of them, but AMV Hell is the king of focus busters. The Graveyard handed out general concepts in advance and was, for reasons outside of my control, a huge waste of time in the end. Conet is the only exception: godix invited participants that he knew would meet standards, told them to select-from on a large database of tracks, and told people to come back with something cool. The only pick points might have been the shorter track length and the competitive compulsion among everyone but doki to break the video in a visually distinctive way....but then again, you look at the editors involved, and most of us have a history of that anyways, hence being asked to do this.
As I work my way back into the hobby, it's something to be aware of as much as for anyone else who wants to develop: stay away from short videos and stay away from MEPs. They're nowt helping.
Thursday, October 29, 2009
Friday, October 23, 2009
math, graphs, and process crap part II
More process stuff from the re-assembling of my stats sheets that look to have been lost when Keystone went out of service.
This is a graph showing the average number of seconds per video element (spc, seconds per clip) for the SH videos up through SH110. There isn't as much interesting about it mathematically as the one on process time above, but let's see if there's anything else that can be gotten from it. Open the graph up full size if you want to follow along; this one's more squintable, but it's still easier to look at 110 data points when the bars have more than a pixel each.
The first look shows that there's a lot of variation in the sample space, but that spc generally tracks better with time than with video style. The second is that in that regard, there is a pretty uniform falloff in spc from about SH034 to SH054, and another, less notable, drop in average in the early 90s. The second one is easy to explain; I switched editing environments and was more able to employ shorter cuts, since I wasn't restricted to using only clips longer than 15 frames/0.5 sec, or using exactly the clip as cut, modulo any crossfading with the next one in sequence. The first drop might be attributable to re-joining the .org, around SH043, and picking up more pressure to cut closer and make internal synch secondary, but the trendline does go back a couple months even before that. The .org may have contributed to this trend and pushed it forward, but I was already doing the things that resulted in a dropping average spc even before I got my delusions of competence reset.
The video that this trend starts on may provide a clue as to why it started. SH034 sucks. It sucks hard, and I became aware of it doing so soon after the video finished. In reaction to a video that was a pretty good idea coming out like absolute garbage, I did a deep and thorough re-examination of everything about my process to determine where I went wrong, and what I'd need to do to improve and avoid this kind of situation in the future. One potential solution path was to change editing environments, but the trial for Adobe Premiere fucked up my capture board and kind of put itself permanently off-limits. I still have a Verbot against using Adobe editing products as a result of this. The other solution path -- since, as noted in the video entry, many of the problems came from a lack of source and cocommittant overuse of filler -- was to:
a) be more aggressive in gathering source, and conscientious in tracking source volume
b) be more proactive in editing long songs
c) be more willing to cancel videos in progress, especially for source availability reasons
All these things contributed to a falling average spc. Part b) probably the least, but a song that's 30 seconds shorter because a repeated chorus got cut out has 30 fewer seconds that need to be papered over with 4-second filler cuts. Part c) kind of disappears in the results, but there was a Linkin Park video after SH035 also using Yumede and a Nevermore video after SH061 also using WHR that never saw the light of day because they were burning through the few remaining good cuts at a rate too fast to be sustainable.
Part a) was really the most significant, though, and though I was still working from subtitled sources for nearly everything after SH034, the focus really became on getting all of the frames that I would need, and nothing else, in each clip taken rather than "let's just grab every continuous extent without subtitles on it that MovieStar will accept". Of course, I was still taking everything, but in that flensing process, naturally grabbing more smaller cuts that I might have neglected before. The more one-second interrupted-action cuts available, the fewer six-second pans need to end up in the final product. These changes necessarily took a while to accumulate, but over that six-month, 20-video stretch, a lot of effort and introspection was put into continuously improving the process, which paid dividends further down the line; dropping the average spc into the minimum possible range for AMV with MovieStar was pretty much a side effect, but it makes for a nice trailing indicator. Your videos won't get better if you just deliberately reduce your spc, but as you improve, your spc will trend down towards the minimum compatible with your style and your editing gear.
Stuff like this shows the reward of keeping stats on process; you never know when you're going to have a statistically-significant sample space on your hands, and at that point it becomes interesting to look at the numbers and see what you didn't notice happening while you were making all those videos. These are the only tools I have that are of real use; only total number of video elements is tracked in addition to these, and that's just (spc x however long the song is), which is a bad indicator for what kinds of projects are under survey and useless for everything else. If there's some other tool that you think would suit your process development to track, invent it and track it.
This is a graph showing the average number of seconds per video element (spc, seconds per clip) for the SH videos up through SH110. There isn't as much interesting about it mathematically as the one on process time above, but let's see if there's anything else that can be gotten from it. Open the graph up full size if you want to follow along; this one's more squintable, but it's still easier to look at 110 data points when the bars have more than a pixel each.
The first look shows that there's a lot of variation in the sample space, but that spc generally tracks better with time than with video style. The second is that in that regard, there is a pretty uniform falloff in spc from about SH034 to SH054, and another, less notable, drop in average in the early 90s. The second one is easy to explain; I switched editing environments and was more able to employ shorter cuts, since I wasn't restricted to using only clips longer than 15 frames/0.5 sec, or using exactly the clip as cut, modulo any crossfading with the next one in sequence. The first drop might be attributable to re-joining the .org, around SH043, and picking up more pressure to cut closer and make internal synch secondary, but the trendline does go back a couple months even before that. The .org may have contributed to this trend and pushed it forward, but I was already doing the things that resulted in a dropping average spc even before I got my delusions of competence reset.
The video that this trend starts on may provide a clue as to why it started. SH034 sucks. It sucks hard, and I became aware of it doing so soon after the video finished. In reaction to a video that was a pretty good idea coming out like absolute garbage, I did a deep and thorough re-examination of everything about my process to determine where I went wrong, and what I'd need to do to improve and avoid this kind of situation in the future. One potential solution path was to change editing environments, but the trial for Adobe Premiere fucked up my capture board and kind of put itself permanently off-limits. I still have a Verbot against using Adobe editing products as a result of this. The other solution path -- since, as noted in the video entry, many of the problems came from a lack of source and cocommittant overuse of filler -- was to:
a) be more aggressive in gathering source, and conscientious in tracking source volume
b) be more proactive in editing long songs
c) be more willing to cancel videos in progress, especially for source availability reasons
All these things contributed to a falling average spc. Part b) probably the least, but a song that's 30 seconds shorter because a repeated chorus got cut out has 30 fewer seconds that need to be papered over with 4-second filler cuts. Part c) kind of disappears in the results, but there was a Linkin Park video after SH035 also using Yumede and a Nevermore video after SH061 also using WHR that never saw the light of day because they were burning through the few remaining good cuts at a rate too fast to be sustainable.
Part a) was really the most significant, though, and though I was still working from subtitled sources for nearly everything after SH034, the focus really became on getting all of the frames that I would need, and nothing else, in each clip taken rather than "let's just grab every continuous extent without subtitles on it that MovieStar will accept". Of course, I was still taking everything, but in that flensing process, naturally grabbing more smaller cuts that I might have neglected before. The more one-second interrupted-action cuts available, the fewer six-second pans need to end up in the final product. These changes necessarily took a while to accumulate, but over that six-month, 20-video stretch, a lot of effort and introspection was put into continuously improving the process, which paid dividends further down the line; dropping the average spc into the minimum possible range for AMV with MovieStar was pretty much a side effect, but it makes for a nice trailing indicator. Your videos won't get better if you just deliberately reduce your spc, but as you improve, your spc will trend down towards the minimum compatible with your style and your editing gear.
Stuff like this shows the reward of keeping stats on process; you never know when you're going to have a statistically-significant sample space on your hands, and at that point it becomes interesting to look at the numbers and see what you didn't notice happening while you were making all those videos. These are the only tools I have that are of real use; only total number of video elements is tracked in addition to these, and that's just (spc x however long the song is), which is a bad indicator for what kinds of projects are under survey and useless for everything else. If there's some other tool that you think would suit your process development to track, invent it and track it.
Friday, October 9, 2009
math, graphs, and process crap
This is process stuff that maybe ought to be in my .org journal, but I can use pictures here, and not there.
This is a graph of the production time officially noted for every SH video so far. Let's see what's of interest. (open full size if you actually want to follow along, don't just squint at the preview.)
The first and most striking thing is that there is a sine wave rather clearly apparent in the results, with a period/wavelength of approximately 9 videos. This is not perfectly consistent, but it's remarkable that a pattern like this is detectable at all. Even from someone (perhaps one of the few) who keeps stats on their process, it's really weird to see an emergent mathematical pattern in the data.
The second is that most SH videos finish within 20 hours of official start of work, and nearly everything is done within 40 hours of work. This helps explain the frantic pace of completion in the fall of 2002 and winter/spring of 2003, when I was job-hunting and GRE-prepping about 25 hours a week and spending about 25 hours on AMVage. The third is that there are quite a few videos, usually bunched together, running well over 60 hours, but this behavior disappears entirely after SH053. What happened after SH052 that resulted in this sort of spike disappearing?
Looking at where the spikes are, and what videos are represented, there is a simple formula at stake: videos that spike out were produced from digisubs, largely or entirely, and were all done over at least 10 episodes. That the spikes exist, and that those on the demos aren't even higher, is an artifact of changes in the clipping process and how records were kept.
SH videos have always been assembled out of clips rather than from regions of episodes selected in the editing environment. However, the process by which these clips were created has changed several times, and until SH093 when DVD rips came in at long last, some of the stages were dependent on whether I'd capped the video or was using someone else's encode. Up until SH052, the digisub process went like this:
- render source file to MPEG2 (usually; some stuff for demo 1 was done to MPEG1 because that was what I was using at the time) with TMPEG
- clip in MovieStar, producing full-quality MPEG2 clips and low-quality MPEG1 clips for drafting (videos from SH020 to SH092 were drafted with MPEG1 clips, due to problems synching SH019, then reassembled from the appropriate MPEG2 source for the final build)
After SH052, the process went like this:
- clip in Virtual Dub, processing the .avi to 640x480
- render clips to MPEG2 with TMPEG
- produce drafting versions in MovieStar
From the journal at the time of the change:
"I'm trying out a new clip-collection process on the current video as kind of an experiment. With my current hardware, I need to put in 17-18 hours of processing time per ep before I can even start thinking about getting clips. I'm trying now to make clips in VDub, run 'em through TMPEG to make the HQs, then make the LQ draft versions in my main editor. This is all attempting to save time, on the proposition that even if I get 3 minutes of usable source from an ep, that's 19 or so minutes that I'm not able to use in the video and shouldn't waste time working with."
This held up, and the precipitous drop after SH052 is notable; only two later videos -- one involving a lot of building from manga cuts, and the other thanks solely to some encoding mistakes -- even go above 50 hours, while before this it was virtually guaranteed that a "serious" video would require more than 60 hours. The sole reason for this was the extended render time on Keystone, which has been noted here, below, as a 500MHz K6-II with less than 200MB RAM. As noted, each episode represented between 10 and 18 hours of effectively dead time running the render, which all went into the production stats, since this was effectively the same step as capturing the source, which was what the process tracking was initially built on. When this is taken out by clipping in VDub, the resulting stats are a hell of a lot closer to the actual attention time given to the video; speed was improved along with tracking accuracy.
The demos (demo 2 and 3), incidentally, are where they are, despite each using 20-30 episodes' worth of source, because common production time was reckoned proportionately on each demo for the videos included. Each video has about four hours of unique production work, something that you can also pick up by looking back at demo 1; the rest of those 70-95 hours are its share of the rendering and clipping that produced the source pool. If that production time was counted in full on each video, the demos would look like each video was the end product of 250-350 hours of work, which is even less accurate as far as effort goes.
Thankfully, all this is in the past. The limitations of drafting, NTSC-TV framerate, and cuts no shorter than 15 frames are no longer a part of how I make AMVs. A good school in many ways, but one I'm glad to be out of.
This is a graph of the production time officially noted for every SH video so far. Let's see what's of interest. (open full size if you actually want to follow along, don't just squint at the preview.)
The first and most striking thing is that there is a sine wave rather clearly apparent in the results, with a period/wavelength of approximately 9 videos. This is not perfectly consistent, but it's remarkable that a pattern like this is detectable at all. Even from someone (perhaps one of the few) who keeps stats on their process, it's really weird to see an emergent mathematical pattern in the data.
The second is that most SH videos finish within 20 hours of official start of work, and nearly everything is done within 40 hours of work. This helps explain the frantic pace of completion in the fall of 2002 and winter/spring of 2003, when I was job-hunting and GRE-prepping about 25 hours a week and spending about 25 hours on AMVage. The third is that there are quite a few videos, usually bunched together, running well over 60 hours, but this behavior disappears entirely after SH053. What happened after SH052 that resulted in this sort of spike disappearing?
Looking at where the spikes are, and what videos are represented, there is a simple formula at stake: videos that spike out were produced from digisubs, largely or entirely, and were all done over at least 10 episodes. That the spikes exist, and that those on the demos aren't even higher, is an artifact of changes in the clipping process and how records were kept.
SH videos have always been assembled out of clips rather than from regions of episodes selected in the editing environment. However, the process by which these clips were created has changed several times, and until SH093 when DVD rips came in at long last, some of the stages were dependent on whether I'd capped the video or was using someone else's encode. Up until SH052, the digisub process went like this:
- render source file to MPEG2 (usually; some stuff for demo 1 was done to MPEG1 because that was what I was using at the time) with TMPEG
- clip in MovieStar, producing full-quality MPEG2 clips and low-quality MPEG1 clips for drafting (videos from SH020 to SH092 were drafted with MPEG1 clips, due to problems synching SH019, then reassembled from the appropriate MPEG2 source for the final build)
After SH052, the process went like this:
- clip in Virtual Dub, processing the .avi to 640x480
- render clips to MPEG2 with TMPEG
- produce drafting versions in MovieStar
From the journal at the time of the change:
"I'm trying out a new clip-collection process on the current video as kind of an experiment. With my current hardware, I need to put in 17-18 hours of processing time per ep before I can even start thinking about getting clips. I'm trying now to make clips in VDub, run 'em through TMPEG to make the HQs, then make the LQ draft versions in my main editor. This is all attempting to save time, on the proposition that even if I get 3 minutes of usable source from an ep, that's 19 or so minutes that I'm not able to use in the video and shouldn't waste time working with."
This held up, and the precipitous drop after SH052 is notable; only two later videos -- one involving a lot of building from manga cuts, and the other thanks solely to some encoding mistakes -- even go above 50 hours, while before this it was virtually guaranteed that a "serious" video would require more than 60 hours. The sole reason for this was the extended render time on Keystone, which has been noted here, below, as a 500MHz K6-II with less than 200MB RAM. As noted, each episode represented between 10 and 18 hours of effectively dead time running the render, which all went into the production stats, since this was effectively the same step as capturing the source, which was what the process tracking was initially built on. When this is taken out by clipping in VDub, the resulting stats are a hell of a lot closer to the actual attention time given to the video; speed was improved along with tracking accuracy.
The demos (demo 2 and 3), incidentally, are where they are, despite each using 20-30 episodes' worth of source, because common production time was reckoned proportionately on each demo for the videos included. Each video has about four hours of unique production work, something that you can also pick up by looking back at demo 1; the rest of those 70-95 hours are its share of the rendering and clipping that produced the source pool. If that production time was counted in full on each video, the demos would look like each video was the end product of 250-350 hours of work, which is even less accurate as far as effort goes.
Thankfully, all this is in the past. The limitations of drafting, NTSC-TV framerate, and cuts no shorter than 15 frames are no longer a part of how I make AMVs. A good school in many ways, but one I'm glad to be out of.
Subscribe to:
Posts (Atom)