Previous Page | Next Page
- by mudlord at 2:41 AM EDT on April 23, 2009
- Silence detection is done via a GME API function. Maybe it is indeed related to the sample buffer issue, and I know that is at least a pressing issue for whats there currently.
And I only tested up to 8000ms. And yes, beyond that, there is detection issues. Which leads to the sample buffer issue, since detecting silence involves counting of null samples.
So: I really should try how hcs does it. Or maybe dr0 can lend a hand? I honestly am not that cluey with audio coding (my experience is in graphics programming, however)
And in_zip shouldnt affect it at all. It seems definately the sample buffer issue rearing its ugly head.
- by mudlord at 2:43 AM EDT on April 23, 2009
- And, that installer, DLL and txt file from the link should be the most recent stuff before I add hcs's stuff.
I mainly want this sample buffer bug killed before killing the others and redoing the GUI design to be more like NotSo Fatso.
edited 3:16 AM EDT April 23, 2009
- by DrO at 8:51 AM EDT on April 23, 2009
- And in_zip shouldnt affect it at all.
i'd hope in_zip wasn't the cause of any off the observed issues though the publically available version of the plugin badly needs to be updated (i know some people have had newer test builds but nother ever final has been released).
now i've only had a quick skim through this thread but if vgz is a gzip based format, would it be of any benefit if i implement reading of gzip based archives in in_zip? would also be a good incentive for me to start working on it a bit more and getting a newer 0.7x based version out the door...
-daz
edited 8:52 AM EDT April 23, 2009
- by Mouser X at 11:21 AM EDT on April 23, 2009
- I figured as much, but in_zip has caused strange issues in the past, so I just wanted to get rid of anything that might, somehow, interfere. Also, since the 450 mhz PC isn't mine (what I've been using to get online), it doesn't have the in_zip beta.
As for gzip support with in_zip, I don't know if that would help. Looking at the VGZs with 7zip, the files don't appear to have an extension. As such, even if in_zip supported gzip, it wouldn't know where to forward the files to, unless in_zip had a special built-in rule that says "if reading from a VGZ, send the extracted file to VGM player." Though, because there's no extension, you'd probably have to add one when you extract it. Not to mention that you run into the problem of an archive within an archive (I didn't think in_zip handled those very well, but I don't remember).
I'm willing to help out in any way I can, of course. So if you want to add gzip support to in_zip, and attempt to get VGZs working using that method, I'd be more than willing to play the part of the guinea pig. After all, isn't it usually my PC that runs into the most problems? :P
Sadly, it is very likely that I won't be available until Sunday or Monday for most of this stuff. I still have homework to do, tests to take, and sleep to get. By the end of next week, I'll hopefully be done with all this stuff. And OH WILL THAT BE A HAPPY DAY!!! Mouser X over and out.
- by hcs at 12:23 PM EDT on April 23, 2009
- fyi mouser, gzip is stream-oriented; it doesn't have any identifying metadata like file name, so he'd have to do something like that. Typically one names gzipped files like blah.ext.gz to get around this (when extracting the .gz extension is stripped off), but there is also the convention of calling gzipped .tars .tgz instead of .tar.gz. It seems reasonable in this instance to name the .vgz output ".vgm" when passing it on to the real plugin.
edited 12:27 PM EDT April 23, 2009
- by SmartOne at 12:33 PM EDT on April 23, 2009
- I use XMPlay.
For RSN, xmp-rar.dll works perfectly. Drag-and-drop an RSN into the playlist and all the SPCs are loaded (Mouser X, without having to rename RSN to RAR!)
This may work simply because the RSNs contain SPCs with extensions.
Applying this to VGZ, I can't say if a gzip plugin would work because there is no gzip plugin to test, and the contained VGMs lack the *.VGM extension.
...What hcs said.
Then again, why don't input plugins/media players do deeper checking than simple file extensions? I vaguely remember something about XMPlay or a certain plugin doing so...
edited 12:38 PM EDT April 23, 2009
- by Knurek at 12:52 PM EDT on April 23, 2009
- XMPlay itself doesn't care about extension (which can be a bother sometime, since it's stealing LOGG from VGMStream).
- by SmartOne at 2:00 PM EDT on April 23, 2009
- I've suggested a feature to allow the selection of certain plugins for specific filetypes. You should ask too.
Suggestions for 3.5
- by hcs at 2:47 PM EDT on April 23, 2009
- The input plugins do deeper checking, but Winamp only cares about file names when deciding what plugin to hand it off to.
- by Mouser X at 8:58 PM EDT on April 23, 2009
- HCS: I didn't know that about gzip. Good to know.
SmartOne: If I setup in_zip correctly, it would handle the RSNs directly as well. Renaming 1 or 2 RSNs for testing is easier than changing the necessary settings (changing an entire directory via command line/batch files would be about equal difficulty to changing the settings though). If I were to replace SNESAmp entirely (which is very possible for this plugin), I'd go and change the necessary settings.
I'm well aware that there are people who like XMplay. I like Winamp. Call me stubborn, but I don't plan on switching anytime soon (I certainly would have already if it was of even remote interest to me). Mouser X over and out.
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