Posts for natt


Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
For comparison, here's my workflow for now. It has strengths and weaknesses: 1. Download movie file, dump. 2. Create avisynth script (usually this means just copy+pasting the old one). 3. Manually enter subtitle times, check a/v sync, trim length. 4. Prepare a slightly different HD script which includes HD resize, and 30fps conversion. 5. Hit the batch button. Automatically does: a. dedup first pass b. all audio encodes directly from the avs, including sample undelay for aac c. resize of _512kb encode, and AR labelling of other encodes d. all video encodes at specified CRF e. all muxing 6. Examine resulting encodes. If I don't like one, change CRF and repeat step 5 (only the needed parts will be redone).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Syncs on lsnes rr1-d5e2(bsnes v085 (compat))
  File: Yoshi's Cookie.smc
CRC-32: f2261787
   MD4: e550834cec525efbe81d236c4b1ac5c7
   MD5: 97fab1f4518e37856b1e57fe7a7427e6
 SHA-1: ec7cc80cedf9b5a1bf9b33fe2267d4d719b04ef6
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
the "9 bits" only comes into play when specifically storing palette colors. the individual graphics tiles themselves (in the case of the genesis) are all 4 bits per pixel, with 4 pixels combined into a 16 bit word and no wastage. accordingly, the only waste of space is in the palette ram itself; and it's likely there that the other 7 bits of each word just don't exist (since it's special purpose memory). the limiting design factor was likely the complexity of the video DAC rather than memory space, as even say, 24 bit color wouldn't have used up much more resources (so long as it was still a paletted mode and individual graphics tiles were still 4bpp).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
New build: http://www.mediafire.com/?mpxe68utrpn8al5 Fixes an issue with 2GiB split. 64 bit builds are also included (I don't test them as much though). If you make a dump with "audio in avi" on, and it comes out wrong (or you think it comes out wrong), send me the cfrdbg.txt file (should be in the same folder as dolphin.exe). Note that cfrdbg.txt is automatically overwritten every time you start a new dump, so make sure to send the right one.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Nach wrote:
Is there a difference between the two encodes?
They both actually link to the same file, looks like it was just a bit of confusion resulting from the slow editing earlier
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Syncs on BizWhack 1.0.4 interim
  File: Bionic Commando (U) [!].nes
CRC-32: 7425c3d1
   MD4: d995aea07258f39d81981c7443c3b12b
   MD5: 63178e365821fdb97129bfc8001e2100
 SHA-1: 68f46b6a6e9c093a146cdbcc079325ba572179d5
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
syncs on snes9x 1.43-rr v17
  File: Super Mario RPG - Legend of the Seven Stars.smc
CRC-32: 1b8a0625
   MD4: 67f4b7cb3201efa34ec9ca503718245e
   MD5: d0b68d68d9efc0558242f5476d1c5b81
 SHA-1: a4f7539054c359fe3f360b0e6b72e394439fe9df
Link to video
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
syncs on fceux 2.1.5 "old ppu"
  File: FinalF.nes
CRC-32: 362541ad
   MD4: fba31a73efa360faea5e61b83db26ca7
   MD5: 41588fdf17bffa9576c5777da012fd6c
 SHA-1: 6b8c4af9aeb1a07bb5954babe4509bc294792381
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Even before the doom source code release, you could run special TSRs while recording a demo (in the original executable) that could give "slow-mo" capabilities by screwing with timing. These demos would generally sync when played unaltered. I'd guess this was as early as 1996 or before; I know it was a topic of discussion at Compet-N (a website which hosted unassisted demo replays) early in that site's history.
Post subject: Flac is dead! Long live lord youtube!
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Numerous encoders and publishers have been reporting issues recently with flac uploads to youtube. Certain segments of audio are missing usually at the beginning, but scattered elsewhere as well. Until a fix is known, I would recommend no one use flac for youtube uploads. The alternatives that come to mind immediately are raw PCM and high bitrate vorbis, but I'm sure there are other alternatives as well.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
syncs on "VBA-RR v24 svn422"
  File: Metroid - Zero Mission.GBA
CRC-32: 5c61a844
   MD4: efc1f8fcd3afd9d17d2cd7d991ecba26
   MD5: ebbce58109988b6da61ebb06c7a432d5
 SHA-1: 5de8536afe1f0078ee6fe1089f890e8c7aa0a6e8
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I'm going to reprocess the audio tracks before publication. Other than that, did anyone want to get any subtitles or whatever on here? I don't think they're particularly needed, but if you want...
Post subject: YCgCo shootout
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Now that madvr actually supports YCgCo, I decided to give it a bit of a test. The run is 1247M. If you'd like the uncompressed dump I worked from, just give me a holler. I'm comparing a 10 bit 4:4:4: YCbCr (PC.601) encode to a 10 bit 4:4:4 YCgCo (fullrange) encode. The YCbCr encode was done at --crf 18 using my normal quality assessments for publication. The YCgCo encode was two-passed to match the YCbCr on size, and is within 0.2% of that target size. Command lines and x264 outputs:
avs2pipemod\avs2pipemod.exe -rawvideo=vflip 1247M.avs | dedupc\dedupc_color.exe NUL 60 1 240 160 yuv444p10le | x264\x264_64_10.exe --crf 18.000000 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --input-fmt raw --input-csp i444 --input-res 240x160 --input-depth 10 --output-csp i444 --colorprim bt709 --transfer bt470m --colormatrix bt470bg --input-range pc --sar 1:1 --tcfile-in temp\times.txt -o temp\hi10.h264 -

avs2pipemod\avs2pipemod.exe -rawvideo=vflip 1247M.avs | dedupc\dedupc_color.exe NUL 60 1 240 160 ycgco10 | x264\x264_64_10.exe --bitrate 337 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --input-fmt raw --input-csp i444 --input-res 240x160 --input-depth 10 --output-csp i444 --colorprim bt709 --transfer bt470m --colormatrix YCgCo --input-range pc --sar 1:1 --slow-firstpass --pass 1 --stats temp\ycgco.stats --tcfile-in temp\times.txt -o temp\ycgco1.h264 -
avs2pipemod\avs2pipemod.exe -rawvideo=vflip 1247M.avs | dedupc\dedupc_color.exe NUL 60 1 240 160 ycgco10 | x264\x264_64_10.exe --bitrate 337 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --input-fmt raw --input-csp i444 --input-res 240x160 --input-depth 10 --output-csp i444 --colorprim bt709 --transfer bt470m --colormatrix YCgCo --input-range pc --sar 1:1 --slow-firstpass --pass 3 --stats temp\ycgco.stats --tcfile-in temp\times.txt -o temp\ycgco3.h264 -
x264 output (YCbCr)
raw [info]: 240x160p 1:1 @ 25/1 fps (cfr)
timecode [info]: automatic timebase generation 1/60
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile High 4:4:4 Predictive, level 2.1, 4:4:4 10-bit
avs2pipemod[info]: invoking FlipVertical() ...
avs2pipemod[info]: writing 24551 frames of 240x160 BGR rawvideo.
avs2pipemod[info]: finished, wrote 24551 frames [100%].
avs2pipemod[info]: total elapsed time is 166.957 sec [147.050fps].
dedupc[info]: wrote 20309 out of 24551 frames
x264 [info]: frame I:67    Avg QP:32.76  size: 18998
x264 [info]: frame P:4730  Avg QP:38.65  size:  1533
x264 [info]: frame B:15512 Avg QP:41.77  size:   563
x264 [info]: consecutive B-frames:  4.5%  4.7%  9.2% 23.1% 11.7% 10.5%  6.3%  5.
5%  3.0%  5.0%  5.2%  4.8%  2.4%  2.3%  0.6%  0.4%  0.6%
x264 [info]: mb I  I16..4:  3.1% 11.7% 85.1%
x264 [info]: mb P  I16..4:  1.1%  1.3%  1.0%  P16..4: 28.8%  5.0%  7.1%  0.1%  0
.4%    skip:55.1%
x264 [info]: mb B  I16..4:  0.1%  0.1%  0.1%  B16..8: 16.8%  3.2%  2.9%  direct:
 1.6%  skip:75.3%  L0:48.7% L1:44.8% BI: 6.5%
x264 [info]: 8x8 transform intra:32.4% inter:11.0%
x264 [info]: direct mvs  spatial:97.5% temporal:2.5%
x264 [info]: coded y,u,v intra: 43.8% 30.4% 28.1% inter: 6.6% 2.8% 3.1%
x264 [info]: i16 v,h,dc,p: 64% 32%  4%  0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  6%  5% 84%  1%  1%  1%  1%  1%  1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 18% 16%  6%  7%  7%  7%  8% 10%
x264 [info]: Weighted P-Frames: Y:4.2% UV:3.0%
x264 [info]: ref P L0: 36.2% 10.4% 12.7%  3.7%  4.9%  4.0%  5.5%  2.0%  2.6%  2.
4%  2.8%  2.6%  2.9%  2.7%  4.0%  0.7%
x264 [info]: ref B L0: 65.3% 10.4%  6.6%  3.2%  2.6%  2.2%  2.1%  1.1%  1.1%  1.
1%  1.0%  1.1%  1.1%  0.8%  0.4%
x264 [info]: ref B L1: 89.1% 10.9%
x264 [info]: kb/s:337.09
x264 output (YCgCo second pass)
raw [info]: 240x160p 1:1 @ 25/1 fps (cfr)
timecode [info]: automatic timebase generation 1/60
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
avs2pipemod[info]: invoking FlipVertical() ...
avs2pipemod[info]: writing 24551 frames of 240x160 BGR rawvideo.
x264 [info]: profile High 4:4:4 Predictive, level 2.1, 4:4:4 10-bit
avs2pipemod[info]: finished, wrote 24551 frames [100%].
avs2pipemod[info]: total elapsed time is 152.812 sec [160.661fps].
dedupc[info]: wrote 20309 out of 24551 frames
x264 [info]: frame I:69    Avg QP:33.44  size: 18409
x264 [info]: frame P:4771  Avg QP:38.90  size:  1536
x264 [info]: frame B:15469 Avg QP:42.06  size:   558
x264 [info]: consecutive B-frames:  4.7%  4.9%  9.3% 23.0% 11.2% 11.0%  6.2%  5.
8%  3.2%  5.1%  5.4%  4.5%  2.3%  2.1%  0.4%  0.4%  0.5%
x264 [info]: mb I  I16..4:  2.9% 11.8% 85.2%
x264 [info]: mb P  I16..4:  1.2%  1.3%  0.9%  P16..4: 28.9%  5.1%  7.1%  0.1%  0
.4%    skip:54.9%
x264 [info]: mb B  I16..4:  0.1%  0.1%  0.1%  B16..8: 16.6%  3.2%  2.8%  direct:
 1.6%  skip:75.5%  L0:49.4% L1:44.1% BI: 6.5%
x264 [info]: 8x8 transform intra:31.1% inter:11.2%
x264 [info]: direct mvs  spatial:90.3% temporal:9.7%
x264 [info]: coded y,u,v intra: 45.5% 26.5% 33.1% inter: 6.5% 2.1% 3.7%
x264 [info]: i16 v,h,dc,p: 64% 31%  4%  0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  6%  5% 83%  1%  1%  1%  1%  1%  2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 18% 16%  6%  7%  7%  7%  8% 10%
x264 [info]: Weighted P-Frames: Y:4.5% UV:3.1%
x264 [info]: ref P L0: 36.2% 20.0% 15.7%  6.0%  5.1%  4.3%  3.8%  1.7%  1.4%  1.
2%  1.1%  1.0%  0.8%  0.8%  0.7%  0.1%
x264 [info]: ref B L0: 65.0% 16.1%  7.9%  3.1%  2.2%  1.6%  1.3%  0.6%  0.5%  0.
4%  0.3%  0.3%  0.3%  0.2%  0.1%
x264 [info]: ref B L1: 89.2% 10.8%
x264 [info]: kb/s:336.69
The encodes are on archive.org: Collection http://archive.org/details/GbaCastlevaniaAriaOfSorrowusajuliusVersionIn0438.9ByCpadolf YCbCr http://archive.org/download/GbaCastlevaniaAriaOfSorrowusajuliusVersionIn0438.9ByCpadolf/castlevaniaaos-tas-cpadolf_10bit444.mkv YCgCo http://archive.org/download/GbaCastlevaniaAriaOfSorrowusajuliusVersionIn0438.9ByCpadolf/castlevaniaaos-tas-cpadolf_ycgco.mkv The YCbCr encode looks slightly more reddish to me when I A/B view them (I guess we'll never get these things perfect...) Other than that, I wouldn't say either one is terribly better than the other. My conclusion is, don't bother with YCgCo for final encodes.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
New build: http://www.mediafire.com/?vhrsxi513z8g88r Yanked out a lot of useless stuff, fixed some stuff, added some stuff. Compiling: git patch serial is in the patches subfolder. You're on your own for the rest. Installing: Unzip the executables on top of an existing recent build (preferably 32 bit TAS-Input branch). Installing: Unzip the executables for the desired architecture (32 or 64 bit) on top of a suitable build (preferably TAS-Input branch, matching architecture). Features: If you turn on DSP "Dump Audio", you get the same crappy audio dump as always. DTK may or may not work in it, there can be gaps, etc. You also at the same time get a sequence of dump files which form a much more accurate audio dump. The sequence is split every time the audio frequency changes (can be 32k or 48k). This new dump should have perfect timing, but does not include DTK at all. If you turn on DSP "Dump Audio to AVI", and Video "Dump Frames", you get a an avi with both video and audio track. The video track will be time compensated to match the audio, which means occasional drops and/or dups. The audio track will be the same as the improved audio track in "Dump Audio", except that it's all combined to 48khz. The upsampler used is not very good. If you have on Video "Dump Frames" but not DSP "Dump Audio to AVI", you'll get a silent AVI file with each frame dumped once at an irregular framerate. Since AVI can't store VFR, you'll get a matroska timecodes file as well. This is the same video dump as in normal Dolphin, except now you get the information you need to reconstruct correct timing for it. There are also various debug text files that can be made. They're not likely to be useful. DTK support is planned for the future. The discriminating tasvideos encoder should use the separate dumps (which can both run at the same time, just turn on dump audio, dump frames, and turn off audio to avi), not the combined one. The combined one force-resamples audio to 48khz, which is not optimal if a game is 32khz. The combined one forces video framerate to 60:1 exactly (or 50:1 depending on region), which can result in slight dup/drop discrepancies if the real framerate of the game is one of the alternate framerates (say, 60*27000/26999). I'm currently working on a customizable VFR->CFR converter for avisynth which allows more control over the VFR->CFR process; you can see the error level and dup/drop levels of a particular VFR->CFR conversion, and tweak the parameters for a better one (which takes near zero time to do, as compared to redumping).[/s]
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Sounds good to me. The SRAM/savestate movies already have a category, and a "Hack" category could be added. I just wish these things could be done in less dramariffic maners...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
rog wrote:
Well i don't really want to see it put in some back corner. If that is really the only place it can be put, then i will be canceling it.
Every single "starts from SRAM" movie on this site is in the "Other" section. http://tasvideos.org/Movies-C4015Y.html http://tasvideos.org/Movies-Hacks.html Why would you make a movie that "starts from SRAM" and not expect it to end up in the "Other" section?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I think everything with 'starts from SRAM' gets placed in that section.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
Done. Check please. I guess I encode Genesis wrong, as it must be narrowed horizontally a bit, right? Must fix my script. I think I WILL reencode it. I hope today or tomorrow.
Looks good to me. I personally consider yt:stretch=4:3 perfectly acceptable for publication quality encodes, and would like to publish this. (You can always replace the youtube later if you're not happy with it.)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
How?
you add:
yt:stretch=4:3
as one of the 'tags' (used typically as the search parameters) this changes the aspect ratio without modifying the video, making it more correct (in this case)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Brandon wrote:
But I'm saying that many people, myself included, would like to edit these files with external programs. Why would the external tool have to be of my own creation? Plenty of these tools already exist.
Not quite what I was getting at. Change that phrase to mean "external tools that aren't BizHawk". All I'm trying to say is that if the text and bin formats both load identically in BizHawk, and both function identically in every way inside BizHawk, then why shouldn't they have the same extension? The external tools can sort it out amongst themselves which "subtype" they are.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Brandon wrote:
adelikat wrote:
To summarize Brandon's post: If an emulator had both a binary and a text file format. Would you want them to be the same extension and freely convertable? Or a different movie extension.
Explain what you mean by freely convertable please. If you mean that an emulator would be able to open either one without knowing what it is up-front, then yes, that's the other option as I understand it. Is there something more?
Well, unless you're directly editing it with external tools of your own creation, the two formats should behave identically right? So why should they have different extensions?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
Making HD.
Would you be able to add the tag yt:stretch=4:3 to that youtube HD?