Point taken. I didn't take into account how awfully small resolution some of these early game systems have.
I don't find it strange that lossy compression movies would be bigger, though. I am more surprised that lossless codecs can compress them so well.
I told you exactly what to do... it doesn't get simpler than this.
Example:
x264 --preset veryslow --crf 25 --acodec copy "Turtles in time.avi" -o "Turtles in time.mkv"
Also, if you would post your command line and errors, it would be easier to help you.
Looks like you forgot the input file.
x264 --preset <your_preset> --crf <your_crf> --acodec copy "<input>" -o "<output>.mkv"
Replace <input> with your input file and <output> with the name you want for the output file.
Then execute that command line.
...
3. select ffdshow to compress in x264 with some AviSynth settings there
4. save to AVI ...and thats all
...
Regardless of everything else, this is something you must not do.
For the compression step, download x264. I tend to use the one at http://x264.fushizen.eu because it has audio features built-in (no need to mux the compressed file later).
If you're going to use avisynth, select the 32-bit version. Otherwise, and if you run a 64-bit OS, choose the 64-bit version.
If you plan not to upload the compressed movie to YouTube, you can choose the 10-bit version. This is likely to be slower than the 8-bit version, but the compression should be greater.
Otherwise choose the 8-bit version.
At the command-line, type
x264 --preset <your_preset> --crf <your_crf> --acodec copy "input" -o "output.mkv"
To get the list of presets, google or type x264 --help. This option controls the speed. The slower, the better compression (avoid ultrafast and placebo). Replace <your_preset> with this value.
Then experiment with the crf value. The lower, the better quality, but the higher file size. So choose what YOU find the best tradeoff between quality and filesize. Default is 23.
"input" is the file to encode.
"output" is the filename of the output (do NOT put .avi at the end).
This should compress your file for you.
There should also be some encoding guide somewhere?
Also, this does not resize the video in any way or form. If you want that, you can add --vf resize:width,height
There are Great parts, but with the cutscene-like-Loading-screen not emulated properly, it just looks liek you skip to places. I know some of those are cutscenes that are skipped, and that's fine, but i think we may need to wait until Dolphin can Emulate Load times properly. That being said, this was an awesome run!
We can still do unofficial runs until it's fixed, though ^_^
For YT encodes of regular gameplay vids I dump from emulator with CamStudio codec and then reduce framerate in VirtualDub, compressing with Xvid (best quality settings) and upscaling a frame by 4 with nearest neighbours method.
That seems like a good way to degrade the quality a lot?
Preferably one shouldn't even upscale.
And compressing with xvid seems like ... a bad idea. x264 will indeed compress a lot better than xvid.
Or perhaps it's a product issue under Win 8? Who can say? At this point, I think it is best to wait until at the very least the Beta before trying to lay the blame anywhere and attempting any fixes.
In other words, wait with those bug reports until at least the beta ;)
Hmmm. This brings up many interesting points.
It doesn't matter how the discs are emulated, most likely, since they will differ from the original anyway (as some has mentioned, there are different models with different lasers and so on).
Also, what is a potential runner acquired a SPECIFIC cube system just to take advantage of certain bugs? Why shouldn't emulation be able to do that?
So are we going to...
...choose a fixed speed (none/average), and ignore all possible improvements we might achieve due to the hardware differences?
...or allow some type of variable speed in order to maximize abusing the hardware?
Also, I do believe emulating is the same as mimicking the output of device that is being emulated as someone mentioned, and simulating is the same as mimicking some device's internal state.
Many emulators have had improvements over the original hardware in some way or form (texture packs for n64, for example), so it isn't "purely" mimicking the system. SNES emulators, I believe.
But this is interesting, and potentially scary.
Does the reduced loading times just means that the emulator has better hardware / is bettering upon the original hardware, or is it simply because there is a load of stuff that it doesn't emulate properly?
You don't just download a random codec pack (or two) from a random website and install it. You download a codec pack with a good reputation. AFAIK the k-lite codec pack is both comprehensive and trustworthy, so there shouldn't be much problem in using it. (Of course there are other similar codec packs.)
TBH, just look at all the stuff K-Lite contains. Lots and lots of codecs. Codecs tend to interfere with each other in a lot of players. That is why I can never recommend K-Lite.
In fact, here is a quote from Dark_Shikare, head dev on x264:
http://forum.doom9.org/showpost.php?p=1491258&postcount=16
Where he points out some problems with K-Lite.
Codec packs are generally known to be bad. You should only need CCCP, which is a collection of the known components to play the world's different audio and video formats.
Any DirectShow player should do, but I prefer Zoom Player.
So, codec packages are bad, yet you recommend a codec package... nice logic there.
Yes, and no.
Codec packs contains lots and lots and lots of codecs, and they usually interfere with one another.
CCCP is not just "another" codec pack. It contains much lesser components and up-to-date codecs to make everything work. It reduces the likelihood of upside down images.
It contains just a few components! Here is a list if you're interested: http://www.cccp-project.net/wiki/index.php?title=Advanced_FAQ
Codec packs are generally known to be bad. You should only need CCCP, which is a collection of the known components to play the world's different audio and video formats.
Any DirectShow player should do, but I prefer Zoom Player.
If you could jump directly to the last boss--or heck--even directly to the ending by utilizing TASing, where would the fun be in watching the game?
That would be utilizing TASing to its very extremes.
'Tis a sensible definition. But really, it's your run. You should not let yourself be discouraged by the fact that people disagree on a 100% definition.
It's all about what YOU want to do, right?
I believe that regardless of your definition, it should provide entertainment, and for me, that is enough.
Asking someone else to do stuff for you just because you don't feel like doing it is not nice (I know because I'm a jerk myself).
No, that's perfectly fine. After all, you're asking, not telling or demanding.
Telling someone else to do something because you're lazy may or may not be nice, depending on some external variables.
And jumping on people because they say they're lazy is not very nice. You haven't even looked at the work or seen any work of the actual speedrun. So in effect, you are prematurely judging someone.
And you're not being very nice to someone whose work you have yet to see. You should be encouraging great work instead of trying to shoo someone away. Like mentioned, you don't know if any good work will come out of this yet, so you are prematurely judging. Bad.
A completely optimized run we do not need! All we're saying is that we want to see a 100% run, even if it's nor perfect.
Non-TAS runners can do it, so why can't TAS runners?
You could always split it. It's easy with mkvtoolnix.
But hey, thanks for the new links. This makes me happy ^_^
Now to download and watch your WIP run!
EDIT: It cannot be said anything about it other than it was awesome! Slopiness and unoptimization be damned! This was one enjoyable run!
Is there a reason why you won't upload to, say, YouTube? At least there's a full screen option there :(
And I could easily download the video instead of watching on with the cpu-sucking flash plugin.
I'm looking forward to watching this when I have time, of course, but I just wanted to say that.
Patience is not the same as curiosity. And then some people like to know a little progress now and then. Nothing wrong with that.
They will be done when they will be done, of course, and there might not be any say of a final date. That's fine. But a little progress update fills in that void of showing how the project is nearing farther its completion.
Anyway, keep on working you guys. We will be as patient as need be. We do get this for free, after all, if at all.
