Previous Page | Next Page
- by Mouser X at 8:22 AM EDT on September 8, 2005
- 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]
edited 4:49 PM EDT September 8, 2005
- by marioman at 4:43 PM EDT on September 8, 2005
- 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.)
- by Josh W at 4:55 PM EDT on September 8, 2005
- 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...
- by hcs at 10:40 PM EDT on September 8, 2005
- 64th Note v1.0 beta4 9/9/05
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.
Also, for anyone who hasn't seen 'em.
- 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.
Any thoughts?
- by hcs at 6:13 AM EDT on September 9, 2005
- 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...
- by Mouser X at 8:58 AM EDT on September 9, 2005
- 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.
- by hcs at 10:07 AM EDT on September 9, 2005
- 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.
Now, back to my silence.....
- by hcs at 4:07 PM EDT on September 9, 2005
- 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...
Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source