Posts for natt


Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
If you want to interest casual gamers, there must be an option to disable savestates (and slowdowns) for a movie (be it some special extention raher than .TAS). If anyone want's to highlight that he wasn't using ANY of so called cheats, he may show this movie. For now only Nestopia can provide movie free of save/loads.
That would just give false sense of security. There's no way to guarantee non-cheating from such a thing.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Thanks to rog, we have some more sync information on this. It does sync with the 3.0 official release build (and the "mystery build" is in fact 3.0 release 64 bit). The main two issues are: a) it was possibly recorded with idle skipping on, which can cause desyncing. b) it was recorded with wiimote, which was not well supported at the time, so it won't sync on new revisions. The main reason why I'm trying to collect this information is for future preservation; don't want someone to come back to this run in 3 years, try to dump it, and be left scratching his head.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Syncs on "Dolphin [TAS-Input] 3.0-381-dirty" (32 bit windows build); source to this is one of the alternate git trees tracked at the official repository. Settings are pretty usual (no idle skipping, single core, LLE DSP), except that it won't sync at all on OpenGL (?). No rom checksums; blame whoever invented scrubbed images for that. I cannot encode until I know how to work a/v sync. Have a few ideas rattling around, but nothing firm yet. It's not going to be easy =/ Any ideas on how to fix graphical glitches like this? (Lines in backdrop, especially the ones directly beneath the PC) http://img827.imageshack.us/img827/5189/muramoosea2.png Edit: looks like the glitches might be from AA. Well, that's an easy fix.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
Things like what?
Well, this would be getting more into downloadable primaries and _512kb, since our youtubes already "avoid" the issue by massively oversizing everything. If you scale 4:4:4->4:2:0 in avisynth without using chromainplacement parameter, you get MPEG2 chroma siting. If you then play that back in flash player as the _512kb, you get MPEG1 chroma siting, which means relative to how it should be, your chroma will be shifted half a pixel to the right. If you scale 4:4:4->4:2:0 with swscale, you get ??? To be honest I never really noticed it much. FWIW: vlc assumes MPEG1, mpc-hc with evr-cp assumes MPEG1, mpc-hc with madvr assumes MPEG2. Seems like no one is actually reading the bitstream flags.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
So youtube ignores the chromaloc flag, preferring to align the chroma properly?
I agree that MPEG1 placement makes more sense than MPEG2 placement, but when so many other things assumes MPEG2 placement... it can be a problem.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
zeromus wrote:
but youre not doing yourself a favor if youre wasting wishes for something of this magnitude to get revised in psxjin.
No wishes have been wasted. Just wanted to figure out what went wrong, and if it was a quick fix, to fix it. For anyone who happens to read this in the future, here's the executive summary: PSXjin MDEC decoding is wrong. It's probably not a 2 minute fix. The best solution would be to start from scratch with one of the more thouroughly investigated MDEC decoders: MAME psx core, mednafen psx core, PCSX-reloaded. jPSXdec is also a good source of information (although it doesn't actually implement exactly what we're looking for here).
Post subject: Youtube and chroma placement
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lossless h264 4:2:0 in mkv with chromaloc VUI flag. Other than differences in chromaloc flag, the actual video content is identical chromaloc 0 (mpeg2\mpeg4) Link to video chromaloc 1 (jpeg\mpeg1) Link to video What it "should" look like, more or less: Doesn't really matter to anything though. Chroma placement is so unreliable as it is. Edit: Did a similar test loading mp4 with the chromaloc positions into JWplayer, and it gave the same results (always JPEG/MPEG1, regardless of bitstream flag).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I took a quick look at both mednafen and pcsx-reloaded. Both use slightly tweaked JFIF coefficients, not quite the same but not nearly the magnitude of difference we'd be looking for. I decided to capture output from pcsx-reloaded and... it looks like the coefficients are not the problem. The colors in pcsx-reloaded are rather different than the ones in psxjin, and the pcsx-reloaded colors look much closer to the originals. But, those coefficients are almost the same ones as psxjin uses! (And the miniscule difference between them is not big enough for this). So there must be some other mdec error causing incorrect colors, perhaps something in the IDCT? Whatever it is, it's out of my league, and I doubt anyone else will be interested in fixing it. Meh. Edit: Note that the slight decrease of redness going from FMV->backdrop (especially visable in the pcsx-reloaded capture at the top left corner) is also visible in my analog cap from a PS2. So I think pcsx-reloaded probably has it mostly or completely right.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Well, here's a capture off my PS2, compared to psxjin. http://www.mediafire.com/?e1dbdcmsz38y33r [25MiB] I'm aware that this captured video has many... technical shortcomings. I was about ready to burst a few blood vessels just getting the capture to work at all. I think it's good enough to show the one thing that it needs to show: there is no colorshift when the FMV ends and texture backdrop begins. jpsxdec appears to use the same conversion coefficients that psxjin does, pc601, which doesn't look right. other things i've tried that don't look right include pc709 and an alternate matrix (labeled as "wrong") that's in the jpsxdec source code.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
It does seem like the per-game threads are rather long and unwieldy at times.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Syncs on VBA-RR v23.5 svn421
  File: Sonic Advance (U).gba
CRC-32: 63f70fd8
   MD4: e7a2cf5f3bfdf74fea2ae387561cd681
   MD5: 49ecc8ef1988e7ae81fbda1b4cf71eed
 SHA-1: d842afa7dd1e84de08addb94a51506f1bcafd551
Publication quality encodes available upon request. Link to video
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
For anyone interested in such things, here's http://www.mediafire.com/?5vsxm6d5fwnj34c the audio from the dump from 7:38:56.643 to the end, compressed as FLAC. The idea is to decide if the vorbis compression in the downloadables is sufficient... Edit: Got some feedback and am going to up aotuv to -q3 for the final encode. That won't be updated for a bit though...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Derakon wrote:
Using SDL would also pretty well lock you out of ever adding an N64 or PSX emulator core, let alone something more advanced; you need 3D acceleration for those.
You most certainly do not; the most accurate PSX graphics are done in full software (as well as PS2 graphics), and I have a hunch if there were any accurate N64 emulators out there, they'd have a soft graphics mode too.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Consider these not ready for publication. I hope to get the author's .srt track in at some point, as well as possibly better chapters, as well as possibly redump because an outstanding bug in psxjin was fixed. Archive.org collection http://www.archive.org/details/PsxFinalFantasyIxusaIn73712.28ByLil_gecko Primary[1.4GiB] http://www.archive.org/download/PsxFinalFantasyIxusaIn73712.28ByLil_gecko/finalfantasy9-tas-lil_gecko.mkv 10bit[1.4GiB] http://www.archive.org/download/PsxFinalFantasyIxusaIn73712.28ByLil_gecko/finalfantasy9-tas-lil_gecko_10bit444.mkv
Post subject: A Call for Chapters
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
The encodes are going along nicely; Normal and Hi10 are finished at about 1.35GiB each, and _512kb is processing. They look as good as anything on psxjin possibly could. 8 hours is a very long time. I've added a few chapters to the MKV: just the disk switches, the start, and the end. Most encodes have no chapters at all, and I don't think it's terribly necessary, but if someone wants to make more in depth chapter files with major game events, FMVs, bosses, or whatever you think is relevant, I can add that in.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
FractalFusion wrote:
Maybe it's just me, but I don't see a difference between the two screenshots other than that the top one has interface stuff on it. Besides, I don't think an off-by-one video dump is anything to worry about, if I understand correctly what you mean by off-by-one (I assume that means all the frames are consistently off by one).
What I'm meaning by "off by one", is that the screenshot (taken with the F12) key has everything shifted to the right one pixel. Video dumps are also like this. Watch the comparison video, it makes it pretty clear. Edit: Yes, it is the exact same frame, there's no issue there. If you shift over one pixel and then use AviSynth Subtract(), the two look exactly the same (except for the one pixel border on the right that's gone missing)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
It worked when I was dealing with 4.8G of sound when none of the command line pipings I tried did.
The main difference then would be that I'm using sox in the middle and you aren't, and that's what led me to my solution. Apparently, over 4GiB sox must also be told to ignore the wav header length:
avs2pipemod\avs2pipemod.exe -wav 3489S.avs | sox\sox.exe -t wav --ignore-length - -t wav - trim 4672s | neroaac\win32\neroaacenc.exe -q 0.25 -ignorelength -if - -of temp\aac.mp4
works fine
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
I use SoundOut in the avs.
SoundOut(\
output = "CMD",\
filename = "C:\...\out.m4a",\
executable = "C:\...\neroAacEnc.exe",\
prefilename = " -if - -of ",\
postfilename = " -q 0.25 -ignorelength")
Have you checked that the avs has sound the whole time? Avisource has a limit when opening wavs.
The original source is 3 Wav files with 2GiB splitting (psxjin output). The script previews correctly, and my vorbis audio dump works correctly (command line output looks fine, and the file plays correctly with correct audio and sync the entire way through). SoundOut() looks like loads of fun, but do you have any reason to believe it will actually behave differently in >4GiB cases? It's doing essentially the same thing as avs2pipemod; calling neroaacenc with audio coming off the stdin pipe.
Post subject: PSXjin: video off by one
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Top = printscreen from emulator (correct) Bottom = internal screenshot function output (incorrect) comparison video (lossless rgb x264) http://www.mediafire.com/?0bgdrnxowqihizu Error also occurs on all video dumps (not just internal screenshot function). ...
Post subject: nero AAC... 4GiB input limit?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
24347.420s corresponds to 4GiB of input data. Don't really understand why this is happening; the wav sox sends out has no length information (as it warns) and nero is given the -ignorelength parameter which makes it ignore the wav length fields and instead trigger on EOF. This command line has worked for other AAC encodes I've made... nero must internally count the number of bytes read and processed with a 32 bit int.
##EXECUTING##
##"avs2pipemod\avs2pipemod.exe -wav 3489S.avs | sox\sox.exe -t wav - -t wav - tr
im 4672s | neroaac\win32\neroaacenc.exe -q 0.25 -ignorelength -if - -of temp\aac
.mp4"##
*************************************************************
*                                                           *
*  Nero AAC Encoder                                         *
*  Copyright 2009 Nero AG                                   *
*  All Rights Reserved Worldwide                            *
*                                                           *
*  Package build date: Feb 18 2010                          *
*  Package version:    1.5.4.0                              *
*                                                           *
*  See -help for a complete list of available parameters.   *
*                                                           *
*************************************************************

avs2pipemod[info]: writing 29065.420 seconds of 44100 Hz, 2 channel audio.
avs2pipemod[warning]: audio size over 32bit limit (4GB), clients may truncate au
dio.
sox\sox.exe WARN wav: Length in output .wav header will be wrong since can't see
k to fix it
Processed 24347 seconds...
avs2pipemod[info]: finished, wrote 24347.420 seconds [83%].
avs2pipemod[info]: total elapsed time is 365.124 sec.
avs2pipemod[error]: only wrote 1073721225 of 1281785025 samples.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Cardboard wrote:
I) Thanks a lot for the encode Dada! II) Thanks a lot for the run Lil_Gecko! III) It is possible to download the videos from Youtube using Realplayer. Trying to download the first one now, 508 MB. I'll get back to you when I know how the quality holds up.
If you're in no hurry, you might want to wait for downloadable. I project it will be about 2GiB (which will probably be about the same as the 500MB per segment you're downloading from youtube), and will probably look better simply because of no youtube reprocessing.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
The run fully syncs with the 1.1 greatest hits US disks as recorded on redump.org. PSXjin 2.0.2 "svn0" I'm making downloadable encodes (but it's going to be another 16 hours of encoding before they're done, heh). Game looks pretty spiffy.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I got out my ps2 and my FFIX cds and started the game while observing it on my TV (wish I still had the capture card setup...) There's an FMV->backdrop seamless transition very early in the game, right when you meet Vivi. It's about 5 minutes into the FFIX tas on the workbench, and doesn't take much longer to get there unassisted. When viewing it on real hardware, I saw no noticeable color shift at the transition point, but the psxjin dump has a shift there. (top: FMV, bottom: backdrop) (comparison video in lossless x264 rgb) http://www.mediafire.com/?ucfdc1pueca2u6a