Well, I've spoken to the guys in #tasvideos... Aktan, being as crazy awesome as he is, is going to try encoding this himself, complete with hacking apart the input file.
Actually, I didn't say such thing, but I'm up to encoding it if there is a request for it.
I hate to nitpick, but the publication text isn't technically correct. Mega Man Battle Network 5: Double Team predates ZX by over a year by Japanese release date (at least according to GameFAQs).
I assume you mean the publication text is incorrect in stating that this is the first Mega Man game on DS?
Your videos look very impressive! And right now, you're still faster -- and I like the style of your intros.
as far as i know, Youtube transcodes everthing if the resolution is LESS THAN OR EQUAL to 1080p. If you encode with 1100p (for example by adding some black borders...), youtube should offer an "original" option.
(or you may take your current encode and double the solution, which would be 2160p... no current computer would be able to playback this, but youtube might create a better 1080p video)
YouTube shouldn't cause the flicker since the resolution sent is the same as the output, but I have heard about the reduce resolution problem YouTube does. I guess the only solution is your suggestion of original mode.
Edit: When I get some time, I'll check some things...
it doesn't really matter, I don't think anybody cares about this run.
You're wrong. Zeupar liked it and wanted it to be continued, hence why I encoded it for him. You also have been bugged to upload to YouTube so there is interest! Don't give up!
The reason why the sound is out of sync is because YouTube does not like some of the tricks used to make the file smaller. I had no idea that you would want it on YouTube though. I oculd make a version meant for YouTube, if you like.
What would be very helpful is if people actually posted what sort of x264 scripts they used for specific encodes (Instead of having to download the MKV and open it up in Mediainfo). I've also taken note that certain encoders will lean towards looser scripts than other encoders (For example, in HD encoding, mmarks uses a very barebones script that doesn't actually bother to squeeze down the filesize, generally ending up 4-8 times the size of a similar lossless encode. I, however, used an SD encoding script on my HD encodes, which does seem a bit overkill, but it generally halves the overall MKV size of the encode compared to mmarks's encodes).
By posting the scripts where? In the workbench thread? The workbench thread really isn't a place to claim encoding, explain what settings were used on your encode, etc. It's suppose to be about the TAS, not discussing about encoding methods and which is better or worse. On that note, there will probably be disagreements on which script is better/worse also. It be another argument. Lastly, just the line used to encode to H.264 does not show the whole picture. You would need to know the whole process to see what is wrong. Just like before, just cause x encode is smaller does not mean it is as good quality as y encode, even if it was encoded in lossless H.264. There could be filters added before encoded to H.264.
By the way, what does it matter on the size if it is being sent to YouTube anyway? Unless it hits the 20 GB file limit, who cares the file size as long as it is pretty much lossless or close to it. Everything will be reconverted anyway on YouTube.
I too have been a little confused about multiple encodes. If there are multiple encoding available prior to publication (which is odd when compared to how things were previously), how do I know which one of them became the official one when published? It's a bit hard to tell because inconsistent ways of calculating file size are used (powers of ten, not two). Then there are no hashes (SHA-1 etc.) provided, so it's impossible to tell if the downloaded file is okay (unless downloaded via Bittorrent). So here's my little request: provide hashes, so people can check integrity and separate different encodes easily. Hashes of all official encodes previously made should also be made available.
I also don't understand why more than one people start to encode the movies. Isn't that a waste of time and clock cycles? And why on earth does someone encoder provide Matroska and MP4 versions separately. That's waste of space. Matroska suffices in my opinion. I also think that archive.org links should be revealed only after publication. That way archive.org's bandwidth is potentially saved, because a few more people might download the encode via Bittorrent.
I make encodes even if there is one available, because I enjoy making encodes. While you could say it's a waste of CPU cycles, you could say that about anything else.
SHA-1 might be a good idea.
I provide both MP4 and MKV because people have different preferences on what they like. Just because you prefer MKV, does not mean other people do. In fact, it's actually a lot easier to convert from MP4 to MKV instead of the other way around.
Archive.org bandwidth will still be used from the torrent because we use webseeding.