in_zip (v0.6.8.5 29/10/2006)

[DrO]

The name sort of gives it away. Yes there are other archive reader plugins but none i've found properly handle multi-file archives (which p2p networks seem to like )

This plugin is still basic as i post 0.5.0 with basic support for zip and rar achives (using unrar.dll bundled with the installer). It's still alphaware like but it works so that's something.

When you add in the archive it will create a single playlist entry. When you play that entry it will auto add any supported files in the archive into the playlist and will then play the first file (unless shuffle is enabled and then it may go a bit funny for the current version).

Known issues so far:
* Shuffle on can do wierd things when clicking on the root item in the playlist
* Rar achives report 0 valid files in the playlist title even when there are valid files
* Not tested on corrupt/broken archives so anything could currently happen
* Anything else i've forgotten


in_zip v0.6.8.5 | changelog

-daz

[gaekwad2]

I tested it with a zip file with multiple format files:

* Sometimes files are skipped or don't start.
* It failed to open a wma file once (the next time it succeeded).
* video and .mka (audio only Matroska, also associated with in_dshow) files get skipped every time
* .la (yet another lossless format, la != flac) files cause a FLAC_FILE_DECODER_SEEKABLE_STREAM_DECODER_ERROR and then get renamed in the playlist like the last previous file, plus an extra (archive) at the end.

Apart from those points it works

[CraigF]

isnt readfile.dll that is distributed with winamp able to uncompress the majority of files? maybe you could use that rather than supply more dependant dlls?

[DJ Egg]

afaik, read_file.dll only works with Peter's input plugins (in_midi, in_wave, in_vorbis, in_mod), and is also limited to single files (the first file in the zip/rar).
I think the main reason for doing this plugin was people (and karaoke lords) wanted the ability to play zipped mp3 albums... though it'd make even more sense to me to be able to play zipped wav and lossless format albums.

[DrO]

it's limited to single file archives and goes funny when there are multiple files / non supported files in the archive from what i've gathered / been told.

as for the external dlls, i'll be merging unrar.dll directly into in_zip and i want to add 7zip support as well in a future version. it's just for ease of development at the moment that i'm doing it as i am (changing in one of the next versions so rar support becomes optional until i integrate it all in).

but i can see where you're coming from craig

-daz

[CraigF]

prehaps you can get access to that dll's source and feex?

[DrO]

could try to do that though it may just be easier to complete this and make a complete replacement instead of trying hacking up someone else's code

-daz

[toqer]

Originally posted by DJ Egg

I think the main reason for doing this plugin was people (and karaoke lords) wanted the ability to play zipped mp3 albums... though it'd make even more sense to me to be able to play zipped wav and lossless format albums.

Zipped wavs are a pretty good idea. The CDG plugin just looks for any CDG file with the same name during playback, so yah, I could use zipped wav.

Dro.. Rocks.. Thanks

PS

Just my thoughts on external DLL's. It's a good thing, because modern ones might be faster than older ones. As long as the interface stays the same, just pop in a newer one, mo faster version.

[DrO]

well in_zip will extract what winamp tells it are the supported file formats and then passes playback to the correct input plugin hence any supported file format should be working fine (assuming the input plugins work fine with things or not as gaekwad2 points out)

gaekwad2: any chance of getting a copy of that archive to play with?

-daz

[shins]

Originally posted by t0qer
Zipped wavs are a pretty good idea.

Why not just use FLAC?

[DJ Egg]

...or zipped flac :/

[gaekwad2]

Zipping audio files isn't useful to reduce size, it's used to put several files into one archive.

@DrO: That archive is a bit too big (I don't have unlimited bandwidth), I'll make one with short clips.

[DrO]

got to love all those p2p kiddies out there

gaekwad2: that's fine, as long as it's the same type as the files you tested it with then i can test things fine my end

-daz

[gaekwad2]

I made one with short audio clips.
It's still a bit too big for an attachment (248KB), if you pm me an adress I'll send/upload it.

Behaviour seems a bit different this time, la still causes an error (but zipped la doesn't play in foobar either), mka doesn't play at all, mp3 plays in in_mp3 but not in in_mpg123, and flac only plays (in Gutenberg's in_flac) when there's another file before it.

PS The .wvc file is a wavpack correction file, it's not supposed to be recognised as audio (unfortunately I can't see/hear whether it's being used or not).

[DrO]

pm'd

and i've a nice list of test reports from Egg to go through as well, yay me (between falling apart due to a bitch of a cold i've got, will teach me not to walk home at 2:30am on one of the coldest nights so far :/ )

-daz

[UltraZelda64]

Awesome. Perfect for listening to classic gaming music from Zophar's Domain without having to leave an archive program open or extract all the files.

And minus another reason to use Foobar200, which is both good and bad... it already gets virtually no use from me...

[DrO]

Originally posted by UltraZelda64
And minus another reason to use Foobar200, which is both good and bad... it already gets virtually no use from me...

heh, can't let it have all the glory

-daz

[amano]

That should go into the official WA installer like JTFE did!

DrO...rocks...again!

[DJ Egg]

My only concern with that is n00bs not unchecking "associate with files" or clicking the "select all" button and then finding that Winamp has become the default handler of all .zip and .rar archives. Sure, de-selecting zip & rar in Prefs should fix it and reassociate them with the previous handler . . . but n00bs will be n00bs, and all that, heh.

Re: gaekwad2's issues with in_dshow associated filetypes...
That is most likely caused by the system DirectShow filters not being able to locate the temp files. I've no idea about 3rd-party .la and .wv plugins though, nor in_mpg123 - I guess that must be a problem with those 3rd-party plugins, heh.

The plugin works as good as perfect for zipped mp3, wav, ogg, mod, midi, aac - which will suffice for most people.

Maybe the project should be renamed to in_zip Audio archive support?
Unless DrO comes up with yet another one of his mystical and magical fixes....

[DrO]

Originally posted by DJ Egg
My only concern with that is n00bs not unchecking "associate with files" or clicking the "select all" button and then finding that Winamp has become the default handler of all .zip and .rar archives. Sure, de-selecting zip & rar in Prefs should fix it and reassociate them with the previous handler . . . but n00bs will be n00bs, and all that, heh.

so true, that's why there will be an option at some stage to restrict filetypes being added to that list and also to specifiy what is/isn't allowed like in_mp3, etc do but i totally see the concern on the issue.

with the in_dshow stuff, i think Egg has probably got it since i have to 'adjust' certain api messages and there's a fair chance it's not 100% complete and so it borks (though it may also be possibly due to the video interface but i don't know at the moment )

Maybe the project should be renamed to in_zip Audio archive support?
Unless DrO comes up with yet another one of his mystical and magical fixes....

er, shouldn't that be breaking?? if videos can work then all else should be able to work fine as well so it's not that much of an issue to look into as well as the handling of ml support for the items (useful i think if i can get to do it)

will just have to see what happens with the developmet of this one since now it's working, i no longer need to bundle native support into plex as i was planning to do

-daz

[Maxim]

If I try to open a .zip URL it crashes Winamp. It's a shame, I'd love for it to work that way.

If the zip contains a .m3u, could it add the files in the order they appear in that?

[DrO]

Originally posted by Maxim
If I try to open a .zip URL it crashes Winamp. It's a shame, I'd love for it to work that way.

can you give me an example of the url that crashes so i can force test it my end

Originally posted by Maxim
If the zip contains a .m3u, could it add the files in the order they appear in that?

planned for later versions of the plugin

-daz

[d3x7r0]

DrO does it again, this could be usefull if the m3u thing would happen otherwise ziping MP3 is completely useless.

Still nice going DrO

[Koopa]

DrO, well done, love this plug-in, thank you. Finally, I can zip up all my .spc files.

My only concern with that is n00bs not unchecking "associate with files" or clicking the "select all" button and then finding that Winamp has become the default handler of all .zip and .rar archives. Sure, de-selecting zip & rar in Prefs should fix it and reassociate them with the previous handler . . . but n00bs will be n00bs, and all that, heh.

I agree, you should simply make .zip and .rar file extensions non registerable.

[DrO]

it will be changed in the next build when that comes out with the default of the options being off (i'll be making it more like in_mp3 so it's still possible to associate things but... only when it's manually done ) - useful say if you specifically name an archive to a different extension (some might do it )

-daz

[Koopa]

i'll be making it more like in_mp3 so it's still possible to associate things but... only when it's manually done

Yes, this is probably the best solution, n00bs are not able to register .zip files etc. with Winamp, but advanced users can add these extensions, if they need.

Go on with you good work, I'll looking forward, to future releases of this great plug-in.

[Maxim]

Originally posted by DrO
can you give me an example of the url that crashes so i can force test it my end

My test is non-standard because it's using my own input plugin in_vgm accessing files from here. Hence my desire to have it work with URLs.

The behaviour is very alphaware, though. If I don't use it on a local zip first then it displays "<< #W}| >> (Contains 0 valid files)" for the URL.

If I do use it locally first then it crashes when accessing a URL.

This "local" use means just having a zip in the playlist, not actually playing anything from it.

So, I tried it with an MP3 instead of a custom format. There's a file here with a scary DDR MP3 in it to avoid getting leeched too much. If I add the URL to Winamp I get a similar junk string filename. If I play from it locally and then exit, I get an exception in winamp.exe. If I play it locally, or even just add the local zip to the playlist without playing, and then access the URL I either get a 0 file listing or (usually) an exception at 0x00006c28 in in_zip.dll.

In the interests of removing bug possibilities I tested it with the latest WA5.08 and it's exactly the same (unsurprisingly).

[DrO]

Maxim: i see what you're trying to do now (was a bit full of wine yesterday). the reason why that test file won't play is because there's no support in the plugin for it to download http://blah.zip files and then play them from a temporary location as is needed since you can't extract the file to be played on the webspace being played from.

just looked at the zip files you have and i see that there's a m3u playlist in them so when it's done the adding of files in playlist order should fit you quite well

but basically it won't work at the moment for what you need until the support is added to download the file first since you need to have the whole zip/archive downloaded before you can properly scan it for files, etc

hope that makes a bit more sense (now the wine is gone from me :/ )

-daz

[Maxim]

I kinda sorta knew that but I was hoping you'd say "I'm adding it" or at least make it bitch about URLs. I have bits and bobs of code from my plugin for downloading URLs to temp files prior to play which you're welcome to.

[Mouser X]

Okay, I know I emailed you about my problem/request already, but I figured I'd put it up on this forum topic for others to get some ideas for uses of this plugin.

I have hundreds of songs that take up less than 1k. As such, they are actually wasting space, since the allocation tables aren't small enough to accomodate such a small file. If I was able to store all of these songs into 1 archived file, then drive space could be saved. 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?

DrO: Feel free to answer this, or the email I sent, but please don't waste your time answering on both, unless there was something I asked in the email that wasn't addressed here.

For files to experiment with, go to http://www.zophar.net/psf/ for Playstation Sound Files, http://www.zophar.net/usf for Ultra (64) Sound Files, or http://www.zophar.net/gsf/ for Gameboy Advance Sound Files. The input plugins for these can be found by following links at the bottom of the above links I mentioned.

I hope that can help improve the functionality and development of this awesome plugin. Thanks again! Mouser X over and out.

[EDIT] It doesn't seem to load the next song in the list when the currently playing archived file is done playing. Perhaps that is a limitation of the format I have compressed?

[Koopa]

It doesn't seem to load the next song in the list when the currently playing archived file is done playing. Perhaps that is a limitation of the format I have compressed?

I can reproduce this with any file type (.spc, .gym), it doesn't matter if I use zip or rar archives. I have to press the Next button, manually. Can you fix this issue?

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.

[Koopa]

Maybe another bug. Winamp doesn't play files, if the .rar archive contains a folder.

Take a look at the attachment (.rar archive, wich contains some .spc files), I can't reproduce this with .zip files.

[Mouser X]

@ Koopatrooper: When it comes to SPCs, what Winamp plugin do you use? I've been using SNESAmp, and it works great (though you may need 3.1 instead of 3.2)(3.2 introduced some bugs, and unwanted behaviour, so I reverted back to 3.1). SNESAmp reads the SPCs directly from the RAR archives as well. However, you'll need to rename it *.rsn for it to work. And, unlike DrO's plugin, it access it exactly like a directory. An example, pasted directly from my active playlist:

#EXTM3U
#EXTINF:107,Super Dai Koukai Jidai - Overture
X:\00_Music\Emulated Audio\SPCs\00_D\uw.rsn\uw-01.spc
#EXTINF:120,Super Dai Koukai Jidai - Menu
X:\00_Music\Emulated Audio\SPCs\00_D\uw.rsn\uw-02.spc

If you don't use SNESAmp, I recommend that you at least give it a try. You can find it at http://www.snesmusic.org (I think). Because of that plugin, I have 13895 SPCs, and it takes up less than 72mb of drive space. So, even though DrO's plugin supports reading from RARs, I won't be using that for my SPCs. The one I have already works great.

As for sound accuracy, I have compared SPCs to the original soundtrack (mainly Megaman X series), and it is very very close to the original (though I do seem to recall it being either higher, or lower, pitched than the actual OST, but not by much).

Anyway, if that's of any interest to you, I recommend that you look into it. Mouser X over and out.

[EDIT] P.S. If you need to get 3.1, let me know, and I'll put it somewhere you can get it, or I'll email it, or something. All they have on their site is 3.2

[Koopa]

Mouser X, thanks for reply.

When it comes to SPCs, what Winamp plugin do you use? I

Nope, this also happens with .gym or .nsf files(and mp3 files, too, I've compressed some files for testing). Is there a folder in the .rar archive, then Winamp won't play the files.

SNESAmp reads the SPCs directly from the RAR archives as well. However, you'll need to rename it *.rsn for it to work...

Thank you very much for these informations. I'll try it.

But other input plug-ins are not able to read directly from .rar archives, so I'm looking forward to DrO's great plug-in.

P.S.: I use SNESAmp, its the best .spc plug-in for Winamp.

[Mouser X]

@ Koopatrooper: You're already using SNESAmp? Well then, that's great! I must fully agree, "SNESAmp, its the best .spc plug-in for Winamp."

@ Koopatrooper: Since you're already using it, what version are you running? Also, have you tried reading a *.rsn file yet? I've stopped decompressing SPCs ever since they were able to read from the archived files (except when I want to add SPCs to my Winamp Media Library, in which case I extract them to a folder that has the same name as the *.RAR file, except it's called [filename].rsn. That way, when I delete the decompressed folder, and I rename the *.RAR to *.rsn, the ML accuratly leads to the SPCs).

@ DrO: (and below)
Okay, that aside, I have a question for DrO. 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.

Another question. Any particular reason your M3U strings look like this?:

#EXTINF:75,Megaman 8 - Dr. Light's Lab Theme (Archive)
zip://D:\Documents and Settings\All Users\Documents\OC Best cd (audio)\Megaman8_psf.rar,29

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? The reason I ask is actually 2. 1] I think it looks cleaner without the prefix "zip" (not a big deal, I assure you) and 2] I like to be able to see the file names in my playlist, when viewed as text. I have a search program that searches playlist data (not file data, at all!), and if the file name doesn't show up in the playlist, this search utility will probably be less affective than I would hope (again, for the general audience, not a big deal, but for me, I would like that).

Last question. When you load the files into Winamp, it shows only file names. When SNESAmp loads the files, it loads them with the (%artist% - %song name%) in the list. Will the final version of in_zip be able to do that as well, do you think?

Thanks again for you time and effort to address my questions. If an answer is not quick in coming, I'll realize that you're very very busy and that, at this time, answering my questions would not be helpful, as some of those questions fall into the "wait and see" catagory, since you, at this time, might be unsure whether or not you can do the things I asked.

Anyway, good luck, and hope to read an answer soon, whatever that answer may be. Mouser X over and out.

[DrO]

right, here goes the reply... (which i've been meaning to do for a few days but a lack of time went against that)


Maxim: 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)


Koopatrooper: 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.


Mouser X: 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

-daz

[Mouser X]

Thanks for the reply. I did not mean to imply that I was impatient for your reply to my email by posting in this forum. I just thought that since I asked a question relating to this project in an email, that others might want to know what the question, and answer was.

I'm glad to see that my questions and comments are being taken into consideration. Hopefully, they provided some ideas to include, and possibly even sparked your interests as to how to implement them. I definatly look forward to updates to this great utility! However, I realize that patience is needed, as you are still trying to recover from the failed backup (unless you've said otherwise elsewhere. I haven't looked around, so the situation may have (for the better, hopefully) changed). Good luck with it all, and I'll try to keep up on this. If you have any questions, please feel free to ask. I'd be happy to help in any way I can. Mouser X over and out.

[Koopa]

@DrO

First, thank you very much for your reply. I'll looking forward to the next release.

Just one request. Can you put the unrar.dll in Winamp's plug-in folder (...\Winamp\Plugins\) instead of the program folder ( ...\Winamp\), because some other plug-ins like SNESAmp put the same file in Winamp's Plug-in folder too.

@MouserX

I use SNESAmp 3.2, no problems here.

Also, have you tried reading a *.rsn file yet? I've stopped decompressing SPCs ever since they were able to read from the archived files

Yes, works fine for me, again, thank you for these informations.

[zanks]

Firstly great plugin

I had one suggestion though...Could we have an option maybe to use a default password for the archives (RAR/ZIP)

Something like a checkbox to use the password all the time and a textbox to save the password

It's useful when you're not supposed to have mp3s on the system, so you can zip them up with a password. in_zip could decrypt them on the fly with the default password!

Dunno if it makes much sense to you...once again, great plugin

[DrO]

yeah it makes sense since the zip code at the moment is setup to send an empty password when opening the zip so altering that to take a default/custom password is pretty easy to get in. not sure on rar though since i only just looked at the api for it to get it implemented in this test version.

when dev work starts again on the plugin i'll look at getting it implemented (was already planning to but if there's demand for it then i can look into it a bit sooner). there's no eta on dev work beginning again since i've a few other plugins higher up in my todo list and then this can get some more attention again especially to fix the 'quirks' with it

-daz