Emulators with video capture and good sound emulation

I usually use BSNES for play testing, but SNES9X for YouTube videos, but it sounds like SNES9x doesn't do good pitch modulation. Am I just using an outdated emulator, or is SNES9x still like that. Or is pitch modulation supposed to sound like that, and BSNES sounds wrong?

None of them. The problem isn't the emulator, it's the capture mechanics that people use. Snes9x is the only emulator that actually can capture bitstream video and audio in the emulator without skipping frames, but you have to do it by first recording the SMV file, and then playing it back with the avi recording.

You need to capture the video with zmbv codec, integer rescale it to at least 720p60 and then upload the avi directly to youtube. Otherwise youtube will convert 240p60 into 360p30 and cut the audio fidelity by about half.

This is a lot of work to make sure the resulting output isn't garbage. If people use any of the standard video capture tools (eg OBS, Xplit) the video and audio will be lossy compressed by the capture software as it will record at the desktop volume, thus requiring normalizing the audio.

This is why youtube videos of emulated games tend to be terrible, because the video uploaded was compressed with h.264 and aac audio at lossy rates, and then youtube recompresses it a second time.
There is no way to get youtube to play lossless video/audio. However if you upload a lossless source (1440x1080 ZMBV 32bpp, keyframe roughly every 600 frames) you actually will run into a file size limit where youtube will flake out when it crosses about 2GB of data. So that's why I end up cutting videos into several pieces.

So from a preservation point of view, you can have the best emulator in the world, but if you capture it poorly, garbage in, garbage out. It is technically possible to capture h.264(4:4:4) in a lossless mode, but not many video tools can understand this as most h.264 video is 4:2:0. h.264 is what most USB-based capture devices use, and are likewise much more lossy than what you can do with an emulator.

I would actually love to have higan support a mechanic like the SMV file so that it could render an AVI, or invoke ffmpeg so that the resulting file could be uploaded to youtube in one step, but I don't think very many people have this use case in mind since video editing tools tend to balk at frame-based video and all want to work with time-based video (mpeg-2 or mpeg4 containers.)

TL;DNR version:
You either have to use an emulator that can record losslessly or you can use a high-accuracy emulator, but end up having to use lossy capture tools, so neither case is going to have the right audio.

Pad to 280x240, then scale nearest-neighbor to 560x480. If you pixel double before encoding, the 4:2:0 crap won't hurt. This leaves only YouTube's 30 fps limit on video smaller than HD, but that can be worked around by either frame-blending (so that flicker is handled in a least-astonishing manner) or exhibiting your video elsewhere.

I don't know what to use with Super NES emulation, but this is what I came up with for NES using FCEUX (SDL) and FFmpeg on Linux:

Or when making a lossless intermediate, replace out1.mp4 with something like -vcodec huffyuv -acodec copy out1.avi

Any chance of a bsnes-rerecording?

I think that's called LSNES, if I understood correctly.

You guys missed the point entirely. SNES9x sounds bad even when I'm not recording a video. I was asking if there was either a way to fix SNES9x's sound quality, or a video capture plugin for other emulators.

As far as I can tell, the comments addressed the feasibility of "video capture plugin for other emulators". In particular, I mentioned "rerecording" because an emulator with thorough support for key logs would be amenable to modification to support recording of a key log, such as Snes9x's SMV file, and then video capture from that key log.

Well, the ideal solution is retrofit Higan
1) retrofit higan with SMV support
2A) retrofit higan with either the ZMBV codec ala DOSBOX, or
2B) retrofit higan with being able to pipe a raw stream (-c:v rawvideo -c:a pcm_16le) to FFMPEG

FFMPEG and Youtube can read the ZMBV 16bpp or 32bpp without any trouble. Only the 8bpp indexed color mode has any minor issues, which you wouldn't use for SNES emulation anyway.

What I used with DOSBOX if I'm trying to force Youtube to not suck


This doesn't include scaling or aspect ratio correction, as typically I would cut/edit/crop/scale the video in virtualdub first. If I bypass that, it's instead


Needless to say these settings are extremely overkill and are meant really for video editing rather than straight to youtube, but if you upload it straight to youtube, it will work. This doesn't include aspect ratio correction or padding (see tepples example)

Basically youtube is a crapshoot, because they change things sometimes, and that results in files sometimes work when they are uploaded and stop working later. For example, I have a few videos I used the ZMBV codec for on youtube with no keyframes, and originally Youtube transcoded to all smaller formats automatically (eg 720p to 480p) and this worked fine, but then youtube seems to have switched to transcode-on-the-fly and without keyframes, you can't seek these videos. Likewise 4:4:4 h264 video will upload, and so will non-compliant frame-rates and levels will upload, but they will play at the wrong speed or will have no picture after the first 2 seconds.

The worst thing I discovered with youtube is that it drops frames during playback, so if you seek in youtube to say 1:00 it will not be 1:00 in the original video.

I know this doesn't address "why does the sound not sound accurately" question but what I'm trying to point out here is that there is not currently a way to capture accurate audio in an emulator, and even if you could, the average person doesn't know how to maintain that audio over their editing process, and then youtube will ruin it if you don't upload the footage at 720p60.

Just use BizHawk, it uses the bsnes core.

http://tasvideos.org/Bizhawk/SNES.html
http://tasvideos.org/forum/viewforum.php?f=64
http://tasvideos.org/forum/viewforum.php?f=52

I usually resize the video with Avisynth to >= 720p and encode the video/audio with x264 (or x264vfw in VirtualDub) and the audio with 192kbps MP3.

I'd suggest staying away from multi-emulator suites that don't write their own cores, because they tend to never update the libraries once they get them working because they're afraid of breaking them afterwords. In the case of Bizhawk it uses BSNES v87 from 2012.

Lsnes uses BSNES v85 from 2013.

(Those are the git import dates that I could find)

x264vfw/mp3 is probably the worst possible option (as it just keyframes h264 frames from a very old version of x264 from 2009.) ZMBV (from dosbox) produces the smallest lossless files for emulators. Lagarith or huffyuv produce much larger files because they are meant to be lossless intermediate files that you record to because raw uncompressed captures are too large for mechanical drives at HD rates.

Another codec that can be used as an intermediate is the camstudio codec but there are bugs in some versions of it so you have to use the same version of the codec to record and play, and not switch between the stand alone codec and the ffdshow version.

That's why I use the ZMBV codec for short things that can be broken up into chapters like RPG's. If you want to do one long video, your only option is h.264/aac or h.264/pcm but the latter, the audio is 8.8MB/minute alone.

Realtime encoding tends to put too much strain on the cpu, potentially causing jitter. What I did for dgen, when I needed Genesis recording, was add dumping support as individually LZO-compressed frames. This resulted in minimal dumping overhead, and quite acceptable space usage as well. For audio, I just told alsa to dump what it received to a wav file.

The Camshow codec uses lzo and delta frames (the bugs in some versions are the delta frames playback), ZMBV uses straight lz (via zlib.)

And yes, what you really want with software emulation is to playback the state of the emulator, not in real time, so it renders everything, at the correct framerate, and this is something that higan would be incredibly useful for.

And isn't that good enough?


I use ZMBV for recording (iirc BizHawk doesn't compress the audio). The x264vfw/mp3 combo is just for YT/Vimeo.

Kega Fusion uses a custom codec that essentially just stores whatever data is written to the video chips, resulting in really tiny lossless files and no meaningful extra CPU power during recording. When done you convert the file over with your favorite video processing software. That's probably a bit more work on software side (new video codec creation is probably not straightforward) than creating and then recording keylogs into a video.

That's basically what ZMBV does in indexed mode on dosbox, the changes to video memory are delta frames, and changes to palette are basically the only thing different in many frames.

A SNES-specific codec in a mpeg-2 or mpeg-4 container could actually store the proper framerate if it's time-based. However because the SNES output is > 256 colors, you wouldn't be able to just store the changes to the video memory because how the SNES works is closer to having 5 layers with color math (transparencies)

Basically the ideal mechanic is to use something like snes9x or performance-based bsnes forks to record the input, and then play back the input on higan to a lossless+scaled+aspect ratio correct output.



That's good enough for TAS, that's not good enough for quality. If you're trying to preserve the output, especially for mastering for another use, you need to use the most accurate builds.



I would never use mp3 for youtube because youtube will always transcode that to aac.

The examples I used above


That's based on settings that youtube recommends and thensome, a more conservative setting is
https://www.virag.si/2015/06/encoding-v ... th-ffmpeg/


The difference between the above and the below is CRF goes from 22 to 21, and audio goes from 384 to 512, and Google's recommended settings are on https://support.google.com/youtube/answer/1722171?hl=en

And vorbis. And opus. And you don't know which encoding or bitrate the viewer will get.

Chiptunes are a particularly bad match to any lossy codec at all; with some I can pass an ABX test even at bitrates well above the nominal "normal" audio "transparency" bitrate. The only conclusion I can come to, since you can't specify the codec, is to just not worry about it much.

Have you reported your listening test results on these killer clips to hydrogenaudio or wherever codec experts hang out nowadays?

It's still a GIGO rule. If you are wanting to make sure that the listener gets the highest fidelity audio, you have to upload it in PCM and and have the video at 720p (as I've stated several times already) otherwise Youtube will force the audio quality down.

I always find 240 video/audio (that gets converted to 360 by youtube) is extremely terrible, like the audio has been resampled to 16khz.