Previous Page | Next Page
- by mudlord at 11:41 PM EDT on April 23, 2009
- @SmartOne: XMPlay and its archive plugins work via checking the file headers. Hence why VGZ and RSN work fine regardless.
Plugin update. link is at usual spot.
- by Mouser X at 11:57 PM EDT on April 23, 2009
- Yay!!! Great news!!! The buffer issue is fixed. At least, as near as I can tell. I've maxed out the buffer settings, and the song plays all the way through. Something interesting (leave this in!) is that unlike most of the plugins I've seen where, as soon as the "buffer ahead on track change" is reached, the time display shows the next track's time and sits there, doing nothing, until the current track is done. Once the current track is over, the time display starts to change (as it should, since the track is now playing). With in_mgme, the next track's time doesn't display until 7-8 sec. after the "buffer ahead on track change" is reached. Once displayed, it acts as usual (doing nothing until current song is over). But this is a nice feature! Like I said, I don't see that very often. And with my usual setting of 3000, I'll never have to worry about the time displayed showing the next track's time.
Nicely done!!! Thanks a bunch! Maybe I should hunt down some other plugins that suffer from the truncation problem, and point them to this thread. It might help.
Something I just noticed (since I've never seen the end of the track before...) is that when listening to "Mahoujin GuruGuru (1995)(TamTam)(Enix) \ mgg-02.spc", "Mahoujin GuruGuru (1995)(TamTam)(Enix) \ mgg-continue.spc", and "Mahoujin GuruGuru (1995)(TamTam)(Enix) \ mgg-43.spc" (they were among the shortest SPCs that were over 25 sec. long) they play to the end (the entire 30 sec.), but then they go a little further (about 4-5 seconds). It seems to me that the time, as displayed by Winamp, doesn't take into account the fade time. Is this the case? If you're aware of that, any ideas on how easy it will be to fix (or if it will be fixed at all)? Just thought I should point that out in case you didn't notice it. Mouser X over and out.
edited 12:10 AM EDT April 24, 2009
- by mudlord at 12:27 AM EDT on April 24, 2009
- Well, if the sample buffer issues are fixed, it could be related to how fading is done o:. Not sure on the best approaches to fix that (kode54, any thoughts?). Maybe setting the fade time after the initial calc is done (since GME allows fade length to be changed during playback). I guess I need to now round up more SPC sets xD
- by SmartOne at 12:57 AM EDT on April 24, 2009
- Mudlord, VGZs don't work because there's no gzip archive plugin, plus the VGMs lack extensions(?). (Unless I try this in_zip Mouser X is talking about? I'd rather have another offical XMPlay archive plugin.)
Winamp = filename (extension) to determine appropriate plugin
XMPlay = header to determine appropriate plugin
Right?
- by Mouser X at 1:17 AM EDT on April 24, 2009
- On Blargg's site, it says that GME supports VGZ. I assumed the code to handle VGZ was already in place with the GME library stuff. Since mudlord doesn't plan on supporting VGZ files directly, I'm left to assume that I was mistaken, and that GME doesn't contain the code necessary to handle VGZ natively. Is that the case?
As for in_zip, it doesn't support gzip yet, but DrO mentioned that he was considering putting gzip support in. So, it seems to me that currently, the only way to play VGZ files (using in_mgme)is to extract their contents, and then load the results into your player of choice (adding file extensions if necessary). While doable, I would say that it'd be better to stick with in_vgm, since it supports VGZ.
Since we're on the topic of VGMs anyway, I'd like to mention some interesting behavior. When playing VGM files, the fade time appears to be included in Winamp's displayed time (whereas I don't think fade time is included when displaying SPC times). However, unlike SPCs, when "buffer ahead on track change" is hit, the next song's time is displayed. If you have it set to 20000 (I tried it for testing purposes. I normally have it set at 3000, which is almost nothing), then for 20 sec., the next song's time is displayed, doing nothing. This is NOT a big deal. It still plays the entire song (which is far more important). I just thought it was odd that SPCs and VGMs are being handled differently. Mouser X over and out.
edited 1:19 AM EDT April 24, 2009
- by mudlord at 1:35 AM EDT on April 24, 2009
- @Mouser X: VGZ support relies on Zlib. For some reason when I compile it in, it refuses to co-operate (the crashes)
I did VGM stuff differently due to some test files I had that have loop times set and stuff. Looking at the code would show you precisely how its calculated. Not sure on the stuff with buffer ahead though.
I guess I could DL more stuff and see if I can get a uniform timing algo or something, depending on what fields are set (like for looping times and stuff). I guess this is also the time for coming up for a decent timing algo (another thing I really wanted to improve)
@SmartOne: You were right about XMPlay. Archives are opened depending on the file header. So you can load VGZs (which are renamed ZIPs) and RSNs (renamed RARs)regardless of its true extension. Not sure on the exact mechanics of in_zip though.
- by DrO at 9:01 AM EDT on April 24, 2009
- in_zip works on an extension and file header based check with it handling anything in a zip:// style entry or whatever extension has been associated with the plugin (as the other winamp plugins generally offer). then in_zip will work out the archive type from the file header, extract out the file(s) (depending on the extraction rules) and then forwards things on to the relevant input plugin (mainly based on file extension but also partly on a known plugin list for certain aspects to ensure correct transparency between the archive and the required input plugin).
handling off these vgz files would just require an extraction rule off sorts (implemented by default like i do with the re-writing off the _lib= tag in extracted xSF sets) that would extract and forward on these unnamed files to either in_vgm(or whatever it's named now - haven't really been following it's development much of late) or to in_mgme. now i'd assume people would only be using one off these two plugins at the time or am i wrong in this thinking? if so which one would be looking to have a higher priority for usage with the extraction rule?
-daz
edited 9:02 AM EDT April 24, 2009
- by unknownfile at 9:25 AM EDT on April 24, 2009
- zlib isn't too hard to use, if it's crashing you should check your code against some example stuff, or you might need to build the library a different way yourself. I had to do this with some stuff (in particular HW) but eh...
- by mudlord at 7:06 PM EDT on April 26, 2009
- File updated. VGZ support is fixed, too. The issue was some code from GME was fuxxored. Reextracting from the ZIP fixed that....
Some other stuff was updated too.
Again, in the usual spot.
- by SmartOne at 10:56 PM EDT on April 26, 2009
- The usual spot http://mudlord.fileave.com/ doesn't seem to work.
edited 10:56 PM EDT April 26, 2009
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 22 23 24 25 26 27 28 29 30
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source