in_zip (v0.6.8.5 29/10/2006)

[DrO]

i agree it is a bad idea to be basing it on that but for an interim solution which works then it's better than nothing until i work out why WM_WA_MPEG_EOF is being swallowed (my only guess is that it's related to in_zip's init process and the related subclass that's needed to get certain functionality implemented).

-daz

[Borg Number One]

[priestlyboy]

Originally posted by DrO
priestlyboy: is that happening when you're playing the files

-daz [/B]

Yes, as i'm playing them they do not have a length time.
It's just left at 0:00 never gets updated.

Not sure why but it's been like that since using this plugin.

I also use the WSP Module Player 5.3 and the Enhancer Plugin with my MODs/S3Ms and the like for cleaner sounds.

~Allustar

[DrO]

i'll have to add it to my list of things to check out. do you have any test files i can work with though (is easier to test with ones you're already using )

general notes on the plugin's dev... in between trying to find the time to code i'm trying to track down the track advance issue, bzip2 code started to go into the plugin last night (and i'm dabbling with it a bit more now since i've sneakily got msvc6 installed on the work machine now ). i'll try to push through gzip and unace support as well since they're pretty easy to bolt into the code as well. unace.dll will have to distributed with the installer like i do with unrar.dll since that's how the support can be added. however i've managed to build unrar.dll myself now but i'm looking to try to integrate that directly into the plugin as well to cut down on the unrar.dll dependancy).

-daz

[Mouser X]

Just this morning (after reinstalling WinXP), I installed Winamp 5.11, 64th Note 1.0 beta 20, and in_zip 0.5.6.9 alpha (otherwise clean install), and loaded up some USFs from a RAR file. They worked, and I didn't notice anything wrong with it. That is, until I selected "play continously" inside the 64th Note options. Then, if I was lucky, I'd get a brief blurp of sound, and it would go onto the next song in the list.

Now, this could be a problem with 64th Note, but I brought it up in this thread because I thought this information could prove useful to you. Using it, you might be able to refine the "track end" stuff you're looking for. Anyway, thanks for the help and improvement. Sadly, due to bad hardrives (still), I still cant' do much with anything, until I get my computer back up and running. Mouser X over and out.

[hcs]

64th Note sets the track length to -1000 when playing without limit, but never generates an EOF message by itself. It's probable that in_zip is therefore thinking the track has ended immediately and taking matters into it's own hands. Another case for my suggestion...

[DrO]

in_zip v0.5.6.9a alpha

• Fixed (for final i hope) the track advance issues by ensuring the in_* plugins are initialised correctly when in_zip loads them
• unrar.dll rebuilt and optimised the size of it (removes 33k from the publically built version)

get v0.5.6.9a

how i'd missed out a line of code to init the mod.hMainWindow member of the in_* plugin when i load it with in_zip is beyond me. all seems to be 100% now even with the turrican test rar which i was having some issues with

-daz

[DrO]

the reports i've had back currently about v0.5.6.9a are that it fixes all of the issues with track advance and the incorrect handling of strange times as a work around fix for the track advance stuff.

from what i can tell, it looks like the loading order of the in_* plugins was the main cause for the bug not showing up on all of my test installs. from what i can tell now there aren't any other issues now with the emulation layer as it currently stands which means i can look now towards prefs options, 5.x meta data api support (with looking to a psuedo tag format stored in the comment field of the archives), extraction based on the order of an associated playlist (viable now that i've fixed my pls/m3u reading code to handle things correctly) and the option to index the files based on the archive entry so the archives can be modified without messing up things and some other things i need to look at

-daz

[falcn]

v0.5.6.9a alpha works fine
The only thing that's not yet perfect is password-protected archives handling(it should ask password once per archive, not twice for each track). But it's really not so important, pluging just great, saved my Winamp from Foobar invasion.

[DrO]

the password handling of the plugin is a bit 'rough and ready' as it currently stands. as times allow i can look into implementing the ideas i have about the handling and some form of caching the password for the current winamp instance to make things a bit easier to use

-daz

[Borg Number One]

Hello DrO.


Here are some really important improvements:


a)
support for RAR/ZIP/... archives which were not compressed with common compressors like: WinRAR/WinZIP/...

http://exotica.fix.no/tunes/archive/...ll-of-them.rar
http://hangar18.campus.luth.se/exoti...ll-of-them.zip



b)
more userfriendly playlist entries.
It would be really great, if you could replace the current "system":

zip://drive:\path\...\path\archive.ext, archive entry x
(e.g.: F:\MyMusic\MIDI\MIDI.rar,2)


with this one:

zip://drive:\path\...\path\archive.ext, [tune] / [directory in archive\tune]
( e.g.: F:\MyMusic\MIDI\MIDI.rar, 7thguest-intro.mid
or F:\MyMusic\MIDI\MIDI.rar, tyrian\tyrian-intro.mid )

or with this one:

zip://drive:\path\...\path\archive.ext\[/][tune] / [directory in archive\tune]
( e.g.: F:\MyMusic\MIDI\MIDI.rar\7thguest-intro.mid/
or F:\MyMusic\MIDI\MIDI.rar\tyrian\tyrian-intro.mid
using "/" would make it easier to detect where the archive ends and where the content(s) begin. )

c.)
latest in_zip.dll has following troubles with midi files:

+ if one track is finished and the next track begins,
than the MIDI volume control in Windows' Mixer (sndvol32.exe) is set to Zero... no MIDI volume.

+ Winamp's Volume control does not work if a Midi file is played from an archive.



--> Check this:
http://bnobtc.pix-art.com/winamp/MIDI.rar
with in_zip.dll
to see the mentioned bugs.


If you use this .m3u file
http://bnobtc.pix-art.com/winamp/midi.m3u

then "Read_file.dll" will be used to play the music...
and without any problems.

Testing conditions:
+ Winamp 5.1 Surround Edition
+ in_zip.dll (v0.5.6.9a)
+ no other 3rd party plug-ins

[DrO]

a) if the the files aren't adhering to the correct zip/rar specifications then i'm not going to look into handling such formats. i have a zip file from toqer which just doesn't extract out but can have the files in it read so i'm probably guessing this is the same with those files which i can't look at since downloading ~100Mb at work won't go unnoticed). however if the files aren't correctly adhering to the zip/rar file format specs then in all fairness i shouldn't need to update things my end since i'm using the correct rar/zip libraries

b) is already on the todo list as i've mentioned a few times with the aim to be to use zip://drive:\path\...\path\archive.ext, [tune] / [directory in archive\tune] as the format but will not be done until i get the preferences implemented since it will be a configurable option as to which indexing system is used for the zip:// entries

c) that file seems to play ok so far on the quick test i've just done but i'd need to look into it properly on my machine at home.

-daz

[Borg Number One]

Hello DrO.

Reffering to:

a)

That the current in_zip.dll (v0.5.6.9a) release
has troubles with the HVSC (high volatege SID collection) rar archive
has nothing to do with (in)correct rar specifications.

Your unrar.dll was/is surely compiled with stuff (libs, sources, etc...) directly from rarsoft / http://www.winrar-rog.com/,
is not it?


Well, WinRar.exe itself has no troubles to load the zip/rar release of the HVSC.

So I tried to re-archive / convert the RAR archive
(which was build with a Linux packer [-->Rar file info])
and loaded this re-archived RAR file to Winamp.

However, I still get the same error inside the playlist:
"<< HVSC 43-all-of-them >> (Contains 0 valid files)".


So anything is wrong with your plug-in or with the unrar.dll.

[u]This question could maybe help:[/b]

What is the highest number of entries inside a rar file that in_zip.dll is able to handle?

The current HVSC contains 30803 files.


c)

"that file seems to play ok so far on the quick"

DrO, please read previous posts more accurate.

I wrote that playing MIDI files from a rar archive is no problem.
But after a MIDI track ends and a new one begins,
then the MIDI volume in Window's Volume Controll will be set to zero.

I never saw this kind of "feature" (I mean: "bug" ) before.


I really hope that you will find the bug and solve it.

[DrO]

in_zip v0.5.6.9c alpha

• Fixed volume and pan init issues for plugins (should fix in_midi issues)
• Adjusted the zip entires to only display a time when the file is played (instead of 0:00 when the title is queried on display)

get v0.5.6.9c

this is the first chance i've had to look at the plugin for a while since dev work is concentrated on other projects so issues with the test rars, etc have not been properly looked. i have a feeling that it's because they appear to be generated from a unix platform since a re-created version of the large rar file works fine under windows (though why the unrar.dll handling is then borking is a bit confusing... this will be properly looked into when time appears to do so).

so at least that's another two bugs fixed (with the correct volume and pan initialisation for the loaded in_* plugins)

borg#1: speed reading in a non-existant lunch break is why i miss read your post specifically about point c but hopefully this 'c' build should fix the issue (appears to work according to hcs)

-daz

[DrO]

in_zip v0.5.6.9g alpha

• Fixed OEM/Ansi conversion issues with the rar support so files with umlauts, etc in them will now be correctly listed and extracted for playback
• Fixed an issue where some of the in_zip_rules.ini entries could be double processed

get v0.5.6.9g

This has near enough been releaseable for a few weeks as it was but a fix for hcs (see earlier posts) regarding the handling of non standard characters in rar files meant it's better to get this newer build released.

The issue with rar's is the text is OEM encoded but conversions to ansi were not being made by in_zip so as soon as characters like umlauts were present then the internal tests would fail or the correct output name would not be formed and so playback on such files would fail.

Other changes include an expansion of the in_zip_rules support to handle mini wildcard (related to a project hcs is working on), improvement in the handling of in_zip_rules so it won't now potentially allow for duplicate extraction of some rules (which will speed up initial playback for such formats) and a few other minor tweaks, etc that i'll detail when i get home.

-daz

[evolution76]

It is working for me. I got a ton of mp3's in winrar files now i do not have to extract them out. Good Job Dro

[DrO]

in_zip v0.5.8.0 alpha

• Implemented the required interfaces for extended information to be queried from zip files and for the tag (on saving) to be sent to the clipboard (since there is no internal support of the dll to write to archives and it can only read the stored tags from the comment of zip and rar files)
  More documentation will come on how to use this but makes storing zip/rar in the media library a bit easier i've found
• Updated to the latest lzma sdk (4.30) which means 7z files with sub-folders can now be handled like zip and rar's already are!
• Adjusted the rar file handling so that it should now correctly parse any rar file thrown at it
• Sped up the closing of the 'file info' dialog with it caching the number of files in the archive (otherwise winamp was causing this to be re-calculated from a title update)
• Fixed zip support to fully release the file so it can be editted by other programs whilst winamp is now loaded (was only part closing the file handles before)
• Fixed a potential memory leak when trying to auto-detect the type of archive being processed
• Added a small bit of information to the top of the 'file info' dialog about the archive being looked at
• Improved the 'file info' dialogs response when it is querying the current archive
• Some minor code organisation and cleanup to give a potential increase in certain areas

get v0.5.8.0

and a new version arrives (again)... main fixes are the zip file locking issue fix and the update of the lzma/7z code to handle such files with the archived files being in folders in them.

all of the interfaces for metadata retrieval and writing are now implemented by the plugin though there are some limitations to it. reading is only supported on zip and rar files (since the lzma sdk doesn't seem to provide any obvious method to handle this. there is no write support for the tags so instead i've implemented it so the tag is written to the clipboard (and then will need to be manually added to the zip/rar file).

this is because i've not had a chance to add in zip write support and writing of rar formats is not possible without using the winrar program. so at best only archive formats which have open encoders (like zip) will eventually be able to have the tag written to the archive's comment directly. and yes that was read correctly, the archive tag is to be stored in the archive's comment field. i'll be creating proper documentation on how to use this along with updating the in_zip_rules.ini documentation (since that received an update two builds back)

-daz

[DrO]

just a quick one since i had an email earlier today asking about ace support and i've got it working ~80% at the moment. just having a few quirks with the file extraction (especially when the ace has the files stored in folders in it). currently it's upped the size of in_zip by ~1.5kb (64kb -> 65.5kb) which is pretty good considering i think. only downside is the 75.5kb extra dll that's needed but the installer is already setup for the handling of installing it so it's not a real issue

so that now just leaves gzip and bzip2 extraction support to implement (gzip will be a few kb increase i think but bzip2 will increase the dll by 20kb max i think though with the extra dlls, under 300k for potentially 5 mainstream archive formats ain't too bad imho )

-daz

[DrO]

in_zip v0.5.9.0 alpha

• Ace file support (not passworded files though) via unacev2.dll (included in the installer as an option)
• Adjusted the entry added to the open file dialog to take a single line for all archive types supported instead of a line per archive type (when the magic ini setting is enabled )
• Slightly altered the temp folder creation as a first step to fix the case where it can fail to create correctly at times
• Slight tweaking of the About dialog and installer to reflect the Ace support

get v0.5.9.0

Ace files are now supported (though passworded files are not at the moment). Hopefully all else with the Ace support should the same as the other formats (seems to be the case from my testing). There are probably a few tweaks that could be done to the code but as initial support goes i hope it's ok

-daz

[rejdzu]

is it possible to get tar support in this plugin ??

[DrO]

it all depends on how easy it is to build the required tar code and integrate it into the project. however i'd really need to finish implementing the gzip and bzip2 support into the plugin to make use of tar's worth it (seeing as tar isn't really a compression format but is a container instead) and to add in archive recursion seeing as a tar's are generally inside of an existing archive format.

it's something i can look into though no promises on when

-daz

[DrO]

in_zip v0.5.9.2 alpha

• Fixed the creation of the temp extraction folder to now work correctly in all cases and to be unique to prevent potential issues (should fix the issue of playback taking 2 attempts to work that has been reported)

get v0.5.9.2

This new build should fix the last of the extraction issues (had always wondered why it would occasionally not generate the temp extraction folder) and is recommended to be used if you use in_zip

-daz

[DrO]

in_zip v0.5.9.4 alpha

• Fixed a major memory bug with the 7z extraction (is safe now and will release it's memory asap)
• Made the plugin happy to work with DEP enabled

get v0.5.9.4

Was a simple bug to fix but the effect wasn't good. I've verified the other supported archive formats and they all keep the winamp vm usage at the same before and afrer a track was played through in_zip. There is an issue with the plugin's handling of mutliple files with the same filename in the same archive (since that does happen) and i'll be looking to finish the fix for that for the next version of the plugin. The need to fix the memory bug with this asap meant the file fix was not ready.

-daz

[zephirum]

did a quick read through the previous posts but not sure if someone already mentioned this.

I think the ultimate goal of in_zip is to make the archieves behave just like another folder, and therefore winamp can read through it nicely.

However at the moment, there seems to be a bit of problem with ML. Archieved music only show up in the "recent items" section of the ML.

It'd be nice if more integrations are implemented:
a) the played music can be listed in the library
b) media scan can read through the archieves and list them
c) using the ML, songs from different archieves can be easily located and played
d) on open file or open directory, archieves are listed as supported file type.

if that happens, I can finally throw away foobar2k
and embrace winamp

[DrO]

d) add exts=1 to the in_zip section of winamp.ini

the media library integration of the plugin as it stands is rather limited. psuedo tags can be held in the zips comments based on what you edit in the ml if the zip is added to the media library. the main issue is getting the zip:// entries to act like real files (as far as the ml is concerned) so metadata per file could be stored in the psuedo tag that way.
when the ml attempts to write the psuedo data for the moment in_zip will output it to the system clipboard since there's no write support implemented (would mainly be implemented for zip files). then the psuedo tag needs to be added into the archive's comment externally

-daz

[zephirum]

wow thanks for the lightening fast reply

well, I'm not too concerned with editing media info into the file in the archieve, but having the files listed in the ML and the entry links back to the file.

So I can just click on the "Artist - Song" in the ML
and winamp would go and open up the archieve and fetch me the song.

As for the editing tags, I can always unzip them, edit them, and then zip them back up again :P

[Azjo]

I havent bothered to read all of the threads but i have noticed one problem:

It does something with medialibrary so it doesnt save what songs you have listened to.
Thats all i noticed, but im sure it fucks up more in medialibrary.

[DrO]

you've lost me there since the only ml interaction is from an api that the ml/winamp queries metadata (if it's even there) from the plugin via and that's it

-daz

[hcs]

I got an email regarding in_zip and the media library, too, which didn't make any sense to me since I don't use the ml myself.
Not asking you to fix it or figure it out, but here it is anyway:

"Hi is it possible to have .rar files of usf soundtracks in winamp media library and play the entire ust soundtrack? when i have .rar files of usf soundtracks in winamp i can only play the first song (though if i press track 1 5 times i can play the first 5 tracks). That would improve your plugin so much. Winamp media library support."

[Mouser X]

While I realise all development is currently on hold, I just thought I should point this out for future referance. I've been using the most recent version of in_zip on my laptop (it's an old one that I got for free. But it works, and it was free), and it seems that in_zip doesn't work quite right. When I load an archived file (specifically RAR), it will play the first 2 files just fine, but it then skips everything past that point. I've downgraded in_zip, and it works just fine, so it's not a major complaint. I just thought you'd like to know that it's not doing what it's supposed to be doing.

Also, and I found this interesting, when I downgraded, I didn't change the old playlist (created with the most recent in_zip). When I tried to play the files, the first 2 played, but the rest skipped. When I reloaded the archive, it worked fine. That implies that there's something wrong with the playlist entries. I haven't checked this thoroughly, and I could provide more details if you want. However, since this is on the back burner, and will be for the forseeable future, I figured this is enough for now. If you need/want more info, I'll see what I can provide. Mouser X over and out.

[Mclane]

Has anyone managed to get .hes files (PC Engine music files) to work with In_zip (and in_nez obviously). For them to work they use a .m3u playlist file for the subsongs built into the single file. When I use them zipped it's picking up the .hes file and playing it but ignoring the .m3u file.

I altered the in_zip user file with a new a new rule for the hes files but it's still ignoring the .m3u file. If I open (not extract) the zip file and drag and drop both files onto Winamp then it works fine.

I just need to know if it's me not reading enough of the forums and making a silly mistake or simply that in_zip does not handle the .m3u files in the right way.

As development is halted I obviously don't expect any fixes and that's not the intention of this message, I just want to know if it's me or not..

Cheers for any help and mega thanks to Dro for the excellent plugin, it makes numerous emulated game music formats so much easier to play AND maintain.... :-)

[Mouser X]

in_zip doesn't handle the M3U files in the way you want it to (basically, it doesn't handle them at all). What Winamp does when you load an archived HES file, is it extracts the HES to a temp directory, and plays it from there. Even if you create a rule so that it extracts the HES file, and the M3U file, it won't work, because in_zip is loading the HES file, not the M3U. The data you want loaded is the M3U file, since that's where the information is stored. If in_zip loaded the M3U file, then making a rule would make a difference. I can't think of any way to make in_zip load the M3U file, instead of the HES file. So, it sounds to me like you're stuck.

While I'm here, I'd like to ask a question. Has anyone else experienced problems with in_zip v0.5.9.4 alpha? Everytime I've loaded an archive into it, it loads the first two file properly. After that, all of the playlist entries seem to be randomly generated numbers. I loaded a RAR that contained 36 valid files. It loaded about 50 entries, only 2 of which lead to files in the archives. The rest were seemingly random numbers that increased in order, but never sequentially. I had entries up to around 1200 (push CTRL+E on one of them, the number on the end is supposed to lead to a file). This is happening on my PC and my laptop (as mentioned above). If it's not the plugin causing this problem, then it must be another Winamp plugin that I have installed that's somehow interfering with in_zip. If that's the case, then it sounds like not-so-fun times ahead. Thanks in advance for anything anyone else has experienced in this matter. Mouser X over and out.

[Mclane]

Originally posted by Mouser X
in_zip doesn't handle the M3U files in the way you want it to (basically, it doesn't handle them at all). What Winamp does when you load an archived HES file, is it extracts the HES to a temp directory, and plays it from there. Even if you create a rule so that it extracts the HES file, and the M3U file, it won't work, because in_zip is loading the HES file, not the M3U. The data you want loaded is the M3U file, since that's where the information is stored. If in_zip loaded the M3U file, then making a rule would make a difference. I can't think of any way to make in_zip load the M3U file, instead of the HES file. So, it sounds to me like you're stuck.

Sorry for the late reply Mouser...

Does look like I'm stuck, I ventured over to the XMPLAY player which has Zip loading as well and it too suffers the same fate with HES files...

Oh well...One day maybe :-)

[DrO]

if you can send/link me some example files and the required dlls i can have a look at the possibility of implementing a custom mode into the plugin to handle the m3u over the hes files (with complete steps on what happens normally in a non-archive setup)

sorry for not replying to this before (and the pm) but freetime was short when you did it

-daz

[Mclane]

Originally posted by DrO
if you can send/link me some example files and the required dlls i can have a look at the possibility of implementing a custom mode into the plugin to handle the m3u over the hes files (with complete steps on what happens normally in a non-archive setup)

sorry for not replying to this before (and the pm) but freetime was short when you did it

-daz

Sent you a couple via the email addy on your webpage link.

Many thanks for having a look, I wish you success but thanks for trying whatever happens!

[DrO]

Originally posted by Mouser X
Has anyone else experienced problems with in_zip v0.5.9.4 alpha? Everytime I've loaded an archive into it, it loads the first two file properly. After that, all of the playlist entries seem to be randomly generated numbers. I loaded a RAR that contained 36 valid files. It loaded about 50 entries, only 2 of which lead to files in the archives. The rest were seemingly random numbers that increased in order, but never sequentially. I had entries up to around 1200 (push CTRL+E on one of them, the number on the end is supposed to lead to a file). This is happening on my PC and my laptop (as mentioned above). If it's not the plugin causing this problem, then it must be another Winamp plugin that I have installed that's somehow interfering with in_zip. If that's the case, then it sounds like not-so-fun times ahead. Thanks in advance for anything anyone else has experienced in this matter. Mouser X over and out.

with some much appreciated help from mouser x the issue came down to reading the titles on playlist load and an errornous incremention of one of the internal variables which is responsible for the index entry on the end of the zip:// entries. removed that (since it wasn't needed anyway) and now it's all working correctly from the irc message i saw from mouser x. so a big thanks to him in helping to point out and help in the testing of this issue

a 0.6 build is in the works at the moment which is to bring the plugin up to compatability with the unicode changes in the next feature release of Winamp (means i've been able to test the new interfaces and so far it all seems to be working well ). there's also been a number of other code improvements including better handling of failed extractions or trying to play a zip:// entry which just doesn't exist (which came up from the issues mouser x had been having). i've got to finish adding in a configuration dialog for setting which filetypes can be associated instead of having to mess around in winamp.ini to hard code in the current defaults (which isn't ideal).

so a new version should be out soon (though i've not had a chance to look at the hes/m3u request yet) which i'd expect some minor issues at most due to the large number of code changes that have been made (though personally the code seems to be working better than what was in the 0.5.9.4 build so i don't know, heh)

-daz

[DrO]

in_zip v0.6.0.0 'Mouser X Edition' alpha

• Changelog to follow, basically fixes for 5.25+ (to test the new unicode handling) and general improvements in extraction support, etc so this build should be better than the older 0.5.9.x ones

get v0.6.0.0

Big thanks goes to Mouser X who's helped in the last few days to test, provide bug reports and then to confirm the fixes so here's a build for you

There will be a newer build possibly tomorrow which adds in a basic config dialog (assuming i remember to bring the copy of that code home as i've failed for the last 2 nights ) so that you don't have to set a winamp.ini setting to associate archives to winamp/the plugin and also you'll be able to specify what files are associated along with the option to remove the root archive entries once the zip:// entries have been added to the playlist (add rem_zip_root=1 to the [in_zip] section of your winamp.ini for the time being)

-daz

[Mclane]

Cheers Dro...

Hope you get a chance to sort out the hes m3u issue out at some point but till then, its a big thanks..

[DrO]

i've not had a chance to properly work out the best way to handle the m3u extraction (was aiming to do it for this release but due to trying to fix compatability issues with 5.25 it got dropped).

-daz

[Mclane]

No probs...

If it happens I'm over the moon as they say, if not then I still have a bloody good little plugin for Winamp..

Either way I win :-)

Cheers Daz.