64th note really needs to update by oddMLan at 2:43 PM EDT on August 30, 2014
The webpage of 64th note says: "64th Note is a USF plugin for Winamp, based on Project64 1.6 by Zilmar and Jabo and Azimer's HLE Audio Plugin."
Now the Project64 2.1 source has been officially released, with tons of bugfixes, especially a very important one that affected all PAL USF rips using the Project64 1.6 core, which have the wrong pitch, a semitone lower than intended (!) (bug report here: http://forum.pj64-emu.com/showthread.php?t=3275).
Also Azimer released a new version of his plugin that implemented HLE support for Musyx games and added support for XAudio, making the games sound a lot better than with previous versions of his plugin. (http://www.emutalk.net/threads/55161-Audio-v0-70-WIP-4-Feedback)
The Donkey Kong 64 USF rip from the official repository seems to be from the PAL version of the game; the tracks sound a couple of cents lower compared to the NTSC version of the game. Only the PJ64 1.6 core suffers from this bug, which is the one that the 64th note uses. Project64 2.x has fixed the bug, so the PAL and NTSC version of the game sound exactly the same.
I will post a comparison soon so there's no place for doubt.
P.S: The USFLIB file is named NUS-NDOP-USA, which is the NTSC version. What? There must be something wrong with the rip then. But I swear the miniusfs sound exactly like they are from the PAL version of DK64 when using Project 64 1.6. Or maybe I'm right and the rip is from the PAL version and has been labeled incorrectly; I tried other USF rips and they sound correct.
If you're gonna update I'd recommend to take a look at HatCat's RSP, a really small RSP interpreter as fast as Jabo's RSP recompiler and a whole lot more accurate (100% accurate AFAIK). It is what Azimer recommends when using his plugin to get the best audio.
And a mirror on Github that I haven't synced up lately.
It's still based on Project64 1.4 or whatever the original was. Anyone feel free to fork the project and update it. It also needs, at the very least, accurate R4300i interpreter core, since there seem to be some glaring faults.
I will not include any recompilers, unless they can be made fully portable to x86-64 as well as ARM neon.
While at it, the HLE sound code that I integrated could use a fix for the IIR filtering employed by Conker's Bad Fur Day, mostly for tracks like Rock Solid. (sparse3d.miniusf)
Without the correct implementation, it's either down to intentionally not doing anything and sounding wrong, or spitting out an error notice and not playing at all.
I'm not asking for either hcs or joshw to give their attention to this. I'm asking for anybody. Anybody at all.
Seriously, people use my libraries, but the only thing I'll ever hear is questions about how to integrate them properly. Next to nobody contributes anything back, and when they do, it's usually some very minor fix, like getting it to compile on some platform I hadn't considered yet. Those minor fixes are welcome, but I'd like someone to help with major things like this as well.
Well, if someone does an update it will hopefully fix Mario Party which doesn't work with the current plugin. Who knows what other rips just plain don't work.
I know I asked this on another forum but I don't think the answer you gave satisfactorily answered my question.
Are you (somewhat) taking up the challenge of creating a version of the plugin that can produce more accurate results and improve compatibility with previously problematic games? Or are you aiming to create a more featureful/portable version?
Now that Kirishima (sp) mentioned it, my Mario Party randomly crashes now. Same with some of the 'extra' tracks with DK64; I had to use HLE for those to even play then convert them to FLAC.
It would be great if this can get the new Project 64 recompiler and all that jazz. I especially want to hear if there IS something wrong with the pitch of the Rareware games that were mentioned (DK64) and if that changes with an update.
I know for sure Ocarina of Time is off compared to the official OST releases, though really you should listen to those for that anyway because the OST sounds like it uses higher fidelity versions of the same samples.
edit: http://help.foobar2000.org/problem/2e329a5666a483c2197fff811c51a1ab When I last tried to play a Mario Party track.
Not touching recompilers, I need accurate interpreters only. Unless someone wants to port recompilers to x86_64 and ARM, as well as any other platforms that may deserve this library.
oddMLan at 10:49 PM EDT on August 30, 2014 The Donkey Kong 64 USF rip from the official repository seems to be from the PAL version of the game; the tracks sound a couple of cents lower compared to the NTSC version of the game. Only the PJ64 1.6 core suffers from this bug, which is the one that the 64th note uses. Project64 2.x has fixed the bug, so the PAL and NTSC version of the game sound exactly the same. -My fault :P Can't remember the reason why...i think it was the only rom of it at the time, and didn't bother (or care) to use a NTSC version.
Kirishima at 12:02 PM EDT on September 5, 2014 Well, if someone does an update it will hopefully fix Mario Party which doesn't work with the current plugin. ? It works perfectly fine for me? Using what settings?
kode54 at 6:45 PM EDT on September 30, 2014 Not touching recompilers, I need accurate interpreters only. Agree! I ported the Project64 recompiler to x86_64 (very badly at that). Re-doing that for multiple platforms (and one such as ARM) will be a major pain in the ass. Fast interpreter+hle all the way ☺
Mario Party works fine with foobar, but not with the current winamp(or plugin).
Winamp Plugin Update by TwilightOne at 6:31 PM EDT on October 21, 2014
Hello Josh!
First thank you for your work! My problem is with the newest version of the plugin... I use MediaMonkey (For library options...)which is compatible with Winamp plugins but the "latest" beta version of 64th note for Winamp will not work on my system.
Thank you very much, I hope you can give me a positive answer!
The plugin, when it tries to load the INI file, it sends a 'WM_WA_IPC' call which MediaMonkey doesn't support, gets nothing back and dies.
I've attempted to fix this, by reverting it to the old Winamp 2.x behavior if the message returns nothing. Also, I had signifcant difficulty getting it compiled under Visual Studio 2013, so I can't 100% guarantee nothings broken. :) Get it here
the ini API message was added in v2.9 so it's technically a 2.x API... and i'm sure the in_usf mods i provided showed how to use it correctly for the different Winamp versions.
Now it needs something to get Banjo Tooie working, and I think it may be the R4300i interpreter's fault for messing something up. The failsafe I added to the main emulation loop prevents it from livelocking completely.
The original assumption of the library in my current design was that the DMA would always produce a stream of samples, and it runs until the client supplied buffer is filled completely, buffering up any remainder until the next client call.
Unfortunately, rips which are broken in the way of the BT rip don't actually reach any DMA streaming state, so they run whatever code for ages on end. So I added a simple check that keeps a count of how many R4300i instructions have executed since the last DMA block was transferred, and if that hits some high count, it aborts with an error message. It doesn't break any games that I've tested, at least none that weren't already broken.
At least now, with that IIR filter in the HLE code, HLE is prime for most regular use cases. That one RSP breakage should still be fixed, since the RSP code I borrowed could use that fix upstream for full system emulation. (If it wasn't mentioned here, I don't recall where it was, I'll have to dig around.)
EDIT: I've updated lazyusf in my repository with a quick fix for TLB accesses outside the range of N64MEM, so that they now do some generic open bus thing. This stops Harvest Moon 64 from crashing.