Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
MUGG wrote:
Ok, I finally got around to trying this out.
I was afraid of getting a developer key on the google account that my main youtube channel is tied to - because it required me to fill in false information - so I made a new google account. Sadly, the developer key I got only works for said google account and I wasn't able to get any keys from my other two google accounts, since this page
https://code.google.com/apis/youtube/dashboard/gwt/index.html#newProduct
would appear simply blank since then.
So I had to open a new youtube account.
Aside from these troubles, I was able to upload a test video just fine and am going to upload an actual file now.
---
EDIT:
My upload failed at 15%.
http://i.imgur.com/f9nLn.png
It might be worth noting that Chrome, when I had tried it, always froze halfway through the upload - most likely due to my ip changing, but I don't know if it can be related to YTU...
The highest progress I got in Chrome was 70%. I might as well just try until it's up - though it takes over 20 hours to get anywhere...
If your youtube account already has a developer key, go to
http://code.google.com/apis/youtube/dashboard/
And you will see it
Also, you do NOT need to use the same developer key as the youtube account you're uploading to. My ytu credentials.txt uploads to TVC using a developer API key bound on my personal gmail/youtube.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I don't think this adds much over the existing SOTN movies. Same glitches, same methods. Route is different because of the different starting location and items, but you don't really see anything "new".
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Mothrayas wrote:
I confirmed this run syncs on PSXjin 2.0.2 svn0, with the first ROM natt mentioned (Monkey Magic (USA).bin and checksums in natt's post), and with either scph7502 (PAL) or scph7001 (NTSC-U) as BIOS. (natt's "scph1000" is actually scph7502 judging by the checksums).
Do you have a list of verified bios checksums? That would be very handy.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Remember that Grunt was the Senior Publisher at the time, so what he said is more than just an opinion. Looking through everything that was said, seems pretty unambiguous.
Downloadables: Always both screens at original resolution. Extra split gap optional if appropriate for a particular game (eg, Sanic Colours).
Youtubers: Depends on game, but for games primarily on one screen, the doublesize "main" screen on one side, next to the stacked both screens, seems to be the most popular. If a game actually uses both screens rather equally, should resemble the downloadables more (eg, Sanic Colours).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
BrotherMojo wrote:
natt wrote:
I think you've misunderstood a bit here...
...it can certainly be made to sound different; just render with a different soundfont. If that would make it "better" in someone's opinion, I'm all for it. Just make sure your opinion is not based on "what it happened to sound like on some particular computer I had 5 years ago".
Ah, I misread your earlier post. Specifically:natt wrote:
The reason you get no midi at all, is because Microsoft GS Wavetable Synth (the most likely one to use) bombs out because it can't operate in the Hourglass tasee environment.
This made me believe you were referring to a problem with how the default Microsoft soundfont is rendered, rather than a problem with how the default Microsoft midi output functions. I'm not as familiar with MIDI rendering as I'd like to be.
Anyway, that's interesting... I'm running it on a Windows 7 computer I got this year and the music sounds exactly like I remember from when I played it years ago on XP. I'm not sure what soundfonts are being used, since I'm pretty sure they were the defaults in either case. Anyway, I think some of the sounds in the soundfont you used are quieter than they are in mine... in particular, the music is significantly louder or quieter in different stages. I'd expect the intended BGM volume to be a bit more consistent.
...though realistically there's also quite a bit of nostalgia factor making me think the cheesy sound effects fit better with the harsher sounds of my midi soundfont than smoother sounds of yours.
On a final note, it seems a little excessive that the encoded video runs for around 2 minutes after the end screen is reached, and a little odd that the end screen shows the previous best time as 0:00 and fewest detections as 0... but now I'm feeling all nitpicky. Really I'm just happy to see something I made being published here.
Well, the encodes go through the end of the music that plays over the ending screen, per standard guidelines; which is 2 minutes, in this case. As far as "previous best time"... I just encoded what the game spit out at me. Not sure how there'd be a previous anything though, as the movie file only plays the game once?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
BrotherMojo wrote:
Anyway, it sounds pretty good. The replacement synths have a few issues... some instruments sound distinctly different, some sounds are louder or quieter, etc. The synths/samples actually sounds a bit higher quality, but the improper balance makes things a bit weird... though also, I'd totally forgotten there's music during the end screen, so not missing that is good. So if actual Hourglass output is required for integrity, this is ok, but if we can get something more accurate that'd be better.
I think you've misunderstood a bit here. Nikujin uses system midi output to make its music. That leaves the sound dependent on any one of a million different variables in the system synthesizer used. I can play Nikujin right now on this computer, outside of hourglass, and have it sound near exactly the same as that video I posted. And it's nothing specific to this computer either; I could have played it in Windows XP on my old Pentium 4 7 years ago and had it sound exactly like this. (I had an emu 10k1, which could do hardware soundfont rendering, and I used this soundfont on many occasions). I also could have used windows 98 with an old SB16 clone that used its OPL2 for system midi rendering... that would sound nothing at all like this. I also could have plugged a real synth into the midi out on my emu10k1... could sound like a 20 year old Roland, heh.
I'm interested in knowing if there are any particular instruments or tracks missing due to some bug/missing patch set, or if there are any timing/sync bugs, or if the soundfont in question sounds just plain bad with this music. And it can certainly be made to sound different; just render with a different soundfont. If that would make it "better" in someone's opinion, I'm all for it. Just make sure your opinion is not based on "what it happened to sound like on some particular computer I had 5 years ago".
BrotherMojo wrote:
Wow, it's interesting that it doesn't desync with the midi support... makes me wonder what the original issue is...
Depending on your midi hardware and driver implementation, a particular setup could introduce timing changes. Since hourglass doesn't trap midi calls, what you were seeing is the timing behavior of your particular midi setup; could be anything. Moving forward, if I make a complete midi API within hourglass, that will become the standard hourglass midi setup and so there will be no variation between systems.
In case anyone wants to play around with it, the midi file is here:
http://www.mediafire.com/?9kvmv2u2kr9e6n2
One could render it like such:
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Would like some feedback on this audio track
Link to video
The midi data was outputted from a modified build of hourglass.
There's no stitching involved, since hourglass was actually running the submission when I did this.
The midi was rendered with fluidsynth 1.1.3 using default settings and weedsgm3.sf2.
Would like some feedback before I move to publication.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Here's my progress so far:
Hourglass simply ignores midi calls; they're not hooked or anything. This means that they get passed on to the regular subsystem. The reason you get no midi at all, is because Microsoft GS Wavetable Synth (the most likely one to use) bombs out because it can't operate in the Hourglass tasee environment. Some other wave synths bomb out as well. Using loopMIDI, I get functional midi output; but now the problem is how to get a\v sync. The TAS does sync properly when I'm using loopmidi, but there's significant studdering whenever midi playback starts or ends, so I can't use that realtime audio capture for anything.
I have high hopes though.
This is a (b) disk.
In either case, bios #1000 is required; that's a J bios and this is a U rom.
Edit: The checksums on this bios are the ones that it synced with. But this is actually bios 7502.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
http://code.kliu.org/hashcheck/
(Open source, painintheassware free)
Install that, then when you go to "properties" on a file, there will be a hash tab.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
sameasusual wrote:
In the normal encode, there are a few places where Bass disappears from a frame or two in Commando Man's stage.
All instances seem to be after landing from a jump and immediately dashing on quicksand.
The youtube encode doesn't seem to show this, probably becuase it encodes at 30fps.
I'm using mpc; is anyone else seeing (or not seeing) the same thing?
Yeah, about that...
I did get a dump at one point that didn't have that graphical glitch, but it had other problems. When I finally got stuff working to the point that I was able to create the dump that you see, that bug somehow cropped up. And I tried a bunch of Dolphin's infinity video settings and couldn't remember which one fixed it.
After months of not being published and trying revision after revision to sync and source code modifications and bisecting config files (thanks for the help on that, rog!) and god knows how many hours... I just threw in the towel and hoped no one would notice.
It's only a few frames anyway.
Edit: The old youtube (not on the publication) http://www.youtube.com/watch?v=hnfenkfyiTA does not have that bug, because it's off a different dump. The one attached to the publication does though.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Spikestuff wrote:
Encoding HD now as we sit you can still watch the SD version (hope this encode can be the official version when published)
Always interested in having new encoders around, and I welcome your efforts.
However, encoding, especially for an emulator as funderful as PSXjin, is a complex process. You might consider hanging out in the IRC channel and catching a few hints from the real idiotspros.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Warp wrote:
In other words, the reason for banning an emulator cannot be "its keypress files cannot be replicated on the console". That's an impossible demand to make for consoles with nondeterministic sources of random timing.
True.
Taking a specific example though (SNES); there are better reasons than that. byuu made quite a few test roms and ran them all on the original console plus available snes emulators. You can say without a doubt that bsnes is more accurate than any snes9x, even though there isn't a SNESbot at all.
Also, replicating keypress files on the console doesn't show much about accuracy either, especially when the bot doesn't force matching the emulator's timing (droid64 or whatever they call it).
NES also has accuracy tests, which have been tallied here: http://tasvideos.org/EmulatorResources/NESAccuracyTests.htmlTub wrote:
In the case of SMW or SM, it's not just a question of saving frames, but also a question of comparing to existing runs. If you're working on an improvement, and you're losing a frame - was it you, or was it the emulator? How will you find out?
Same for the final submission. If you're switching emulators, you'll need to explain how many frames were gained or lost due to the change.
Yes, it's extra work; but considering that the original run you're comparing with was never "right" in the first place, the switchover seems like a no-brainer to me.
Tub wrote:
Since the goal of this site is to produce entertaining runs, perfect console compatibility is a nice feature to have, but by no means required. And to address the issue you raised in the edit of the initial post: the goal of this site isn't to expedite emulator development, either.
I think the goal of this site ought to be to produce runs that are verifiable and authentic, first and foremost. But people don't agree with that, so oh well I guess.
In any event, nothing is going to happen. There was discussion about obsoleting 1.43 when 1.51 came out, but that didn't happen, and it's been how many years now? TASers only switch to new emulators when they don't like the old ones (eg Famtasia); the community at large doesn't care whether they're TASing the console or TASing the console with speed-change cheat codes.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Bernka wrote:
There are two formats can be used in PSXjin: binary and text. But if you use text, you can't open it with a tas-editor, the movie submitted here is a text file. I just converted it to binary, and it can be edited now.
I have submitted a movie with text format before, and it can't be opened by judges, so it got cancelled.
I think this is maybe a reation that some people can't get it to sync.
How would that change anything? If both files have the same data in them, they'll both be opened identically by the emulator. For the purposes of sync check and encoding, what does it matter what some other application does.
That being said, with PSXjin being PSXjin, I did have to check and see, and I got the same results. Desync at the first boss, with both movies, with both the redump.org verified ISO and the ISO that the author claims he used (although since he refuses to provide checksums, couldn't say for sure), consistently, every time. Am I missing some funderful hidden PSXjin setting?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
If you don't click 3D button. the video is just unwatchable. For me the encode from OP never loads, disables navigation, volume and quality. If you press that button and then press again to switch 3D off, the vid gets stretched horizontally to full width. Just try all these things.
Yeah, I'm not seeing that at all. I do see that if you turn 3d on and then off again, the video is now stretched inappropriately. But just loading the page and watching the video in 2d, or switching between 2d transcodes, no problem.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I'm not following you. Other than the virtualboy encodes (which are not what we're talking about here), if I go to any of the videos with 3d encodes listed, including your original post, I don't see 3d anything.
Edit: Oh, I see. It shows you the 3d button when you click the format list menu (gear icon). That's new isn't it?
What's wrong with just not clicking on the 3d button then? It does inform you that it's "converted from 2d", should be enough of a hint to stay away from it.
Aside: I love how youtube is spending their dev time on pointless bullshit like this instead of their 9 million item bug list.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
DarkKobold wrote:
about the sound - FF8 runs at 59.997 FPS, not 60. Every sound file, whether 2 minutes or 4 hours, comes out at a matching length. I've encoded it enough to know. This makes it look like sound desyncs, but it doesn't.
The video files that come out of the emulator are labeled as 60.000fps. If that's not what they should be, then that's an emulator problem.
FFIX comes out similarly, making me think it's possibly a global emulator failing (and not game-specific).
Dada wrote:
There's one last problem to be solved for the FF8 encode: I have no idea what to do with the disc switch fades: http://wedemandhtml.com/tmp/195_ff8dk-640x480.avi
If anybody could shed some light on this, that would be great. It almost seems like some kind of strobe effect. I've seen the same effect when playing FF8 on a real PSX hooked up to a PC monitor.
I've talked about it with several people on the ffmpeg irc channel but nobody knew what it is. Maybe some kind of frequency problem/difference between PC/tv.
edit: this is what happens when I decimate by 3 and then blend deinterlace... looks better but it's not a full fade to black. http://www.youtube.com/watch?v=YJiF0RWZZE4
edit: choosing a different offset for the decimation seems to fix the problem:
My best guess of what's going on is that PSXjin is outputting garbage fields (since it is definitely outputting twice as much information as it should be in interlace mode). That in itself only fixes the opening though, not any of the disk changes. Not sure exactly what's going on there; I just selected whatever cadence appeared to work.
So basically, the clip is field separated, half of the fields are dropped (hopefully the fake ones), that's weaved back to 30p, and then up-converted to 60p. Note that the use of "60fps" here is only to get a 1->2 going; actual conversion to 59.997fps is done elsewhere.
Here's what I used. Note that this is operating on all 640x480 segments concatenated together to a single file (should be exactly 2396 frames)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
rog wrote:
I'll pick up a tablet PC as my portable computer and leave my laptop at home most of the time.
Sounds like you should have got a desktop.
I hate people who buy overpriced crap like this when they could have just got a $600 desktop with better performance, and then plan to not even take it anywhere.
Agreed 110%. Everything about a desktop computer is always massively superior to a laptop computer, excepting the one property: portability.
A lot of people I know are like that too. They have laptop computers and would never even consider a desktop computer, but they don't actually do any real portable computing with them. When pressed on the issue, the usual response is some bullshit "use it in my bedroom and then move it to the couch!"... like that's worth the price.
