As I watch, I'm noticing many issues like not recording from the very first frame, not turning frame skip to "0", not changing the sound to 48khz (or 44 in this case? can't remember), not setting enable null frames and dual-core in lagarith settings (which I'd recommend), rendering at 29,97 FPS instead of 30FPS, etc.
Well, is just a tutorial. People will know that the movie should played from the very first frame. The emulator was going slow due to the Screen Recorder. Thanks for the config of Lagarith. And as far as I know, 29,97 against 30 is clearly no difference. 30 FPS is just an approximation.
EDIT: I have already leave the link in the description of how configure the emulator.
Well, is just a tutorial. People will know that the movie should played from the very first frame. The emulator was going slow due to the Screen Recorder. Thanks for the config of Lagarith. And as far as I know, 29,97 against 30 is clearly no difference. 30 FPS is just an approximation.
The text tutorials already on this site make all of these things exactly explicit though, including issues like "how to record starting at the first frame". How is your guide more useful when it leaves these things out?
As far as the framerate goes, VBA dumps are at EXACTLY 60 fps. In order to put it on youtube, it must be less than or equal to 30 fps (otherwise youtube does another framerate conversion). You can get exactly 30fps by dropping every other frame frame or doing any of a variety of special blends that preserve motion. Any drop to 30000/1001 fps is going to have an occasional stutter in it. Not terribly noticeable; but then again, you didn't gain anything by choosing ~29.97 over 30 either.
Why are you resampling the audio to 48khz? Since it's originally 44.1khz, the only thing resampling it does is add another lossy conversion.
As I watch, I'm noticing many issues like not recording from the very first frame, not turning frame skip to "0", not changing the sound to 48khz (or 44 in this case? can't remember), not setting enable null frames and dual-core in lagarith settings (which I'd recommend), rendering at 29,97 FPS instead of 30FPS, etc.
Well, is just a tutorial. People will know that the movie should played from the very first frame. The emulator was going slow due to the Screen Recorder. Thanks for the config of Lagarith. And as far as I know, 29,97 against 30 is clearly no difference. 30 FPS is just an approximation.
EDIT: I have already leave the link in the description of how configure the emulator.
I'm sorry, but you are wrong. I've been using Vegas for a while too and lowering the FPS to 29.97 adds some nasty motion blur that can cleary be seen in your MMZ2 encode. I suggest (if you really don't want to switch to AVIsynth + VirtualDUB) that you render your encodes at its native FPS (60).
Well, is just a tutorial. People will know that the movie should played from the very first frame. The emulator was going slow due to the Screen Recorder. Thanks for the config of Lagarith. And as far as I know, 29,97 against 30 is clearly no difference. 30 FPS is just an approximation.
The text tutorials already on this site make all of these things exactly explicit though, including issues like "how to record starting at the first frame". How is your guide more useful when it leaves these things out?
As far as the framerate goes, VBA dumps are at EXACTLY 60 fps. In order to put it on youtube, it must be less than or equal to 30 fps (otherwise youtube does another framerate conversion). You can get exactly 30fps by dropping every other frame frame or doing any of a variety of special blends that preserve motion. Any drop to 30000/1001 fps is going to have an occasional stutter in it. Not terribly noticeable; but then again, you didn't gain anything by choosing ~29.97 over 30 either.
Why are you resampling the audio to 48khz? Since it's originally 44.1khz, the only thing resampling it does is add another lossy conversion.
When I used the .mp4 format with 44.1khz, YouTube desynced it. I don't know why but it just started to do it (stupid YT). Anyway, after looking why is this happening, some guy say that putting the Khz to 48 will fix it. It works!
When I used the .mp4 format with 44.1khz, YouTube desynced it. I don't know why but it just started to do it (stupid YT). Anyway, after looking why is this happening, some guy say that putting the Khz to 48 will fix it. It works!
I would expect no less from our glorious lord and master, Youtube. That being said, there might be other possible solutions as well:
Try a different muxer. Mp4Box comes well reccomended.
Try a different container. A lot of people have success uploading to Youtube in mkv.
Try a different audio codec. It "shouldn't" matter, but you never know with Youtube. Flac? Vorbis?
I personally have uploaded youtube at various framerates (30fps for most stuff, 29.9something for Turbo Grafix 16) all with avc+flac in mkv, and haven't had any audio desyncs, for what it's worth.
Anyway, I just put annotations and edited the description in the video-tutorial all the correction that has been told me here (such like "start the AVI recording from the first frame" and check the Lagarith Lossles option that Nahoc tell here).
If the game is actually widescreen, then primary/10bit444 wil be flagged as widescreen and 512 and HD (or whatever YT encode there is) will be widescreen.
See for instance Mega Man 10 "Mega Man".
For youtube, it's one of the many options used to fix flicker pattern problems. That sort of thing needs to be handled on a case by case basis; there's no one best blend/decimate.
For all others, encodes should be kept at native framerate.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
We had a long discussion on the use of aspect ratio correction a while back. It was decided that aspect ratio correction should only be used when it's obvious that it's necessary (e.g. to make circular artwork in the game appear properly round).
In some cases that might mean, in practice, that some encodes are uploaded in widescreen. For example a PC game that's 320x200.
But other than that, there's no way you can really do this without losing information or distorting the picture.
We should start TASing PSP games. Those are all 16:9... :P
Are the current-generation consoles the first ones to support 16:9 TVs and monitors (and hence such resolutions)? Or did the previous-generation ones also have support? (OTOH, TASing those is still far ahead and not necessarily a good idea because the property owners might take more notice the more recent games we TAS.)
We should start TASing PSP games. Those are all 16:9... :P
Are the current-generation consoles the first ones to support 16:9 TVs and monitors (and hence such resolutions)?
No. Both Wii and PS2 support widescreen to some extent, and probably others as well.
"For stream", what do you mean?
If youtube, the encode you send it isn't actually streamed; its read and transcoded by them. Their end sets all the streaming parameters. So CBR serves no useful purpose there. You should use VBR with no VBV/HRD limitations.
If _512kb, then yes, the encode is streamed, so technically speaking, you'll gain a bit of speed in seeking to areas that haven't been downloaded yet by setting some reasonable VBV parameters. But this will hurt quality, and I'm not aware of any major complaints about _512kb encodes without VBV limits. Better to leave it off.
For reproduction in YouTube. And thanks. And now have another question: Which Kbps are recommended in Average of VBR? I don't want a file size so big but I don't want to lose visual quality.
I think it's really better to use some sort of quality-based rate control. Exact sizes don't matter, and quality-based control picks up on differences between sources and blending methods.
I'm not familiar with your encoding software so I can't say how best to control it in this respect.