*implement backwards seeking
[edit]
*track # tag
edited 5:22 PM EDT September 12, 2005
Backwards seeking is now possible (though it must be manually enabled). Also silence detection is now disabled by default for safety. I think I've decided against bothering with the track tag, of course that doesn't mean it can't be used I just don't want to put it in the info window.
Okay, maybe it's only for foobar, but it has the option (when you right-click the track) to edit the length and fade-out. Again, I'm not sure how one would go about this.
Perhaps I'm still waiting for the outright foobar plugin... Who was working on that again?
Don't get me wrong, this one works fine, it's just that I'm the kind of guy who likes to customize things to his own taste.
So that's it. I leave it to you.
As for editing track length, the option is there, at least for Winamp. If you're using Winamp, and click on the track you want to edit, then push Alt+3, it will bring up the info window so that you can edit the track length (the box will be in the upper right hand area). Or, you could right-select the track, and then select "View file info." That should work as well. Now, if you're using Foobar2k (which is what it sounds like you're doing), then I can't really help you, other than to say that the track length box should be there, when you view the file's contents... I've used Foobar2k before, and I could have sworn it worked, but I could easily be wrong, and thinking of another plugin in foobar2k...
Anyway, thanks again HCS. Great stuff. Mouser X over and out.
edited 11:41 PM EDT September 12, 2005
XMPlay uses Winamp input plugins directly and thus supports the file info box, so if you just don't want to use Winamp you could edit the tags that way.
Also:
v1.0b8
I just keep cranking out new versions when I get features working...
beta 8 now features Audio HLE, pulled straight from Mupen 0.5 (which uses Azimer's audio HLE, but I think it might be newer than the 0.55.1 source I was using last go-round). So R. Belmont, look well at how compatible this is.
For those who wanted the feature where HLE is enabled only when it will work nicely, please do me the favor of starting another thread with your test results for games. I'll add in a database or something like that to the player.
You may notice that in Pilot Wings the reverb builds up into a screech. I'm not sure what causes this, but it was a problem with the old version as well, I just eliminated it by disabling reverb in the HLE. I figured that it's an HLE bug like any other (see Goldeneye, Zelda) so I left it unchanged this time (which also makes supported games sound nicer due to reverb).
edited 2:42 AM EDT September 13, 2005
edited 11:08 AM EDT September 14, 2005
011. Blast Corps - Orion Plaza.miniusf (Blast Corps set)
and
06 - Matt and Mitt.miniusf (Zool set).
Start playing the first one. It has a duration of 0:56 seconds (0:51 plus 5 seconds of fade). Let it play to the end and the player will follow to the other one.
Except that it will start playing from 0:58 mark (it will still play from the song's beginning, just the time will be borked). So instead of playing the file for 1:28 (1:18+10 sec fade) it will play for about 20 seconds, then end.
This happens when using XMPlay, I couldn't reproduce this with winamp2. Maybe it's something that Ian broke, but all the other winamp plugins work fine.
Heck, most of the usfs work fine. This just happens sometime (I suspect it has something to do with the fade part, I couldn't get unfaded songs to behave like that).
Without testing I can tell that it's a problem with XMPlay, the time reported comes directly from the output plugin. Apparently under some circumstances it won't reset its time when I close and reopen it. I'll examine the behavior to see if I can work around whatever bug causes this.
re: HLE
No, it'd be best if the Audio HLE info is stored within the plugin, or in a "hlecompat.ini" file kept with the plugin, because Audio HLE is a component of the player, not the USF. The same should have been done with those "bug tags" I used to use... The _enablecompiler tag, however, defines behavior which the USF is expecting of the emulated system
edited 6:59 PM EDT September 14, 2005
"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 encountered the same thing with the Majora's Mask set earlier today. It was really bugging me because it would skip like, 10 tracks (I saw it just zip right through them, as though the files didn't exist) before I could get it to stop, even though I was clicking "stop" as fast as I could the entire time. I'm wondering if this is somehow related to my earlier problems where tracks were getting skipped in the "Bust a Move '99" set. However, then, I assumed it was silence detection problems because of my prebuffer state (which is probably what the problem was, after all. I'm just curious if it's related, which it could be, but is probably not). If I knew how, I'd send you any data I could to help you track down the problem. Chances are, I don't know how, and probably don't have the resources to figure it out. Oh well.
Other than the odd set or 2 that skips track, beta 8 has been treating me nicely (though I forgot what the "RSP sections" in the plugin are for). Thanks again. Mouser X over and out.
(though I forgot what the "RSP sections" in the plugin are for)
I suggest an addition of a simple information dialog within 64th Note which would explain options like "RSP sections" and "Round Frequency"
edited 11:41 PM EDT September 14, 2005
edited 11:42 PM EDT September 14, 2005
Printed code(in prelim2.zip):8014A7E0
My code:80159b03
I looked hard at the XMPlay bug, I can't figure out why the output time isn't reset on a normal track change. I may contact the XMPlay people about this, because as far as I can tell I'm doing everything right. I've completed a workaround, but the wrong time is still displayed at it may mess things up for the next track playing.
As for the skipping issue... I still haven't seen it myself and I can't think of anywhere to look. Make sure you have "Show errors" enabled, something might be failing without telling you, and the message would give me somewhere to look.
Help dialog... maybe.
[edit]
ah, here's the XMPlay issue. There used to be an error with 64th Note taking up far too much CPU in XMPlay, it was related to the continuous reading of the OutputTime. Well it looks like this is a similar issue, if the output time is read too often (or maybe at some particular magical time) it never resets to zero on the next track. I'll be working to sort this one out.
[edit]
found another issue no one seems to have noticed:
XMPlay has an odd way of stopping, if you only click the stop button once it will stop the audio output and tell the input plugin to seek to 0 ms. You have to click it twice for it to tell the plugin to stop. Thus with 64th Note you must enable Seek Backwards for XMPlay to stop properly. This and the suggestion to use "Round Frequency" in fb2k and xmplay will be included in the help dialog and readme, if I ever get to writing it.
edited 1:47 AM EDT September 15, 2005
* cleaned up some audio code
* added help box
* raw tags now editable
Let me know if the help box is poorly executed, I couldn't think of a tidy way to do it.
Also, something I failed to mention in the .txt, the comments field in the info window now does automatic word wrapping, before the text would just scroll right off the screen.
64th Note 1.0 beta 9
edited 9:46 AM EDT September 15, 2005
I was able to cause the skipping behavior by preventing the CPU thread from exiting cleanly, thus forcing it's eventual external shutdown, and this would cause it to skip many tracks. With the new track end code there is a pause while we wait for the CPU thread to die, and then a clean transition to the next track.
Let me know, of course, if you experience this bug ever again.
v1.0 beta 10
edited 9:35 AM EDT September 19, 2005
btw, i had been having some issues with these new builds of the plugin with in_tv (http://www.brics.dk/~barnie/WinampTV/) but it only seemed to happen on my current dev install of winamp (was fine on other clean and modified installs) so i think there may have been some setting conflict since this plugin kept flagging up a message that it 'Failed to allocate N64MEM' and then a 'Allocate_Memory failed'.
Nice plugin btw (especially once i fixed my own plugin's issues with it :o) )
-daz
There's also a pause caused by the initial work the recompiler has to do...
Upon further thought, I really should just kill the CPU thread outright, rather than waiting for it to gracefully shut down.
Hi DrO, I hope that you're right about those errors being someone else's fault. I know 64th Note would cause crashes in other plugins before I fixed some problems with it freeing other plugins' memory by mistake.
Thanks for your work on in_zip, too.
edited 2:19 PM EDT September 19, 2005
edited 2:20 PM EDT September 19, 2005
but from what i can see, 64th Note seems pretty stable (even with my attempts to break it which were an api oversight on my part) so i think it's something to possibly forget about since i can't reproduce the issue elsewhere
-daz
edited 8:09 PM EDT September 19, 2005
But yea, I think it's stable enough. :)
Also, just about as rarely as I've heard the static, I've noticed that sometimes the tracks start out with a sort of "chhzzs" sound for less than a second, and then it resumes as normal, usually without any differance in sound than any other time.
The 2nd problem could be related to my prebuffer, as the track does actually play for 1 or 2 seconds, then you hear a very breif blurb of static, followed by normal playback. If you replay the song, it's played without the static every time.
Is this a big issue? Not really. It's just a little annoying. I've noticed it off and on for a little while (though I can't remember how long). I can only speculate, but I'm wondering if it is in anyway related to the fact that my computer has been on since Friday night, with Winamp up (but not playing) most of that time. I doubt it's a memory buildup problem, because I stopped (and no, not paused) playback 2 or 3 times while listening to the PD set.
Here's a thought for problem 1 (slight static during playback). Quite awhile ago, my speakers (only the left side, oddly enough) would get static in them. This happened with just about everything I did. So, I assumed it was the speakers. However, I haven't had that problem in a long time (and I'm still using those speakers), so I sort of forgot about it. This could be related, I suppose, though, since i don't know what the problem is now, or what the problem was with my speakers back then, I have no idea. As for problem 2, (breif static blurb) I have no ideas, other than a music rendering problem having to do with the prebuffer.
Okay, other than that little (very, mostly) annoyance, I haven't had any problems with 64th Note. Thanks again for a great plugin! It sounds really good. Mouser X over and out.
To determine if the static you hear is actually in the playback write the output to a WAV and see if it's still there.
Here's another beta.
* removed unused debug, COM, GUI, profiling, FPS, pause/stepping stuff (saved 84 kb)
* reduced CPU Thread termination timeout on close to .2 seconds (rather than 2 seconds)
And I got the go-ahead a few days ago from zilmar to release the source, so here it is.
If everything goes smoothly the final release should be ready soon.
edited 4:08 AM EDT September 21, 2005
edited 4:09 AM EDT September 21, 2005
As for the unstability of Winamp, my computer has been on and running since late Friday night. I almost always turn it off at night. The reason I haven't recently is because I have the rare opportunity to max out my bandwidth to my hearts content. I don't actually own the connection. I have to share it with someone. So far, they haven't noticed (or, if they have, they haven't commented) that I've been downloading for the last 4.5 days straight. Anyway, I plan to keep my computer up as long as I have internet access. That being the case, my memory hasn't been cleaned out for a few days. I think there's been some kind of buildup because every time I run Winamp, it eventually crashes. Usually what happens is that I'll leave it unattended (without Winamp playing anything) for awhile. When I get back, if I try to play a song in Winamp, the CPU hits 100%, and memory jumps up about 100-200mb. After that, I have to "end process" on Winamp to get anything to go back to normal. The worst part about that is that nothing responds when this happens, so I end up waiting at least 5 minutes for task manager to show, and another 30 for the "end process" function to take effect. It's rather annoying, to say the least.
Why do I bring this up? Well, as I said, it's more likely than not a problem with memory consumption on my computer. But, it did crash, and everytime it did is when I was trying to play a USF (though I probably should have tried to play something else to see if it would have the same effect). Generally, Winamp takes up about 150mb of memory (I have a lot of plugins, and a HUGE (46,000+) playlist). However, when playing USFs, I've seen it get pretty close to 200mb. Since my computer is already sitting at about 500mb of memory used (I have a 512 card, and a 512 page file), Winamnp generally raises it quite a bit higher.
Anyway, I guess that could be considered another "stress test." I downloaded beta 11, but I haven't used it yet because of my crashing problem (which is probably memory related). Just letting you know how things are going on my end, in case your interested. Oh, and I did answer your question... Mouser X over and out.
[EDIT] You are correct. In_zip does not yet support multi-part files. But it will, eventually. It was originally started to be used as a kareoke device. If you have in_zip, and a MP3 with a CDG file inside an archive, it will load the lyrics with the MP3 into Winamp. So, multi-file support is possible, it just hasn't been done yet. I've just been using it/playing with it because I know that it will eventually support multi-part files. And, it can save space for PSF (not MINIPSF though) files.
I have no idea when multi-part support will be put in, but since the plugin is getting stabalized (no bugs, that anyone has mentioned (they've been getting ironed out in these last few builds)), the feature might be added soon. I know that's the reason I want it. Anyway, perhaps you can still find a use for it, even without multi-part support. I use in_ym to playback GYM files because it offers compression on said GYM files. Interestingly enough, if you put those compressed GYM files into a RAR, they're even smaller. And, in_zip does a good job of sending the files where they need to be. The only thing I noticed is that in_ym didn't display the file information correctly inside the playlist when I played the files this way. They kept their file name. Normally, they're supposed to show the title info stored inside the GYM file. Oh well, no biggie, since the file names are often just as good as the info inside the GYM file.
And there's my take on in_zip. Hopefully that helped. Mouser X over and out (again).
edited 3:22 PM EDT September 21, 2005
Here's what I did:
-Changed the "Tagger" field to "Tagged By" (in HA the field is labeled as "Tagged By" and the actual tag is "tagger".)
-Added OST Track Number field (for you stinkin' purists.)
Teh modification
It doesn't even have to be a number only or relate to the OST...
It'd sound better, I think, producing the effect of a linear decrease in volume.
In my research it appears that using a sine/cosine ("s-shaped fade") is more popular among people making this kind of choice for audio. this page is typical of what I've been reading.
So something like: (cos(pi*(t-s)/f)+1)/2 where s is the start of the fade (the length tag), f is the length of the fade (the fade tag), and t is simply the time.
This seems like it really should be a matter of a configuration option.
edited 3:51 PM EDT September 24, 2005
* added alternate fade types (linear, log, cos)
* cleaned out unused options
* added "Track" field to USF Info window
* changed "Tagger" to "Tagged by"
* generally rearranged USF Info window
I don't like the empty space in the info window next to the track field, but I can't figure out a way to eliminate it. Track should be the first field in the window, so I can't just shove it in a corner.
Also, the three fade types discussed are now implemented and selectable in a combo box (which I just learned how to implement). cosine is the default at the moment, as it has won me over, but I'm still not sure it should be the default in the final version.
Something else I should mention: before release I intend to add a setting in the INI that specifies which version the settings are for, and if the version is different from the current version (or not set) the default settings will instead be written and used. This is to start everyone off with a clean slate after this beta test period has ended.
[edit]
Bah, looking at the info window the spacing between fields is a bit uneven and this is irritating me. I don't consider myself much of a UI designer but I do like consitancy in my dialogs. So here's the fastest new version yet:
v1.0 beta 13 and source
edited 4:54 AM EDT September 25, 2005
I finally got around to testing it, but unless I'm missing something it doesn't work with 64th Note at all (can't find the usflib). Advice?
in_zip 0.5.5.0 can now read multi-part files. I've listened to PSFs, USFs, and GSFs. It seems to be working great! However, it should be noted that when in_zip adds the files into the playlist, it doesn't display the PSF tags, only the filenames. However, when the file itself is actually played, all the info is loaded, and displayed, properly. It looks like it's doing a pretty good job so far!
Oh, another thing I noticed is that if you push Alt+3 on a song that is not currently playing, the info menu won't show up. That's expected though, since that file isn't loaded out of the archive.
Just thought I would provide you with a heads up that it's now available. One thing to note is that to get it to load multi-part files, you need to manuelly edit a file called "in_zip_rules.ini" which is saved in the same place as winamp.ini. Since the file is put there automatically when in_zip is loaded, you can view it and add other formats as you see fit. Eventually, that will be configureable from the plugin, but DrO wanted to code the configuration stuff all at once to keep things a little easier/cleaner to deal with. You can get in_zip 0.5.5.0 here. Enjoy! Mouser X over and out.
edited 2:43 PM EDT September 25, 2005
source
Fixed tab order (at least it's logical now). Focus is set in info window now so tabbing will get your right into the fields rather than having to click first.
minor change, but I figure I should get it out there anyway...
I have a new version ready but I'll wait to release it until I've checked this out.
[edit]
I installed "ASIO output plug-in (exe version) v0.62 SSE2" (and ASIO2KS since my sound card doesn't natively support ASIO) and it seems to work fine with what sets I've tried it with. Can you tell me something more about your configuration?
edited 3:12 PM EDT September 27, 2005
* removed a warning and interrupt in GenerateSectionLinkages (needed for Mario Tennis)
* added Auto Audio HLE (included file is incomplete but should be correct for those games it supports)
The Auto Audio HLE function depends on the in_usf.ini, which isn't nearly complete. I'll test some more as I go along. If you want to play with it yourself it is documented in the included 64thv100b15.txt. It's pretty basic, and I just use a checksum because I didn't know CRC32 off the top of my head.
edited 3:22 PM EDT September 27, 2005
I'll keep the most recent one at this address.
Just in case, this is how I have 64th Note configured: Recompiler on, round frequency on, seek backwards on, rest off, and cosine fade selected.
And the ASIO (dll, normal version) plugin: Priority above normal, buffer 7, shift output channels 0, settings all off, resampling on, thread priority above normal, sample rate 48 KHz, quality top. I've never had any problems with this plugin, except for 64th Note, that is.
edit: I know what the problem is! Both games are MK zomg!!11
edited 11:55 PM EDT September 27, 2005
-daz
Actually if you look at handled exceptions you'll see a whole lot of 0xc0000005 (whatever exception that is... I remember the code but not the name) but they're just thrown away by PJ64.
Glad to see it's working well.
Regarding the bizarre frequencies I'm going against my previous decision and looking into resampling techniques (optional, of course).
[edit]
but first: Koji, try this modified plugin:
http://www.halleyscometsoftware.com/usf/64thv100b15FORCE441.zip
it will force the freq to 44.1KHz, if you can play Mario Kart and Mortal Kombatwith this we'll know that the frequency was the problem.
No one else should use this plugin!
edited 10:40 AM EDT September 28, 2005
def: Failed attempt to access data or programs which you are not currently authorized to access, so generally some weird memory issues but i couldn't see anything unless something else is at play with it :)
-daz
The recompiler lets problems in the n64 code become problems in x86 code, so it has its own exception handler around the compiled code to just ignore stuff like that (which was probably caused by my own meddling). I've only noticed it while running the debugger with Mario Party.
-daz
Then again, I suppose it's the codec I used that doesn't support the wonky rates. Anyway, I've run into similar problems before, but only once has it been an issue. Basically, if I wanted to turn USF files into MP3s, a resampler could prove useful, otherwise, it's not something I need (though obviously, this plugin isn't developed for just me. I'm just saying it's works as is, for me, but that the added functionality of resampling could also prove useful, especially to others).
Just thought I'd let you know about that Koji isn't the only one that has had problems (with the sample rates). Mouser X over and out.
I had always thought it odd that I didn't notice any problems with the plugin whereas you did, even though you had resampling enabled so it wouldn't possibly be a problem with your sound hardware. Then I noticed that you're using the dll version of out_asio, which stopped development back at 0.58, whereas I'd been using the exe version which is up to 0.62. So I switched to the dll version, turned on resampling, and pow! it crashes with Mario Kart 64 (and Mortal Kombat 4).
I don't know if this is a difference between the exe and dll version or if something was fixed between 0.58 and 0.62, but my guess is that your problem will be solved if you switch to the new exe version.
Also, Mario Kart 64 will work with Round Frequency enabled (but not Mortal Kombat 4, it must use some value for the dacrate that I don't support with round frequency yet, that'll be fixed in a moment), and both work (for me) if you disable resampling in out_asio. Therefore I conclude that it's a problem with the resampling code in out_asio that was later fixed (though I don't see any mention of this specifically in the change log, but maybe the babelfish translation hides it...)
So update your plugin!
[edit]
This fixes Koji's problem, Mouser posted while I was writing this.
For the mp3 issue (since I've gone off the idea of resampling) I suggest you use the diskwriter, tell it to convert the output to a similar sample rate to the one the game uses, write a WAV, then convert via LAME or your favorite MP3 encoder. That's what I do.
edited 5:56 PM EDT September 28, 2005
I'll also take a look at the out_asio source and see if I can't fix the resampling bug on that end.
[edit]
nope, too complicated
edited 10:09 PM EDT September 28, 2005
round frequency is now stored in in_usf.ini, as I might have to add new dacrate settings to the list and there's no sense in rereleasing the plugin every time that happens. plus the easy user-editability.
It now includes a setting for Mortal Kombat 4, so that should now work with out_asio.
I recommend bugging otachan about it, it's his broken plugin after all.
or, better, yet, use a dedicated resampling plugin like HQSoftProc, which can redirect output to any plugin...
or maybe not, since it doesn't seem to like the odd rates either. Is it that hard to write a resampler that fuckin' works?
edited 8:21 PM EDT September 29, 2005
The shitty performance of Chopper Attack and Snowboard Kids was bothering me, so I poked around to try and fix it. At some point, not expecting it to help much, I changed the Sleep call in the output interface to 1 ms instead of 50 ms... and voila, the CPU usage is reasonable. I don't understand exactly why... I suppose it's a matter of timing not working out nicely with 50 ms.
For example, observe the CPU usage of Chopper Attack under both timings:
and with audio HLE enabled the CPU usage is very low indeed!
I request that people with machines unable to handle the more intensive sets test this out and let me know how it goes.
ALSO, major change in this version, in preparation for the final version, the version of 64th Note that wrote the settings is stored the INI, and if it doesn't match the current version the defaults will be written. This means that your current settings will be overwritten to set a clean slate.
64th Note v1.0 beta 17 and Source
Additional testing shows no improvement on other machines... bizarre. Maybe I'm somehow avoiding another problem on my machine. In any case it's shown that all that CPU isn't actually needed for music generation, there's some overhead involved which can be removed... somehow.
edited 11:05 PM EDT October 5, 2005
Yeah. So all I did was trick windows into thinking I was using less CPU somehow while it's actually using more.
I'll have a new beta up soon with a reversion to the old timing method. Boy do I feel like an idiot... and I was all excited.
I did a little research into the causes and it seems that the miracle CPU usage occurs when I change the sleep value to less than the length of one Winamp buffer (576 sample) + 3 ms. I guess the trick is that in this instance the sleep function will most often be called more than once since it might wait and still not have any space left to write, whereas if the delay is longer than the length of a buffer you're pretty much guarunteed that space in the output plugin's buffer will have opened up. So these multiple calls to Sleep cause the apparent decrease in CPU usage.
edited 1:28 AM EDT October 6, 2005
I fixed an issue with CPU usage going up to 100% at the end of a track.
-daz
1. Load a miniusf
2. Click on the playlist entry and bring up the info screen using alt+3.
3. Without closing the info window, click on the main Winamp box, and press alt+3. You should now have two info boxes.
4. Click OK on one of the boxes
5. Try to close the second box.
6. It should crash.
Thanks.
edited 4:52 PM EDT October 8, 2005
Also, can you get it so that when "Display Errors" are not enabled it also stops such things as DMA and TLB errors from being displayed.
In any case I've modified it so that it won't allow two info windows even if winamp requested it.
I changed a few instances of MessageBox that were left in the RSP (and some in the Audio HLE that hadn't really been a problem) to DisplayError so they're now affected by the configuration. All the TLB errors, however, were already DisplayError, so those shouldn't show up if Display Errors is disabled anyway.
beta 20 and source
plugin configure window - help,
"64th Note Help" refer to from an external text file, or include string in resource?
I am localizing this plug-in.
well if you could please check in v2.80 again to make sure this isn't a problem anymore in that old version
Tomoyo:
The help text is all in the wamain.c file, compiled in as a global string. A resource would have been a better way to go about it.
Thanks.
edited 10:33 AM EDT October 11, 2005
When listening to some USFs in a RAR file, I changed the playtime settings to "play continously" or something like that. When I tried to play the files, it skipped past them almost immediatly. I was lucky to hear a blurb of noise at all from the files. So, the question I have is, does this happen because of the way 64th Note plays forever? I've noticed that it zeroes out the playtime in Winamp's playlist when you have that selected, and I think that might be messing up in_zip's end file detection.
Since I'm talking about the playtime, and play forever, and stuff, I figured I might as well make some suggestions. With HE, when you select "play continuously" (or whatever), the file time in the playlist doesn't disapear, but it just continues past it. Also, if you change that setting while the file is playing, but before it reaches the end, it will still end when that time is reached. I was wondering if this could be implemented in 64th Note, or if it would not be woth the effort.
Anyway, thanks in advance for your consideration on these points of interest/error. Mouser X over and out.
I think the zero time is fine, actually 64th note sets the length to -1000. I don't have any intention of changing the "play forever" behavior.
http://forums.winamp.com/showthread.php?postid=1792636#post1792636 may be of some interest ;)
-daz
edited 6:54 PM EDT October 21, 2005
-daz
Again, thanks a lot for all the work you've put into this terribly useful plugin.
at least it's confirmed as fixed now so that's one less thing to worry about.
i have to admit from all of the testing with archives and formats related to it (like usf ones), i'm starting to enjoy listening to the older music formats again or it's just i'm getting nostalgic :)
-daz
If you need more info., please tell me what you need. Seeing as how this hasn't happened before, it might not be a big deal (and might even be a bug with the video plugin in Winamp, for all I know). Anyway, I just thought you might want to know about that problem in case there was something that could be done about it. Thanks in advance. Mouser X over and out.
End of line.
Do you have Audio HLE or Auto Audio HLE enabled?
I fixed that bug Josh and I were discussing that broke games using the alternate FPR access mode, and I also implemented a small workaround for an irritating problem with the DirectSound output plugin, wherein it would cut off the track early (like a half second). It seemed to be due to the size of the buffer, as when I changed it to 333 ms (from 2000ms) that problem went away, so I now don't stop sending data to the output plugin until (Track Length + Max Latency) (max latency being the buffer size, or close to it). I've tested it with the DSound output plugin and also WaveOut, but I haven't tried any of the alternate players (XMPlay, KBM, foobar2k, etc.) yet.
And yes, I do have Audio HLE and Auto Audio HLE (both) enabled. So what's this mean?
edited 10:09 PM EDT October 26, 2005
That will probably help fix your problem. Hopefully, that helps. Mouser X over and out.
And you were right--well, partially. Seems I have to turn off Audio HLE altogether, that is, can't have it OR Auto. Well, whatever works, I guess.
Looks like I need to be more careful with those. Does anyone want to volunteer to check through all the sets for Audio HLE compatibility? Or a few people? I don't think I can do justice to the feature, I'm going to strip everything I'm not absolutely sure of out of the INI now and it'll ship like that in 1.0 if I don't get some support for this.
edited 10:54 PM EDT October 26, 2005
It doesn't work with HQSoftProc Plugin 4.4 and Otachan's ASIO plugin together (the SSE .dll version).
I don't want the plugin to round the frequency,but use HQSoftProc to do that instead.
But even if I do set that option,it does not work properly.
Also,I use ASIO4ALL v2.6 instead of ASIO2KS. ASIO4ALL is light-years better :)
Now,it works with HQSoftProc only if I use DirectSound instead of ASIO. With ASIO it does not.
Note: 0.9 worked perfectly fine for some rips,but unstable or not at all for many (crash-fest).
Using a standard Audigy2 soundcard,AMD AthlonXP CPU.
Resampling techniques are not needed.The HQSoftProc plugin will solve this with the best quality possible. The thing is to bug the author to add support for bizzare frequencies like this :)
The .EXE version of Otachan's ASIO Plugin is not more advanced. The version number is lower because it needed less bugfixes to reach the same level of features and performance.
Otachan DOESN'T make faulty plugins.You don't understand how ASIO works. ASIO is a standard primarily used by musicians and operates on certain selected (fixed) samplerates mainly used in music production.
It can support bitrates from 16,24,32 bits (integer and float) and fixed samplerates of 8,11,22,24,44.1,48,88.2,96,192 and higher multiples.
It cannot support weird samplerates natively.That's why you MUST use an external resampler plugin before the ASIO out plugin to be able to play the USFs.
Otachan's ASIO plugin features a built-in resampler,which is actually Foobar's SSRC resampler,set to high quality mode.
But you can use a better solution,like the HQSoftProc Resampling plugin www.hqsoftproc.go.ro and play them through it. But the "bug" here lies in those two resampling plugins itself.
They can support any "wacky" input samplerate and resample it to 48,96 or 192kHZ(whatever your soundcard can achieve),but they haven't thought of supporting wacky rates like this.
If you can bug these developers to support it,and they fix the issue,this is the best solution.
NOTE:if you ever listened to something through the ASIO plugin instead of DirectSound or WaveOut,you'l never want to get back.ASIO output sounds clearly superior :)
HQSoftProc is GREAT! I use it with otachan's ASIO (dll) plugin and ASIO4ALL driver all the time.Works for SOME odd samplerates like 37800Hz (PSX XA Audio),but not with
the freaky samplerates of USFs :(
You MUST bug the creator of HQSoftProc or SSRC. If you can't reach his homepage,you can probably find him posting in the threads of DriverHeaven's kX Project forums :)
But,interesting is that HQSoftProc works perfectly with DirectSound,but not ASIO :( So,you should force them to release a new version. HQSoftProc needs a Winamp 5.11 Surround fix and some other fixes,so it's more likely the HQSoftProc creator will release
a new version first.
Koji: It's not ASIO plugin's fault,it's SSRC's (and HQSoftProc's) fault.
Long time no see Koji.How's your Japanese going? :)
edited 11:12 PM EST October 30, 2005
But whenever you want to advance one song forward (press Forward button in Winamp),Winamp always freezes :(
This is not happening when I play any other file (PSFs,MP3s,OGGs,WAVs,SPCs,...),just with USFs.
This happens with any USF.I've tested the Super Mario 64 USF rip as one of the USFs that was guaranteed "bug-free" and it was at an acceptable sound bit/samplerate (16bit/32kHz) for all output plugins to handle,but it just freezes.
Why does this happen? I play other 32kHz files perfectly,that's even the samplerate SNES uses and it plays SPCs well.
I have tested with the SNES AMP plugin,first outputting at 32kHz/16bit (original SNES sound) ,output sent to HQSoftProc,HQSoftProc output sent to Otachan's ASIO_out plugin,in Otachan's plugin output set to ASIO4ALL driver,resampling to OFF (HQSoftProc does the resampling work)
16bit/32000Hz is resampled to 32bit/96000Hz with HQSoftProc and sent to ASIO4ALL driver. Works great.I can seek,repeat,go back and advance tracks easily.
Then set SNESAMP's output to 44100Hz/16bit and resampled again to 32/96000 - everything's fine again.
Set SNESAMP output to 32/96000 through ASIO without any resampling - fine again with best quality :)
I use 32bit/96kHz,not 24bit/96kHz as output for better rounding to 24bit and less CPU usage,even though ASIO is set to output at 24bit/96kHz
But when I try with 64th note:
with "Round Frequency" - it manages to play,but if I press forward,stop or whatever,it freezes everything.
Without "Round Frequency" - it crashes Winamp instantly
So,the conclusion here is - something's terribly wrong with 64th Note and ASIO output,not that as I thought before it was an issue with the resampler :(
You might want to test things out.
Go and try ASIO4ALL driver instead of ASIO2KS (ASIO4ALL works with every soundcard AND with onboard motherboard audio device) and HQSoftProc and test things a bit.
edited 10:42 AM EST October 30, 2005