64th Note v0.10 by hcs at 4:09 PM EDT on May 24, 2005
What's in the works: (also, I'll post beta versions here as it becomes practical)
* fix "fade up" effect after fade to silence with some output plugins * fix problem with editing the wrong file's tags after another track starts playing * make the defaulting to file name on incomplete title optional * MAKE A SINGLE .DLL!!!!
But only if you (or someone else who wants this feature) will personally take the responsibility of accurately filling in the "taggedby" field in each and every USF already released (using exactly what's at USF central), updating the info.txt, removing the tagged by info from the comments tag, repacking it into a .ZIP using 7zip with Ultra compression, and uploading it to the server. Because that's what I'd do if I was adding that.
I'm willing to help, where possible, in adding the "Tagger" info. into the currently available files. However, chances are I won't be much help. Though I can tell you which ones I worked on, and who helped me, and that sort of thing.
A tagger field would be nice, but I figure using the comments box works just as well. Maybe that's just me... Anyway, Mouser X over and out.
I'm pretty much of the same mind, Mouser, but if someone wants to put in the work (and it looks like UNKNOWNFILE is well on the way to finishing) then more power to them.
-FZero X -OgreBattle 64 -Perfect Dark -SpaceStation Silicon Valley -WaveRace Shindou -Wonder Project J2
AND NOW, GOING OFF TOPIC WITH PETER S. CONWAY! ;P
For all you Rayman 2 fans out there. Here's some high-quality non-sequenced music from the Dreamcast Rayman 2 (compressed to VAG, then to PSF2): http://petersconway.dynu.com/xsf/psf2/rayman2dc.rar
The incorrect tempos for Super Mario 64 and Mariokart 64 should be fixed. Maybe when hcs was stripping Project 64 to make the plugin, he removed something that maintains the original speed of those games.
I don't think so, more likely is that when the game enabled these tracks it changed the tempo of the sequence player and this data is not in the sequence itself. Same with the Wave Race tracks, the tempo actually changes within the game on the final lap. That's not something you get from the generic music engine, which is all that I ripped.
Then maybe you can put a tempo control dial on a future release. It could be similar to the one on the SNESAMP SPC plugin for Winamp, and on the USF tags a default speed could be implemented for an single track.
Sample Rate by True_X_Unknown at 4:24 PM EDT on July 3, 2005
Can you put a Sample Rate Modifier, like in HighlyExperimental. I would like here USFs at 96Khz or 48Khz.
That has already been answered. You can read about it here. Basically, unlike the SPC player, or the PSF player. 64th Note only passes the audio to Winamp. It doesn't do the audio processing itself. It is preset in the N64 code as to what sample rate the music is played back as (I think that's right. Read the linked thread above for more details/clarity).
Hopefully, that answered your question. Mouser X over and out.
"Then maybe you can put a tempo control dial on a future release. It could be similar to the one on the SNESAMP SPC plugin for Winamp, and on the USF tags a default speed could be implemented for an single track. "
I agree. Some USFs sound like they were ripped from a PAL version (which has a slower tempo), so it would be nice to have that.
In addition to that, how about a pitch modifier? Just a fun little addition ^^;
Get a DSP plugin that'll let you change pitch/tempo if you really want it, that's beyond the scope of the player. Really, the sample rate and tempo, whether or not it be accurate as to what the game normally plays, are what the USF has been ripped to play. 64th Note really has no business playing them any other way. Errors in tempo are the fault of the ripper. As for the PAL comment, I'm fairly certain that all USFs so far have been from NTSC games, either US or Japanese releases.
Any chance that volume control can be added as well (ala Highly Experimental)?
My sampled music collection is all normalized at 0.89db, and it's nice because I can adjust PSF volume levels to be the same. Therefore I never have to change the volume of my speakers. It would be great to be able to adjust global USF volume. :)
I don't claim to know--well, anything--but, I would assume that the sound data from PAL games would be identical to that of NTSC games, since by the N64 era, audio was corrected (heck, even most NES games had their audio corrected). If anything, I'd guess that it would run faster, since the audio would try to play 16.6...% faster than it was already running, and one assumes that 64th Note plays at NTSC speed.
But yeah. It's not as if they included code in the systems to make the audio play slower. It's just that the whole system runs slower, so that's how it goes.
Again, chances are all this is wrong, I don't know anything.
OK, I'm going through and making some changes, so far I've added the Tagger field and fixed the fade-up which was really bothering me. What I've been unable to figure out is the bug CaitSith2 reported wherein sometimes you wind up editing the wrong track. I can't see how that can happen in the current code.
Open the tag editor, of the current song. Somehow change the song playing, (let the timer run out, or just change it yourself. (You can still change it yourself, through the playlist winamp controls, even if the dialog is modal.), then change the tags.
Found it. Winamp calls the info window with a pointer to the name of the file, but apparently it also changes the string when the currently playing file changes. So I make a local copy within my info window function now. Really careless on their part, I guess this is part of what foobar advocates are complaining about.
I'm now working on the default tag value, and I'm adding a feature to optionally round the frequency to a more reasonable value. Currently I'm using a lousy rounding technique. I've gone through all the USF sets and found what frequency the game is actually requesting from the OS and I've made a table of values to change to. With the "round AI frequency" option off I'll use the literal calculated value, direct from the AI dacrate register for accuracy's sake. This option will be disabled by default.
Also the use of %file% as a tag in the title format will be supported, it'll be replaced by the name of the file. Also, if anyone can point me at instructions for accessing winamp.ini I'd like to pull the configuration out of the registry at this time but I don't know how.
Alright, beta 2 is now up: http://www.halleyscometsoftware.com/usf/in_usf010_beta2.zip
I've got all the bits I mentioned out of the way, except for the single-dll. I've also found a new bug: When the recompiler is enabled and a USF is played wherein the AI DAC rate has not yet been specified at the time of the save state it will use the sample rate of the previously playing USF. This does not occur when the interpreter is enabled. It appears that the DAC rate is simply never set by the game. You can see this in action by playing, say, Body Harvest after Blast Corps (Body Harvest uses my driver, which doesn't initalize the audio hardware until after the save state was made). The Dynamix intro is actually a better example because you can run it in interpreter mode and see that this problem doesn't exist then.
Something from the recompiler apparently isn't being reset. Drat. The good news is that this is only a problem on a small number of sets, namely my "generic driver rips" and the Dynamix rip, at the moment. I've really no idea what I can do about it.
I'm very strongly considering rewriting 64th Note. I'm currently shopping around for a CPU core. I'd love to use PJ64 1.6 but the source isn't available, so I'll probably stick with 1.4 unless my examination of Daedalus or 1964 (also only an old source version) show promise.
Well, I'm no coder, so my say in the matter is mostly superficial. Nonetheless, there's 2 ways I view it. Does it work? Yes. Then why change it? The second view is "Geez, this is a mess. I know I could do better than that!." As I said, I'm no coder, so I tend to go with the 1st viewpoint the most. However, I have heard of many complaints about 64th Note over the past. Yes, most, if not all, of them have been addressed, fixed, worked around, or soemthing. However, that can potentially leave the source code a huge mess (from what I understand, it was a mess (more or less) in the first place, let alone after you started using it). As such, a huge cleanup may be a good idea. The problem with that is, sometimes to clean it up properly requires rewriting it. If that's the best course of action, then I say go for it. But keep in mind a few things. How long did it take 64th Note to get where it is now? How much can you improve on what you've got?
Because you've been developing 64th Note for some time, I would assume you could do better now because you've learned from previous experience with the code. On top of that, a rewrite would probably make it more manageable for when there are more problems later on (as there seems to be with 64th Note, currently (meaning, something seems to turn up now and again that causes problems. Ex: Mischief Makers, or the PD and Pilot Wings bug (data not saved in the savestate dealy))). Also, a rewrite would potentially mean less of those problems later on as well.
To reiterate and simplify, do what you think best. Just weigh the pros and the cons (on a side note, if pro is good, and con is bad, what's progress when compared with congress?). Anyway, good luck with whatever you choose. I'm sure the result will be better than before. Mouser X over and out.
Are you sure you're not a coder? Your nested parentheticals say otherwise...
I've been splicing stuff into the original code and commenting at random for a year now, and as you noted it was a mess before and now it's a disaster. What's spurring me to do this is the Mischief Makers and Bust A Move '99 problems, but the whole thing could use a rewrite. Knowing what I do now about how it's structured I'm sure I can do a much better job, and I know about the bugs in PJ64 that need fixin'. It's said that just about anything written (be it a story, essay, or code) is better the second time around. In my case it'll help make up for the fact that, when I started out, I had very little idea what I was doing. For instance, I'll be incorporating the plugins into the main module from the beginning, even before I wrap it in Winamp's API, so the redundant code and multiple DLLs issues will be solved when they're easier to track.
It's a good idea, now I just have to get myself motivated to go through with it. I was also considering writing my own CPU core as a learning exercise but I decided against it. Maybe later.
I mean, the way I see it, it's really a no-brainer: at some point you'll decide the code's too damn garbled you can't even look at it. You might as well do it early on, be happy with the rewrite and maybe save time in the long run compared to doing it later (assuming you wouldn't stop working on 64th soon after releasing v0.10).
Realistically though, it's probly just a matter of available free time and desire to do it when that comes around.
PS: The habit of nested parentheses can soon lead to the dark side that is LISP and insanity (the two being interchangeable).
Taking into consideration your current problems with the sets in existence (Bust a Move; Mishief Makers; Mario Party; Conkers Bad Fur day; ect.) it would seem that either a rewrite, or a cleanup is in order. Chances are good that a cleanup would require a rewrite...
In other words, let us know how it's going! Oh yah, and good luck. From what I understand, you'll be using the same core for the player, but you're looking to see if there's other options available. Also, since the Bust a Move set works with plugins other than Azimer's, I assume you're looking at using something else for that as well. Or that you're at least looking into it.
Obviously, it sounds like (to me) that it's best to do a rewrite now. The plugin has gone through numerous iterations and updates, and it's been treated pretty well (considering). You have more knowledge, and insight about its inner workings. Chances are, you can easily fix what's wrong, once you have a clean slate to work from. And, since you've already gotten this far once, it should go faster the next time around. Roughly, how long did it take for 64th Note to reach a (fully) releaseable version? Apparently, 0.5 (or 0.7?) is where it reached reasonable solidity (before that, there was almost a new version every time ripped sets were released). And it had been in development for what, about 2 or 3 months before that time? Oh yah, based on Darkpulses USF mirror, 0.5 came out roughly on 10/5/04 (and v. 0.7 on 10/16/05?).
Anyway, I'd think it would be available fairly quickly, once you started getting the ball rolling. And then perhaps 64th Note would reach the elusive 1.0 stage! Oooh. Ahhh. Okay, I need sleep. Mouser X over and out.
You were thinking about what core to use, right? Well, though you probably knew this, 1964 is open-source (or so I gather, based on what it says). Have you looked into that? Is it any better/worse than the Project 64 core you're using? Those are some ideas I have. Hopefully that helps. However, seeing that you used PJ64 core in the first place, chances are that it's probably better than the 1964 one.
Just out of curiousity, what's the differances, and why would you prefer one over the other? Thanks in advance. Mouser X over.
P.S. It would seem that Project 64 got an update in June 2005 to 1.6 (but the source is not available). The source for 1.4 is dated at 12/25/01, correct? Where as the source for 1964 v0.9.9 is dated at 1/1/04. It seems to me that 1964 is newer, and therefore possibly better. Of course, you're the one doing the research, so you'd know best. I was just wondering if 1964 might be a viable alternative, if you needed one.
By the way, the dates I posted are from zophar.net, in case you were wondering. And, I'm not sure of the date for the 1.4 source, but that's what it looks like. K, I'm done now.
The trick is that neither Project 64 nor 1964 have the sources to their latest versions publicly available. The 1964 source is here, and it is dated 9/22/02, version 0.8.5. The Project 64 source is here and dated 12/22/01, version 1.4 build 52.
Both are quite out of date. For reasons which aren't at all clear to me the authors seem to prefer not to release their latest versions. From what I've heard it's had to do with the fact that although thousands of people have downloaded the source to PJ64 no one has done anything useful with it. There seems to be a lot of disgust towards the people who just recompile things with the official XBox SDK to run the emulators on XBox (especially those who hack arcade emulators to play new games that the authors don't want publicly available yet).
This is something I tried to clear up when I contacted zilmar about the possibility of using the 1.6 source for my rewrite, demonstrating that I fixed numerous bugs in the source and wrote an entirely new interface for a special application of the CPU and RSP cores. He seemed willing enough to let me use it, "I have no issue with giving you the source code for pj64," so hopefully in the next few days I'll have some code to work with.
Well that's cool. Hopefully, the source you get from Zilmar will be greatly improved over what you currently have (well, any improvement is going to be good). That does pose a question though. When/if you get the 1.6 code, and make 64th Note 1.0 (or whatever), will you release the source to the player? I would assume that you will (that way people can get it running on Linux, Mac, Foobar2000, ect.). However, when you do, do you have permission to release the updated core code? Or will that be a separate deal? Or what? I'm just curious. I realize it's not a big deal (and not really my concern, for that matter), but considering their sentiments on releasing the most recent source, Zilmar might not like the idea of it being released with your player code. Just a thought.
Anyway, good luck with that. Hopefully all goes well. I know that I look forward to a potentially more efficient 64th Note. Mouser X over and out.
CPU by ninninetynine at 3:45 PM EDT on July 28, 2005
I'm not sure how much USF stuff is done on the main CPU or RSP, but you might be able to use the CPU core from MAME. It has a MIPS III/IV core(C interpreter and x86 dynarec), and works well enough to run the R4600 KI arcade games with no crashes(like U64emu does) and a few other MIPS games using R4700, and R5000.
Oops. Well, uh, sorry about the double post. Apparently, when I refreshed (I didn't realize I had posted a message. It was like, almost 3 hours ago) it reposted that message. Is it even remotely possible to clean that up? I'm guessing it's not... Mouser X out.
Hmm, I hadn't considered taking a look at MAME's compiler. I'll have to take that into consideration. The RSP is a bit weird, though, and even the PJ64 RSP emu from 1.4 has been pretty much perfect so I think I'll just be using that.
I don't currently know what kind of deal I'll have regarding the 1.6 code (or if it will ever materialize). I'd like to rerelease it with my changes... The excuses for not releasing that I mentioned above are not directly from the authors, by the way, I don't know why they personally don't release it.
I've been told by someone with significant knowledge of MAME that it's MIPS core would never work for the N64 (no MMU/TLB), and it's slow anyway.
Fortunately that point is now moot, as I have the PJ64 source in hand (thanks again zilmar!) Upon my triumphant return from California I shall begin work on it in earnest.
Oh, and zilmar gave me an interesting argument for not releasing the source: when you know that the code is out there and anyone can make bug fixes and add new support it lessens your desire to do it yourself. This is apparently what happened after 1.4, he hoped someone else would pick up the project and it sat dormant for a while. Interesting motivation...
Oh yeah...forgot that MAME's MIPS core didn't support the MMU/TLB yet. MAME's PowerPC core doesn't support it's MMU either, mainly because none of the arcade games have used it so far.
I said: Please add in a tag like _recompiler=no so that I can switch games without winamp crashing on me (e.g, Mario Party then Diddy Kong Racing).
I meant: Please add in a tag like _recompiler=no so that I can switch games without having to switch recompiler mode on and off over and over (e.g, Mario Party then Diddy Kong Racing).
The new tag I want is something like "HLE=On" or "HLE=Off" or something. That way, the sets that work just fine with HLE on can use it, and thereby decrease CPU usage, for those on slower CPUs. I've been wanting that since the beggining, but apparently it never happened. I noticed that Super Mario 64 runs a lot better (takes less CPU but sounds just as good) with the HLE on, whereas Golden Eye sounds quite messed up. Also, apparently, this is the case with some of the Zelda tracks. They don't sound right with HLE on. Basically, if the "HLE=??" is blank, or doesn't exist, it would take no action on those sets. As such, if the user has HLE on in their settings, then the sets with "HLE=??" blank or non-existent would run with HLE on, since that's what the settings are. However, if they have HLE off in their settings, then it would run the songs with HLE off. But if the "HLE=??" is set to off, or on, it would run the set as such.
Of course, the plugin settings would probably need a new selection. I'm thinking something like "Overide HLE tags." With it selected, it would run all sets as the plugin is set to do (if HLE is off in the plugin, then all sets, regardless of tag, will be run with it off).
Those are ideas I've had, and wanted for some time. However, I can see reasons why you wouldn't want to include such a feature. If the user has a high enough CPU speed, HLE won't make a noticeable differance in CPU usage. It will also make that much more work for taggers to add it (not that they'd be required to, unless it was obvious the set didn't work with HLE on, such as Golden Eye).
Anyway, if I was to place a request, that's what it would be (oh, and put the settings in the "plugins.ini" or "winamp.ini" file, instead of the registry (the registry is already a big enough mess/pain, it doesn't need to be any worse...(opinion, I suppose))).
That's all for that, I guess. Mouser X over and out.
HLE tag observance would be disabled by default, but I can see how it would be a useful option.
Regarding the .ini, apparently this is what the GetPrivateProfileString functions are for, when it comes time for the new program to save settings it'll use an .ini.
I've started work on the new version of 64th Note. I'm still at the "getting it to work in PJ64 at all" stage, though. Seemingly everything I've thrown at it works great under the interpreter (including the troublesome Bust-a-Move '99 set and some recent rips that wouldn't work on the interpreter) but only a few seem to work right in the recompiler without crashing or bizarre behavior. Mario Party is one that works in the new recompiler. So I guess that's nice.
It really makes me appreciate how relatively stable the current incarnation is, and how very much work I had to put into it to get it that way. I'm really dreading this project, especially with all this trouble right off the bat...
I decided to try moving the 1.4 recompiler back into the 1.6 source I'm working with now, and that seemed to fix the recompiler issue. I didn't want to just sloppily throw the old code in there, though, as I'm trying to start off fresh with 1.6, so I did some tedious testing to find just what changed that affected the recompiler so. It turned out to be the stack analysis that was added in. Even with SPHack set to false there were a few things done which apparently break a few games. I removed all the stack-specific code from 1.6 and I now have that working. I've tested the recompiler and the interpreter on all sets I have (prelim and released, 43 in all) and it seems to work perfectly. I also fixed zilmar's Basic Audio Plugin so it now isn't totally useless for listening purposes. I'll be writing my own AI handling routines when I move things over to Winamp but until then the Basic Plugin will suffice.
Oh, and zilmar gave me an interesting argument for not releasing the source: when you know that the code is out there and anyone can make bug fixes and add new support it lessens your desire to do it yourself.
That's crap and you know it :-) As long as there's some way for external folks to contact you before they start doing something it's not a problem. MAME has over a dozen devs "on staff" and we get external submissions all the time, no problems. I think it's more like stupid elitism as the driving force, just as it's always been in N64 emulation.
Well I don't know what motivates him to work, and if he doesn't want to release his own code then any reason he gives is fine with me. In any case I have it now and I'm making progress.
I've finally achieved a single binary which plays every existing set.
In any case, I'm going to look at playing USFs portably with the latest Mupen64 source - while nobody was looking it's turned out to be pretty nice, and it's already portable. The minus is that it only has audio HLE, but music played great in all the games I tried (including Conker) so that may not be much of a problem.
The "1" in "1.0" implies "first major revision", not "complete".
It has all the functionality of 0.09 and 0.10 beta with the exception of Audio HLE at the moment. There are still bugs, evident due to crashes when switching tracks. You can safely discard your RSP.dll files now. This plays everything I've tried it with yet. That means Mischief Makers, Bust-a-Move '99, and Mario Party with the recompiler. (btw, the problem with BAM'99 is that it keeps reading the controller. I've left minimal support in (the port returns an error for all controllers)).
I was going to use UPX, but it seems to crash the Interpreter... so you've got a 728 KB (-ish) .dll instead of 131 KB.
Bug reports... missing features... put 'em here. If you can get it to reliably crash please tell me your circumstances.
you guys owe me a case of Mountain Dew and about 8 burritos which I consumed in the few days I've been working on this almost continuously.
edited 2:07 AM EDT September 6, 2005
oh, yeah, it uses winamp.ini (which it will locate even if you're running it with the foo_winamp_input wrapper). to get it to work with foobar's replaygain scanner you must enable "round frequency".
Good job; the plugin sounds great. Thank you. I did find a few things that you should know about:
#1 - After about 20 sec. the standard Winamp visualization bogs down and eventually ceases to work. It also does this when it is approaching a loop point. I don't know if this is a minor problem or a symptom of an underlying bug.
#2 - I did manage to get the player to crash a few times. The first time it did give me an window that said that Winamp had encountered a serious error. However, the other times I got it to crash Winamp just disappeared (as if I closed it normally). The player seemed to like crashing when I tried to switch to a short (>30sec) track after playing a track that was stalling because of problem #1. Maybe the two problems are related.
Thanks for giving your time and Mountain Dew toward this great plugin.
edited 10:22 AM EDT September 6, 2005
by unknownfile at 8:18 AM EDT on September 6, 2005
Regarding this update, does this mean Mario Party is now a complete set?
I was going to use UPX, but it seems to crash the Interpreter... so you've got a 728 KB (-ish) .dll instead of 131 KB.
So, what's UPX? Sorry for my ignorance, but I was just curious as to the size differance. Would it be possible to bugfix the UPX to not crash the interpreter? Or is it not worth the effort (I'm pretty sure it's not worth the effort, but I thought I'd ask)?
I've noticed this is a beta (not surprising, but definatly cool). Would you recomend I wait until it's more finalized before I start using it? I'm guessing that it doesn't really matter to you, overall, but I thought I'd ask. What it probably comes down to is, do you want Winamp to potentially crash, or work stabily? If the latter, then wait for a final release of this version (that's probably the answer I can expect).
Thanks again! If I had money, I'd donate (for that matter, if I had your address, I'd consider sending Mountain Dew, or frozen burritos to you, except that they still cost money, which I don't have). Good luck, and it's awesome to hear the improvements that are coming. Mouser X over and out.
UPX is a program that compresses EXEs and DLLs (not to be confused with winzips self extracting), work quite well too. For example, i think it compresses MAME from i think about 25Mb down to 4?
Hmmm, i would recommend to use this as an experemental version.
Still don't run my dk64 tests (no surpsise there). Maybe a ripper should be made using it.
Ah. I've heard of it before, but that's all I can really say. Bug fixing that is almost certainly not possible. Obviously, I didn't know what it was I was asking. Oh well. Perhaps, in future versions of 64th Note, this will be fixed? One can hope, of course. Thanks for your reply. Mouser X over and out.
Well, I tried the new version, and all it did was crash on me. I didn't get any sound, at all, with the recompiler on, or off. My settings are with the "detect Silence" on, and the default time set to 170 sec. with 10 sec. fade. Recompiler on, or off, doesn't make a differance. Everything else is default settings. Also, it no longer works with any of the previous sets either... I've decided that I won't be using this beta for awhile...
One thing to note. I have loads and loads of input and general plugins for Winamp. It is possible that one of these is causing errors to arise. However, they've never given me problems before...
I'm using Winamp 5.093, XP Pro, 512 RAM, 2ghz CPU (athalon 64 bit). Anything else important? Currently, I'm using DrO's Jump to File Extended v0.97 r11 (meaning, it's being rebuilt, so it sometimes has issues). The reason I bring that up is because everytime Winamp crashes, JTFE brings up a debug.txt file. I could send that file to you, if you think it would help. It provides info on all the dlls that were running at the time that Winamp crashed (in relation to Winamp, I believe). It might, or it might not, give you an idea of where the problem is.
Thanks in advance for your help, and for the future improvements that 64th Note will see. If you have any questions, I'd be happy to see what I can do to answer them. Mouser X over and out.
Regarding UPX, it's what Neill uses for Highly Experimental, IIRC. I tried disabling everything optional in the compression but it doesn't seem to help. It may be a bug in 64th Note that's exacerbated by the decompression, for all I can tell.
Regarding the visualization, I'm aware of that. I have a fix but it comes at the cost of accuracy in track times. I'll be working on stabilizing that.
Regarding MouserX's crash... I'd definately blame it on JTFE. I've got a copy now and I'll be seeing what it does to bring crashes about so readily. Have you tried temporarily uninstalling it?
I also had a problem which caused errors and crashes in Winamp.It was a Input Plugin to play Sega Genesis Gym Files.U should not use to much input plugins/codecs and especialy try not to install more than one codec pack.Maybe this is the fault?
The beta doesn't output any sound when using XMPlay (www.un4seen.com). 64th 0.10 works quite fine (heck, I seem to recall writing to you earlier about something adn you putting an optimized build).
I've just given the plugin a round on my PC. Ubuntu Linux 5.04, Winamp 2.95, and Wine CVS 04/19. Winamp in general is fairly slow (visualisation problems perhaps? Works a lot faster in SSB), so I didn't get a whole lot of testing done. But I loaded up my entire USF library. I got nary a crash. I tried samplings from just about all of my USFs.
So where do we send the Mountain Dew? :) Fix the visualisations, and I'll send you a case.
It's odd that there should be problems with the sound output, I cheated and more or less directly copied the Winamp interface code from the old version. I'll be rewriting that soon and I'll test it out in XMPlay.
Oh, and I don't really like Mountain Dew, it's just what was in the fridge.
I fixed the timing (I had used a long for the cumulative time, the fractions of usecs thrown out added up to seconds off by the end of tracks, now I have a double), and visualizations work as well. I cleaned up how the end of track shutdown works, also.
I tested it out in XMPlay and it seems to work fine (but then again so did the last version). I also tried JTFE and it didn't seem to crash, so if you could send me the crash log from that it might help. Also check for plugins that might be interfering, like the one PdZ suggested.
New version by marioman at 4:08 PM EDT on September 7, 2005
I tried out the new build, and I got 0 (as in ZERO) crashes. So, whatever you did fixed the crashing for me.
However, I found one minor thing that might need to be looked into. (You know I just HAD to find one problem.) When you play a timed file and then switch to an untimed file, Winamp applies the time from the timed file to the untimed file.
Example:
I play a file that is 3:00 long. I load an untimed file in the playlist. The playlist (not the seek time) shows 5:12 as default the time for the untimed file. I press the play button. The untimed file starts playing, but the time on the seek time is 3:00.
This gets really annoying when you have just played a file that is less than 30 sec, but, like I said, it is a minor deal. Everything else sounds/looks great. Thanks.
(By the way, you are right - that dog on Animal Forest sounds hilarious. Is he supposed to be singing in Japanese, or is he just singing jibberish? Very funny.)
When I said that JTFE brings up a "debug.txt" everytime Winamp crashes, I ment EVERY time Winamp crashes, regardless of the problem (a week or 2 ago I was doing something (I don't remember what) that caused Winamp to crash, everytime, without fail. I think it had to do with the Media Library, but I can't remember). In other words, the txt file might help.
However, in regards to checking for bugs, I personaly doubt it's JTFE (since it's shipped with Winamp, just not the version I'm using, so it does of course put JTFE in the position to be the problem, but I doubt it). But I will have to agree with PdZ in that it could be an input plugin causing the problem. In fact, I'm fairly certain the one that caused him problems is the one that caused me problems. It's called "in_ym.dll." It plays compressed GYM files (which is why I use it. It's cut down GYM size from 6mb to 100kb). It's gone through numerous iterations, some of which were not done by the original author of that plugin. Also, another good reason to believe that it's the culprit here is because it has been proven to cause problems in the past. I don't remember what other plugins it's interfered with, but it hasn't given me any problems in a very long time, so whatever plugins they were I either don't use, or they have gone through enough newer versions (and improvements) that they no longer conflict. Another thing to note is that this GYM plugin hasn't seen an update in about 5 years. In other words, don't expect anyone, let alone the author, to fix that plugin to cooporate with 64th Note. Considering how often I listen to GYMs, if it becomes a serious problem, I'll probably have to let the GYM plugin go... :(
Anyway, since I'm not home right now, I can't test out the new beta to see what results it has on my machine. However, I should be home within the hour. I'll try it out then. One last note. When I tried beta 2, it didn't crash until I tried to play another file (using HE). What I mean is, I'd play a USF (any, it would seem), and no sound would come out. I'd stop it, (since Winamp was still in the "play" mode), go to a new track (those being PSF), and play it. That would often work, but when I went back to the USF, it wouldn't play again (this time being a different USF from a different set). Then, when I went to a new track (being PSF again), it would crash, and "debug.txt" would appear. Just thought I'd let you know.
[EDIT] Oh, and the problem listed above by marioman wasn't exactly present in beta 2, but it was there. When I loaded a USF into the playlist, it would say, for ex: "New Tetris - Dvie (or something)" with the track time. However, if I was on "Chrono Trigger - Singing Mountain" and then went to the USF, the USF would take on the previous track's info, and say "Chrono Trigger - Singing Mountain." However, I didn't notice wether it effected the track times or not. Also, it only did this if I didn't stop the previous track first. At the time, I was listening to a PSF from the Super Robot Wars Alpha set (unlreased), and the USF appeared as "Gundam Wing - White Reflection" because I skipped to the USF without stopping the song first. If I recall, it didn't go through the info change if I stopped the song first. I'll see if this is still the case with beta 3 when I get home. [/EDIT]
I'll let you know how the new beta runs on my machine in about 1 hour. Thanks in advance. Mouser X over and out.
edited 10:31 PM EDT September 7, 2005
YM2612 and Winamp Plugins by marioman at 7:40 PM EDT on September 7, 2005
I CAN'T STAND YMAMP!!!!! For starters, it doesn't play the instruments right. I have compared actual .wav rips that I have made from a real Genesis to the output of YMAmp, and the plugin output absolutely stinks. Secondly, as you said, it is very unpredictable. I had major problems with it too. The only thing that YMAmp is good for is tagging GYMs; that is it.
Although YMAmp DOES support the enhanced compression, it is some type of specialized Zlib compression unique to YMAmp and is not able to be read by any other plugin/utility. Therefore, it does help with the file size issue, but it sends the compatibility down the drain.
If you want a good GYM player, I suggest in_gym. It is not very configurable and it does not allow you to edit tags, but it produces the most accurate sound of any GYM plugin available.
I have done much research on GYM accuracy, and I have concluded that the GYM output from any plugin is not perfect. So, I messed with my EQ settings in Winamp until a came up with a setting that, when used in conjunction with in_gym, sounds almost exactly like the real thing. I guess I could post the settings if you really wanted them.
So, anyway, there is my off-topic two cents worth.
Well, I've removed "in_ym.dll" and "gen_jumpex.dll" (which I assume is JTFE),and still no sound. Even on the sets that worked under v0.10. However, on a positive note, it hasn't crashed... I think I'll send the "debug.txt" to you, and see if it might help (don't get your hopes up, I have no idea what that file actually contains).
As for YMAMP, marioman, if you don't like it, what other GYM player would you recommend that provides compression? Or that reads through compression? I'm not one of those "It's not 110% like the original so it's useless." people. In other words, audio quality isn't my aim. It sounds good enough for me. I use YMAMP because it provides excellent compression for those nasty huge GYMs. If there's another Winamp plugin that you know of that provides compression (it doesn't even have to be as good of compression as YMAMP), then let me know, and I'll look into it.
As for incompatibilty issues, if you use Foobar2k, then whatever GYM plugin comes with that reads the YMAMP compressed files just fine. I tried it out just to see how well it worked. I was rather impressed that it read the YMAMP compressed GYM files. Anyway, that's just to let you know that not everyone is a purest... Any alternatives you have to offer though I'm open to, so long as they provide compression.
Also, it would seem that YMAMP isn't what was causeing the lack of audio output. Neither was JTFE, or even my (meaning I use it) really spiffy plugin that puts the song title, and time, and even playback buttons on the currently active titlebar, responsible for the lack of audio out. I guess my next best method would be to start from scratch and start adding stuff until it no longer works... Anyway, I'll send that txt file when I get the chance. Mouser X over and out.
OK, OK....maybe I did sound like a perfectionist, but I am not trying to be one. I usually do not care if a plugin is somewhat off, but when I listened to the YMAmp output I thought that it was so inaccurate that I chose not use it. (It takes a lot to make me dislike an output plugin.) So, I just wanted to clarify my position - I am not really a fanatic.
As far as the compression goes, I forgot about the Foobar plugin. I tried that one out myself and thought that it sounded very good. The only reason that I don't use it is because I am pretty well established in Winamp and would not be interested in switching back and forth between players every time I want to change music formats. I don't know of a good Winamp plugin that does support that compression. Again, it is YMAmp specific, and I cannot find a Winamp plugin that will support it. (Aside from YMAmp itself.) However, I have heard that plugins exist where you can put music files in .RAR format and Winamp will decode them and play them back using the proper plugin. I have not confirmed this, but I have heard rumor about it. So, my suggestion would be for you to use in_gym, but you can do what you feel is best.
On a more on-topic note, I did finally get the new beta to crash twice. It crashed for me both ways that I mentioned before. (Error then crash, and close without error.) The only thing is that both times it crashed, I was playing tracks from the new Paper Mario set. So, I don't know if it is a Paper Mario specific problem or not.
Well, I finally found out what plugin was causing the problems. It was another of DrO's plugins (he's makeing JTFE for Winamp. From what I gather, he's actually on contract with them, so JTFE is actually pretty good, most of the time. Which is why v0.97 isn't final yet, there's still some issues being worked out on it). This plugin is called "in_zip" and allows Winamp to play files from compressed archives (ZIP, RAR, and even 7zip, or something). It's in the beta stages right now, and hasn't seen an "official" release from DrO (that's his forum name, by the way). In other words, JTFE is probably more reliable than in_zip is right now. As such, I've removed in_zip. However, what this means for me is that marioman's above recommendation can't be followed because I no longer have a plugin that can read from archived files. Well dang.
As for the titling errors, they disappeared when I removed in_zip. Apparently, in_zip is doing some pretty screwy things to cause those errors. Either that, or 64th Note (or in_zip for that matter) is to beta to to be considered safely stable/not conflict with other plugins.
Thanks again for the help, and time spent to sift through this mess. Mouser X over and out.
so did just the titling errors go away with in_zip or can you now actually use the player?
I've also noticed issues with Paper Mario being more crashy than other USF sets. I don't think it's a problem with Paper Mario, since the same tracks don't regularly crash, but more likely something in 64th Note that is brought out by something PM is doing.
Yes, removing in_zip allows me to use 64th Note 1.0 beta 3 just fine. So far, no problems. However, a new version of in_zip (0.5.3.0 alpha, I was using 0.5.2.5, or something. Apparently, that version had a loading bug) came out, so I'm going to try that and see what difference it makes. Yah, alpha. There was a beta sometime ago, but he had a HDD crash, and lost the source, so he's rebuilding in_zip. That's why it's in the alpha stages again. I suppose I could also try the old beta. It might work for compressed GYMs...
Well, 0.5.3.0 doesn't allow 64th Note to work either. However, interestingly enough, the old, beta (and lost source code) in_zip allows 64th Note to work fine. Interesting. That being the case, chances are that as in_zip alpha improves, it will fix this problem.
I just notified DrO about the problem (he was getting ready to "finalize" this stage of in_zip, so I thought I would bring this error to his attention). Perhaps things will be taken care of on his end? For all I know, he might even try to contact you and work out the problem. Anyway, I just thought you might want to know that info.
[EDIT] When listening to the "Bust a Move '99" set (or whatever it's called), I noticed that some tracks were skipped as though they had silence in them, but weren't actually silent. I think it has to do with my output plugin settings. I have a fairly high prebuffer set, so that the song preloads a good section of the audio before it actually starts playing. I think that the silence detection was thrown off because of this, and skipped the song. After reloading them (they worked when I listened to them again), there is often a section where the instruments drop out for like, 1 sec. or less. Perhaps the silence detection is mistaking this breif moment as silence or something... This just happened to "sparse0a.ram.miniram.miniusf" in the Mischief Makers set as well. In fact, I had to attempt to load it about 3-5 times before I could actually listen to it. I'm using the Wave Out plugin, with the "Buffer ahead on track change" set to about 3 sec. and the prebuffer set to 5 sec. Hope this info helps pinpoint the problem (I seem to recall a similar thing happening in earlier itterations of 64th Note... Perhaps it's related?). Thanks again for your dilligent efforts. Mouser X over and out (again). [/EDIT]
I don't know if this will help or not, but when I used beta 3 to play the Mario Party 3 samples from Josh, I felt like my Winamp turned into the crash-o-matic. It seemed to be an init problem. (I don't know for sure.)
Hmmm, that most likely wouldn't be the plugins-but my fault.
Thats weird, with this revision of my ripping (i think this is 7) i didn't get it to crash, otherwise if i did i probally would of took the entire thing back to formula.
Crash for you not for me. Strange, i tested it on 3 different PCs...
changes: * Fixed a bug in RSP where it would attempt to deallocate already deallocated memory (this fixes at least one crash bug). I went ahead and cleared up similar situations anywhere else VirtualFree was used. * silence detection now won't end a track until it's actually played to the point where the silence starts, which should fix things for users with large buffers (before the track would end as soon as the specified amount of silence was *rendered*) * fixed bug wherein default length wouldn't be used * added "always use default length" option (by request) * rearranged config dialog
sooo, I haven't seen any crashes yet, y'all let me know how this version works out. I used to be able to get it to crash reliably by putting the following in a playlist: FF7 Prelude sparse66 from Paper Mario Get Heart Container from Zelda OoT and just cycling for a few times. That no longer happens in this version.
Snag by Yoshinkeru at 4:30 AM EDT on September 9, 2005
I was going to post this, but then I saw you had the next version up, so I downloaded it.
I'm still having this problem. (You didn't think you'd get off that easy, did you? :) )
Don't worry, it's only a little thing. It's just that sometimes when changing tracks (whether or not in the same set), it gives me an "error": "Thread did not stop, terminating". After hitting "OK", it goes to the new track and starts playing, no other problems whatsoever.
Sometimes the CPU thread refuses to die by itself and the control thread throws up that message. It did that in the old version as well, but I had pretty much every warning message disabled so it didn't become an issue. I've never had this happen within Winamp, though, only in foobar2k. In any case error messages will be disabled, either by default or altogether, in the final version. Nothing to worry about, just a little irritating.
Also, a change I hadn't mentioned on the above list: 64th Note now saves changes to plugin.ini in the plugins directory (or whatever directory the dll happens to be in (if you don't rename it, otherwise it might have trouble finding itself), as does Highly Experimental, et al.
Also, I noticed a problem with the new config window: the current CPU priority name field is too short, so if you choose "Highest" or "Time dependent" it doesn't fit. I've fixed this...
One thing I wanted to ask was, since 1.0 now plays Mario Pary 1 using the recompiler, does that mean it will see an official release soon? Or must we wait for 1.0 to be finalized? Just wondering. Mouser X over and out.
Yeah, when 1.0 gets a final release MP1 will be released, too.
Beta 4 by marioman at 1:16 PM EDT on September 9, 2005
MUCH more stable; no crashes in a limited testing period. (It didn't even crash with the Mario Party 3 crash-o-matic.) Thanks.
I know I said that I would be quiet, but I forgot to mention this earlier. First off, let me establish that I know that xSF cannot support backward seeking. However, most xSF players offer a pseudo-backward seeking option. What the players do is when a person backwards-seeks, the player restarts the track and then seeks FORWARD from the beginning to the desired time.
My question is: Can this be implemented in 64th note? If not don't worry about it, but it would be something nice to have.
Thanks for your hard work in bringing this player to perfection.
Sure, it's possible. Do I want to spend the time implementing it? Not really. Try seeking, and you'll see how slow USF playback is. That won't be any faster for the pseudo-backwards seek. It's of such limited use, and I'd have to spend a significant amount of effort getting it working accurately and bug-free, that I'd rather just not embard on that path. When 1.0 is released the code comes with it. If someone else wants to add this feature and sufficiently test it and show it to me then by all means I'll add it. It'd be a fairly simple modification, there'd just be many ramifications all through the rest of the program to ensure things don't mess up. Or perhaps some day when I can't think of anything better to do...
Bug by unknownfile at 4:30 PM EDT on September 9, 2005
Yeah, it looks like there are some bugs to be worked out of the time tag reading (witness some tracks which shouldn't fade using the default fade anyway). Unfortunately I'm away from my code for the weekend so I can't put any work in on it right now.
That's odd, I've used XMPlay without Round Frequency before and it's worked... but not with those games so maybe it just couldn't handle them specifically.
So far, beta 4 has been working great for me. There was once or twice where I got a crash, but I think it's because I was loading a playlist containing over 47,000 songs while either listening to a USF, or right as the USF was finishing playing (and therefore Winamp was attempting to load the next song, while also loading the new playlist). In other words, I'm pretty sure it was a user based error (in the order I was doing things), and not a 64th Note error. Just something I did while listening to USFs that got a crash.
On a side note, DrO fixed in_zip (it's now v0.5.3.1) so that in_usf works while in_zip is installed. He also said that, with additional testing, he found that USF would be a good format to test with to get in_zip working even better (meaning, for in_zip to load USFs into in_usf, requires that in_zip extract both the *.miniusf, as well as the *.usflib file). I was glad to read that, because that's the biggest reason I want to use in_zip, so that I don't have to have all those tiny 1k, or less, files all over my drive... When in_zip is finalized, I can keep USFs, GSFs, or PSFs in the RARs (or ZIPs), and load them straight from there. That will definatly save me some drive space.
Anyway, just thought that might interest you. Mouser X over and out.
ooh, very cool, I'd be very happy to see a nice, solid archive plugin that supports multipart formats. You might want to suggest he test out MDX and the other PSF formats (as they all have that same property).
v1.0 beta 5 is out, get yours today. This should fix the problems with Play Forever (when you have a fade on a 0 second track it'll just play silence forever... and the bug was that I didn't clear the fade value for each track). The same fix solved the problem of tracks without a fade tag (the early ones before it was possible to edit in 64th note) assuming the fade of the previously playing track. I haven't heard of any crashes since beta 4 came out (except for Mouser's stress test failures), so be sure to let me know if there are still problems.
Error display is now an option, and in order to make that useful USF loading failures are a lot more graceful and will simply skip to the next track without crashes (ideally...) if error display is off, otherwise you'll get a few errors for each failure. "Display Errors" is disabled by default. I've also enabled more error reporting because of this in order to try and track down the odd error some people have been reporting wherein tracks will be skipped (especially in Mystical Ninja), which I've never been able to reproduce. I also redid the logo a bit, it's smaller (file size) now.