in_zip (v0.6.8.5 29/10/2006)

[ByTor201]

Any progress so far?

[DrO]

unfortunately not, i've only just gotten back into coding and most of my time is stuck on the jtfe project at the moment. as soon as i can i'll try to get a fixed in_zip out the door.

so much to do, so little time to do it in, heh

-daz

[ByTor201]

Ah, ok... that's pretty much what I thought. I just had to give a friendly nudge to see what was going on.

[DrO]

nothing wrong with a little nudge, just other projects and real work have hindered me getting things done on this one to complete the recursion issues it has with the playlists, etc

-daz

[Winner2]

DrO,

Thanks again for all the work on this plugin. I'm using in_zip.dll version 0.6.8.5, midi plugin in_midi.dll version 3.13, and Winamp version 5.32.

I've browsed this thread fairly thoroughly but didn't yet spot mention of my problem; sorry if I missed anything.

The problem I've noticed with this plugin is that Winamp will not properly load a zipped playlist of midi (.mid) files if the titles of the midi files have a space in them (i.e., "pink panther.mid"). However, Winamp will play individual, non-zipped .mid files with a space in the title just fine.

If the spaces in the file names are removed and files rezipped, the in_zip plugin will work.

I've also used the file association trick of renaming .zip files for Winamp as .wzf (Winamp Zip File) and associating with the Winamp Open action. This works pretty slick.

For zipping, I am using IZArc3.5 beta 3, but I doubt that this is a factor.

Please let us know if you can confirm this behavior. If this issue has something to do with in_zip, is it something that can be fixed?

I realize this utility is not among your high priority tasks, but thanks for any help you can provide.

[Winner2]

After more testing I've found out that the name of the zip file is what causes a problem, not the names of the midi files. This is not as bad a situation.

If the name of the zipped file has a space in it, like "movie midis.wzf", and that file is double clicked, the playlist will load with an entry "1. Movie", which is unplayable.

But if the space is removed, like "movie_midis.wzf", and the file is double clicked, the file will unzip in the playlist and the songs start playing.

However, if a zipped file with a space in the title is dragged and dropped into Winamp's playlist, the title of the zip file will display, like "<<movie midis>> (Contains 100 valid files)", does not play immediately, but extracts the songs once the play control is activated.

I suppose much of what I'm describing is expected behavior, though from a user standpoint I'd expect that double clicking an associated zipped file, even with spaces in the title, would work. Perhaps a fix is to adjust the file type association parameters somehow, but I don't know what will work.

[Winner2]

I've discovered a workaround. In the file assocation parameters, the application association for the open action can be set to "C:\Program Files\Winamp\winamp.exe" "%1". The quote marks containing %1 were added manually. These would not usually appear when making a file type association in Windows 2000.

[DrO]

any associations set via the filetypes dialog (after you've added ;wzf to the extension list on the archive support) page is handled by winamp (as is the same for any input plugins which can have their supported extension list modified).

just re-read your posts and saw

I've also used the file association trick of renaming .zip files for Winamp as .wzf (Winamp Zip File) and associating with the Winamp Open action. This works pretty slick.

which seems to put that you were doing things outside of the remit of the winamp/in_zip combo which would explain why your registry entry didn't have a "%1" in it

-daz

[Winner2]

Thanks DrO. Yes, I feel silly that I didn't check the association list in Winamp. Anyway, if you're a moderator of this forum could you please remove one of the duplicate posts above? The board would not let me remove one of those posts even soon after the posting. Thanks very much.

[DrO]

we all do it so not to worry and i've removed the duplicate post now for you

-daz

[TRT]

Hi,
thanks for this great addon.
The file association doesnt seem to work for me, no additional file types are selectable in the options and when I restart winamp the editbox is empty again. As a workaround Ive added them in the config of in_mp3 for now so i can use these archives in the media library.

[DrO]

what OS are you using and do you know if winamp is set to use multi-user settings or the old style settings. i'm not too sure what could prevent the settings from otherwise being applied - what happens if you switch to the rules tab and then back after setting things?

when

[itsanogo]

Wow! I just found this plugin, it is soooo awesome! I like to have my whole albums in only 1 file each

I know DrO is npt really coding this plugin anymore, but i am just wondering if i am the only one who get winamp to mostly start at the second track and leaving the first track behind?

[DrO]

i leave the plugin alone for 6months from a public release (has been a number of internal releases to people to resolve and implement some Xsf related file specifics) and it's being called not developed again, heh (was only a few weeks ago i last tweaked it but i've not fixed the playlist loading mode so it's not going public until that happens)

as for the issue, i've not seen that in a long time though it may be because i've internally fixed it or something else (can't check my dev logs at the moment). when it happens, is shuffle enabled or disabled?

-daz

[itsanogo]

Well i can "fix" the problem when i replace "spaces" by "_". Even by doing this, i remember it happening once since. So it's no big deal. I always include a playlist, the front cover of the album (folder.jpg) and a CRC file in each archive.

I'm glad you keep have time to develope the plugin.

itsanogo

[byblo]

I just tested your plugin, it simply rock! I remember this topic a year ago or something and I didn't tested it at that time (too lazy)

But I've found a problem :

To do not mess OS general file association, I've associated the .WAZ extension (Winamp Album Zipped or something...) and of course, renamed my album.zip to album.waz

Unfortunately, the rule editor didn't working well anymore using another extention than ZIP if :

-Create a zip file which include a test.mp3 and test.cdg files.

-Rename the archive from test.zip to test.waz

-Change the first default rule : mp3|%file%.cdg to mp3|*.cdg

It seem that the variable %file% still working, but not the '*' anymore :/


I hope you could fix this also, in waiting for it, I still using .ZIP extension.


Another note - I've read this in the plugin :
"* Wildcard support in the rules options is on the possible todo list as an extension of the *.* type actions provided by allowing a more specific extraction but with still the control over it to narrow the results down." Did you do it yet ? Because it would be useful to create a rule like : "*.* | *.jpg" than "mp3,mp2,wav,gym,cym,ace,flac,ape,mpc,... | *.jpg" to show album's cover ^^,

[byblo]

After some tests : When a different extension is used than expected (zip for zip, rar for rar, ect...), the program didn't handle correctly rules.

[DrO]

can you attach a copy of your winamp.ini and in_zip_rules.ini files please and i'll see if i can reproduce the issue. i know i had made soms alterations to the handling of things on that respect and will let you know what i can find/fix (at most i'll be able to provide a interim dev build since there's a number of other parts of the code that need finishing before a new release)

-daz

[byblo]

There are the files (see attachement)

[byblo]

I've noticed also another little problem using wildcard for the extraction rule :
It seem that the plugin check incorrectly for the extension period from the beginning instead the end. So, files to decompress like :

\covers\My.Cover.jpg will not be extracted using the common *.jpg wildcard

Same problem when the folder also containing a period :
\some.covers\Cover.jpg

[seyss]

why zip an already compressed file? mp3 wma wmv aac aac+

[ByTor201]

Originally posted by seyss
why zip an already compressed file? mp3 wma wmv aac aac+

Organization is one good reason.

[DrO]

for those formats it's often down to how they've been distributed that people seem to leave them in archival formats) but i can see why to some it seems pointless though for things like mp3+cdg it's useful to have as a zip bundle so things remain together correctly.

from my experience, in_zip is nowadays better suited to the game emulation area of things like usf sets and other similar formats which are distributed as zip/rar achives and in those cases it's best to leave them as a contained file rather than extracting them out and going that way.

it's all really down to different people's needs and requirements. for a lot i don't think in_zip will every be useful, for others it's a key essential and is used heavily - it's just down to what people need from different formats, etc

-daz

[byblo]

Nothing new about it ?

[DrO]

not currently, i briefly did some work on in_zip a month ago but work on any of my plugins for the last few months has basically been nothing due to other work commitments. i will get around to looking at the issues and releasing a proper new build of in_zip, just not sure of when that will be at the moment

-daz

[byblo]

Thank you. I'll keep an eye on it.

[byblo]

Could you consider to make the plugin open source please ? :S

[Koopa]

Just a small request, before I forget it again, heh.

DrO, if you ever start working on this again, is there any chance, to integrate an option, that in_zip doesn't write any entry to ml_history?

The plug-in extracts the zip files to a temp folder, after closing Winamp, the temp files will be deleted.

Result is, that all zip:// entries in ml_history are just dead links. So an option would make sense, I guess.

[DrO]

just tried this one out and with my dev build i'm not seeing such an issue with ml_history, it just stores it all as a valid zip:// entry as per what's in the playlist editor. now this might be because i've already fixed it, not too sure at the moment as my code changelog notes are a bit messed up as far as in_zip is concerned at the moment.

we'll talk about this when i next see you in the beta dungeon

-daz

[mikerosoft]

hi there,
drag and drop works fine as the files are not in folders / subfolders. how to fix?

[Koopa]

Cannot reproduce, drag and drop files from explorer to eg playlist works fine for me, when the files are in folders too.

[mikerosoft]

even zip and rar? mhh how can i reach this?

[Nunzio390]

Originally posted by mikerosoft
even zip and rar? mhh how can i reach this?

It works just fine, with both ZIP and RAR, as I already showed in my reply to you HERE.

[mikerosoft]

sorry, you must missunderstood me.
please read HERE

[DrO]

preferences -> archive support -> check 'Allow archive files to be associated with Winamp (This may cause unexpected results so be warned)' and then make sure that the archives you want handled (zip, rar, etc) are entered in the edit box below it.

that will then resolve the issue though you then need to make sure that you don't re-associate winamp's file associations otherwise you'll end up with winamp as the default handler for the archives - this is the reason for the "(This may cause unexpected results so be warned)" part against the option.

Winamp's handling for dropping a folder onto it is to work through the files in the folders and _only_ add those that are reported as being supported (which in_zip doesn't do by default due to the conflicts that arise from it).

there's a possible way to work around the issue with it all being incorrectly associated to winamp but i don't really fancy implementing such a hack (causes me more hassle with code maintenance and stability that i just plain cannot be bothered to deal with anymore).

--------------------------------------------------------

development is going very intermittently on this one - have done a few changes which make it work better with 5.5+ and upgraded the 7zip code to the current sdk which seemed to give a slightly faster extraction on 7z files (though i need to look into re-doing the whole handling of the code so playback can start sooner instead of waiting for the file to be completely extracted). the rules editor is going to undergo a complete code review as it's acting like a bottle-neck in processing of files that i need to reduce if/where possible. so i'd like to think before my 6 year forum anniversary i'll have a new version done (ideally well before then but 4months seems like a reasonable timescale to work against...)

-daz

[mikerosoft]

well thanks,
i set the editbox to default and tried to enqueue but had no effect.
checked again the box and it was still filled. no effect.
restarted winamp and the box was empty...
re-association is disabled

[DrO]

once you've set to default/entered the files you want to be acknowledged you need to close the preferences so that the settings will then be applied. if it's not keeping the setting option then that either means you've issues with the access rights on your winamp settings location or there's been a failure in the plugin - i know it worked ok with the version i've got those the public version should work ok as well...

-daz

[mikerosoft]

i could not really find a point about media library support. how can i add zip entries to ml?

[hmmhesays]

I noticed that it doesn't remove *.cdg files when the song is done playing. That would be pretty useful especially if you are caching the un archived files on a ramdisk.

Thanks

[byblo]

A little hopeless bug report:
Read-only audio files contained in rar files aren't deleted once played. (on zip files, the problem do not happens)