Hey,
Just discovered this :
http://www.smwcentral.net/?p=viewthread&t=85373&page=1A different version from the one made by psycopathicteen but it has some interests.
It's very close in fact except that:
- it plays at 15 FPS instead of 30 FPS but it uses a not optimal LZ2 compression scheme so that explains.
- it has very good audio quality (32 Khz) using HDMA streaming successfully as far i can tell.
It may be a good solution to mix the psycopathicteen version (GFX part) and this one (sound part) to have a full working one.
I know there is still some slowdown issues to fix but i guess the audio HDMA can help for that too
I remember seeing that. Extremely impressive until you realize it's 15 fps and letterboxed... still pretty good.
IIRC psycopathicteen's version uses DMA to speed up decompression, which would make it incompatible with HDMA on a 1/1/1 due to the
lockup bug.
On the other hand, there were ideas being kicked around for improving it around the time the last version came out (and the thread was hijacked by NES discussion). He and tepples were discussing improvements to the video codec, and I had suggested using most of audio RAM as a giant buffer so as to allow the CPU to fill the buffer during slack time and ignore it during demanding segments. The last implemented improvement that I know of was unrolling the APU-side streaming loop, and it's not clear what, if anything, became of the rest of that discussion. Maybe he got tired of working on it...?
Quote:
the video streaming routine is just LZ2 decompression on-the-fly (decompression may take up to 4 frames. on frame 0 i start it, frame 2 i upload the first half [i assume it's been decompressed already], and frame 3 i upload the second half). the decompression routine is the optimized one included in LM (aka this), so i cannot take credit for it.
It sounds like it doesn't even do any decompression on the 4th frame, it just waits.
I wonder if he/she has the tiles arranged vertically or horizontally? Arranging them vertically would compress better.
Ah i forgot you were using DMA for decompression...
Doing 100% software decompression has a big impact on decompression performance ?
I wonder what bring the biggest advantage:
- DMA for video decompression
- HDMA for audio streaming
About the alternate version, yeah the LZ2 compression scheme is definitely not really efficient.
In fact it takes more time but it also decompression half amount of data finally so the compression ratio itself is much more worst than 30 FPS version... At least that allowed to have 32 Khz audio =)
I'd definitely be interested in seeing a version exclusive to non 1 CPU SNES's that utilizes both. Does anyone know many 1/1/1 SNES's there are out there compared to other versions? 2/1/3 seems to be the most common (it's what I have).
The thing is, as far as I can tell the latest version leaves potential optimizations on the table. As long as that remains true (assuming it is), I don't think it's a good idea to sacrifice compatibility in order to achieve something that might be attainable some other way.
@psycopathicteen: Do you consider your version finished, or do you hope to do more work on it at some point?
Last time Tepples was going to make a decompressor that limits the number of indexed slivers per frame, because indexed slivers took the longest.
I see. It wasn't clear to me from the thread whose court the ball was in. If that's the case, perhaps at some point after CoPH is done we might see some movement.
I got it down to only 2 or 3 lag frames, by unrolling the tile decompression loop.
...wow. That's quite an improvement.
What's the audio sample rate? Still 12 kHz?
...
Now that I re-read my last post, it kinda sounds like a passive-aggressive attempt to hurry you both up. I apologize if I sound like I have a sense of entitlement about this - really, I just wanted information.
But hey - progress is cool too...
I'll speed up the sample streaming code by feeding 4 bytes at a time instead of 2. I'm also thinking of using IMA-ADPCM because it compresses slightly smaller.
Wouldn't that stick you with filter 0 and thus 4-bit PCM? Or is the SPC700 powerful enough to decode IMA ADPCM directly to the echo buffer?
If you end up with excess streaming capacity, I suppose you could do a version bigger than 8 MB. If I recall correctly, the MD version exists in two sizes, and since there are (I think) no flash carts that can handle 8 MB but not 12 MB, hardware compatibility isn't an issue.
But I suppose your goal here is probably to reduce the data rate rather than the ROM size...
93143 wrote:
...wow. That's quite an improvement.
What's the audio sample rate? Still 12 kHz?
I also have that impression of that is using the older samples.
I got it running at 16khz, but I didn't switch the samples yet, so the sound is speeded up.
But the music is synchronized, only that the quality is clearly lower.
Is it just me or are the vocals in Bad Apple kind've muffled to begin with?
Señor Ventura wrote:
But the music is synchronized, only that the quality is clearly lower.
Is the latest work getting posted somewhere I don't know about, or are you just talking about the old one?
psycopathicteen wrote:
Is it just me or are the vocals in Bad Apple kind've muffled to begin with?
I don't think so. I think there's just so much high-frequency energy in the rest of the instrumentation that the vocals get a little buried.
I'm getting a virus warning. I don't know if it's Firefox or Avast, but something is refusing to let me have the file.
I'm actually not getting a virus warning. I use Internet Explorer. I had to click the "FREE USER" button on the bottom left of the screen twice, with each time some BS website popping up that I exited out of, but then it asked me if I wanted to download the file, and it worked. I always use Media Fire, as I haven't had any problems with it.
Damn though, seeing something like that on the SNES is surreal. The sound quality is great. Surprisingly, I think the vocals sound clearer than the electronic noises.
Huh. Tried IE and it worked (with ads). And now Avast says "no threat found". Maybe the site detects AdBlock and tries to take revenge?
Oh well.
Watched it a couple of times. Looks like a blip right near the end of Flandre's section, but otherwise smooth. Very nice! (Though the screen doesn't blank at the end...)
I boosted the mid range to make the voices sound clearer.
http://www.megafileupload.com/oqTD/Bad_ ... _boost.zip
I'm not sure that's such a good idea. The vocals do seem to pop out more, but the frequency balance of the whole track is now unpleasantly heavy on the mids.
Honestly I don't think the mix really needs fixing, and if it did we wouldn't be able to do much without the individual tracks. It's just a busy style - I'm sure a Japanese speaker wouldn't have a problem with the vocals.
...
Also, how are you aligning the video and audio? I'm hearing the audio a significant fraction of a beat late, about half a beat late in the early parts of the video, which is too much to be explained by the emulator's audio buffer, but perhaps not too much for a system buffer downstream... I've tested on my laptop (with crappy onboard audio) in bsnes v072, bsnes+ v073, no$sns and Snes9XW (Snes9X and ZSNES don't work), and on my dedicated music rig (with an E-MU 1212m) in no$sns and bsnes v017 (!); they all seem to behave about the same except for bsnes v017, in which the audio outright fails halfway through... I can't seem to find any way to check non-ASIO buffer sizes on either machine, and I don't have a flash cartridge capable of loading an 8 MB ROM; can anyone confirm the timing on real hardware with a CRT and analog audio? Or would that be overkill for something that should be perfectly predictable given the data and code?
Speaking of real hardware, are you doing any sort of active sync, or do you simply bet on the APU oscillator being accurate enough?
psycopathicteen wrote:
http://www.megafileupload.com/oqSB/Bad_Apple.zip
Now with 16khz audio.
Sound doesn't work on Real HW with this version. Just a FYI
Edit: to be more clear, sound breaks in the first second of power-on but the animation stays running for approx. 3:38 on real hardware.
the other version
viewtopic.php?f=12&t=14856#p179854 sound and video both work on real HW as-is.
93143 wrote:
... I've tested on my laptop (with crappy onboard audio) in bsnes v072, bsnes+ v073, no$sns and Snes9XW (Snes9X and ZSNES don't work) ...
Specifically for
snes9x (64-bit test builds) (snes9x_testbuild_11102015.zip is the latest): loads + runs, but the demo soft-locks after a few frames of animation, with a very odd audible effect that I can't put my finger on (gut feeling is some kind of sound engine problem, but hard to say).
hi. im the author of the demo linked in the first post
Markfrizb wrote:
the other version
https://forums.nesdev.com/viewtopic.php ... 56#p179854 sound and video both work on real HW as-is.
this is great to hear; i was never able to test it on hardware
i had numerous planned improvements planned before scrapping them for the easy way aka LZ2 (i discuss some of them in the smwc thread). i doubt you guys require my help considering youre far more advanced than i am, but im here regardless in case anything is needed (questions w/e)
Ladida wrote:
hi. im the author of the demo linked in the first post
Markfrizb wrote:
the other version
https://forums.nesdev.com/viewtopic.php ... 56#p179854 sound and video both work on real HW as-is.
this is great to hear; i was never able to test it on hardware
i had numerous planned improvements planned before scrapping them for the easy way aka LZ2 (i discuss some of them in the smwc thread). i doubt you guys require my help considering youre far more advanced than i am, but im here regardless in case anything is needed (questions w/e)
If you need anything else tested on real HW, just let me know. I make Snes pcbs that have a wide range of capabilities. Cool demo! I'm very impressed. Maybe you could add a loop feature where at the end it restarts on it own???
93143 wrote:
Is the latest work getting posted somewhere I don't know about, or are you just talking about the old one?
No, no, i'm talking about the 15fps version, but it souns lossy to me.
If it were at 32khz using the older samples, the music should be asynchronous, right?.
So... if really it goes at 32khz?, i found this confusing ^^u
Well, BRR is a bit lossy, and it's not possible to perfectly compensate for the S-DSP's Gaussian antialiasing (you can come close, but I think it accentuates the loss of quality caused by the BRR). But mostly I think what you're hearing is the fact that it's been converted to mono.
The 15 fps version and the 30 fps version are totally unrelated; they're done by different people working independently. They aren't using each other's "samples"; they're using different conversions of the original 44.1 kHz stereo track. The 15 fps version uses a 32 kHz mono stream. The 30 fps version uses a 16 kHz mono stream (it was reduced to 12 kHz a while ago due to CPU overload, but the video decoder has been sped up and so the audio has been reverted to 16 kHz).
There was indeed an old developmental WIP of the 30 fps version that ran a 16 kHz audio stream at a lower rate (~14 kHz or something like that), but that was because the decoder was having trouble sustaining 30 fps, so the audio was stretched to fit the video. Such measures have not been necessary for a long time; all recent versions run the audio at the correct pitch.
...
Oh, hey - I just noticed something. Ladida's version has the same audio/video sync issue I noticed with psycopathicteen's version. Maybe it is a PC-related audio buffering issue... Markfrizb, if you don't mind checking, how does the timing look on real hardware? Is the audio synchronized properly with the video in the 15 fps version, or is it half a beat late?
93143 wrote:
...
Oh, hey - I just noticed something. Ladida's version has the same audio/video sync issue I noticed with psycopathicteen's version. Maybe it is a PC-related audio buffering issue... Markfrizb, if you don't mind checking, how does the timing look on real hardware? Is the audio synchronized properly with the video in the 15 fps version, or is it half a beat late?
Well, I think my opinion is all it's good for...as an opinion.
Here's a video of the demo:
http://www.youtube.com/watch?v=BDDq0ZtavCMMy LCD monitor has about a 2 to 3 frame lag (measured by the 240p test suite)
Thanks! Yes, the audio is still lagging (unless I'm sorely mistaken about something crucial; see below). Two or three frames is nothing; the gap I'm seeing is something like a fifth of a second. Actually, in your video it seems to be even bigger than in bsnes, which is odd because TV lag combined with no audio buffering should reduce the gap, not increase it...
And I think I may have identified the problem. Compare this:
https://www.youtube.com/watch?v=ZF9cxhiFw3Mwith this:
https://www.youtube.com/watch?v=FtutLA63Cp8It's especially obvious with Patchouli, but you can see it pretty clearly any time anybody is dancing. (Unless my computer handles YouTube videos wrong, which would explain my results with your test video...)
Where are people getting the raw files to encode?
This is the original source of the video, if you want to be absolutely sure on the correct timing.
timing the audio with the video was a complete crapshoot on my part. i was too lazy to properly time it using the original video
dont blame your PC
Nicole wrote:
This is the original source of the video, if you want to be absolutely sure on the correct timing.
Looks like it more or less matches the second link in my post. The one where actions seem to land on the beats instead of between them, and the characters actually look like they're grooving to the music.
Both SNES versions seem to more or less match the
first link in my post.
This is not a huge deal, as few people seem to have noticed the discrepancy in the YouTube videos (there are multiple videos with the same timing issue, leading me to suspect inheritance), not to mention that the timing in Stef's MD version is even worse, but it might warrant some attention once more important issues are resolved.