If MKVs are problematic, just use MP4.
Is it really needed for high-quality encodes? How much space would be saved e.g. per minute? EDIT: If 128kbits is used instead of 192kbits, that would save 14MB per 30 minutes of video - an amount which would add only ca. 2 minutes to my upload time (uploading at 100KB/s). Not enough to justify the hassle, imo.
Seems like x264vfw is too old (?) so it doesn't know about the --input-range option. You could try updating it, but it probably won't help...
Just use the following: encode.rar
Extract (WinRAR/7-Zip/...) and use the batch file. Edit it to change the parameters.
Metroid Zero Mission stores the stereo setting in its SRAM file, so I hacked the .vbm file (changing the byte at offset $14 to $02) to let it play from reset and SRAM. Unfortunately the movie desyncs. Maybe the amount of lag is different, or the RNG is changed.
I've read that the appropriate dimensions are:
SNES - 256x240 OR 256x224;
VBA - 240x160.
And for the sample aspect ratio:
SNES - 5:4
VBA - ??? (The page I'm looking at doesn't specify).
The GBA uses a dot matrix display with square dots, so that 240x160 is already the aspect ratio (3:2 after reducing the numbers).
The SNES, like any other console hooked up to the TV, depends on the characteristics of the TV. It may output 256×224 pixels, but how those are displayed is another matter. (In fact, raw emulator output is too narrow because artists accounted for the stretching!)
A classic SD TV signal contains 525 lines per frame. The first 262.5 lines are the first "field" and contain the even-numbered lines of the frame. The remaining 262.5 lines are the second field, drawing the odd-numbered lines of the frame. By transmitting half a line in the first field, the second field's lines end up being drawn interlaced (vertically shifted) between the lines of the first field. (And the second field's half-line shifts it back to the first field's positions.) The fields are drawn 60000/1001 times per second (b/w TV was exactly 60 fields per second, but color TV needs a little bit more time), and the result is a full frame of 525 lines at 30000/1001 (ca. 29.97003) frames per second. There are no discrete pixels in a line; all you have is an analog voltage (=brightness) curve for each R/G/B electron gun. There's always a little bit of "smearing" (blurring) at the edges.
Most consoles twist this signal a bit. The frequency can be different (SNES' is in fact slightly higher than 60) and most importantly, the normal mode is to omit any half-lines. The result is that there's no vertical shifting; each field is drawn over the previous one, resulting in ~60 frames per second with faint black scanlines where the interlaced lines would've shown up. The number of pixels per line simply means that the console changes the signal that many times per line. You can displays 256 "pixels" per line, all of them of equal size... or 257, 258, 259 etc. with each of them also of equal "pixel" size because the TV is using much smaller phosphor cells. The final aspect ratio is always 4:3 because that's the ratio of the screen's width and height.
The NTSC-encoding unit of the SNES can change the signal 512 times per line; it's just that the video unit can't create "transparencies" (color math) in those video modes, so most games use the 256-pixels-per line modes. (This can even be toggled per line: Secret of Mana 2 uses hi-res mode for text boxes). (Some games like Kirby's Dreamland 3 or Jurassic Park use alternating vertical lines in this mode to create fake transparency - they use the fact that an SD TV won't display pixels as discrete units.) The standard number of lines per SNES frame is 224, or 239 if the game enables overscan mode (useful for PAL TVs). The SNES can also go back to interlace mode; in that case the number of lines is doubled (448 or 478); see RPM Racing for an example (it looks good for static screens and bad in motion). Just to be sure you should always record BizHawk/SNES9x video in hi-res mode.
So for best results the 512x448 emulator output height should be padded to the fully visible NTSC raster height (~483 lines), then it should be stretched horizontally to a 4:3 ratio, and then you can remove the excess black lines. (Or you can just be lazy and bilinear-stretch 512×448 to 1440×1080.)
(Btw. there's even a way to get a 4:3 resolution with "nearest neighbor" scaling: x=7*256 and y=6*224; unfortunately this resolution (1792×1344) can't be displayed by most PC monitors yet.)
inavojo wrote:
So, if I keep everything else the same (including the dimensions of 2048x1796), will the video's quality be similar to what the NES looks like?
Well, imo any video clip that has at least 1080 lines will probably be fine.
This is what I would do: Watch the video (muted or with headphones) while recording my voice with Audacity or another audio editor; edit the audio; combine gameplay audio and voice in the audio editor to a single audio file; compress file (e.g. with lame), mux compressed audio into encoded video.
inavojo wrote:
Is there any way around this, that won't compromise the visual quality?
It doesn't really matter what the specs of a system are once you go beyond a certain level of faithful emulation; what matters is how hard it is to emulate. A good N64 emulator will be slow, too. Even a puny 6502 can be slow.
In case of the Saturn it's probably because it has more system components than the N64 that need to be synchronized.
In VirtualDub you can just configure the dialog like this:
(Note that the "VirtualDub hack" checkbox is required for VirtualDubMod; I haven't tested it with the regular VirtualDub. If you use x264vfw in other applications, remove that check.)
Replace <keyint> with a number; it's described on that page.
The command line is actually the most flexible option; you can write batch files if you don't always want to type it out.
encode.bat:
@echo off
x264 --sar 7:6 --crf 20 --keyint 600 --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 %1
Now you can execute it with "encode dump.avi" from the command line or drag'n'drop dump.avi onto the batch file in Explorer.
It should also be noted that I am using VirtualDub for this purpose (it is my understanding that this is all I will need; please correct me if I am wrong). [...]
- I am looking to encode this video to 1080p HD, if possible (720p, if not). [...]
- I am using x264 (64-bit) with VirtualDub (64-bit).
Note that for advanced video effects Avisynth is a popular tool; for that it'd probably best to use a 32-bit toolchain. VirtualDub can handle the resizing though; you just set "Video -> Full Processing Mode" and add a resize filter.
inavojo wrote:
At the bottom where it says "Use command line", I copypaste:
x264 --sar <PAR> --crf 20 --keyint <keyint> --ref 16 --no-fast-pskip --bframes 16 --b-adapt 2 --direct auto --me umh --merange 64 --subme 10 --trellis 2 --partitions all --input-range pc --range pc --rc-lookahead 250 --no-dct-decimate --tcfile-in times.txt -o video.mp4 in.avi
... as shown in the "Encoding" portion of the Encoding guide. I enter it exactly like that, without changing anything (which I'm fairly certain is the root of my problem).
That pasted text is a command-line to be used in a console window (like that of cmd.exe), and you need to use actual parameters for "<PAR>" etc. (open cmd.exe, navigate to where x264 is and use "x264 --fullhelp |more" to see all options).
If you're using VirtualDub then you can select the CRF and SAR values through that; also remove the "-o video.mp4 in.avi" part because files are handled by VirtualDub. You probably don't need the "x264" at the beginning either.
It's because we have no known bugs. It gives a strong incentive for certain types to point out, "Aha! Look, bsnes does have bugs!"
And, you know, it does. I never said it has no bugs. Zero bugs ≠ zero known bugs. I'm at zero known bugs because any time I find one, I fix it right away.
But nine times out of ten, when bugs are reported around here, they are confirmed to also occur on hardware. bsnes is to the point where it faithfully recreates very minor glitches like a single 8x1 tile line blinking at the very bottom right of the screen in a game.
I don't have an extraordinary amount of time, and I don't like wasting it chasing false bug reports. That's happened more times than I can count.
As far as evidence to reproduce bugs: I want a picture of the game running on real hardware, yes. I've seen bugs caused by copiers and flash carts (eg Speedy Gonzales), other emulators avoid bugs (ZSNES and Dragon View is a good example), etc. And I also want a detailed description of how to trigger the bug. This information helps me to reproduce the issue, and to fix it. Once it's reported here, anyone on the forum can test and confirm/deny it. So the original submitter isn't required to go buy the game and get out the digital camera. Many people here are happy to help test bug reports.
Yes.
I see games as a labyrinth designed by the developers, with the ending in the middle. For a speed-oriented TAS it doesn't matter how you reach this ending (breaking the walls, teleportation, ...), just that you do. The TAS spending the least of the viewer's time doing that wins. The only advantage of timing based on input file length is that calculating the TAS length can be (not reliably) automated; note that the viewer wouldn't even see a difference if the emulator wouldn't announce the input file's end.
Byuu will want a 10-page report and a picture of you playing it on real hardware, along with a video of you playing it on real hardware, and a video capturing that before he'll accept a bug report.
(Note that the "VirtualDub hack" checkbox is required for VirtualDubMod; I haven't tested it with the regular VirtualDub. If you use x264vfw in other applications, remove that check.)
