right, here goes the reply... (which i've been meaning to do for a few days but a lack of time went against that)
i've got jnetlib for handling file downloads, etc so that won't be too much of an issue to deal with i hope (no idea on these proxy things, etc people deal with but hey, i can deal with that if it happens at some point)
not sure why it wouldn't advance to the next track properly since it works fine in the mp3 zips i've tested but some of the code in there is a bit ropey which is most likely the cause by it not reporting file paths correctly, etc
And DrO, please rename the Plug-in to e.g. "Winamp Archive Player", "in_zip.dll" in "Preferences" -> "Plugins" -> "Input" doesn't look very nice.
well initial i called it DrArchive ReadO but i've refered to it as in_zip for those who've played with early test versions and i sort of like the name
maybe i'll rename it but i'm sort of attached to the name now but i can understand where you're coming from
With the rar extraction issue, the rar code was added just before i put out the test version and i've not properly looked at what the unrar.dll api is for dealing with such things but once i've got in_zip rebuilt i'll look into the correct handling of folders, etc since at the moment it'll be clogging up your temp folder with partial extractions i guess.
yeah i did get your email, i'm just a bit slow when it comes to reading them (as my backlog of emails shows
) i do read them as i get them, it's just finding the time between everything else to sit down and reply to them at the time.
The other problem is that, to get these files to play, 2 files must be loaded. 1 is the song (it's actually a re-direction thingy), and the other is the song data. For those of you familiar with PSF, USF, or GSF, then you'd know what I'm talking about as the *.xSFLIB files for *.MINIxSF files. Currently, the in_zip plugin can't play those files because the *.xSFLIB file is not found. Is it possible to get in_zip to load these extra files, so that *.MINIxSF songs can play?
i'm intending on adding in some pre-defined rules based on what the format to be played currently us. currently the only rule i've got is if it's a mp3 then i look for a corresponding cdg file since this was initially designed for toqer
but at some point i will be able to add in handling for these extra files as needed.
When in_zip is finalized, will it be able to read the tag data, while the file is in the archive? In other words, if I push "Alt+3" on an archived file, will the file info show up, in the final version? It does not currently do this, and I don't see that as a problem, as this is just a "sampler," so to say. I'm just wondering if I can hope for that in the future.
at some stage i want it to do that but it'd be configurable as an option since i've got planned an expanded version of the info dialog you get when viewing the info on the root zip item so you can set tag fields, etc when the file is played (useful for the ol' karaoke basis). but allowing for the proper file dialog for that file is possible (only downside is that i still have to do a temp extraction of the file inorder for the proper input plugin to read it but that's just how it works).
What I mean by that is, why does it start with "zip://" and then end with the number? I realize what it's doing. "zip://" means, more or less, that it's being accessed by the in_zip plugin (I assume), and the number is the number of the file in the archive (again, assumed). What I want to know is why it must be loaded this way. The answer is probably too technical for me, but I'd at the very least like to try to see it from your point of view. I ask this because the SNESAmp plugin reads from *.RARs (though they must be renamed to *.rsn to work) as though they're directories, without the prefix, and with out numbers, but by actual file name. Would it be possible for in_zip to ever do this?
you're basically right
zip://blah is so that the plugin knows it's dealing with the extracted item in the archive (basically it makes detecting and then handling things simpler for me).
the number is the index to the file in the scan that was done when the file was loaded. why i did that, well basically for speed in early development of the plugin and there's nothing stopping it from storing the filename there. since the number indexing is already there i'll keep that but i can add in an alternate option to store/index by the filename (possibly useful if you want to manually add in a file from an archive)
hope some of that makes sense, if you need anything else clarified then please do ask but as you say, some things are still in the "wait and see" catagory since i don't quite know how things will/won't work
and not bad for 30mins typing